devel September 2014

devel@lists.fedoraproject.org

187 participants
232 discussions

The Shimmer Project - Desktop Suites & GTK+ 3
by poma 07 Nov '14

07 Nov '14

Hi Fi fratelli artisti! Guys, please consider to update these three super duper very cool mega awesome themes, Albatross http://shimmerproject.org/project/albatross Bluebird http://shimmerproject.org/project/bluebird Greybird http://shimmerproject.org/project/greybird Here are the patches that I use, Albatross https://bugzilla.redhat.com/attachment.cgi?id=935301 Bluebird https://bugzilla.redhat.com/attachment.cgi?id=935304 Greybird https://bugzilla.redhat.com/attachment.cgi?id=935217 and why are these patches needed http://goo.gl/Ye23cM Thank you for maintaining this three super duper very cool mega awesome themes! :) poma Ref. https://bugzilla.redhat.com/show_bug.cgi?id=1114161

3 15

Improving the offline updates user experience
by Stephen Gallagher 06 Nov '14

06 Nov '14

-----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-----

32 78

Firefox Gtk3 test package
by Martin Stransky 06 Nov '14

06 Nov '14

Hi guys, first $SUBJ is available at: http://stransky.fedorapeople.org/FirefoxGtk3/ It's just a src.spm and plugin support it not finished (don't browse youtube ;-)) but may work as a preview. I'll provide Fedora builds and repo later. ma.

18 58

Re: Broken dependencies: freesteam
by Antonio Trande 16 Oct '14

16 Oct '14

-----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-----

2 2

Future changes in the new package and new branch processes
by Pierre-Yves Chibon 13 Oct '14

13 Oct '14

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

10 21

Go packaging
by Richard Henderson 11 Oct '14

11 Oct '14

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~

7 18

Agenda for Env-and-Stacks WG meeting (2014-09-16)
by Honza Horak 07 Oct '14

07 Oct '14

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

1 3

Intent to update libinfinity to 0.6.1 (soname bump)
by Till Maas 06 Oct '14

06 Oct '14

Hi, I would like to update libinfinity to 0.6.1 where possible. I prepared a copr build at: https://copr.fedoraproject.org/coprs/till/gobby05/ I did not yet test whether the gedit or kte plugins rebuild properly, but I will do so before updating Rawhide. Regards Till

3 8

How to handle upgrades to Fedora 21
by Stephen Gallagher 06 Oct '14

06 Oct '14

-----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-----

23 54

Proposal: Increasing application icon sizes to 64px
by Richard Hughes 02 Oct '14

02 Oct '14

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

17 42

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2014