devel July 2017

devel@lists.fedoraproject.org

213 participants
267 discussions

RFC: Always sourcing /etc/bashrc for interactive mode in bash
by Siteshwar Vashisht 10 Oct '17

10 Oct '17

We are discussing about always sourcing /etc/bashrc for interactive mode in bug 1193590 [1]. Currently /etc/bashrc is sourced by user's bashrc script and if a user forgets to source it, some of the default configurations will not be set (for e.g. see bug 1390780 [2]). I am pondering over the idea to source /etc/bashrc by default (see commmit at [3]) and fix current /etc/bashrc script to avoid double sourcing [4]. This change may cause undesirable effects if a custom /etc/bashrc is prone to double sourcing and might break some systems. Any comments about this change are welcome. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1193590 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1390780 [3] https://github.com/fedora-testing/bash/commit/87ac935a6643a9afee44a95757714… [4] https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20 -- -- Siteshwar Vashisht

2 2

SELinux policy contibutions
by Robert Marcano 07 Oct '17

07 Oct '17

Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib the right place to contribute to the Fedora SELinux policy? I added a pull request for a small update needed for a new release of cups-pdf, but I am not sure someone is monitoring that. There is another one from rhatdan there so I presume is the right place.

5 5

Nonresponsive maintainer: attempting to contact kanarip
by James Hogarth 05 Sep '17

05 Sep '17

Hi, Has anyone heard from kanarip or able to contact him? I've been attempting to contact for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1223593 If there's no response in one week an issue will be filed with FESCo following the nonrepsonsive maintainer policy to review the ownership status of the packages. For ruby maintainers please note that this has a significant impact on you, if you want to keep track of this, as he owns puppet, rubygems and ruby ... https://admin.fedoraproject.org/pkgdb/packager/kanarip/ Regards, James

4 8

Non-responsive maintainer process for caillon, and retiring xchat
by Debarshi Ray 04 Sep '17

04 Sep '17

Hello everybody, I would like to initiate the non-responsive maintainer process [1] for Christopher Aillon [2]. A long time ago, he used to be part of the Fedora and Red Hat desktop teams. He is no longer around. He left software development and was last seen living off the grid in Hawaii [3]. Therefore I have jumped straight to the fourth step in the aforementioned process. Here is a list of his packages: https://admin.fedoraproject.org/pkgdb/packager/caillon/ I am particularly interested in xchat, which I want to retire right after removing Chris as the point of contact for his packages. HexChat [5] is the natural replacement of XChat these days. XChat is dead [6] - the last upstream release was seven years ago [7]. On the other hand, HexChat has been a part of Fedora for the last four years, upstream [4] is involved in both the Fedora [8] and GNOME communities, and I learnt that the MATE spin already ships it by default. For what it is worth, this was already discussed and approved on desktop(a)lists.fedoraproject.org [9]. Cheers, Rishi [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers [2] https://admin.fedoraproject.org/accounts/user/view/caillon [3] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… [4] https://admin.fedoraproject.org/pkgdb/package/rpms/xchat/ [5] https://hexchat.github.io/ [6] https://en.wikipedia.org/wiki/XChat [7] http://xchat.org/ [8] https://fedoraproject.org/wiki/User:Tingping [9] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o…

3 6

No i686 kernel: Can we require SSE2 for i686?
by Florian Weimer 28 Aug '17

28 Aug '17

I ran into this unannounced change: https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels If this is accepted, all x86 hardware on which Fedora can run will support SSE2, and we should reflect that in the i686 build flags. How likely is it that this proposal is accepted? Ideally, we would know this before the mass rebuild so that we can change the compiler flags in redhat-rpm-config. Thanks, Florian

37 96

ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
by Moez Roy 24 Aug '17

24 Aug '17

ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev) Sources were last updated 2016-01-06 13:43:26 - https://koji.fedoraproject.org/koji/packageinfo?packageID=425 Since then there have been numerous security vulnerabilities including ImageTragick. I commented here: https://bugzilla.redhat.com/show_bug.cgi?id=1299275#c153 that "Many security bugs were closed automatically when F23 went EOL. Those are the only 2 versions supported upstream @ https://www.imagemagick.org/download/linux/CentOS/x86_64/ "

12 23

Removal of code signing trust bits from ca-certificates
by Kai Engert 23 Aug '17

23 Aug '17

Until recently, Mozilla maintained three individual trust bits for each root CA certificate: - trust for TLS servers - trust for email security - trust for code signing The next CA update from Mozilla will switch the code signing trust bit OFF for all CAs. Mozilla will no longer maintain this trust bit. See https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRR… for background. I'm not aware of anyone using this trust bit. The removal might have no effect. This update of the CA list is supposed to get published with Firefox 56 on September 26. In order to allow the Fedora community to test potential effects of this change, I intend to publish an update to the ca-certificates packages early, and keep it in updates-testing for a few weeks. Tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1472468 Thanks Kai

2 2

PkgDB and the ArbitraryBranching Change
by Ralph Bean 20 Aug '17

20 Aug '17

Hello, As part of the Factory 2.0 and Modularity efforts[1], we’ve been developing a plan to migrate to an “arbitrary” branching model from our current model of one branch per release (as had been discussed at Flock and DevConf[2]). The main motivation behind this is to enable functionality required by Modularity[3] and to ultimately reduce some package maintenance burden. For some packages, it makes sense to have only a single branch that feeds into multiple releases. For other packages, it makes sense to have multiple branches which correlate with multiple upstream minor releases. Today, our source branches are tied to the distro release, via PkgDB. We want to decouple that and use modules to put it all back together again. To make this happen requires significant infrastructure changes. Our proposed plan[4] is to decommission PkgDB entirely and to replace it with a combination of PDC[5] and pagure over dist-git. (Tangentially, getting pagure over dist-git to play nicely with PkgDB was a challenge. This route gets us to a pull-request interface for spec files quicker.) We have brought this Change to FESCo[6][7][8] who expressed general agreement on the project but also concern that the community may be caught by off guard by the removal of PkgDB. As part of this change, we have proposed a timeline[9] that outlines the steps we plan to take to actually proceed with the migration. Please review that if you have time and provide feedback. We are most concerned with missing scripts/tools that may rely on PkgDB’s API. If you can think of any that we may have overlooked, please let us know and we will add it to the timeline! We are meeting again with FESCo next Friday, June 2nd, where a decision will be made on the Change. Any feedback before that would be greatly appreciated. Ralph and Matt, From the so-called Factory 2.0 team [1] https://fedoraproject.org/wiki/Infrastructure/Factory2 [2] https://youtu.be/5gqccjyjwFk?t=26m27s [3] https://docs.pagure.org/modularity/ [4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranc… [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching [7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html [8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html [9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

15 27

debuginfo/source improvements vs mass rebuild
by Mark Wielaard 19 Aug '17

19 Aug '17

Hi packagers, Just before the mass rebuild some debuginfo/source improvements were enabled by default (%_debugsource_packages and %_debuginfo_subpackages). See https://pagure.io/releng/issue/6863 and https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo for some background. It didn't cause mass breakage, but there were some issues. Sorry about that. The good news is that we now have fixes (or workarounds) for the bugs found. So hopefully if your package did fail to rebuild you can just resubmit it again or add a small tweak to get it building. Here is an overview of the issues you might have seen and how it was resolved (and a few questions on what the proper default/workaround/fix should be in some cases). = -debugsource generation fails with error: Could not open %files file This was caused by the package changing the working directory in % install. Fixed upstream and backported to rpm-4.13.0.1-38. Please just rebuild your package. = -debugsource generation fails with error: Empty %files file Caused by rpm/find-debuginfo.sh/debugedit being unable to find any source files for the generated .debug files. This could be seen as a packaging bug. Most likely caused by missing -g in the package build flags. But the old non-split debuginfo/source generation would silently accept an empty debug source list. So there is an upstream patch to just create an empty -debugsource package in that case (and generate a warning): http://lists.rpm.org/pipermail/rpm-maint/2017-July/006098.html Upstream indicated they would rather not generate a -debugsource package at all in that case (which seems hard, but maybe I didn't try hard enough) or to just treat it as a hard error (also for the non-split case). = Using %excludes resulted in error after generating -debuginfo: error: Installed (but unpackaged) file(s) found: /usr/lib/debug/bin/hello3-1.0-1.x86_64.debug Fixed upstream and backported to rpm-4.13.0.1-39 Please just rebuild your package. = Using RemovePathPostfixes failed after generationg -debuginfo: error: Installed (but unpackaged) file(s) found: /usr/lib/debug/bin/hello.foobar-1.0-1.x86_64.debug Fixed upstream and backported to rpm-4.13.0.1-39 Please just rebuild your package. Note that in both of the above cases in the old situation your -debuginfo package would contain .debug files for executables not installed by the main package... With the fix, in case you use split-debuginfo (the default) these aren't included anymore making the debuginfo packages smaller. = No .gdb_index in .debug files. Caused by missing %_include_gdb_index macro in redhat-rpm-config https://bugzilla.redhat.com/show_bug.cgi?id=1476722 This used to not be easily configurable. Now it is. But we got the default wrong. If you like to have .gdb_index sections right now then add %global _include_gdb_index 1 to your spec file. Or wait till fedora-rpm-config has been updated. - Putting extra files under /usr/lib/debug causes: error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-1.pyc /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-2.pyc /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.pyc /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-1.pyc /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-2.pyc /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.pyc /usr/lib/debug/usr/lib64/libpython3.6dm.so.1.0.debug-gdb.py /usr/lib/debug/usr/lib64/libpython3.6m.so.1.0.debug-gdb.py https://bugzilla.redhat.com/show_bug.cgi?id=1476593 This is caused by split debuginfo checking which file corresponds to which main/sub-package. Without split debuginfo anything found under /usr/lib/debug is just put into the -debuginfo package, no questions asked. The immediate workaround is to add the following to your spec file: %undefine _debuginfo_subpackages This disables split debuginfo packages and just generates one big -debuginfo packages with everything under /usr/lib/debug/ included. But this might or might not be a packaging bug. In particular if it contains generated pyc files those probably really shouldn't be there. The basic issue is that we have been trying to make the debuginfo packages self-contained and non-conflicting between versions. So you can easily install debuginfo for different (bi)arches or versions. But some packages assume that if they drop anything under /usr/lib/debug it will just magically appear in the debuginfo package (which has been historically true). But with the split debuginfo we have to make a choice which subpackage it belongs to. Best rpm fix would probably be to add such files to the "main" debuginfo package. But it would probably be better to move these files to the python3-devel package. Maybe we should discuss with the gdb maintainers how/where they would like to see these gdb python extensions installed. I doubt the -debuginfo package really is the place for them anyway. = Packages that already create sub-debuginfo or split-debugsource packages by hand probably will fail with an error similar to the above (Installed (but unpackaged) file(s) found). Please add either (or both) to your spec file: %undefine _debugsource_packages %undefine _debuginfo_subpackages But we would like to know if that is necessary. Please file a bug report against rpm in fedora bugzilla and we'll take a look to see if we can help use the fedora rpm defaults in your .spec file. Cheers, Mark

3 3

Blocker bug process proposal: waiving late-discovered blockers to next release
by Adam Williamson 18 Aug '17

18 Aug '17

Hi, folks! So, during the blocker review process in the last few cycles, we have several times come up against the unfortunate situation that a bug that in the usual course of events would block a release is discovered extremely late - say the day before the go/no-go meeting - and at least some folks have argued that it's sometimes appropriate to not block the release in this case. This position has gained quite a bit of acceptance, and we agreed at the F26 Final go/no-go meeting to draft up some formal policy for this so we can make such decisions consistently and not in an ad hoc way that might lead to it becoming a loophole that gets abused. So, here's my proposal for that. The actual guts of the 'review blockers' process are kind of split between https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , so we could kinda document this in either, but my preference is for the former. I propose we add a new section to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , called 'Exceptional cases' or similar, as a sub-section of the 'Reviewing blocker bugs' section. This is my proposed text. Note that it also covers another type of case we have occasionally come across in the past, but similarly never specifically formulated. ################## === Exceptional cases === Generally speaking, any bug that is agreed to be a violation of the [[Fedora Release Criteria|release criteria]] should be accepted as a blocker bug for the next relevant milestone release. However, as explained in the [[Fedora_Release_Life_Cycle|Fedora life cycle page]] and the [[Fedora_Release_Criteria#Release_Constraints|release criteria]], we consider Fedora's release process not to be strictly based on time ''or'' strictly based on quality, but to take both into consideration. This can mean that, in some exceptional circumstances, we may agree that a bug constitutes a sufficient violation of the release criteria that it would ordinarily be accepted as a blocker bug for the next milestone release, but in fact accept it as a blocker bug for a later milestone release. There are currently two established circumstances in which this may occur. Firstly, it may occur if it is agreed to be very unlikely that the bug can possibly be fixed within a reasonable time frame for the release to be made. For instance, fixing the bug may be a task of such technical complexity that it cannot possibly be achieved for several weeks or months, and it may be held that such a delay would be too disruptive to Fedora's development to be justified. Secondly, it may occur if the bug is discovered very late in the release validation process. Sometimes, a relatively less important blocker bug (such as a non-vital default installed application on a release-blocking medium failing to run, for instance) may only be found very near the end of the release validation process, too late for it to be reasonably possible to fix it without delaying the release. Again, we may make the determination that in such a case it is preferable to go ahead with the release rather than delay it to fix such a late- discovered bug. All such cases must be evaluated and discussed by the usual parties (usually at a blocker bug review meeting) and all relevant factors must be taken into account, much like the discussion of a bug that is a 'conditional' violation of the release criteria. At least the following will almost always be relevant: * The severity and likely prevalence of the bug * Whether the bug could, or should, have been discovered earlier * How long the release in question has already been delayed * Whether delaying the release may give us an opportunity to carry out other desirable work * The possible effects of the expected delay (to Fedora itself, and also to other things influenced by Fedora's schedules, including downstream projects) It is expected that in almost 'exceptional' cases, the bug will be accepted as a blocker either for the very next milestone release, or for the equivalent milestone for the next release (e.g. if this 'exceptional' provision is agreed to apply to a bug that otherwise would have blocked {{FedoraVersion|long|next}} Final, it should be accepted as a blocker either for {{FedoraVersion|long|next2}} Alpha or {{FedoraVersion|long|next2}} Final). ################# That's a bit wordy (suggestions for cutting it down are appreciated!), but I think it covers all the salient points. Thoughts? Concerns? Suggestions? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

7 18

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2017