Improving the offline updates user experience
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
concern for their data or a corporate policy mandating full-disk
encryption. Disk encryption requires a password (or other more
complicated credentials) be be presented just after the kernel is
booted and before the drives can be mounted and their data read.
With the current implementation of the offline updates in Fedora, this
leads to a very unpleasant user experience when updating. We offer two
ways to perform offline updates in the default user environment of
Fedora Workstation: "Install updates and reboot" or "Install updates
and shut down".
With "Install updates and reboot", the behavior is as follows:
1) The system shuts down and initiates an ACPI reboot.
2) The system presents the kernel boot menu and then starts the
updater kernel.
3) The system presents the user with a password prompt for the disk
encryption (possibly more than one, if the system is configured with
different passwords for different partitions).
4) The offline updates occur.
5) The system shuts down and initiates an ACPI reboot.
6) The system presents the kernel boot menu and then starts the
standard (possibly updated) kernel.
7) The system presents the user with a password prompt for the disk
encryption (possibly more than one, if the system is configured with
different passwords for different partitions).
8) The system completes booting.
During this experience, the user has been required to enter their disk
encryption password *twice*. The same is true for the "Install and
shut down" case, except that the two passwords are separated by some
actual wallclock time.
== Proposed Improvements ==
We could significantly improve this situation by allowing the system
to drop directly from the interactive system into the updater
environment without doing a full reboot or relaunching the kernel.
Lennart, would it be possible to set up a special systemd target for
performing updates that would essentially stop all processes except
for systemd and then apply the updates?
In an ideal world, it would then also be possible after update is
completed to restore operation to the standard boot targets of systemd
so that the system comes back up without having to perform a total
reboot. The exceptional case would of course be that in which either
the kernel, libc or systemd[1] needed to be updated, in which case a
reboot could be performed.
In this scenario, we can reduce the number of encrypted disk
challenges to at most a single one, and that only if absolutely
minimal plumbing packages saw an update.
I'd very much like to hear from the plumbers on this matter.
[1] I'm told that this might not be necessary; that systemd can
re-exec itself to pick up its own updates. That would reduce the scope
presumably to "only the kernel" forcing reboots.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQTB1YACgkQeiVVYja6o6MvpgCeLbkWSgY5XGI4nJg3skjyu8v+
nQUAoIyvNHpJ8SRytPPKGZ3C8kZ560J9
=zZ+N
-----END PGP SIGNATURE-----
9 years, 5 months
Re: Broken dependencies: freesteam
by Antonio Trande
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all.
On 08/25/2014 01:39 PM, buildsys(a)fedoraproject.org wrote:
> freesteam has broken dependencies in the F-21 tree: On x86_64:
> freesteam-ascend-2.1-6.20140724svn753.fc21.x86_64 requires
> libascend.so.1()(64bit) On i386:
> freesteam-ascend-2.1-6.20140724svn753.fc21.i686 requires
> libascend.so.1 On armhfp:
> freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires
> libascend.so.1 Please resolve this as soon as possible.
>
buildsys(a)fedoraproject.org sends me above message via mail.
It's okay to me:
$repoquery -R freesteam-ascend --enablerepo=updates-testing
ascend-libs(x86-64)
freesteam(x86-64) = 2.1-6.20140724svn753.fc20
libascend.so.1()(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libfreesteam.so.1()(64bit)
rtld(GNU_HASH)
$repoquery --whatprovides libascend.so.1*
- --enablerepo=updates-testing --archlist=x86_64
ascend-libs-0:0.9.8-10.20140710svn4695.fc20.x86_64
I don't know what's the problem...
- --
Antonio Trande
mailto: sagitterATfedoraproject.org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: D400D6C4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJT+y1PAAoJED2vIvfUANbEv/cP+QG2OQj6MBAeg0C7WowrrOqU
n7x789PtBZnxpkOiIvItqyL/Tm4Mg0W7u3ylQpcXzSYRnhyQtNQQfFzEL+EiPWRX
Vm12tTtjyqSgYC3A3fY5ycIHlLz1IhbmNV9Rd8oSWc7CVLOiADat1ocWrhm+1xN7
2sC2scpCvVaJXxOh3j/4WaStmHxANUShTeTIV5e6AKpMx3RGBTgSRdeXqN4zu5uG
zJ4tzzodQKv4R510oSlsKotuY2apP3ccpqq0DrGIExXsMvSd3DbQxT7qK4GPoaOj
mfXaxW1dZMsJ8HaTXJVwj71aUqaG4k4XIE1izx8RRwR9/OuHshxGh24cGuGIuE65
Q+QHArIKAioZvCLURJfZZUG/ODaOzVNvYK9FK91E6WDsTD0cy3KUWf8DSoGyy1Je
DQ0WTc24wfoN8V27h0/alxw8v1jI8eKbY+0hJBc0OaKQ14VBKfHczgkRjSFHoqeJ
xeqp74D2wnmaty4AM119oaCO5g0rVJooVXUgsdFvERDby2Bb5lGCv/a2dZ6e+Y0q
C2nGmL5sTN+wBHwHi2JejbdHKh6mSL9JyXf7YouRkPs1GuuOfed0IpSHKRKLcsB0
Syej5dVc1qXq34Gnf1kviifVmZHFEW/bkNC3nxNUOLO/foOqfaeQUx8dByXgb0tQ
vmGe4BAmbVKVHOKOqJRl
=g0XH
-----END PGP SIGNATURE-----
9 years, 6 months
Future changes in the new package and new branch processes
by Pierre-Yves Chibon
Dear all,
In the last months, Till and I together with infrastructure and
release-engineering have been thinking and working on how we could improve the
current workflow for new package and new branch.
To give you an idea, this is the current workflow:
Current new-package procedure:
==============================
* packager opens a review-request on bugzilla
* reviewer sets the fedora-review flag to ?
* reviewer does the review
* reviewer sets the fedora-review flag to +
* packager creates the scm-request and set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager, check if reviewee
required a sponsor or not, check if there was a review)
* cvsadmin processes the scm-request:
- Create git repo
- Create package in pkgdb
* cvsadmin sets fedora-cvs flag to +
We thought that a number of these steps could be automated. For example,
creating the git repos themselve could be automated using information from pkgdb.
Our idea has been to port part of this procedure to pkgdb itself.
This is our proposal:
New procedure
=============
* packager opens a review-request on bugzilla
* reviewer sets the fedora-review flag to ?
* reviewer does the review
* reviewer sets the fedora-review flag to +
* packager goes to pkgdb2 to request new package and specifies:
- package name
- package summary
- package branches
- link to review on bugzilla
=> requests added to the scm admin queue
* cvsadmin checks the review (check reviewer is a packager¹)
* cvsadmin approves the creation of the package in pkgdb
=> package creation broadcasted on fedmsg
* git adjusted automatically
What are the main changes:
- More work for the packager that asks for the package to be created directly
in pkgdb instead of using the SCM request mechanism in bugzilla
- No more use of the fedora-cvs flag in bugzilla
- Simplied work for releng that just checks the review and approves/denies in
pkgdb
Similarly, for new-branch:
Current new-branch procedure:
=============================
* packager find the original package review ticket / opens a new ticket
* packager make the change request and sets fedora-cvs flag to ?
* cvsadmin checks the request/package (check if user is a packager, check if
package exists in the RHEL for EPEL branch request)
* cvsadmin processes the scm-request:
- Adjust git repo
- Adjust package in pkgdb
* cvsadmin sets fedora-cvs flag to +
New new-branch procedure:
=========================
* packager requests new branch in pkgdb (2 clicks)
=> requests added to the scm admin queue
* cvsadmin checks the request/package (check if package exists in the RHEL for
EPEL branch request - check if the user is a packager done in pkgdb itself)
* cvsadmin approves the creation of the new branch in pkgdb
=> branch creation broadcasted on fedmsg
* git adjusted automatically
Currently, we are working towards these workflows but of course they are not
set in stone and we would like to discuss them as early as possible to be sure
we're not going in a completely wrong direction.
Thanks for your feedbacks,
Pierre and Till
¹ We should be able to automate the check if the reviewee/reviewer are
packagers or not.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 6 months
Go packaging
by Richard Henderson
I'm working on enabling Go on systems without golang support, but for which the
gccgo compiler works.
But in order for this to work, there needs to be some amount of coordination
with the regular golang package, the spec files of binaries written in go, and
the golang-*-devel packages.
(0) I start with a "go" driver program that is built with, and defaults to
building with, the gccgo compiler. I.e. -compiler gccgo is the default. I've
called this package "go-gccgo", for lack of a better name.
(1) I was disappointed to discover that all of the -devel packages depend on
golang. That meant that when I wanted to uninstall golang on my test system
and install my go-gccgo package, all of the development libraries were
uninstalled too. This seems silly, because the -devel packages don't *really*
depend on golang, any more than glib2-devel depends on having gcc installed.
I think that removing this unnecessary dependency can happen independent of any
other change we can make.
(2) We need some rpm token to coordinate the version of the Go language that
the installed compiler. Currently the packages check "golang >= version", but...
(3) The golang and go-gccgo packages probably ought to conflict, since both
contain a /usr/bin/go. I don't see using alternates as terribly useful here,
and anyway there may well be a Go language version conflict from (2) between
the two compilers. Certainly for f21, golang is v1.3.1, but gcc 4.9 supports
go v1.2.
(4) For packages that build binaries written in go, like docker, we need an rpm
macro to say whether we expect to build with gccgo or gc. The command line
options for the two compilers are not compatible, and so the %build section of
the spec file needs to be adjusted (sometimes trivially, sometimes not).
I'm currently defining %use_gccgo in the /usr/lib/rpm/macros.d/macros.golang
file installed with my go-gccgo package.
(5) There's currently a %go_arches macro that specifies those arches to which
golang is ported. If go-gccgo exists, is this macro actually useful anymore?
r~
9 years, 6 months
Agenda for Env-and-Stacks WG meeting (2014-09-16)
by Honza Horak
WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston,
22:00 Tokyo) in #fedora-meeting on Freenode.
= Topics =
* Language specific mirrors for Fedora Playground compliant packages
* SCLs, building above them and their position in Fedora/EPEL
* Picking chairman for the next meeting
* OpenFloor
9 years, 6 months
How to handle upgrades to Fedora 21
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There has been some discussion in various forums lately about how we
will handle fedup upgrades from Fedora 20 to Fedora 21 products.
Several suggestions have been made that warrant discussion:
* Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.
* Upgrades from Fedora 20 become Fedora Workstation systems and have
the appropriate environment group installed on them. This mechanism
will not remove any existing packages.
* Fedup should provide a selection for which Product (or
non-productized) version to upgrade to.
I am personally opposed to forcing all upgrades to become Fedora
Workstation (even if in general the majority of existing deployments
are desktop/laptop machines).
I think either the first option (easy) or the last option (requiring
fedup changes) will be preferable. In the selectable case, I think
that fedup should operate as a non-productized upgrade unless
otherwise specified at the command-line. If we pass --server,
- --workstation, --cloud, it should upgrade existing packages as well as
installing the complete set of the @^fedora-$PRODUCT-environment comps
environment group.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf
cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd
=U4A7
-----END PGP SIGNATURE-----
9 years, 6 months
Proposal: Increasing application icon sizes to 64px
by Richard Hughes
At the moment applications have to provide an icon >= 32x32px in size
to be included in the AppStream metadata and shown in the software
center. This is *tiny* on a HiDPI screen, so should I mandate that all
applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for
the shell and gnome-software, or should I just pad+scale icons for the
HiDPI case and make them look ridiculous?
I don't think we can, or should, design a software center to accept
the lowest common denominator when it comes to icon sizes; we're doing
really well now with AppData coverage[1] and I think we can raise the
quality of upstream and packaged icons in the same way.
My proposal would make 64x64 the smallest icon size we show in the
software center, and this will still be slightly blurry[2] in the
HiDPI case. This would affect 539 (over half of all desktop
applications) packaged in Fedora. It's clear we can't just do nothing,
as more and more devices will have HiDPI screens, and more and more
icons will look crazy small and fuzzy.
I don't think it's a good idea to mass-file 539 bugs, nor do I want to
contact 539 upstream maintainers. 127 packages only ship a 32x32 icon,
and that might be a good starting point for contacting upstreams or
filing bugs.
Ideas? Comments? Affected packages attached as a text file.
Richard
[1] http://blogs.gnome.org/hughsie/2014/09/25/appstream-progress-in-september/
[2] https://ryanlerch.fedorapeople.org/software-blurry2.png
9 years, 6 months
