devel March 2012

devel@lists.stg.fedoraproject.org

288 participants
310 discussions

RFC: Primary architecture promotion requirements
by Matthew Garrett 25 Apr '12

25 Apr '12

This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. ------------------------------------------------------------------------- Secondary architectures in Fedora are subject to looser constraints than primary architectures for two primary reasons: 1) To make it easier to bootstrap an architecture without the overhead of the primary architecture release engineering process 2) To avoid primary architecture development being held up by poorly developed or niche architectures Promoting an architecture to primary architecture status is a significant responsibility. It implies that the port is sufficiently mature that little in the way of further architecture-specific changes or rebuilds will be required, and also that it has enough development effort to avoid it delaying the development of other primary architectures. Further, it means that the architecture becomes part of the overall Fedora brand. Fedora is an integrated Linux distribution rather than a technology collection, and as such there are various expectations that the overall Fedora experience will be consistent over all primary architectures. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: 1) There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. 2) All builds must occur on Fedora-maintained build servers. 3) Where technically possible, all supported hardware targets must be supported via Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for simultaneous support of install and target media. 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. 5) Sufficient developer resources must be available to fix any architecture-specific issues in such a way that they do not delay overall Fedora development. 6) It must be possible for maintainers of critical-path hardware dependent packages to have direct access to supported hardware in order to rectify any release-blocking issues. For example, X maintainers must have direct access to any hardware with graphics capabilities. 7) The port must not rely on sourceless binaries unless they fall under the generic firmware exemption. Where source and toolchain are available, the binaries must be built in the Fedora build infrastructure. As such, promotion to primary architecture status will require agreement from the Fedora infrastructure, release engineering, kernel and installer teams and is subject to overall approval by the Fedora Steering Committee. -- Matthew Garrett | mjg59(a)srcf.ucam.org

41 182

F17, firewalld, avahi
by Chris Murphy 20 Apr '12

20 Apr '12

Fedora-17-Beta-x86_64-Live-Desktop.iso http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. "The configuration tool firewall-config is the main configuration tool for the firewall daemon." But I'm not finding firewall-config. So unlike with iptables, where I had a GUI Firewall app, now I no longer have an easy or obvious way of altering the default behavior and I'm in effect stuck without ssh. Seems the missing firewall-config is probably an oversight, and it needs to be included on LiveCD installs, and default DVD installs as well. Chris Murphy

9 18

Intent to retire: mod_python
by Joe Orton 19 Apr '12

19 Apr '12

mod_python upstream has been inactive for five years, since Graham Dumpleton went to work on mod_wsgi. IMO it is long past time to retire mod_python in Fedora. But the following packages still depend on it: Source : glump-0.9.11-10.fc17.src.rpm Source : koji-1.6.0-3.fc17.src.rpm Source : viewvc-1.1.13-1.fc17.src.rpm Source : yawn-0-0.3.20120227svn561.fc18.src.rpm I haven't checked whether these are simply to convert over to WSGI or not. Does anybody want to maintain mod_python? If not, I'm going to retire it. Regards, Joe

3 3

Dependencies on Bodhi Updates
by Stephen Gallagher 18 Apr '12

18 Apr '12

As requested during the FESCo meeting, I am going to try to summarize some of the issues inherent in the way that Bodhi updates currently work. First, I'll try to explain the goals and constraints: 1) The stable 'fedora-updates' yum repository should NEVER exist in a state where any package has dependency issues. In other words, it should never be possible for an update to be pushed to stable that breaks cleanly updating any other package. 2) Updates must be possible and (ideally) timely. This is probably self-evident. 3) Packages pushed to the stable 'fedora-updates' yum repository should (ideally) not introduce regressions in packages that depend on them. 4) New features in "superpackages" such as Firefox, GNOME or FreeIPA that have many and varied dependencies may require new features in packages they depend on in order to enhance or fix the superpackage. In the trivial example, a package (let's say libtalloc) needs to make an update to fix a bug. This package requires nothing new from its dependencies and is a self-contained fix. For this example, it is simple to just build libtalloc in koji and then create a Bodhi update and pass it through "updates-testing", get karma and *poof* off to "fedora-updates". Now let's extend the example. Suppose that we have another package libtevent that has libtalloc as a dependency. Libtevent's maintainer wants to add a new feature to libtevent, but the patch from upstream depends on the bug in libtalloc having been fixed in order for the new feature to work properly. In this situation, the maintainer of libtevent would build libtevent with an explicit Requires: libtalloc >= <version> in the specfile (possibly pulling libtalloc into the BuildRoot overrides if necessary) and then test it locally to see that it works. So now we have our first updates dependency issue. If we submit libtevent as its own update, it is possible that it will achieve its karma requirement before libtalloc does. It would then be pushed to the "fedora-updates" repository and then introduce a dependency issue in the stable repository (because users trying to update libtevent would be unable to update libtalloc without enabling the updates-testing repository). The current recommended approach is to bundle the two updates into a single one carrying multiple packages. The first problem with this is that you must have commit privilege on all packages that you are bundling into an update. If you do not, then you need to track down a provenpackager to do it for you. Now let's make the problem even more fun. Consider that the update to libtevent might be coming in because it is necessary for a new feature in libldb, which is in turn providing new functionality necessary for SSSD. So now we have four packages all sitting in the same update. The problem with this is that the tendency will be to only test the most user-visible package(s) in the set. In this particular case, that might be SSSD. So people would likely test SSSD and, if nothing went wrong, consider the entire update stable. But wait! SSSD isn't the only package that depends on libldb, libtevent and libtalloc. So too does the samba package. Suppose that the bugfix in libtalloc, after resolving the original issue, results in exposing another more serious bug in samba? Now we need to pull a samba update into this same update series. A contrived example, you say? That would never happen, bugfixes aren't likely to do that. Well, for one example: https://admin.fedoraproject.org/updates/FEDORA-2011-11845 In this particular example, we knew up-front that it was going to necessitate a rebuild of several dependent packages and we coordinated a single release to address them. So in this case, the proper approach was to bundle them together in a single update. This worked because we specifically knew that the libtevent change was going to break other packages. But what about when we don't know that? Let's take another example: https://admin.fedoraproject.org/updates/FEDORA-2011-17399 In this case, there was a security bug reported against Firefox. Such things are serious, and acted on quickly. However, the bug was actually fixed in the nss package, and Firefox, Xulrunner and friends were rebuilt against that nss package. The problem was this: the fix made to the nss package introduced regressions in every other package that depended on it. However, because the default install of Firefox contained no issues, it rapidly received the necessary karma points and the whole update was pushed to stable. It then broke nearly every application in Fedora that relied on cryptography. The problem here was sociological, not technological. The only package that received testing was Firefox. It's hard to say without evidence whether the problem would have been averted by having nss go through its own update, but I strongly suspect that what we would have seen was greater testing on actual nss features for that specific update. Of course, we now have the same potential for an issue that I described above: If we had separate updates for nss and for Firefox, chances would be highly-likely that Firefox would be pushed to stable via karma points rapidly, whereas nss (which requires much more careful testing) might be left behind in updates-testing. So I really see two options for improving these situations: 1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two months ago (to silence). The idea would be to add the ability for bodhi updates to mark other updates as a dependency, so that in the example above, Firefox could have been marked as ready for stable, but not pushed until the nss update was also marked as ready for stable. This to me seems like the best long-term solution. I'd also like to mention that Ubuntu's Launchpad system has this capability. 2) We could continue on the "single update for multiple packages" approach, but revamp the karma system so that each SRPM gets its own karma, rather than the update as a whole. Then, the whole update would not be pushed via autokarma until all of the dependent packages had sufficient karma (or the owner of the update could push them after the stable wait period, of course). Discuss.

6 8

Reminder: Fedora password and ssh key change deadline looms (2 days left!)
by Kevin Fenzi 15 Apr '12

15 Apr '12

Just a friendly reminder: If you are a Fedora account system account holder, and haven't changed your password and uploaded a new ssh key since we announced the mandatory change, you best do so NOW. The deadline is 2011-11-30 (only 2 days away). http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html If you don't, you may no longer have access to groups you currently do (like packager, or sysadmin or ambassador). Go take a few minutes, read the announcement and security information linked to it, and change your password and upload a new ssh public key. If you aren't a Fedora contributor, the information linked in our announcement is still a great read and may just help you be more secure on your machines. :) kevin _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

2 2

Provenpackager? Want to help out?
by Jon Ciesla 14 Apr '12

14 Apr '12

Hey! As you're aware, as of F15 we changed our default init system from sysvinit to systemd. But we have lots and lots of packages with daemons, and not all have thus far been migrated. Some maintainers haven't responded, some are too busy, some aren't sure how to go about it. In many cases, unit files have been posted by helpful individuals (Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages. If you're a Provenpackager, check out these two tracking bugs: https://bugzilla.redhat.com/show_bug.cgi?id=713562 https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one) And have a look at: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Look through, find something that looks manageable, and volunteer. Most maintainers will be receptive, I think, but remember, offer/ask before jumping in. If they're not responsive, we'll cross that bridge separately. Thanks in advance! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie

5 9

gforth and gcc 4.7
by Adrian Reber 12 Apr '12

12 Apr '12

Trying to build gforth with gcc 4.7 fails currently. The forth engine is build but it fails its included tests. The problem is that every newline the forth engine writes is replaced with 0x00 as seen in following diff: 0000010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU 0000020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S 0000030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC -0000040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !"# ^^ actual output +0000040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !"# ^^ expected output 0000050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 Removing -O2 from the compiler commandline fixes it, but I have no idea why this happens. Does anyone have an idea how this can be solved? Adrian

3 3

Orphaning insight
by Patrick Monnerat 10 Apr '12

10 Apr '12

I'm afraid I've just orphaned the insight debugger. It now miss dependency iwidgets, that was a working up-to-date package orphaned after the forced password change of last year, unperformed by the iwidgets package owner. I don't want to start I new troll on this subject: this has already been widely discussed :-( But my total disapprobation about this practice encourages me to not continue support for this product. If someone wants to adopt this package, please do. Cheers, Patrick

1 1

httpd 2.4 is coming, RFC on module packaging draft
by Joe Orton 05 Apr '12

05 Apr '12

httpd 2.4.1 packages are ready for dist-f18 and will be built early next week. Rebuilds will be required for all packages containing httpd modules. There are API changes in 2.4, so module packages may need patches if upstream has not done that work already: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html There are some significant changes in the packaging, also: 1) Config changes: I've moved to a minimal default httpd.conf which is very close to what we're shipping upstream. a) I'm proposing to split out packaged config snippets from mutable config, with the former in /etc/httpd/conf.modules.d/, containing only LoadModule lines, and ordered to avoid load-ordering issues. b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged modules, and only any reasonable default configurations. 2) Loadable MPMs! MPMs are now loadable modules, so we only need to ship one httpd binary again. Changing MPM is a config tweak. 3) Content. Putting unmutable content in /var was bad practice, so I've moved the /var/www/manual and /var/www/icons to into /usr/share/httpd. We now ship /var/www/* as empty directories. 4) Filesystem locations have moved in-line with upstream, e.g. apxs is now in /usr/bin. /etc/rpm/httpd.macros has macros for everything module packages should need. Since much of the above requires packaging changes for module packages, I've prepared a draft packaging guideline to document best practice: https://fedoraproject.org/wiki/PackagingDrafts/ApacheHTTPModules If anything there looks stupid, needs fixing, is missing, or there's any other feedback, please shout! Regards, Joe

15 31

plug software for fender mustang
by Ian Malone 04 Apr '12

04 Apr '12

Hi, I'm interested in getting Plug http://piorekf.org/plug/download/ included in Fedora, this is a package that supports control of the Fender Mustang range of amplifiers via USB, licensed under GPL3. It has dependencies on qt4 and libusb and is currently packaged through OpenSUSE. I've looked at the spec file and there are some minimal changes required to build on fedora and pass rpmlint. So, what's the next step? If necessary I can volunteer to maintain it myself (and would have to volunteer as a maintainer), but would be more than happy for someone else to take it. Minor issue that still needs sorted out with .spec file: the source is hosted at bitbucket, which means that the source package gets downloaded through a redirection URL by commit id and also contains an extra subdirectory level, I haven't found a REST request yet that can get round that. Thanks for your time, -- imalone

3 4

Jump to page:

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