devel October 2008

devel@lists.stg.fedoraproject.org

330 participants
322 discussions

PackageMaintainers/Policy/EOL out of date
by Patrice Dumas 16 Nov '08

16 Nov '08

Hello, The page https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL is out of date, pre-merge. I would like to update it, however I cannot find an explanation of the current scheedule, there is only something about the releases, https://fedoraproject.org/wiki/Releases/Schedule I can't find the description of the EOL. Unless I am wrong, F-N+2 is EOL one month after the release of F-N, but I don't know exaclty when events relevant for packagers happen, like when new branches for packages aren't created anymore, or when the builds are stopped for real happen. If you give me some information or link to a page explaining the EOL schedule, I'll update. -- Pat

2 3

Reasons to preseve X on tty7
by Dax Kelson 11 Nov '08

11 Nov '08

I would argue strongly that this change should not be made for the following reasons (in no particular order): * The default behavior of X on tty7 has been in place since the beginning (almost a decade and a half). * Long standing behaviors and defaults should not be changed unless there is a VERY good reason with a significant upside. Developers should tread respectfully in such hallowed places. * This specific Linux behavior is well documented in hundreds of thousand of publications ranging from college text books, HOWTOs, Linux books sold in retail stores, blogs, forums, guides, and training manuals. Making a change invalidates all that published knowledge. * Fedora (and presumably RHEL6) now behaves differently from all the major distributions. The axiom about those who ignore history are bound to repeat holds here. UNIX "distros" did the same thing, introducing frivolous incompatibilities. This fractures the user community, creating separate pockets of knowledge and experience for each system. * The "exception to the rule" (such as this one) dramatically increases the costs of cross-distribution support. It turns 300-page books into 1000-page books. Similarly one must remember and commit to memory all the "exceptions" and swap them in and out of your mental working set as needed. * Fedora is now inconsistent with itself in regards to where X is running depending on if you booted to runlevel 3 and used startx or if you booted to runlevel 5. When your uptime is 3 weeks, how do you remember which method you used to start the GUI? * Having tty1 be the user's "primary console" (as mentioned in BZ 465547) is not a worthy goal as desktop (GUI only) users should not and do not care what tty X is on. * Experienced users will try CONTROL-ALT-F1 and nothing will happen, the first thing that comes to mind is "something is broke". * With the current rawhide behavior, what happens when you combine this with fast user switching? The first user's desktop is on tty1, and then is the second desktop is on tty7, and the third on tty8? I tried to test this in my lab but I suspect video driver problems (radeon) because my test machine would lock up. * Having the X server start on tty7 *from the very beginning* would get one less "flicker" without making an incompatible change. I support progress, but I hate to see two steps forward and one back. I understand change is natural but the change should be well reasoned with implications considered and weighed. To put my comments in "context" and to show that I'm not just a nutter with an uniformed opinion, and in a way of introduction, here's a bit about myself. I've used (typically in production) every single version of Red Hat and/or Fedora ever created (go Mother's Day!). I started an ISP and grew it to 10,000 users using (initially) Red Hat 4.2 (not RHEL), and I was the first person/customer of Red Hat to earn an RHCE (Feb 1999). I have minor patches in many different projects and several hundred bugs in bugzilla.redhat.com. I was the official GNOME RPM maintainer for a few years around the turn of the century creating GNOME RPMs for several distributions for each new GNOME release. For the past 9 years I have made a living writing Linux courseware for multiple Linux distributions and teaching Linux training classes along with the rest of the dozen full time instructors at Guru Labs, a company I founded with a college friend of mine. I've sold tens of thousands of Linux training books. Unfortunately, I don't have the time to participate on the lists as much as I would like too. However, because of my daily work I get to observe the low level changes and development process of many different Linux distributions giving me a broad perspective. Our coureware features extensive labs which have thousands of lab steps that exercise virtually all the major software components and features thereof. As we update/validate our courseware to work on the latest Linux distribution versions, our courseware ends up acting like a giant regression test. We end up patching and/or filing many many bug reports in many bug trackers. Uneeded and frivolous incompatibilities between Linux distros are particularly annoying to me on many levels. One practical reason is the bloat it causes in our courseware. The LSB is fine for developers who want to run binaries across multiple distributions, but Linux Sys Admins deserve something akin to the LSB that provides greater consistency at the Sys Admin level by removing squashing these frivolous incompatibilities. This is something that has been brewing in the back of my mind and I (using Guru Labs funding/resources and other interested parties) might tackle at some point. Dax Kelson Guru Labs

62 263

Package Review SIG Meeting Summary 2008-10-23
by Brian Pepple 11 Nov '08

11 Nov '08

=== Present === * Brian Pepple (bpepple) * Jon Ciesla (limburgher) * Rakesh Pandit (chacha_chaudry) * Kushal Das (kushal) * Jason Tibbitts (ubertibbs) * Rex Dieter (rdieter) == Summary == === Package Review Statistics === * bpepple, limburger, and chacha_chaudhry will work on a script to generate weekly package review statistics. === Brain-Storming === * The group brain-stormed for a bit on ways to improve participation in package reviews. Some ideas were: 1. Monthly (or some other time frame) swag drawing for folks that complete a certain number of reviews in a month. 2. Advertise better the concept of reviewing at least a percentage of what they submit. 3. Prioritize the package review queue by the ratio of reviews done / package submissions. 4. Engaging SIG's to review packages. (Ex. Like how the KDE sig keeps an eye on kde-related packages) 5. Coordinate some package review days (and do a better job of it than we have in the past) 6. Hold an IRC workshop (or maybe a trac at FUDCon) on package reviewing. === Future Meetings === * Instead of IRC meetings, the group will use the devel-list to conduct future business. IRC log can be found at: http://bpepple.fedorapeople.org/prs/package-review-sig-2008-10-23.html Later, /B -- Brian Pepple <bpepple(a)fedoraproject.org> https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E

3 2

dependencies between {swfdec-mozilla, gnash-plugin} and nspluginwrapper
by Martín Marqués 10 Nov '08

10 Nov '08

Yesterday I started to finish configuring some things that were left behind on my new laptop (amd64), and bumpped up with flash support for firefox. The thing is that swfdec didn't work, and gnash neither. Solution: remove nspluginwrapper. So I wanted to ask before opening a bug report: shouldn't there be a dependency on all 3 packages (don't know about others) so that you can only have one of the 3 packages (al least the plugins: nspluginwrapper, swfdec-mozilla, gnash-plugin) installed? -- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador

5 6

what QA gets mailed to the packagers?
by Patrice Dumas 10 Nov '08

10 Nov '08

Hello, Still trying to bring the wiki up-to-date, I'd like to fix https://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModi… Some points are likely to be out of date, but I don't know exactly what is done now, regarding: * nagmails sent for EVR * nagmails sent for dependency issues Are those still generated? Is there other similar automatic QA added since pre-merge time? -- Pat

4 4

old release bugs handling
by Patrice Dumas 10 Nov '08

10 Nov '08

Hello, When looking at the infra after eol issue, Toshio made me aware that nothing special is done for bugzilla in eol branches. Maybe it would be nice to have bugs filled against old branches associated with another product, such that they are easier to triage, and owner doesn't get those bugs automatically? As a disclaimer I know nothing about both the technical issues and the organizational issues involved by that proposal. The idea could be along (provided it is technically feasible): * when a bug is filled against an old release in the current fedora product, the product is automatically changed to 'fedora EOL' (or 'fedora Legacy' if that product is to be reused), which means that they don't necessarily go to the same mail adress than current releases. Also there is an automatic answer for those bugs, along: 'You are reporting a bug against an unsupported fedora release, you are urged to upgrade, and retry with the new release'. * the owner of this product is the owner of one of the old releases, for example could be the owner of F7 currently. That way, if this release is orphaned by the maintainer, he won't get bug reports for the old branch anymore. I would even suggest mass orphaning such that the default is that the maintainer doesn't get those bugs. Then people interested in triaging bugs for old releases could be subscribed to the adress all the product bugs are forwarded to, such that they can triage the bugs. Of course this would make more sense in case the infra was left open for old releases, as there would be people specifically interested in triaging those bugs and also interested in becoming maintainers of old branches, but even if the proposal to keep infra open for old branches is rejected --- and I am almost sure that it will be rejected --- it could still be something relevant to do. Thoughts? PS: tell me if this is better to ask that kind of question on the infra list. -- Pat

1 1

review-o-matic : Fedora package review helper
by Kushal Das 03 Nov '08

03 Nov '08

Hi all, I am starting a project called review-o-matic which will do reviews of Fedora packages based on discussions at https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html. We know of having couple of scripts being used by different people to do so, but this tool's target is to consolidate those efforts and add a number of additional features as well. The basic idea is to remove the grunt work from package reviews. Wishlist: Run rpmlint Build the package in mock verify the md5sum of upstream source matches what is in the srpm <your ideas here> Workflow: The instance you submit a new review request, this tool will automatically do the following: * Download SRPM and SPEC as soon as new package review get submitted. * Do a review , post it on bugzilla and also keep track to show on own web front end * People can upload their SRPS to the system to get a review done by the system. Kushal -- http://fedoraproject.org http://kushaldas.in

19 34

undefined symbol: __stack_chk_fail_local
by Douglas Bagnall 02 Nov '08

02 Nov '08

I've been working on a package for OLPC that uses pam_sotp, which Rahul Sundaram packaged for Fedora in order to help OLPC. http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm Unfortunately the installed pam module fails with errors like this: PAM unable to dlopen(/lib/security/pam_sotp.so): \ /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local This is related to gcc's fairly recently introduced stack smashing protection; if it is compiled with CFLAGS="-fno-stack-protector", the module works fine. But that seems wrong. How are these symbols ending up undefined? Has anyone met this problem before? Some googling suggested linking with gcc rather than ld, but I can't work out how to make the rpm do that. (This is all Fedora 9, gcc-4.3.0-8.i386). Douglas Bagnall

3 3

Fedora 11: moving to posix file capabilities?
by Panu Matilainen 02 Nov '08

02 Nov '08

Hate to interrupt the tty1 vs tty7 debate but... We have kernel support for storing capabilities on filesystem since 2.6.24 and recent libcap, both in F9 already. I just committed file capability support to rpm.org HEAD, filling in the final(?) missing piece. Capability support is not going to be in rpm 4.6.0 but no reason they can't be pulled into 4.6.1 which is easily in F11 timeframe. Are we ready to start considering moving away from SUID bits to capabilities, in Fedora 11 maybe? - Panu -

22 48

Fedora 9 spins beta???
by Pavel Alexeev (aka Pahan-Hubbitus) 02 Nov '08

02 Nov '08

On page http://spins.fedoraproject.org/ in section "Fedora 9 spins" all present torrent files has description with "- **Beta**" suffixes. But nor section name nor file names has not include "Beta"... Furthermore, Fedora 9 long time is stable... I assume this is only error in description? Or we have not stable Fedora 9 spins yet? Please fix it, who can.

4 12

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