From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 1 00:09:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Scholz) Date: Thu, 01 Mar 2007 01:09:05 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228234727.7d3893e2.bugs.michael@gmx.net> (Michael Schwendt's message of "Wed, 28 Feb 2007 23:47:27 +0100") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> Message-ID: <87odnd25b2.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> >> /etc is the classical location for configuration files and I >> >> *expect* that I can edit things there resp. that my changes are >> >> not lost silently. >> > >> > /etc contains things, such as GConf2 schema files, which you are not >> > supposed to edit. >> >> Then, they do not belong into /etc and should be moved out it. > > Even if they contain configuration related defaults? When the defaults can be changed by the administrator, the schema files must be %config (at least). When they are static the schema files must be moved out of /etc. > Think of them like constants. You *could* edit them, but it would not > by typical usage in gconftool-2 world, since even site-wide defaults > are created in different files and in a different way. > > There are also normal configuration files in /etc, which are recreated > ("overwritten"), if a configuration utility is used instead of editing > them manually. When files can be changed by configuration utilities, they must be marked as %config resp. moved to /var (when they are the result of some postprocessing and not needed for system bootup). > With such an operation your changes would be lost silently, too. That's why, other configuration utilities than emacs or vim suck ;) > I can follow the requirement that /etc must not contain binaries, but > configuration related static files. I can see the historical importance > of keeping service initscripts in the configuration area to allow for > configuration changes directly in the shell scripts. It would be better to break this historical nonsense instead of trying kludges like the removal of %config. afaik, SUSE's initscripts are already outside of /etc. > But only *if* there is no other place where to customise the service > config, e.g. /etc/sysconfig. Sorry, how can a system administrator know which configuration files are supposed to be editable? Do we require a big fat "### DO NOT EDIT THIS FILE" header for each initscript? Or require a-w permissions for them? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugs.michael at gmx.net Thu Mar 1 02:12:04 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Mar 2007 03:12:04 +0100 Subject: Proposed guideline for init script files In-Reply-To: <87odnd25b2.fsf@kosh.bigo.ensc.de> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> <87odnd25b2.fsf@kosh.bigo.ensc.de> Message-ID: <20070301031204.c542f8bf.bugs.michael@gmx.net> On Thu, 01 Mar 2007 01:09:05 +0100, Scholz wrote: > >> >> /etc is the classical location for configuration files and I > >> >> *expect* that I can edit things there resp. that my changes are > >> >> not lost silently. > >> > > >> > /etc contains things, such as GConf2 schema files, which you are not > >> > supposed to edit. > >> > >> Then, they do not belong into /etc and should be moved out it. > > > > Even if they contain configuration related defaults? > > When the defaults can be changed by the administrator, the schema files > must be %config (at least). When they are static the schema files must > be moved out of /etc. They can be changed and used by an experienced adminstrator. But making rpm create *.rpm{save,new} files would not be wise, since the package scriptlets do the gconftool-2 dance with --makefile-uninstall and --makefile-install, which better works with the right schema files. > > But only *if* there is no other place where to customise the service > > config, e.g. /etc/sysconfig. > > Sorry, how can a system administrator know which configuration files are > supposed to be editable? Do we require a big fat "### DO NOT EDIT THIS > FILE" header for each initscript? Or require a-w permissions for them? Is it the same sysadmin, who deals with *.rpm{save,new} initscripts? Seems to be either a marketing/documentation problem or broken/insufficent initscripts, when it is assumed that this is the proper way to configure a service. If the modification is only applied to fix something, we're back at the better-fix-the-vendor's-package case. Anyway, to find an end, I don't want to object strongly when it comes to keeping initscripts %config. I just don't buy the argument that this is a necessity because having to fix bugs in them, while the Fedora package is not fixed, happens too often. Again, then one could also justify that Python files, Perl files, and so on, are marked %config. From fedora at leemhuis.info Thu Mar 1 06:50:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Mar 2007 07:50:38 +0100 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <1172704975.26805.3.camel@Chuck> References: <1172704975.26805.3.camel@Chuck> Message-ID: <45E677BE.5060507@leemhuis.info> On 01.03.2007 00:22, Brian Pepple wrote: > /topic FESCO-Meeting -- MISC -- extras repo-creation using new > createrepo - skvidal Just wondering: How much work is this and is it worth the trouble? The Extras repo for F7 will vanish in some weeks, and the older yum versions from FC5 and FC6 won't use that feature afaics. Or am I missing something? CU thl From nicolas.mailhot at laposte.net Thu Mar 1 07:03:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 Mar 2007 08:03:08 +0100 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <45E61058.1020801@redhat.com> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> <45E61058.1020801@redhat.com> Message-ID: <1172732588.15284.12.camel@rousalka.dyndns.org> Le jeudi 01 mars 2007 ? 09:29 +1000, Jens Petersen a ?crit : > Hi, > > Thanks for the followup. No charge ;) > Nicolas Mailhot wrote: > > To be honest I'm not too fond of foo-font packages. > > Sorry, did you mean "fonts-*"? Right, sorry > I agree with you for fonts for Western languages for which it is > possible to have reasonable coverage with limited resources. A general font like DejaVu does lao, arabic (better support is waiting on better opentype support pango & qt-side) aboriginal canadian syllabics, armenian, greek, cyrillic so I don't think the "western only" qualifier applies. You just need to get people to work together, doing a whole unicode block is no harder within an unicode font than within a specific font (in fact it's easier since you don't have to redo latin like all the asian fonts do now) > > IMHO (which if worth what it's worth) you're not packaging generic fonts > > for tibetan but a specific font project, and it deserves name recognition > > just like any other upstream. So upstreamname-fonts seems more respectful > > for me. Also have you though of what will happen should someone want to > > package another tibetan font in a few months ? > > Well in the review we are actually now discussing putting two GPL > Tibetan fonts in the same package if it is going by the generic language > name. That's the logical next step. It feels like putting kmail and evolution in the same "MUA" package though. Can't you get by with a "Tibetan support" comps group instead ? I will work with font packages crossing langage boundaries, not force users to install every single font for one langage (and in CJK countries that weights quite a lot), allow you to follow two separate upstream release schedules, etc. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at leemhuis.info Thu Mar 1 07:05:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Mar 2007 08:05:49 +0100 Subject: Fedora Developer Ranking System v1 In-Reply-To: <1172681411.2871.55.camel@localhost.localdomain> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> Message-ID: <45E67B4D.6090107@leemhuis.info> On 28.02.2007 17:50, Christopher Blizzard wrote: > On Wed, 2007-02-28 at 07:51 +0100, Thorsten Leemhuis wrote: >> On 27.02.2007 01:40, Warren Togami wrote: >>> ================================================== >>> = Strawman of Fedora Developer Ranking System v1 = >>> ================================================== >>> This concept document contains only *IDEAS* of why we would want a >>> ranking system, and how a ranking system might be useful. Below are >>> only examples. Please add your ideas to this thread. >>> [...] >> As two other (red hat) people said "overkill" and "Overly complex" I'd >> like to say the opposite: I like the direction, but would like to see >> https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00764.html >> integrated. Sure, maybe some other details need to be adjusted, but this >> scheme might meld a lot to get new people involved and growing up in the >> project. And that's hardly needed and the best for the project. >> >> Even if the system is a bit more complex than what we have now -- it >> lowers the bar (that's quite high ATM) to get involved into Fedora, and >> that's important to get new people in. It's thus a step into the right >> direction. > I think the specific proposal is too complex. (It _is_ a strawman, > after all!) But I like the idea of doing something like this. Then I think we are mostly on the same side ;-) > The > incentives are nice, but I'm more interested in allowing people to > choose their level of participation in a particular part of the project. > For example, there are a large number of packages that I care about, but > I don't need to own. I just want to be informed when there are changes. > Or if someone is doing translations for a particular package, they > should be able to watch that package for changes and jump in when that > happens. As near as I can tell that's not easy right now. Some > examples of the kinds of things that I'm talking about: > > o Watcher - "I care about this package." A "watcher" will be possible with the accounts system and would requires no rank afaics. > o Developer - "I should be consulted when there are major changes to > this package." Not sure where that matches in. Probably a co-maintainer. It seems I fail to see the difference between Developer and Hacker state a bit. > o Owner - "I am accountable for changes in this package. The buck stops > here." That the primary owner afaics, defined in the accounts system > o Hacker - "I can make changes to this package." That the co-maintainer afaics, also defined via the accounts system. I'm wondering if we are mixing up "Relationship to a package" and "status ow a contributor in the project" here. CU thl From nicolas.mailhot at laposte.net Thu Mar 1 08:03:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 09:03:24 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <87y7mi129i.fsf@kosh.bigo.ensc.de> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> Message-ID: <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > This > file won't be touched by any system program (in opposite to fonts.dir and > fonts.scale) Those won't really be touched either. mkfontscale/mkfontdir output is not too reliable, people use "known good & tested" versions of fonts.dir instead of dynamic generation -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Mar 1 08:07:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 09:07:26 +0100 (CET) Subject: Proposed guideline for init script files In-Reply-To: <20070228234727.7d3893e2.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> Message-ID: <43385.192.54.193.51.1172736446.squirrel@rousalka.dyndns.org> Le Mer 28 f?vrier 2007 23:47, Michael Schwendt a ?crit : > On Wed, 28 Feb 2007 22:32:47 +0100, Enrico Scholz wrote: > >> >> /etc is the classical location for configuration files and I >> >> *expect* that I can edit things there resp. that my changes are >> >> not lost silently. >> > >> > /etc contains things, such as GConf2 schema files, which you are not >> > supposed to edit. >> >> Then, they do not belong into /etc and should be moved out it. > > Even if they contain configuration related defaults? Configuration reference files belong in /usr/share with optional overloading in /etc. Makes it easier to everyone. -- Nicolas Mailhot From rc040203 at freenet.de Thu Mar 1 08:16:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Mar 2007 09:16:46 +0100 Subject: Proposed guideline for init script files In-Reply-To: <43385.192.54.193.51.1172736446.squirrel@rousalka.dyndns.org> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> <43385.192.54.193.51.1172736446.squirrel@rousalka.dyndns.org> Message-ID: <1172737006.15418.358.camel@mccallum.corsepiu.local> On Thu, 2007-03-01 at 09:07 +0100, Nicolas Mailhot wrote: > Le Mer 28 f?vrier 2007 23:47, Michael Schwendt a ?crit : > > On Wed, 28 Feb 2007 22:32:47 +0100, Enrico Scholz wrote: > > > >> >> /etc is the classical location for configuration files and I > >> >> *expect* that I can edit things there resp. that my changes are > >> >> not lost silently. > >> > > >> > /etc contains things, such as GConf2 schema files, which you are not > >> > supposed to edit. > >> > >> Then, they do not belong into /etc and should be moved out it. > > > > Even if they contain configuration related defaults? > > Configuration reference files belong in /usr/share with optional > overloading in /etc. That's too strong. It's an option applicable to arch-independent and machine-independent configuration files, if ... > Makes it easier to everyone. ... a package supports it (not all do). Ralf From nicolas.mailhot at laposte.net Thu Mar 1 08:37:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 09:37:42 +0100 (CET) Subject: Proposed guideline for init script files In-Reply-To: <1172737006.15418.358.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> <43385.192.54.193.51.1172736446.squirrel@rousalka.dyndns.org> <1172737006.15418.358.camel@mccallum.corsepiu.local> Message-ID: <16021.192.54.193.51.1172738262.squirrel@rousalka.dyndns.org> Le Jeu 1 mars 2007 09:16, Ralf Corsepius a ?crit : > On Thu, 2007-03-01 at 09:07 +0100, Nicolas Mailhot wrote: >> Le Mer 28 f?vrier 2007 23:47, Michael Schwendt a ?crit : >> > On Wed, 28 Feb 2007 22:32:47 +0100, Enrico Scholz wrote: >> > >> >> >> /etc is the classical location for configuration files and I >> >> >> *expect* that I can edit things there resp. that my changes are >> >> >> not lost silently. >> >> > >> >> > /etc contains things, such as GConf2 schema files, which you are >> not >> >> > supposed to edit. >> >> >> >> Then, they do not belong into /etc and should be moved out it. >> > >> > Even if they contain configuration related defaults? >> >> Configuration reference files belong in /usr/share with optional >> overloading in /etc. > > That's too strong. It's an option applicable to arch-independent and > machine-independent configuration files, if ... And /usr/lib* if it's not arch independant (to be honest arch-specific config files are not found very often) >> Makes it easier to everyone. > ... a package supports it (not all do). Sure, that's a target like complete FHS compliance. It's not useless to remind it - people tend to justify new crappy packages by existing crappy packages otherwise -- Nicolas Mailhot From fedora at leemhuis.info Thu Mar 1 08:51:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Mar 2007 09:51:59 +0100 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <45E61059.2080608@fedoraproject.org> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> Message-ID: <45E6942F.6090607@leemhuis.info> On 01.03.2007 00:29, Rahul Sundaram wrote: > Brian Pepple wrote: >> /topic FESCo meeting -- Free discussion around Fedora Extras > It might be more appropriate now to change this in "Free discussions > around Fedora" instead. This reminds me: A lot of pages in the wiki are still in the Extras/ Namespace. Do we want to ignore that for now or shall we move the files somewhere else? And remove all references to Extras while at it? My vote is to move them to Packaging/, as most of the pages are about packaging, so that?s the obvious place for it -- but that needs coordination with the Packaging Committee, as they use Packaging/ currently (and have restrictive ACLs, which afaics most people would like to avoid). The FESCo pages would be moved to FESCo/ maybe. CU thl From pertusus at free.fr Thu Mar 1 10:59:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Mar 2007 11:59:05 +0100 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <1172704975.26805.3.camel@Chuck> References: <1172704975.26805.3.camel@Chuck> Message-ID: <20070301105905.GC2905@free.fr> On Wed, Feb 28, 2007 at 06:22:55PM -0500, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC > in #fedora-meeting on irc.freenode.org: I don't know exactly where it should be discussed, but I think that having time limit for merge reviews is a very bad idea. Constraint should only be on the package quality. There has never been a time limit for Extras packages, it would be bad to add one in my opinion. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 1 11:33:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 12:33:11 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> Message-ID: <20070301113311.GA5889@neu.nirvana> On Thu, Mar 01, 2007 at 09:03:24AM +0100, Nicolas Mailhot wrote: > > Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : > > > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > > This > > file won't be touched by any system program (in opposite to fonts.dir and > > fonts.scale) > > Those won't really be touched either. mkfontscale/mkfontdir output is not > too reliable, people use "known good & tested" versions of fonts.dir > instead of dynamic generation Does it perhaps make sense to un%config them? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Mar 1 11:41:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Mar 2007 12:41:01 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070301113311.GA5889@neu.nirvana> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> Message-ID: <1172749262.15418.361.camel@mccallum.corsepiu.local> On Thu, 2007-03-01 at 12:33 +0100, Axel Thimm wrote: > On Thu, Mar 01, 2007 at 09:03:24AM +0100, Nicolas Mailhot wrote: > > > > Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : > > > > > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > > > This > > > file won't be touched by any system program (in opposite to fonts.dir and > > > fonts.scale) > > > > Those won't really be touched either. mkfontscale/mkfontdir output is not > > too reliable, people use "known good & tested" versions of fonts.dir > > instead of dynamic generation > > Does it perhaps make sense to un%config them? man mkfontdir ... The file "fonts.alias", which can be put in any directory of the font-path, is used to map new names to existing fonts, and should be edited by hand. ... The fact a file is designed to be a config file hardly can be documented clearer. Ralf From Axel.Thimm at ATrpms.net Thu Mar 1 12:09:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 13:09:01 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172749262.15418.361.camel@mccallum.corsepiu.local> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> <1172749262.15418.361.camel@mccallum.corsepiu.local> Message-ID: <20070301120901.GC5889@neu.nirvana> On Thu, Mar 01, 2007 at 12:41:01PM +0100, Ralf Corsepius wrote: > On Thu, 2007-03-01 at 12:33 +0100, Axel Thimm wrote: > > On Thu, Mar 01, 2007 at 09:03:24AM +0100, Nicolas Mailhot wrote: > > > > > > Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : > > > > > > > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > > > > This > > > > file won't be touched by any system program (in opposite to fonts.dir and > > > > fonts.scale) > > > > > > Those won't really be touched either. mkfontscale/mkfontdir output is not > > > too reliable, people use "known good & tested" versions of fonts.dir > > > instead of dynamic generation > > > > Does it perhaps make sense to un%config them? > > man mkfontdir > ... > The file "fonts.alias", which can be put in any directory of the > font-path, is used to map new names to existing Does that mean that /usr/share//fonts.alias could be installed under /etc///fonts.alias, so we get /usr %config-free? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Mar 1 13:01:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 14:01:13 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172749262.15418.361.camel@mccallum.corsepiu.local> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> <1172749262.15418.361.camel@mccallum.corsepiu.local> Message-ID: <45096.192.54.193.51.1172754073.squirrel@rousalka.dyndns.org> Le Jeu 1 mars 2007 12:41, Ralf Corsepius a ?crit : > man mkfontdir > ... > The file "fonts.alias", which can be put in any directory of the > font-path, is used to map new names to existing > fonts, and should be edited by hand. > ... > > > The fact a file is designed to be a config file hardly can be documented > clearer. And people were supposed to use xresources to customize their apps. Guess what? it was not user-friendly enough to attract many users when you had a core font only desktop, and now core font users are marginal the actual use is probably close to nill (anyone who played with it noticed anyway touching fonts.alias was a quick way to feed apps fonts they could not handle) -- Nicolas Mailhot From tagoh at redhat.com Thu Mar 1 13:03:24 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Thu, 01 Mar 2007 22:03:24 +0900 (JST) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070301113311.GA5889@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> Message-ID: <20070301.220324.1739019135.tagoh@redhat.com> >>>>> On Thu, 1 Mar 2007 12:33:11 +0100, >>>>> "AT" == Axel Thimm wrote: AT> On Thu, Mar 01, 2007 at 09:03:24AM +0100, Nicolas Mailhot wrote: >> >> Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : >> >> > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. >> > This >> > file won't be touched by any system program (in opposite to fonts.dir and >> > fonts.scale) >> >> Those won't really be touched either. mkfontscale/mkfontdir output is not >> too reliable, people use "known good & tested" versions of fonts.dir >> instead of dynamic generation AT> Does it perhaps make sense to un%config them? Unmarking %config from fonts.dir and fonts.scale will makes trouble on upgrading since xfs initscript runs ttmkfdir/mkfontscale and mkfontdir automatically when it detects the updates on the directory where the fonts installed. Probably better keep the real fonts under /usr, which won't be touched by the hand at all and move fonts.* files under /var or /etc perhaps. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Mar 1 13:27:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Mar 2007 08:27:58 -0500 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <45E677BE.5060507@leemhuis.info> References: <1172704975.26805.3.camel@Chuck> <45E677BE.5060507@leemhuis.info> Message-ID: <200703010827.58629.jkeating@redhat.com> On Thursday 01 March 2007 01:50:38 Thorsten Leemhuis wrote: > Just wondering: How much work is this and is it worth the trouble? The > Extras repo for F7 will vanish in some weeks, and the older yum versions > from FC5 and FC6 won't use that feature afaics. It should be a very simple change, and it will get a much wider audience testing the feature. I tried on the internal things and found an issue related to creating the sqlite blob over NFS (still debugging). We really need to try things now instead of waiting until later. (and this would only be on the devel/ repocreation, not all) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 1 13:30:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 14:30:57 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070301.220324.1739019135.tagoh@redhat.com> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> <20070301.220324.1739019135.tagoh@redhat.com> Message-ID: <20070301133057.GC10127@neu.nirvana> On Thu, Mar 01, 2007 at 10:03:24PM +0900, Akira TAGOH wrote: > >>>>> On Thu, 1 Mar 2007 12:33:11 +0100, > >>>>> "AT" == Axel Thimm wrote: > > AT> On Thu, Mar 01, 2007 at 09:03:24AM +0100, Nicolas Mailhot wrote: > >> > >> Le Mer 28 f?vrier 2007 21:00, Enrico Scholz a ?crit : > >> > >> > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > >> > This > >> > file won't be touched by any system program (in opposite to fonts.dir and > >> > fonts.scale) > >> > >> Those won't really be touched either. mkfontscale/mkfontdir output is not > >> too reliable, people use "known good & tested" versions of fonts.dir > >> instead of dynamic generation > > AT> Does it perhaps make sense to un%config them? > > Unmarking %config from fonts.dir and fonts.scale will makes > trouble on upgrading since xfs initscript runs > ttmkfdir/mkfontscale and mkfontdir automatically when it > detects the updates on the directory where the fonts > installed. > > Probably better keep the real fonts under /usr, which won't > be touched by the hand at all and move fonts.* files under > /var or /etc perhaps. If it's really not "intended" to be modifed by a human, then /var seems OK, otherwise it should be better underneath /etc. The original intention may have been to have this modified by people, but perhaps in Modern Times we don't want the users to turn these old radio knobs anymore because they will fall off the radio and hide under the sink? Anyway personally I only care about removing %config from /usr, any solution will do. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Mar 1 13:39:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Mar 2007 14:39:58 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <45096.192.54.193.51.1172754073.squirrel@rousalka.dyndns.org> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> <1172749262.15418.361.camel@mccallum.corsepiu.local> <45096.192.54.193.51.1172754073.squirrel@rousalka.dyndns.org> Message-ID: <1172756398.15418.379.camel@mccallum.corsepiu.local> On Thu, 2007-03-01 at 14:01 +0100, Nicolas Mailhot wrote: > Le Jeu 1 mars 2007 12:41, Ralf Corsepius a ?crit : > > > man mkfontdir > > ... > > The file "fonts.alias", which can be put in any directory of the > > font-path, is used to map new names to existing > > fonts, and should be edited by hand. > > ... > > > > > > The fact a file is designed to be a config file hardly can be documented > > clearer. > > And people were supposed to use xresources to customize their apps. > Guess what? it was not user-friendly enough to attract many users Whether you like it or not, or whether you like this approach or not, this is the way Xt is designed and how it is being used by all Xt based toolsets. > when you > had a core font only desktop, and now core font users are marginal the > actual use is probably close to nill Gradually I am beginning to thing Fedora lacks users from the pre-Gtk/Qt era ;) Anyone who is using Unix for more than 10 years, probably had used it (knowingly or not) for a considerable amount of time. There still is a considerable some amount of SW around which still can use Xresources (and some of them, may-be core-fonts). Ralf From nicolas.mailhot at laposte.net Thu Mar 1 14:22:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 15:22:55 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172756398.15418.379.camel@mccallum.corsepiu.local> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <30739.192.54.193.51.1172736204.squirrel@rousalka.dyndns.org> <20070301113311.GA5889@neu.nirvana> <1172749262.15418.361.camel@mccallum.corsepiu.local> <45096.192.54.193.51.1172754073.squirrel@rousalka.dyndns.org> <1172756398.15418.379.camel@mccallum.corsepiu.local> Message-ID: <14958.192.54.193.51.1172758975.squirrel@rousalka.dyndns.org> Le Jeu 1 mars 2007 14:39, Ralf Corsepius a ?crit : > Anyone who is using Unix for more than 10 years, probably had used it > (knowingly or not) for a considerable amount of time. There still is a > considerable some amount of SW around which still can use Xresources > (and some of them, may-be core-fonts). I do not question the way the core fonts system was designed, nor do I question the fact there is a large pool of software that honors Xresources or uses core fonts. What I question is the number of people that take advantage of core font configurability, given it never worked all that way when it was the state of the art and meddling with it today is a quick way to hose apps no one supports anymore. If you use legacy software you keep the defaults and pray you won't hit a bug, you don't play with known-dangerous eyecandy knobs. fonts.alias needs to be kept in sync with fonts.dir strings to work. fonts.dir content is not reliable (one of the many reasons core fonts fell out of grace), unless you're the one shipping the font files and fonts.dir in the first place. So if you want to play this game you do not need rw access just to the fonts.* files, you need to replave the whole core font directory. -- Nicolas Mailhot From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 1 14:38:57 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 01 Mar 2007 15:38:57 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070301031204.c542f8bf.bugs.michael@gmx.net> (Michael Schwendt's message of "Thu, 1 Mar 2007 03:12:04 +0100") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> <87odnd25b2.fsf@kosh.bigo.ensc.de> <20070301031204.c542f8bf.bugs.michael@gmx.net> Message-ID: <87abyxt4e6.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> >> > /etc contains things, such as GConf2 schema files, which you are not >> >> > supposed to edit. > ... > They can be changed and used by an experienced adminstrator. But > making rpm create *.rpm{save,new} files would not be wise, since the > package scriptlets do the gconftool-2 dance with --makefile-uninstall > and --makefile-install, which better works with the right schema > files. You mean: administrator configures kiosk-mode, nightly 'yum upgrade' overrides this configuration and clients have now the default setup till the next 'cfagent' run? Mmmh... something seems to suck in this scenario... >> > But only *if* there is no other place where to customise the service >> > config, e.g. /etc/sysconfig. >> >> Sorry, how can a system administrator know which configuration files are >> supposed to be editable? Do we require a big fat "### DO NOT EDIT THIS >> FILE" header for each initscript? Or require a-w permissions for them? > > Is it the same sysadmin, who deals with *.rpm{save,new} initscripts? Yes; this admin will learn that initscript should not be edited when he sees the messages about the .rpmsave files. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 1 15:20:19 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 01 Mar 2007 16:20:19 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070228214926.GN1417@neu.nirvana> (Axel Thimm's message of "Wed, 28 Feb 2007 22:49:26 +0100") References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070228214926.GN1417@neu.nirvana> Message-ID: <87649lt2h8.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> >> >%config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias >> >> ... >> >> IMO, the fonts.alias example is a fair use of %config that's ok in my book. >> > >> > But we do want /usr to be "stateless". >> >> afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. This >> file won't be touched by any system program (in opposite to fonts.dir and >> fonts.scale) but might be used to configure preferences for certain fonts >> (e.g. 'fixed' or 'cursor'). > > Which is really hard to do on a real-only filesystem. The '%verify(not md5 size mtime)' magic indicates, that the original intentation was not to protect manual changes, but to handle modifications by 'mkfontdir' runs (which would be a stateless vs non-stateless issue). But since 'fonts.aliases' are not touched by the system, it is either an ordinary configuration file (at a bad location) or the %config is simply a mistake. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugs.michael at gmx.net Thu Mar 1 16:01:20 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Mar 2007 17:01:20 +0100 Subject: Proposed guideline for init script files In-Reply-To: <87abyxt4e6.fsf@kosh.bigo.ensc.de> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> <20070228234727.7d3893e2.bugs.michael@gmx.net> <87odnd25b2.fsf@kosh.bigo.ensc.de> <20070301031204.c542f8bf.bugs.michael@gmx.net> <87abyxt4e6.fsf@kosh.bigo.ensc.de> Message-ID: <20070301170120.2c2316e6.bugs.michael@gmx.net> On Thu, 01 Mar 2007 15:38:57 +0100, Enrico Scholz wrote: > >> >> > /etc contains things, such as GConf2 schema files, which you are not > >> >> > supposed to edit. > > ... > > They can be changed and used by an experienced adminstrator. But > > making rpm create *.rpm{save,new} files would not be wise, since the > > package scriptlets do the gconftool-2 dance with --makefile-uninstall > > and --makefile-install, which better works with the right schema > > files. > > You mean: administrator configures kiosk-mode, nightly 'yum upgrade' > overrides this configuration and clients have now the default setup > till the next 'cfagent' run? Can't follow you here. What you describe sounds quite different from what I refer to. > >> > But only *if* there is no other place where to customise the service > >> > config, e.g. /etc/sysconfig. > >> > >> Sorry, how can a system administrator know which configuration files are > >> supposed to be editable? Do we require a big fat "### DO NOT EDIT THIS > >> FILE" header for each initscript? Or require a-w permissions for them? > > > > Is it the same sysadmin, who deals with *.rpm{save,new} initscripts? > > Yes; this admin will learn that initscript should not be edited when he > sees the messages about the .rpmsave files. ... the hard way, :( because meanwhile the service condrestart has restarted services with pristine initscripts. And similarly when the updated initscript was saved as *.rpmnew. From tibbs at math.uh.edu Thu Mar 1 16:10:57 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Mar 2007 10:10:57 -0600 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <20070301105905.GC2905@free.fr> References: <1172704975.26805.3.camel@Chuck> <20070301105905.GC2905@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> I don't know exactly where it should be discussed, but I think PD> that having time limit for merge reviews is a very bad PD> idea. Where has a time limit ever been placed on merge reviews? Originally there were a few statements to the effect that things wouldn't be in F7 if they weren't reviewed (and accepted), but that was short-lived as people started to realize just how much work is involved. I would be in favor of dropping things from F8 if they haven't been reviewed and accepted, but F7 is simply too soon. - J< From blizzard at redhat.com Thu Mar 1 16:58:06 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 01 Mar 2007 11:58:06 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E67B4D.6090107@leemhuis.info> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E67B4D.6090107@leemhuis.info> Message-ID: <1172768286.32357.1.camel@localhost.localdomain> Final thought on this. Thinking about Havoc's post the other day - he was talking mostly about visibility and workflow. We're interested in something a bit different, which is how do you figure out someone's position inside of Fedora and how can they add some of what Fedora is to their identity. Somewhat different questions, I suspect. --Chris From sundaram at fedoraproject.org Thu Mar 1 17:24:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 Mar 2007 22:54:15 +0530 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <45E6942F.6090607@leemhuis.info> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> Message-ID: <45E70C3F.2050603@fedoraproject.org> Thorsten Leemhuis wrote: > On 01.03.2007 00:29, Rahul Sundaram wrote: >> Brian Pepple wrote: >>> /topic FESCo meeting -- Free discussion around Fedora Extras >> It might be more appropriate now to change this in "Free discussions >> around Fedora" instead. > > This reminds me: A lot of pages in the wiki are still in the Extras/ > Namespace. Do we want to ignore that for now or shall we move the files > somewhere else? And remove all references to Extras while at it? > > My vote is to move them to Packaging/, as most of the pages are about > packaging, so that?s the obvious place for it -- but that needs > coordination with the Packaging Committee, as they use Packaging/ > currently (and have restrictive ACLs, which afaics most people would > like to avoid). The FESCo pages would be moved to FESCo/ maybe. What is the opinion of the Packaging Committee and others on this move? I would do the needful if we can agree on what the new name space should be. If it is not Packaging then it can be under Collection since that matches the dist tag (Fedora Package Collection, .fc). Rahul From bclark at redhat.com Thu Mar 1 19:14:07 2007 From: bclark at redhat.com (Bryan Clark) Date: Thu, 01 Mar 2007 14:14:07 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E5FFE4.3020903@redhat.com> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E5DD2E.3090305@redhat.com> <45E5E66B.8030508@redhat.com> <45E5FFE4.3020903@redhat.com> Message-ID: <45E725FF.3040804@redhat.com> Havoc Pennington wrote: > > > Warren Togami wrote: >> >> I suspect a points system would be good, but we could perhaps improve >> on this... >> >> - Points in itself is not a hard indicator of merit or promotion >> eligibility, just a strong hint of the contributor's value to the >> project. >> - Earning points is logarithmic. You shouldn't earn a super high >> score by doing an inordinate amount of one thing. Points should >> perhaps reward doing different things more than plenty of the same >> thing. >> - Points shouldn't be just for Bugzilla activity, there other >> potential sources. >> - Points might accrue for consistent activity, and gradually fall if >> you stop participating. (Note, points have no relation with access >> levels, so people who participate without care for points to maintain >> only specific packages don't need to care about maintaining >> consistent activity.) >> > > Remember this stuff is for human interpretation. So basing just on > bugzilla is fine; high points means "does a lot of bugzilla stuff." > Having also "years as fedora contributor" or "number of packages > owned" would also be easy to understand, but to me probably easier if > they are separate metrics. > > Any kind of complex formula and nobody knows what the number means. > > But really, define the problem... for me bugzilla points are so people > jumping into the community can tell who is just a drive-by commentator > and who is a contributor. They seem to work fine for that. > > I don't see why you'd want some single rank metric to measure > someone's global Fedora coolness. Wanted to reply to this in order to understand it a little better and maybe help moving forward. Starting with a clear definition of the problem. Pulling from your earlier email here's what I've gathered are the problems you're seeing, but I need help understanding what they are. - Definition of the issues - Easier way for people to gain more responsibility and do the things they want to do. - What are those things specifically? (they should be listed so we can guess how to fix them) The community is getting too big and the top ranked developers are spending too much time administrating? If this is a problem, what are the specific issues related? As the community is expanding people are becoming specialized, decentralized, and thus more anonymous to others. It sounds like you want to stop this, but we should list reasons why even if they are obvious (like we all want to be friends). The community is expanding to accommodate the expanding community? Visibility is probably a key component to solving each of the problems, used in conjunction with some broad and standard controls you can easily avoid lots of overhead of tight controls by making a process more visible to the right people. Think of "With enough eyes all bugs are shallow" and how it could apply to security / process issues. Strict ACLs are the closed and cumbersome way of handling security, open security through visibility and loose controls is the best way to allow people freedom to act and the accountability that is also required by their actions. Should also be mentioned that it's necessary to have an "undo" for this system, wikipedia would be no where if people could easily destroy data and it was lost forever. Remember the problems are not "We need a tiered system to scale the community", that's a solution / meta-issue and since both are vaguely defined it's difficult to know where to start and what to do. Once it's clear what the real issues are, it's a lot easier to address them with some tools or solutions. - Tools - A points system is just a tool. The points system lets people know when a bug is triaged or closed by someone, how much bugzilla work the person has done. If they have a high point value they can probably be trusted to be doing a good job, if they have a low point value you might want to check their work. Relative identity is another tool the GNOME bugzilla has now. The identity shows who's a developer of what package, so when commenting on a bug you can see that I'm the developer or contributor to a certain bugzilla product. This helps to know if I say "We're not doing this" on a bug where you can see I'm also listed as the maintainer then what I say is probably true. The identity is relative because it doesn't know my home address, only the identity that's relevant to the system. Buckets is another tool offered in the report that might be useful here. Used to help control the flow of processes you can create buckets for people to work in, if something falls into their bucket it's their job to act on it and move it along to the next appropriate person's bucket (kind of like hot potato). The flow from one bucket to the next has an automatic motion where a person can just press "done" and it moves to the next bucket, yet it also allows people to move items to any bucket available. And there are lots of other tools to help, but it's more important to use the right tools than have lots of them. But in order to have the right tools we need to know what the exact problems are. Cheers, ~ Bryan From laurent.rineau__fedora_extras at normalesup.org Thu Mar 1 19:31:03 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 1 Mar 2007 20:31:03 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070228214926.GN1417@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070228214926.GN1417@neu.nirvana> Message-ID: <200703012031.03603@rineau.tsetse> On Wednesday 28 February 2007 22:49:26 Axel Thimm wrote: > On Wed, Feb 28, 2007 at 09:00:09PM +0100, Enrico Scholz wrote: > > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> > While reviewing some fonts-* packages , I saw files being installed > > >> >under /usr are marked as %config in their SPECS as shown below > > >> >%config(noreplace) %verify(not md5 size mtime) > > >> > %{ttfontdir}/fonts.alias > > >> > > >> ... > > >> IMO, the fonts.alias example is a fair use of %config that's ok in my > > >> book. > > > > > > But we do want /usr to be "stateless". > > > > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. > > This file won't be touched by any system program (in opposite to > > fonts.dir and fonts.scale) but might be used to configure preferences for > > certain fonts (e.g. 'fixed' or 'cursor'). > > Which is really hard to do on a real-only filesystem. I do not really understand your point. /etc/ could be chosen read-only as well by the administrator. When an administrators set a partition to be read-only, we still has the power to remount it rw temporarily, to modify config files. (I do have friends that have head a /etc read-only, on a server, times ago. It is usable, as long as you have scripts to remount things rw before upgrades and config tunings.) -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From pertusus at free.fr Thu Mar 1 19:32:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Mar 2007 20:32:03 +0100 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: References: <1172704975.26805.3.camel@Chuck> <20070301105905.GC2905@free.fr> Message-ID: <20070301193203.GA3267@free.fr> On Thu, Mar 01, 2007 at 10:10:57AM -0600, Jason L Tibbitts III wrote: > Where has a time limit ever been placed on merge reviews? Originally In the page referring to the merge in the wiki, there is http://fedoraproject.org/wiki/Extras/Schedule/MergeCoreAndExtras * how do we review ~1160 packages from Core for Extras in less then X months (X=something between 2 and 5 afaics)? > there were a few statements to the effect that things wouldn't be in > F7 if they weren't reviewed (and accepted), but that was short-lived > as people started to realize just how much work is involved. Ok, no need to discuss it if it is agreed that there is no mandatory time constraint. > I would be in favor of dropping things from F8 if they haven't been > reviewed and accepted, but F7 is simply too soon. I don't think we should set any kind of time limit. Maybe start helping packagers such that the packages are acceptable in F8... -- Pat From laurent.rineau__fedora_extras at normalesup.org Thu Mar 1 19:36:06 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 1 Mar 2007 20:36:06 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070301133057.GC10127@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> Message-ID: <200703012036.06877@rineau.tsetse> On Thursday 01 March 2007 14:30:57 Axel Thimm wrote: > Anyway personally I only care about removing %config from /usr, any > solution will do. Can you explain your rational against %config files in /usr? Why do you want to bother administrators that would like to set sitewise options in files that are in a NFS-shared /usr? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From Axel.Thimm at ATrpms.net Thu Mar 1 22:05:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 23:05:50 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703012036.06877@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> <200703012036.06877@rineau.tsetse> Message-ID: <20070301220550.GA31912@neu.nirvana> On Thu, Mar 01, 2007 at 08:36:06PM +0100, Laurent Rineau wrote: > On Thursday 01 March 2007 14:30:57 Axel Thimm wrote: > > Anyway personally I only care about removing %config from /usr, any > > solution will do. > > Can you explain your rational against %config files in /usr? "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Mar 2 03:32:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 04:32:13 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070301220550.GA31912@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> <200703012036.06877@rineau.tsetse> <20070301220550.GA31912@neu.nirvana> Message-ID: <1172806333.26830.40.camel@mccallum.corsepiu.local> On Thu, 2007-03-01 at 23:05 +0100, Axel Thimm wrote: > On Thu, Mar 01, 2007 at 08:36:06PM +0100, Laurent Rineau wrote: > > On Thursday 01 March 2007 14:30:57 Axel Thimm wrote: > > > Anyway personally I only care about removing %config from /usr, any > > > solution will do. > > > > Can you explain your rational against %config files in /usr? > > "/usr is the second major section of the filesystem. /usr is > shareable, read-only data. At one point in time, at "use-time". This doesn't mean the data on /usr is inaccessible to a maintainer, nor does this mean /usr to be "vendor-exclusive", nor does this mean /usr not to be customizable. > That means that /usr should be shareable ... between machines using an identical OSes, identical architectures and "compatible" setups ... > between various FHS-compliant hosts and must not be written to. It doesn't mean this. It means /usr must not be written to at run-time, i.e. dynamically created files. These are the files which nowadays go to /var, not % config files (Note: %config == Not 100% under rpm-control != (configuration|customizable files). > Any > information that is host-specific or varies with time is stored > elsewhere." Furthermore: You omitted the next sentence: "Large software packages must not use a direct subdirectory under the /usr hierarchy." X11 traditionally had been installed under /usr/X11*. The sentence above is a reflection of this fact. Ralf From fedora at leemhuis.info Fri Mar 2 06:19:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 07:19:37 +0100 Subject: New place for Extras pages in the wiki (was: Re: Plan for tomorrows (20070301) FESCO meeting) In-Reply-To: <45E70C3F.2050603@fedoraproject.org> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> <45E70C3F.2050603@fedoraproject.org> Message-ID: <45E7C1F9.1040204@leemhuis.info> On 01.03.2007 18:24, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 01.03.2007 00:29, Rahul Sundaram wrote: >>> Brian Pepple wrote: >>>> /topic FESCo meeting -- Free discussion around Fedora Extras >>> It might be more appropriate now to change this in "Free discussions >>> around Fedora" instead. >> This reminds me: A lot of pages in the wiki are still in the Extras/ >> Namespace. Do we want to ignore that for now or shall we move the files >> somewhere else? And remove all references to Extras while at it? >> My vote is to move them to Packaging/, as most of the pages are about >> packaging, so that?s the obvious place for it -- but that needs >> coordination with the Packaging Committee, as they use Packaging/ >> currently (and have restrictive ACLs, which afaics most people would >> like to avoid). The FESCo pages would be moved to FESCo/ maybe. > What is the opinion of the Packaging Committee and others on this move? No idea, they should all be on this list, so they hopefully speak up. > I would do the needful if we can agree on what the new name space should > be. If it is not Packaging then it can be under Collection since that > matches the dist tag (Fedora Package Collection, .fc). We (Board, FESCo, Community) need to agree to use the term them. I brought that discussion up some weeks ago, and Max seemed to like "Fedora Package Repository" (see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00584.html ) and Stickster liked "Fedora Collection" (without package) https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00591.html Anyway: Packaging/ is IMHO by far the best place in the wiki for most of the current Extras/ pages, as new packagers don't care if a policy or guideline was done and is maintained by the Packaging committee or by FESCo -- most will probably prefer to have it nicely presented side my side (that's a problem currently, too, as the review guidelines are in Packaging/ and some other policies are in Extras/Policies/). Further: The name Packaging makes it obvious what the pages are about -- the term Collection/ does not afaics. CU thl From rc040203 at freenet.de Fri Mar 2 06:35:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 07:35:55 +0100 Subject: New place for Extras pages in the wiki (was: Re: Plan for tomorrows (20070301) FESCO meeting) In-Reply-To: <45E7C1F9.1040204@leemhuis.info> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> <45E70C3F.2050603@fedoraproject.org> <45E7C1F9.1040204@leemhuis.info> Message-ID: <1172817355.26830.60.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 07:19 +0100, Thorsten Leemhuis wrote: > On 01.03.2007 18:24, Rahul Sundaram wrote: > > Thorsten Leemhuis wrote: > >> On 01.03.2007 00:29, Rahul Sundaram wrote: > >>> Brian Pepple wrote: > >>>> /topic FESCo meeting -- Free discussion around Fedora Extras > >>> It might be more appropriate now to change this in "Free discussions > >>> around Fedora" instead. > >> This reminds me: A lot of pages in the wiki are still in the Extras/ > >> Namespace. Do we want to ignore that for now or shall we move the files > >> somewhere else? And remove all references to Extras while at it? > >> My vote is to move them to Packaging/, as most of the pages are about > >> packaging, so that?s the obvious place for it -- but that needs > >> coordination with the Packaging Committee, as they use Packaging/ > >> currently (and have restrictive ACLs, which afaics most people would > >> like to avoid). The FESCo pages would be moved to FESCo/ maybe. > > What is the opinion of the Packaging Committee and others on this move? > > No idea, they should all be on this list, so they hopefully speak up. IMO, these package do not belong into a "FPC owned" Packaging directories. "official FPC" and "community contributed packages" should be strictly separated. Whether "Packaging" should be "FPC owned/controlled" is different question. I for own would recommend to change as little as possible, because Fedora already has openedn way to many "construction sites" and we really don't need more. So, a minimalist approach would seem more appropriate to me: Either * do nothing and keep things as they are. * Rename "Extras/" into something more meaningful. Ralf From rc040203 at freenet.de Fri Mar 2 06:47:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 07:47:34 +0100 Subject: New place for Extras pages in the wiki (was: Re: Plan for tomorrows (20070301) FESCO meeting) In-Reply-To: <1172817355.26830.60.camel@mccallum.corsepiu.local> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> <45E70C3F.2050603@fedoraproject.org> <45E7C1F9.1040204@leemhuis.info> <1172817355.26830.60.camel@mccallum.corsepiu.local> Message-ID: <1172818054.26830.65.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 07:35 +0100, Ralf Corsepius wrote: > On Fri, 2007-03-02 at 07:19 +0100, Thorsten Leemhuis wrote: > > On 01.03.2007 18:24, Rahul Sundaram wrote: > > > Thorsten Leemhuis wrote: > > >> On 01.03.2007 00:29, Rahul Sundaram wrote: > > >>> Brian Pepple wrote: > > >>>> /topic FESCo meeting -- Free discussion around Fedora Extras > > >>> It might be more appropriate now to change this in "Free discussions > > >>> around Fedora" instead. > > >> This reminds me: A lot of pages in the wiki are still in the Extras/ > > >> Namespace. Do we want to ignore that for now or shall we move the files > > >> somewhere else? And remove all references to Extras while at it? > > >> My vote is to move them to Packaging/, as most of the pages are about > > >> packaging, so that?s the obvious place for it -- but that needs > > >> coordination with the Packaging Committee, as they use Packaging/ > > >> currently (and have restrictive ACLs, which afaics most people would > > >> like to avoid). The FESCo pages would be moved to FESCo/ maybe. > > > What is the opinion of the Packaging Committee and others on this move? > > > > No idea, they should all be on this list, so they hopefully speak up. > IMO, these package do not belong into a "FPC owned" Packaging directories. > > "official FPC" and "community contributed packages" should be strictly > separated. Whether "Packaging" should be "FPC owned/controlled" is > different question. Too little coffee this morning: s/package/pages/ > I for own would recommend to change as little as possible, because > Fedora already has openedn way to many "construction sites" and we > really don't need more. > > So, a minimalist approach would seem more appropriate to me: > Either > * do nothing and keep things as they are. > * Rename "Extras/" into something more meaningful. From petersen at redhat.com Fri Mar 2 06:58:22 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 02 Mar 2007 16:58:22 +1000 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <1172732588.15284.12.camel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> <45E61058.1020801@redhat.com> <1172732588.15284.12.camel@rousalka.dyndns.org> Message-ID: <45E7CB0E.3030403@redhat.com> Nicolas Mailhot wrote: > A general font like DejaVu does lao, arabic (better support is waiting > on better opentype support pango & qt-side) aboriginal canadian > syllabics, armenian, greek, cyrillic so I don't think the "western only" > qualifier applies. Ok I don't know how many glyphs dejavu currently supports. But there is no coverage for CJK for example and CJK fonts are huge. > You just need to get people to work together, doing a > whole unicode block is no harder within an unicode font than within a > specific font (in fact it's easier since you don't have to redo latin > like all the asian fonts do now) True. I am all for it in principle. Not sure if everyone wants to have truetype fonts each over 30MB in size installed by default. It would certainly stop me having to worry about how we can have good international font coverage installed by default in Fedora. :) > That's the logical next step. It feels like putting kmail and evolution > in the same "MUA" package though. Can't you get by with a "Tibetan > support" comps group instead ? It will work with font packages crossing > langage boundaries, not force users to install every single font for one > langage (and in CJK countries that weights quite a lot), allow you to > follow two separate upstream release schedules, etc. Those are good points. Jens From fedora at leemhuis.info Fri Mar 2 07:00:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 08:00:12 +0100 Subject: New place for Extras pages in the wiki In-Reply-To: <1172817355.26830.60.camel@mccallum.corsepiu.local> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> <45E70C3F.2050603@fedoraproject.org> <45E7C1F9.1040204@leemhuis.info> <1172817355.26830.60.camel@mccallum.corsepiu.local> Message-ID: <45E7CB7C.2070808@leemhuis.info> On 02.03.2007 07:35, Ralf Corsepius wrote: > On Fri, 2007-03-02 at 07:19 +0100, Thorsten Leemhuis wrote: >> On 01.03.2007 18:24, Rahul Sundaram wrote: >>> Thorsten Leemhuis wrote: >>>> On 01.03.2007 00:29, Rahul Sundaram wrote: >>>>> Brian Pepple wrote: >>>>>> /topic FESCo meeting -- Free discussion around Fedora Extras >>>>> It might be more appropriate now to change this in "Free discussions >>>>> around Fedora" instead. >>>> This reminds me: A lot of pages in the wiki are still in the Extras/ >>>> Namespace. Do we want to ignore that for now or shall we move the files >>>> somewhere else? And remove all references to Extras while at it? >>>> My vote is to move them to Packaging/, as most of the pages are about >>>> packaging, so that?s the obvious place for it -- but that needs >>>> coordination with the Packaging Committee, as they use Packaging/ >>>> currently (and have restrictive ACLs, which afaics most people would >>>> like to avoid). The FESCo pages would be moved to FESCo/ maybe. >>> What is the opinion of the Packaging Committee and others on this move? >> No idea, they should all be on this list, so they hopefully speak up. > IMO, these package do not belong into a "FPC owned" Packaging directories. > > "official FPC" and "community contributed pages" should be strictly > separated. Whether "Packaging" should be "FPC owned/controlled" is > different question. Yes -- the stuff from the PC could be moved to the Packaging/Guidelines/ and the organizational stuff (meeting schedule, guidelines drafts) could be under FPC/ or PackagingCommittee/ (and that from FESCo below FESCo/ > I for own would recommend to change as little as possible, because > Fedora already has openedn way to many "construction sites" and we > really don't need more. > > So, a minimalist approach would seem more appropriate to me: Well, moving the pages around is a lot of work (it's not like it's a simple rename of a directory), so I'd say we use this moving time to clean the structure that evolved over time up a bit. > Either > * do nothing and keep things as they are. Might be an option, albeit one that gets confusing one over time. So sooner or later we need to change this. But I'm fine to do that for example right after F7 if we want (that's actually something I'd prefer). > * Rename "Extras/" into something more meaningful. I would dislike that. CU thl From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 07:43:19 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 08:43:19 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172806333.26830.40.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> Message-ID: <200703020843.19562@rineau.tsetse> On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > > "/usr is the second major section of the filesystem. /usr is > > shareable, read-only data. > > At one point in time, at "use-time". > > This doesn't mean the data on /usr is inaccessible to a maintainer, nor > does this mean /usr to be "vendor-exclusive", nor does this mean /usr > not to be customizable. I agree with Ralf. A read-only filesystem is not read-only for the system administrator: it can be turned read-write during administration stages, for upgrades and configurations. Axel, do you agree with that? What is *really* your rational against %config in /usr? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From nicolas.mailhot at laposte.net Fri Mar 2 08:12:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 2 Mar 2007 09:12:31 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703020843.19562@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> <200703020843.19562@rineau.tsetse> Message-ID: <13819.192.54.193.51.1172823151.squirrel@rousalka.dyndns.org> Le Ven 2 mars 2007 08:43, Laurent Rineau a ?crit : > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: >> > "/usr is the second major section of the filesystem. /usr is >> > shareable, read-only data. >> >> At one point in time, at "use-time". >> >> This doesn't mean the data on /usr is inaccessible to a maintainer, nor >> does this mean /usr to be "vendor-exclusive", nor does this mean /usr >> not to be customizable. > > I agree with Ralf. A read-only filesystem is not read-only for the system > administrator: it can be turned read-write during administration stages, > for upgrades and configurations. read-only means hardware read-only in some cases. That means anything the admin must be able to change has no place there Therefore any %config in /usr is very optionnal stuff. The value of allowing %config in /usr over making clear one should not depend on a rw /usr can be debated. -- Nicolas Mailhot From rc040203 at freenet.de Fri Mar 2 08:23:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 09:23:33 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <13819.192.54.193.51.1172823151.squirrel@rousalka.dyndns.org> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> <200703020843.19562@rineau.tsetse> <13819.192.54.193.51.1172823151.squirrel@rousalka.dyndns.org> Message-ID: <1172823814.26830.69.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 09:12 +0100, Nicolas Mailhot wrote: > Le Ven 2 mars 2007 08:43, Laurent Rineau a ?crit : > > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > >> > "/usr is the second major section of the filesystem. /usr is > >> > shareable, read-only data. > >> > >> At one point in time, at "use-time". > >> > >> This doesn't mean the data on /usr is inaccessible to a maintainer, nor > >> does this mean /usr to be "vendor-exclusive", nor does this mean /usr > >> not to be customizable. > > > > I agree with Ralf. A read-only filesystem is not read-only for the system > > administrator: it can be turned read-write during administration stages, > > for upgrades and configurations. > > read-only means hardware read-only in some cases. > That means anything the admin must be able to change has no place there At run-time, yes. But it doesn't mean at "admin-time or installation time" and it also doesn't mean he must change something. The classical use for such situations is a "minimal installation" using a network mounted /usr from a master machine. > Therefore any %config in /usr is very optionnal stuff. The value of > allowing %config in /usr over making clear one should not depend on a rw > /usr can be debated. You could not be much wronger. Ralf From Axel.Thimm at ATrpms.net Fri Mar 2 10:17:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 11:17:53 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703020843.19562@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> <200703020843.19562@rineau.tsetse> Message-ID: <20070302101753.GD17966@neu.nirvana> On Fri, Mar 02, 2007 at 08:43:19AM +0100, Laurent Rineau wrote: > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > > > "/usr is the second major section of the filesystem. /usr is > > > shareable, read-only data. > > > > At one point in time, at "use-time". > > > > This doesn't mean the data on /usr is inaccessible to a maintainer, nor > > does this mean /usr to be "vendor-exclusive", nor does this mean /usr > > not to be customizable. > > I agree with Ralf. A read-only filesystem is not read-only for the system > administrator: it can be turned read-write during administration stages, for > upgrades and configurations. > > Axel, do you agree with that? What is *really* your rational against %config > in /usr? Whether *I* agree with that or not (FWIW I don't) is completely irrelevant, the quote is from the FHS, not me, and we follow the FHS. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 10:26:40 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 11:26:40 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070302101753.GD17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> Message-ID: <200703021126.40172@rineau.tsetse> On Friday 02 March 2007 11:17:53 Axel Thimm wrote: > On Fri, Mar 02, 2007 at 08:43:19AM +0100, Laurent Rineau wrote: > > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > > > > "/usr is the second major section of the filesystem. /usr is > > > > shareable, read-only data. > > > > > > At one point in time, at "use-time". > > > > > > This doesn't mean the data on /usr is inaccessible to a maintainer, nor > > > does this mean /usr to be "vendor-exclusive", nor does this mean /usr > > > not to be customizable. > > > > I agree with Ralf. A read-only filesystem is not read-only for the system > > administrator: it can be turned read-write during administration stages, > > for upgrades and configurations. > > > > Axel, do you agree with that? What is *really* your rational against > > %config in /usr? > > Whether *I* agree with that or not (FWIW I don't) is completely > irrelevant, the quote is from the FHS, not me, and we follow the FHS. What is wrong is your understanding of the FSH. Re-read Ralf's messages. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From Axel.Thimm at ATrpms.net Fri Mar 2 10:36:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 11:36:46 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172806333.26830.40.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> <200703012036.06877@rineau.tsetse> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> Message-ID: <20070302103646.GE17966@neu.nirvana> Nice work. I could probably pick the US anthem and add as much of my own wording/interpretation in it to make it sound like a Taliban mainfest or vice versa. I really like the part where you suggest that the FHS "doesn't mean what they write". And just what on earth does the "omitted next sentence" about "Large software packages" not being allowed to deviate from the FHS layout like X11 once did have to do with anything in this thread at all? :) The FHS' wording and intentions are clear. Whether you agree with them or not is something else, but we're rather committed to following the FHS (with the libexec exception which I submitted to the FHS for review). On Fri, Mar 02, 2007 at 04:32:13AM +0100, Ralf Corsepius wrote: > On Thu, 2007-03-01 at 23:05 +0100, Axel Thimm wrote: > > On Thu, Mar 01, 2007 at 08:36:06PM +0100, Laurent Rineau wrote: > > > On Thursday 01 March 2007 14:30:57 Axel Thimm wrote: > > > > Anyway personally I only care about removing %config from /usr, any > > > > solution will do. > > > > > > Can you explain your rational against %config files in /usr? > > > > "/usr is the second major section of the filesystem. /usr is > > shareable, read-only data. > At one point in time, at "use-time". > > This doesn't mean the data on /usr is inaccessible to a maintainer, nor > does this mean /usr to be "vendor-exclusive", nor does this mean /usr > not to be customizable. > > > That means that /usr should be shareable > ... between machines using an identical OSes, identical architectures > and "compatible" setups ... > > > between various FHS-compliant hosts and must not be written to. > It doesn't mean this. > > It means /usr must not be written to at run-time, i.e. dynamically > created files. These are the files which nowadays go to /var, not % > config files (Note: %config == Not 100% under rpm-control != > (configuration|customizable files). > > > Any information that is host-specific or varies with time is > > stored elsewhere." > > Furthermore: You omitted the next sentence: > "Large software packages must not use a direct subdirectory under > the /usr hierarchy." > > X11 traditionally had been installed under /usr/X11*. The sentence above > is a reflection of this fact. > > Ralf > > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 2 10:46:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 11:46:52 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <200703021126.40172@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> Message-ID: <20070302104652.GF17966@neu.nirvana> On Fri, Mar 02, 2007 at 11:26:40AM +0100, Laurent Rineau wrote: > On Friday 02 March 2007 11:17:53 Axel Thimm wrote: > > On Fri, Mar 02, 2007 at 08:43:19AM +0100, Laurent Rineau wrote: > > > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > > > > > "/usr is the second major section of the filesystem. /usr is > > > > > shareable, read-only data. > > > > > > > > At one point in time, at "use-time". > > > > > > > > This doesn't mean the data on /usr is inaccessible to a maintainer, nor > > > > does this mean /usr to be "vendor-exclusive", nor does this mean /usr > > > > not to be customizable. > > > > > > I agree with Ralf. A read-only filesystem is not read-only for the system > > > administrator: it can be turned read-write during administration stages, > > > for upgrades and configurations. > > > > > > Axel, do you agree with that? What is *really* your rational against > > > %config in /usr? > > > > Whether *I* agree with that or not (FWIW I don't) is completely > > irrelevant, the quote is from the FHS, not me, and we follow the FHS. > > What is wrong is your understanding of the FSH. Re-read Ralf's messages. Repeat after me with a gospel like preaching: a) "/usr is [...] read-only data." b) "[...] /usr [...] must not be written to." c) "Any information that is host-specific ..." The chorus in the background with a higher pitch: "~ and that includes configuration ~" "[...] is stored elsewhere." The refrain goes: "Yes, Lord, the FHS have given us a read-only /usr specfication." "Yes, Lord, we praise you for that." "Yes, Lord, we won't put host-specific information in there." "Yes, Lord, hallelujah." Repeat a-c) again and close with the refrain. Take a piano, it helps. :) (Don't use it on my head, though, the above should make you laugh, I hope) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 10:49:59 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 11:49:59 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070302103646.GE17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> Message-ID: <200703021149.59810@rineau.tsetse> On Friday 02 March 2007 11:36:46 Axel Thimm wrote: > Nice work. I could probably pick the US anthem and add as much of my > own wording/interpretation in it to make it sound like a Taliban > mainfest or vice versa. I really like the part where you suggest that > the FHS "doesn't mean what they write". *I* mean that your reading o the FHS is too strict. How could a /usr partition be read-only during a yum update, for example? A read-only partition, in my understanding, and i my personal practices, is read-only BUT during installation/upgrade/re-configuration, that is during any administration stage. > And just what on earth does the "omitted next sentence" about "Large > software packages" not being allowed to deviate from the FHS layout > like X11 once did have to do with anything in this thread at all? :) I agree: X11 as nothing to do with the current thread. > The FHS' wording and intentions are clear. I still agree. The FHS wording is clear, but your interpretation seems strange to me. Please, do you personally have read-only partitions on your machines? How could you administrate them without remounting them read-write temporarily? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 11:08:38 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 12:08:38 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <20070302104652.GF17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> Message-ID: <200703021208.38950@rineau.tsetse> On Friday 02 March 2007 11:46:52 Axel Thimm wrote: > On Fri, Mar 02, 2007 at 11:26:40AM +0100, Laurent Rineau wrote: > > On Friday 02 March 2007 11:17:53 Axel Thimm wrote: > > > On Fri, Mar 02, 2007 at 08:43:19AM +0100, Laurent Rineau wrote: > > > > On Friday 02 March 2007 04:32:13 Ralf Corsepius wrote: > > > > > > "/usr is the second major section of the filesystem. /usr is > > > > > > shareable, read-only data. > > > > > > > > > > At one point in time, at "use-time". > > > > > > > > > > This doesn't mean the data on /usr is inaccessible to a maintainer, > > > > > nor does this mean /usr to be "vendor-exclusive", nor does this > > > > > mean /usr not to be customizable. > > > > > > > > I agree with Ralf. A read-only filesystem is not read-only for the > > > > system administrator: it can be turned read-write during > > > > administration stages, for upgrades and configurations. > > > > > > > > Axel, do you agree with that? What is *really* your rational against > > > > %config in /usr? > > > > > > Whether *I* agree with that or not (FWIW I don't) is completely > > > irrelevant, the quote is from the FHS, not me, and we follow the FHS. > > > > What is wrong is your understanding of the FSH. Re-read Ralf's messages. > > Repeat after me with a gospel like preaching: > > a) "/usr is [...] read-only data." > b) "[...] /usr [...] must not be written to." > c) "Any information that is host-specific ..." > The chorus in the background with a higher pitch: > "~ and that includes configuration ~" > "[...] is stored elsewhere." I quote below the FHS version 2.3, given at http://www.pathname.com/fhs/pub/fhs-2.3.pdf ===== quote ===== Chapter 4. The /usr Hierarchy 4.1. Purpose /usr is the second major section of the ?lesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-speci?c or varies with time is stored elsewhere. Large software packages must not use a direct subdirectory under the /usr hierarchy. ===== end of quote ===== >From the sentence "Any information that is host-speci?c or varies with time is stored elsewhere.", how could you understand that *sitewise* configuration files must be in /etc?! What is more, I quote the title of the section about /etc: "3.7. /etc : Host-speci?c system con?guration" Here again, /etc/ is for host-specific stuff. So, sharable config files, that are not be written to by the system, can go into /usr/, and should not be in /etc (even the FSH states precisely that /etc is for host-specific stuff). I really what a discussion. You may convince me and Ralf. But give good reasons. AS far as I understand, the FSH does not state that sitewise config files cannot be in /usr, and as far as I understand, the FSH states that sitewise config could not be in /etc (be cause /etc is host specific). What is wrong with my interpretation? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From paul at city-fan.org Fri Mar 2 11:43:31 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 02 Mar 2007 11:43:31 +0000 Subject: The FHS /usr song In-Reply-To: <200703021208.38950@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <200703021208.38950@rineau.tsetse> Message-ID: <45E80DE3.30500@city-fan.org> Laurent Rineau wrote: > I really what a discussion. You may convince me and Ralf. But give good > reasons. AS far as I understand, the FSH does not state that sitewise config > files cannot be in /usr, and as far as I understand, the FSH states that > sitewise config could not be in /etc (be cause /etc is host specific). > What is wrong with my interpretation? I believe that site-wide configuration files may be kept under /usr and that this falls within the description of /usr in the FHS. However, as packagers we do not know if admins using our packages will be wanting to configure them on a host-by-host basis or a site-wide basis. Since it's likely that at least some admins are going to want to configure packages on a host-by-host basis, does it not follow that packages should *not* place configuration files under /usr, at least unless such configuration can be overridden by another configuration file elsewhere such as in /etc? Paul. From Axel.Thimm at ATrpms.net Fri Mar 2 12:00:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 13:00:14 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703021149.59810@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> <200703021149.59810@rineau.tsetse> Message-ID: <20070302120014.GH17966@neu.nirvana> On Fri, Mar 02, 2007 at 11:49:59AM +0100, Laurent Rineau wrote: > On Friday 02 March 2007 11:36:46 Axel Thimm wrote: > > Nice work. I could probably pick the US anthem and add as much of my > > own wording/interpretation in it to make it sound like a Taliban > > mainfest or vice versa. I really like the part where you suggest that > > the FHS "doesn't mean what they write". > > *I* mean that your reading o the FHS is too strict. How could a /usr partition > be read-only during a yum update, for example? That's not at all what I (or the FHS) suggest, and 99.9% of /usr are mounted rw. When the FHS writes read-only it doesn't require you to use ROM media or similar. The files do need to get on the system and be managed, of course. If you like so during rpm/deb operation, the FHS is momentarily violated. ;) > > The FHS' wording and intentions are clear. > > I still agree. The FHS wording is clear, but your interpretation seems strange > to me. OK, let's quote the FHS again which repeadedly lays great emphasis on keeping /usr read-only (or possible to mount read-only if you prefer), and not only from configuration files. Allowing /usr to be indeed a read-only partition, or read-only nfs/gfs mount etc is a primary target in the FHS. And we are even stricter by design, because stateless Linux requires even root to be read-only mountable with /etc and /var exceptions. "/var is specified here in order to make it possible to mount /usr read-only." "Static and variable files should be segregated, because static files, unlike variable files, can be stored on read-only media and do not need to be backed up on the same schedule as variable files." "Historical UNIX-like filesystem hierarchies contained both static and variable files under both /usr and /etc. In order to realize the advantages mentioned above, the /var hierarchy was created and all variable files were transferred from /usr to /var. Consequently /usr can now be mounted read-only (if it is a separate filesystem)." "/usr is shareable, read-only data [...] must not be written to" -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 12:06:31 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 13:06:31 +0100 Subject: The FHS /usr song In-Reply-To: <45E80DE3.30500@city-fan.org> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021208.38950@rineau.tsetse> <45E80DE3.30500@city-fan.org> Message-ID: <200703021306.31937@rineau.tsetse> On Friday 02 March 2007 12:43:31 Paul Howarth wrote: > Laurent Rineau wrote: > > I really what a discussion. You may convince me and Ralf. But give good > > reasons. AS far as I understand, the FSH does not state that sitewise > > config files cannot be in /usr, and as far as I understand, the FSH > > states that sitewise config could not be in /etc (be cause /etc is host > > specific). What is wrong with my interpretation? > > I believe that site-wide configuration files may be kept under /usr and > that this falls within the description of /usr in the FHS. However, as > packagers we do not know if admins using our packages will be wanting to > configure them on a host-by-host basis or a site-wide basis. Since it's > likely that at least some admins are going to want to configure packages > on a host-by-host basis, does it not follow that packages should *not* > place configuration files under /usr, at least unless such configuration > can be overridden by another configuration file elsewhere such as in /etc? I agree with you. In an ideal word, I would have preferred that any configuration file that has a meaning in a site-wise configuration exists in both /etc/ and /usr. For example, /usr/lib/openoffice.org2.0/share/psprint/psprint.conf (from openoffice.org-core) should be marked as %config(noreplace), but there should also exists a similar config file in /etc. (Actually openoffice.org packages, in FC-6, do not have %config files at all.) -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From Axel.Thimm at ATrpms.net Fri Mar 2 12:10:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 13:10:03 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <200703021208.38950@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <200703021208.38950@rineau.tsetse> Message-ID: <20070302121003.GI17966@neu.nirvana> On Fri, Mar 02, 2007 at 12:08:38PM +0100, Laurent Rineau wrote: > I quote below the FHS version 2.3, given at > http://www.pathname.com/fhs/pub/fhs-2.3.pdf > > ===== quote ===== > Chapter 4. The /usr Hierarchy > > 4.1. Purpose > > /usr is the second major section of the ?lesystem. /usr is shareable, > read-only data. That means that /usr > should be shareable between various FHS-compliant hosts and must not be > written to. Any information that is > host-speci?c or varies with time is stored elsewhere. > Large software packages must not use a direct subdirectory under the /usr > hierarchy. > ===== end of quote ===== Ahem, isn't that exactly the quote I gave yesterday? :) > >From the sentence "Any information that is host-speci?c or varies with time is > stored elsewhere.", how could you understand that *sitewise* configuration > files must be in /etc?! I understand that they must not be in /usr. This sentence does not say where to put them, but the FHS has an /etc section as well. > What is more, I quote the title of the section about /etc: > "3.7. /etc : Host-speci?c system con?guration" > > Here again, /etc/ is for host-specific stuff. So, sharable config files, that > are not be written to by the system, can go into /usr/, and should not be > in /etc (even the FSH states precisely that /etc is for host-specific stuff). So font.alias is now a "sharable config file"? Why isn't ntp.conf a sharable file? Do you have ntp.conf under /usr just because you could mount it on another host and share this configuration? 95% of /etc could be declared "sharable" that way, so should /etc get under /usr? That's not working. In fact you could consider that other than clustering software in fedora there is nothing "sharable". The usual Fedora way to sync config across different hosts is to use a sync tool, not so much to outsource half of /etc to /usr and mount this. > I really what a discussion. Then please carry this to the FHS, not here. How did I suddenly got promoted the local FHS advocate here? ;) Really, /usr is not for %config files. > You may convince me and Ralf. No, I obviously can't ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 12:19:01 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 13:19:01 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070302120014.GH17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021149.59810@rineau.tsetse> <20070302120014.GH17966@neu.nirvana> Message-ID: <200703021319.01379@rineau.tsetse> On Friday 02 March 2007 13:00:14 Axel Thimm wrote: > OK, let's quote the FHS again which repeadedly lays great emphasis on > keeping /usr read-only (or possible to mount read-only if you prefer), > and not only from configuration files. Let stop that useless flame. I *agree* that FSH target, about /usr, is to allow /usr to be mounted read-only. But "read-only" and "configuration files" are not correlated at all. When the administrator modifies a config files (I mean with an editor), it is an "admin operation", like an upgrade. I repeat: I have known some machines with /etc/ mounted read-only! Every admin-operation on a partition can require remounting it read-write. It includes upgrades, but also modification of config files. However, I agree that every config file of the system should have an instance in /etc, so that host-specific stuff can be used in that config file. I am not arguing on that point. I just wanted to spot out that your reading of the FSH is not correct. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From Axel.Thimm at ATrpms.net Fri Mar 2 12:29:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 13:29:25 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703021319.01379@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021149.59810@rineau.tsetse> <20070302120014.GH17966@neu.nirvana> <200703021319.01379@rineau.tsetse> Message-ID: <20070302122925.GJ17966@neu.nirvana> On Fri, Mar 02, 2007 at 01:19:01PM +0100, Laurent Rineau wrote: > On Friday 02 March 2007 13:00:14 Axel Thimm wrote: > > OK, let's quote the FHS again which repeadedly lays great emphasis on > > keeping /usr read-only (or possible to mount read-only if you prefer), > > and not only from configuration files. > > Let stop that useless flame. Where is the flame in the above? And where is the stopping? ;) > I *agree* that FSH target, about /usr, is to allow /usr to be mounted > read-only. > > But "read-only" and "configuration files" are not correlated at all. When the > administrator modifies a config files (I mean with an editor), it is > an "admin operation", like an upgrade. I repeat: I have known some machines > with /etc/ mounted read-only! So? Every other embedded device has /etc read-only. What do we really learn from that? > Every admin-operation on a partition can require remounting it > read-write. It includes upgrades, but also modification of config > files. > > However, I agree that every config file of the system should have an instance > in /etc, so that host-specific stuff can be used in that config file. I am > not arguing on that point. I just wanted to spot out that your reading of the > FSH is not correct. Well, you objected on me saying On Thursday 01 March 2007 14:30:57 Axel Thimm wrote: > Anyway personally I only care about removing %config from /usr, any > solution will do. So, are you back with me, now? And my reading of the FHS is fine, but if we're agreeing on banning %config from /usr we can close this, I can live with your opinion on my reading skills. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Mar 2 12:33:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 2 Mar 2007 13:33:30 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703021149.59810@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> <200703021149.59810@rineau.tsetse> Message-ID: <47793.192.54.193.51.1172838810.squirrel@rousalka.dyndns.org> Le Ven 2 mars 2007 11:49, Laurent Rineau a ?crit : > A read-only partition, in my understanding, and i my personal practices, > is read-only BUT during installation yes > upgrade yes > /re-configuration, Nope. You can't conflate file deployment and (re-)configuration in a single "administration" stage. Separation of file deployment and configuration is a major Linux caracteristic. All our tools (rpm...) and guidelines (FHS...) reflect this -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Mar 2 12:27:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 2 Mar 2007 13:27:28 +0100 (CET) Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <200703021208.38950@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <200703021208.38950@rineau.tsetse> Message-ID: <21717.192.54.193.51.1172838448.squirrel@rousalka.dyndns.org> Le Ven 2 mars 2007 12:08, Laurent Rineau a ?crit : > I really what a discussion. You may convince me and Ralf. But give good > reasons. AS far as I understand, the FSH does not state that sitewise > config files cannot be in /usr, The FHS states clearly: ? Any information that [...] varies with time is stored elsewhere. ? If a file doesn't vary with time it will be identical to the initial rpm file deployment and has no need of %config. End of demonstration (a config file that does not change is not a config file it's a static resource) The reason being that in addition to the /usr as a read-only network share (rw on the hosting server) case you focus on you have the /usr as a read-only rom volume case (also live CDs, etc). Also backup systems are not supposed to examine /usr for customizations. That does not mean every existing package is compliant (though the reason why we have a working multiuser system and windows not is we mostly apply our own guidelines). What it does mean is every package using %config in /usr should be examined on a case-by-case basis and a path to removing this %config agreed on. [X has always been a major special case, not a packaging example to emulate even ignoring the fact core fonts are a legacy part of it. xorg is not finished cleaning up the codebase in inherited from xfree86] -- Nicolas Mailhot From pertusus at free.fr Fri Mar 2 12:55:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 Mar 2007 13:55:28 +0100 Subject: The FHS /usr song In-Reply-To: <200703021306.31937@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021208.38950@rineau.tsetse> <45E80DE3.30500@city-fan.org> <200703021306.31937@rineau.tsetse> Message-ID: <20070302125528.GC2912@free.fr> On Fri, Mar 02, 2007 at 01:06:31PM +0100, Laurent Rineau wrote: > > In an ideal word, I would have preferred that any configuration file that has > a meaning in a site-wise configuration exists in both /etc/ and /usr. And there should be a third configuration file which would contain the vendor/packager/upstream defaults, which would change on updates without breaking users config and sometimes be necessary to have the software still working correctly. -- Pat From rc040203 at freenet.de Fri Mar 2 14:00:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 15:00:06 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070302103646.GE17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> <200703012036.06877@rineau.tsetse> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> Message-ID: <1172844006.26830.165.camel@mccallum.corsepiu.local> 1. You are over-interpreting the FHS: * It nowhere says, admins must not modify/customize files below /usr. * It nowhere says, admins must not install files outside of rpm's control. * It nowhere says, /usr is "vendor-exclusive". * it nowhere says installation must be performed read-only (this would be ridiculous). * read-only only makes sense at run-time. Anybody with a little knowledge on the FHS's history knows that, when they say "read-only", they mean "read-only at run-time", in the sense of setting "/usr" read-only to prevent arbitrary users/program to write their for "security-reason". font.alias is not affected by this at all. 2. %config is NOT related to this topic at all. It's about whether rpm knows whether it shall override a file by brute force or play it nice to the user. It doesn't affect the ability to set /usr read-only at all. 3. The font.alias and mkfontdir stuff actually is a very simple, but elegant concept to provide some sort of distributed database, without having bloat a package with scattered files all over the filesystem. You can find several other packages applying similar working principles all over a linux system. 4. The font.alias/mkfontdir approach is part of the traditional X11-packaging for a very long time (ca. 1990) and predates the FHS and Linux. Ralf From rc040203 at freenet.de Fri Mar 2 14:00:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 15:00:53 +0100 Subject: The FHS /usr song In-Reply-To: <20070302125528.GC2912@free.fr> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021208.38950@rineau.tsetse> <45E80DE3.30500@city-fan.org> <200703021306.31937@rineau.tsetse> <20070302125528.GC2912@free.fr> Message-ID: <1172844053.26830.167.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 13:55 +0100, Patrice Dumas wrote: > On Fri, Mar 02, 2007 at 01:06:31PM +0100, Laurent Rineau wrote: > > > > In an ideal word, I would have preferred that any configuration file that has > > a meaning in a site-wise configuration exists in both /etc/ and /usr. > > And there should be a third configuration file which would contain the > vendor/packager/upstream defaults, which would change on updates without > breaking users config and sometimes be necessary to have the software > still working correctly. In practice, such concepts don't work, because each party involved into integrating a package into a system, thinks in different categories based on their (necessarily limited) personal background. Ralf From pertusus at free.fr Fri Mar 2 14:01:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 Mar 2007 15:01:07 +0100 Subject: orphaning ivman Message-ID: <20070302140107.GF2912@free.fr> Hello, I have submitted ivman and it was approved https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208737 but I have never built it and I allready would like to orphan it for the following reasons: * the maintainer is not interested in maintaining ivman anymore because he is not happy with some element of the design of ivman * there is no default conf for the vendor nor real local conf, only per-user conf * there is a potential license issue * I wrote a substitute http://www.environnement.ens.fr/perso/dumas/halevt.html I don't think the license issue is so problematic that we have to remove the files (it is only an issue of conflicting licenses for different people that contributed to the software), but it seems to me that the new package maintainer should solve that issue. -- Pat From jwboyer at jdub.homelinux.org Fri Mar 2 14:23:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 02 Mar 2007 08:23:27 -0600 Subject: ddclient co-maintainer Message-ID: <1172845407.2839.31.camel@vader.jdub.homelinux.org> Hi All, So it seems I'm a bit busier than I thought lately and I'm looking for a co-maintainer for ddclient. If anyone is interested, feel free to let me know. josh From nicolas.mailhot at laposte.net Fri Mar 2 14:49:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 2 Mar 2007 15:49:50 +0100 (CET) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <1172844006.26830.165.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070301.220324.1739019135.tagoh@redhat.com> <20070301133057.GC10127@neu.nirvana> <200703012036.06877@rineau.tsetse> <20070301220550.GA31912@neu.nirvana> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> <1172844006.26830.165.camel@mccallum.corsepiu.local> Message-ID: <45442.192.54.193.51.1172846990.squirrel@rousalka.dyndns.org> Le Ven 2 mars 2007 15:00, Ralf Corsepius a ?crit : > 2. %config is NOT related to this topic at all. %config is about marking files that can legitimately be modified in the future. As already noted, the FHS clearly states /usr is not a legitimate place for files that can change ot be modified Also, * the FHS does not need to state explicitely every consequence of a clearly written rule * the FHS is explicitely concerned with ROM / not just your network share example. Depend on RW /usr for config and you lose big time on an a ROM system or at backup time It's perfectly true everyone didn't make the same choices as the FHS or Fedora. So what? We don't %prefix our GNOME packages because some people like it in /opt -- Nicolas Mailhot From ville.skytta at iki.fi Fri Mar 2 15:27:23 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 2 Mar 2007 17:27:23 +0200 Subject: ddclient co-maintainer In-Reply-To: <1172845407.2839.31.camel@vader.jdub.homelinux.org> References: <1172845407.2839.31.camel@vader.jdub.homelinux.org> Message-ID: <200703021727.24154.ville.skytta@iki.fi> On Friday 02 March 2007, Josh Boyer wrote: > So it seems I'm a bit busier than I thought lately and I'm looking for a > co-maintainer for ddclient. If anyone is interested, feel free to let > me know. Hm, Thomas (Cc'd) is already in initialcclist, is that just a Cc or is he already a co-maintainer? Either way, feel free to add me if more eyes are needed. From jwboyer at jdub.homelinux.org Fri Mar 2 15:27:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 02 Mar 2007 09:27:34 -0600 Subject: ddclient co-maintainer In-Reply-To: <200703021727.24154.ville.skytta@iki.fi> References: <1172845407.2839.31.camel@vader.jdub.homelinux.org> <200703021727.24154.ville.skytta@iki.fi> Message-ID: <1172849254.2839.39.camel@vader.jdub.homelinux.org> On Fri, 2007-03-02 at 17:27 +0200, Ville Skytt? wrote: > On Friday 02 March 2007, Josh Boyer wrote: > > > So it seems I'm a bit busier than I thought lately and I'm looking for a > > co-maintainer for ddclient. If anyone is interested, feel free to let > > me know. > > Hm, Thomas (Cc'd) is already in initialcclist, is that just a Cc or is he > already a co-maintainer? Either way, feel free to add me if more eyes are > needed. Yeah, there's some confusion there. Thomas orphaned it, I picked it up, but initialcc is still set. I don't care either way. There's two bugs open (by you) that need fixing and I just don't have time at the moment. If anyone wants to fix those up, feel free. The ACLs should be open. There's a start for the fixes even. josh From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 2 17:10:32 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 02 Mar 2007 18:10:32 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703021149.59810@rineau.tsetse> (Laurent Rineau's message of "Fri, 2 Mar 2007 11:49:59 +0100") References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <1172806333.26830.40.camel@mccallum.corsepiu.local> <20070302103646.GE17966@neu.nirvana> <200703021149.59810@rineau.tsetse> Message-ID: <87y7mfd113.fsf@kosh.bigo.ensc.de> laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) writes: > *I* mean that your reading o the FHS is too strict. How could a /usr partition > be read-only during a yum update, for example? Add | %_netsharedpath /usr to /etc/rpm/macros Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 2 17:16:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 12:16:36 -0500 Subject: Reduction of Fedora releases Message-ID: <200703021216.39477.jkeating@redhat.com> In an effort to make Bugzilla easier to use, we've been experimenting with not creating new versions of Fedora for every test release. Reason being is that the typical response to a bug filed against a test release is a request to duplicate it with the current development package set. It also makes it harder for a user to find dups of a bug they're about to file if they have to search through N testN versions. Instead we're asking all bugs encountered in test releases to be filed against devel. (yes you may still get asked to repro with current devel packages, but at least the bug will be assigned to the right release then). I didn't communicate this experiment clearly last time around and an fc7test1 bugzilla version got created. We're killing that and moving all the bugs to the devel version. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Fri Mar 2 18:13:02 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 02 Mar 2007 10:13:02 -0800 Subject: Proposed guideline for init script files In-Reply-To: <20070228111726.3207602a@python3.es.egwn.lan> References: <200702271537.36532.jkeating@redhat.com> <20070228111726.3207602a@python3.es.egwn.lan> Message-ID: <1172859182.27848.143.camel@localhost.localdomain> On Wed, 2007-02-28 at 11:17 +0100, Matthias Saou wrote: > - Which commands should be mandatory and which optional (start, stop, > restart, condrestart and status are the most expected ones, reload > doesn't always make sense). This is getting OT for this thread, but the LSB defines some of this in great detail [1] - we should probably at least pull the requirements on status exit codes into the guidelines, since that is extremely important for automating service management. David [1] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 18:33:20 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 19:33:20 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <87y7mfd113.fsf@kosh.bigo.ensc.de> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021149.59810@rineau.tsetse> <87y7mfd113.fsf@kosh.bigo.ensc.de> Message-ID: <200703021933.21148@rineau.tsetse> On Friday 02 March 2007 18:10:32 Enrico Scholz wrote: > laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) writes: > > *I* mean that your reading o the FHS is too strict. How could a /usr > > partition be read-only during a yum update, for example? > > Add > > | %_netsharedpath /usr > > to /etc/rpm/macros And on the NFS server? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 18:47:41 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 19:47:41 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <20070302121003.GI17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021208.38950@rineau.tsetse> <20070302121003.GI17966@neu.nirvana> Message-ID: <200703021947.42175@rineau.tsetse> On Friday 02 March 2007 13:10:03 Axel Thimm wrote: > On Fri, Mar 02, 2007 at 12:08:38PM +0100, Laurent Rineau wrote: > > I quote below the FHS version 2.3, given at > > http://www.pathname.com/fhs/pub/fhs-2.3.pdf > > > > ===== quote ===== > > Chapter 4. The /usr Hierarchy > > > > 4.1. Purpose > > > > /usr is the second major section of the ?lesystem. /usr is shareable, > > read-only data. That means that /usr > > should be shareable between various FHS-compliant hosts and must not be > > written to. Any information that is > > host-speci?c or varies with time is stored elsewhere. > > Large software packages must not use a direct subdirectory under the /usr > > hierarchy. > > ===== end of quote ===== > > Ahem, isn't that exactly the quote I gave yesterday? :) Yes, exactly. I have requoted it to have a self-consistant email, more understable if possible. And I wanted to give the whole quotation, without any ellipsis. > > >From the sentence "Any information that is host-speci?c or varies with > > > time is > > > > stored elsewhere.", how could you understand that *sitewise* > > configuration files must be in /etc?! > > I understand that they must not be in /usr. This sentence does not say > where to put them, but the FHS has an /etc section as well. Just in case it is not clear, my point is that all config file must have an instance in /etc/. However, I do not see anything in the FHS that prevent to have another instance in /usr/. For example, /usr/share/X11/app-defaults/XTerm could be %config, *but* there should exists another Xressource file about xterm in /etc/X11/. Actually /etc/X11/Xresources can already overrides things from /usr/share/X11/app-defaults/XTerm AFAIK. I do not see why we prevent all our users from modifying /usr/share/X11/app-defaults/XTerm, as soon as we provide them a way to do the same thing in /etc/. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From jkeating at redhat.com Fri Mar 2 18:55:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 13:55:50 -0500 Subject: Proposed guideline for init script files In-Reply-To: <1172859182.27848.143.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <20070228111726.3207602a@python3.es.egwn.lan> <1172859182.27848.143.camel@localhost.localdomain> Message-ID: <200703021355.50164.jkeating@redhat.com> On Friday 02 March 2007 13:13:02 David Lutterkort wrote: > This is getting OT for this thread, but the LSB defines some of this in > great detail [1] - we should probably at least pull the requirements on > status exit codes into the guidelines, since that is extremely important > for automating service management. I'm all for extending the guidelines on init scripts in the future. I'd like to get this start done and up in the wiki before adding more too it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Fri Mar 2 05:27:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 Mar 2007 20:27:31 -0900 Subject: Proposed guideline for init script files In-Reply-To: <20070228164849.f5864c62.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> Message-ID: <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> On 2/28/07, Michael Schwendt wrote: > It's called "to mess around in a system". Admins, who do that, often > forget what files they've changed, and "rpm -Va" only reports the changed > checksum, not a diff. Hmmm, how much secret sauce would it take to make it easy to get a diff of changes for scripts files which fail an rpm -V check. Probably not really worth the pain of attempting to kludge together. -jef"goes off to sandwhich yumdownloader, rpm -V, rpm2cpio and diff together inside a delicious perl wrapper"spaleta From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 2 19:21:21 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 02 Mar 2007 20:21:21 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <200703021933.21148@rineau.tsetse> (Laurent Rineau's message of "Fri, 2 Mar 2007 19:33:20 +0100") References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021149.59810@rineau.tsetse> <87y7mfd113.fsf@kosh.bigo.ensc.de> <200703021933.21148@rineau.tsetse> Message-ID: <87tzx3cuz2.fsf@kosh.bigo.ensc.de> laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) writes: >> > *I* mean that your reading o the FHS is too strict. How could a /usr >> > partition be read-only during a yum update, for example? >> >> | %_netsharedpath /usr > > And on the NFS server? The NFS server (and the host which is responsible for filling /usr) does not have the exported /usr mounted ro and does not need this setting. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 2 19:48:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Mar 2007 20:48:19 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <200703021947.42175@rineau.tsetse> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021208.38950@rineau.tsetse> <20070302121003.GI17966@neu.nirvana> <200703021947.42175@rineau.tsetse> Message-ID: <20070302194819.GN31478@neu.nirvana> On Fri, Mar 02, 2007 at 07:47:41PM +0100, Laurent Rineau wrote: > I do not see why we prevent all our users from modifying > /usr/share/X11/app-defaults/XTerm, as soon as we provide them a way > to do the same thing in /etc/. Sigh. :( This is not about what /etc is missing, but what /usr has too much. If you allow modification under /usr in general you shoot off the applications that need to assume /usr not being edited by Joe Admin Random. The FHS tries to setup standards so some assertions can hold true. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Mar 2 20:07:18 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 Mar 2007 12:07:18 -0800 Subject: Proposed guideline for init script files In-Reply-To: <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> Message-ID: <1172866038.20343.105.camel@localhost.localdomain> On Thu, 2007-03-01 at 20:27 -0900, Jeff Spaleta wrote: > On 2/28/07, Michael Schwendt wrote: > > It's called "to mess around in a system". Admins, who do that, often > > forget what files they've changed, and "rpm -Va" only reports the changed > > checksum, not a diff. > > Hmmm, how much secret sauce would it take to make it easy to get a > diff of changes for scripts files which fail an rpm -V check. Probably > not really worth the pain of attempting to kludge together. > > -jef"goes off to sandwhich yumdownloader, rpm -V, rpm2cpio and diff > together inside a delicious perl wrapper"spaleta > Luke Macken, Will Woods, and I were talking about something just a little less ambitious at FudCON. Just keeping a history of config files. Here's a bit of a hack that could get you started. The one glaring problem that I see with it is that it doesn't keep a copy of the original file. ie: When I want to see the change, I probably want a diff3 between the original file, my modified file, and the file rpm is going to install. Without the original, I can only see the changes between my modified file and the new one. REPO="/var/lib/rpmcraziness" VCSCOMMIT="/usr/bin/bzr commit" package=sys.argv[1] changedFiles=os.popen("rpm -V %s" % package) for fileLine in changedFiles: fileParts=fileLine.split() filename=fileParts[-1] if is_text_file(filename): shutil.copy2(filename, os.path.join(REPO, filename[1:]) os.system("%s %s" % (VCSCOMMIT, REPO)) You'll have to write is_text_file() yourself as my imagination ends there :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Fri Mar 2 20:30:17 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 02 Mar 2007 15:30:17 -0500 Subject: Proposed guideline for init script files In-Reply-To: <1172866038.20343.105.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> <1172866038.20343.105.camel@localhost.localdomain> Message-ID: <1172867417.22136.172.camel@localhost.localdomain> On Fri, 2007-03-02 at 12:07 -0800, Toshio Kuratomi wrote: > On Thu, 2007-03-01 at 20:27 -0900, Jeff Spaleta wrote: > > On 2/28/07, Michael Schwendt wrote: > > > It's called "to mess around in a system". Admins, who do that, often > > > forget what files they've changed, and "rpm -Va" only reports the changed > > > checksum, not a diff. > > > > Hmmm, how much secret sauce would it take to make it easy to get a > > diff of changes for scripts files which fail an rpm -V check. Probably > > not really worth the pain of attempting to kludge together. > > > > -jef"goes off to sandwhich yumdownloader, rpm -V, rpm2cpio and diff > > together inside a delicious perl wrapper"spaleta > > > Luke Macken, Will Woods, and I were talking about something just a > little less ambitious at FudCON. Just keeping a history of config > files. Here's a bit of a hack that could get you started. The one > glaring problem that I see with it is that it doesn't keep a copy of the > original file. ie: When I want to see the change, I probably want a > diff3 between the original file, my modified file, and the file rpm is > going to install. Without the original, I can only see the changes > between my modified file and the new one. The last time this discussion came up, I suggested someone just go steal code and/or ideas from Gentoo's etc-update, and no one seems to have done so. It's not like this is a new problem. - ajax From ville.skytta at iki.fi Fri Mar 2 20:45:18 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 2 Mar 2007 22:45:18 +0200 Subject: Proposed guideline for init script files In-Reply-To: <1172866038.20343.105.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> <1172866038.20343.105.camel@localhost.localdomain> Message-ID: <200703022245.18584.ville.skytta@iki.fi> On Friday 02 March 2007, Toshio Kuratomi wrote: > changedFiles=os.popen("rpm -V %s" % package) > for fileLine in changedFiles: > fileParts=fileLine.split() > filename=fileParts[-1] > if is_text_file(filename): > shutil.copy2(filename, os.path.join(REPO, filename[1:]) > os.system("%s %s" % (VCSCOMMIT, REPO)) > > You'll have to write is_text_file() yourself as my imagination ends > there :-) rpmlint's FilesCheck.py has istextfile() which could save some work there. http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/FilesCheck.py From laurent.rineau__fedora_extras at normalesup.org Fri Mar 2 21:20:26 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 2 Mar 2007 22:20:26 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <20070302194819.GN31478@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703021947.42175@rineau.tsetse> <20070302194819.GN31478@neu.nirvana> Message-ID: <200703022220.26621@rineau.tsetse> On Friday 02 March 2007 20:48:19 Axel Thimm wrote: > On Fri, Mar 02, 2007 at 07:47:41PM +0100, Laurent Rineau wrote: > > I do not see why we prevent all our users from modifying > > /usr/share/X11/app-defaults/XTerm, as soon as we provide them a way > > to do the same thing in /etc/. > > Sigh. :( > > This is not about what /etc is missing, but what /usr has too much. > > If you allow modification under /usr in general you shoot off the > applications that need to assume /usr not being edited by Joe Admin > Random. All right, I get your point. I eventually agree with your understanding of the FHS. All config files in /usr should be moved, if possible, to /etc/. The FHS authors should have thought about sitewise configuration files, but that is another problem. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From sundaram at fedoraproject.org Fri Mar 2 21:39:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 Mar 2007 03:09:09 +0530 Subject: Proposed guideline for init script files In-Reply-To: <1172867417.22136.172.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> <1172866038.20343.105.camel@localhost.localdomain> <1172867417.22136.172.camel@localhost.localdomain> Message-ID: <45E8997D.5090609@fedoraproject.org> Adam Jackson wrote: > On Fri, 2007-03-02 at 12:07 -0800, Toshio Kuratomi wrote: >> On Thu, 2007-03-01 at 20:27 -0900, Jeff Spaleta wrote: >>> On 2/28/07, Michael Schwendt wrote: >>>> It's called "to mess around in a system". Admins, who do that, often >>>> forget what files they've changed, and "rpm -Va" only reports the changed >>>> checksum, not a diff. >>> Hmmm, how much secret sauce would it take to make it easy to get a >>> diff of changes for scripts files which fail an rpm -V check. Probably >>> not really worth the pain of attempting to kludge together. >>> >>> -jef"goes off to sandwhich yumdownloader, rpm -V, rpm2cpio and diff >>> together inside a delicious perl wrapper"spaleta >>> >> Luke Macken, Will Woods, and I were talking about something just a >> little less ambitious at FudCON. Just keeping a history of config >> files. Here's a bit of a hack that could get you started. The one >> glaring problem that I see with it is that it doesn't keep a copy of the >> original file. ie: When I want to see the change, I probably want a >> diff3 between the original file, my modified file, and the file rpm is >> going to install. Without the original, I can only see the changes >> between my modified file and the new one. > > The last time this discussion came up, I suggested someone just go steal > code and/or ideas from Gentoo's etc-update, and no one seems to have > done so. > > It's not like this is a new problem. > http://www.redhat.com/archives/fedora-devel-list/2006-July/msg00286.html It is available as RPM even for Fedora is some third party repositories. Rahul From a.badger at gmail.com Fri Mar 2 21:24:07 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 Mar 2007 13:24:07 -0800 Subject: New place for Extras pages in the wiki In-Reply-To: <45E7CB7C.2070808@leemhuis.info> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> <45E6942F.6090607@leemhuis.info> <45E70C3F.2050603@fedoraproject.org> <45E7C1F9.1040204@leemhuis.info> <1172817355.26830.60.camel@mccallum.corsepiu.local> <45E7CB7C.2070808@leemhuis.info> Message-ID: <1172870647.20343.136.camel@localhost.localdomain> On Fri, 2007-03-02 at 08:00 +0100, Thorsten Leemhuis wrote: > On 02.03.2007 07:35, Ralf Corsepius wrote: > > On Fri, 2007-03-02 at 07:19 +0100, Thorsten Leemhuis wrote: > >> On 01.03.2007 18:24, Rahul Sundaram wrote: > >>> Thorsten Leemhuis wrote: > >>>> like to avoid). The FESCo pages would be moved to FESCo/ maybe. > >>> What is the opinion of the Packaging Committee and others on this move? > >> No idea, they should all be on this list, so they hopefully speak up. > > IMO, these package do not belong into a "FPC owned" Packaging directories. > > > > "official FPC" and "community contributed pages" should be strictly > > separated. Whether "Packaging" should be "FPC owned/controlled" is > > different question. > > Yes -- the stuff from the PC could be moved to the Packaging/Guidelines/ > and the organizational stuff (meeting schedule, guidelines drafts) could > be under FPC/ or PackagingCommittee/ (and that from FESCo below FESCo/ > That's one option. To me, the current Extras front page has six sections of which one is for end-users and the other five are for contributors. The end-user one should be merged into the front-page/rest of the site just as Extras and Core repositories are being merged. The contributor pages could replace /Packaging as you suggest or into /Contributors /Developers etc. I can see the organizational view you want to build looking something like this: / == All of Fedora /Ambassadors /Marketing /Packaging /AdminRequests /DraftGuidelines /FESCo /Guidelines /PackagingCommittee /Policy It makes logical sense. But it does mean we have to make a lot of changes to links on every page. I don't see it as being a huge amount more work to move /Packaging => /Guidelines compared to /Extras => /Packaging, though. So I'll go along with anything as long as the Guidelines continue to exist in a non-user editable location. (Although streamlining the creation, submission, revising, and approval of new guidelines from non-committee folks would be nice. /PackagingDrafts is a start but it doesn't go far enough.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From panemade at gmail.com Fri Mar 2 07:02:42 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 2 Mar 2007 12:32:42 +0530 Subject: Fonts scriptlet for CORE packages Message-ID: Hi, While doing reviews of fonts packages in core, i got confused on post and postun sections (to check) of those packages as they are using chkfontpath and mkfontdir and ttmkfdir but our standard scriptlet as given on http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 fonts scriptlets uses following as post section in SPEC. %post if [ -x /usr/bin/fc-cache ]; then /usr/bin/fc-cache /usr/share/fonts fi But some core packages(fonts-japanese,fonts-korean,fonts-chinese,xorg-x11-fonts) also want to use following under %post umask 133 touch %{ttfontdir} 2> /dev/null && { /usr/bin/ttmkfdir -d %{ttfontdir} -o %{ttfontdir}/fonts.scale mkfontdir %{ttfontdir} /usr/sbin/chkfontpath -q -a %{ttfontdir} } mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} (Sorry for copying above text with under defined macros. I just want to give example) Do we need to have alternative scriptlet that includes above lines for post section for fonts packages in CORE? Regards, Parag. From pertusus at free.fr Sat Mar 3 00:22:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 Mar 2007 01:22:24 +0100 Subject: Fonts scriptlet for CORE packages In-Reply-To: References: Message-ID: <20070303002224.GA12901@free.fr> On Fri, Mar 02, 2007 at 12:32:42PM +0530, Parag N(????) wrote: > > Do we need to have alternative scriptlet that includes above lines for > post section for fonts packages in CORE? I am not a specialist, but my findings is that it depends on the type of font. It could be different for bitmap fonts, type1 fonts and truetype fonts. I asked for more precise guidelines some time ago, but nobody was willing to answer. Now that it is more or less mandatory to be able to review core packages, hopefully things will be better. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Sat Mar 3 00:52:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 03 Mar 2007 09:52:42 +0900 Subject: Fonts scriptlet for CORE packages In-Reply-To: References: Message-ID: <45E8C6DA.5010005@ioa.s.u-tokyo.ac.jp> Parag N(????) wrote: > Hi, > While doing reviews of fonts packages in core, i got confused on > post and postun sections (to check) of those packages as they are > using chkfontpath and mkfontdir and ttmkfdir There are two font system on X Window System. They are "X11 core font system" and "Xft". While many newer applications such as GNOME/KDE applications use Xft, not a few applications still require X11 core font system. > %post > if [ -x /usr/bin/fc-cache ]; then > /usr/bin/fc-cache /usr/share/fonts > fi This is Xft > umask 133 > touch %{ttfontdir} 2> /dev/null && { > /usr/bin/ttmkfdir -d %{ttfontdir} -o %{ttfontdir}/fonts.scale > mkfontdir %{ttfontdir} > /usr/sbin/chkfontpath -q -a %{ttfontdir} > } > mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} This is X11 core font system. So if the packager expects that the fonts are used on X11 core font system, the procedure of "mkfontdir" and so on are necessary. Mamoru From peter at thecodergeek.com Sat Mar 3 03:39:04 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 02 Mar 2007 22:39:04 -0500 Subject: Would someone please kick the build system? :) Message-ID: <1172893144.3544.8.camel@tuxhugs> Hello, list. Would one of the Infrastructure admins please kick the build system (specifically xenbuilder2)? I submitted job 28667 (epiphany-extensions 2.17.92-1 for Development) over an hour ago, and it is still showing as "running/prepping," whereas the PPC builder is already finished. Unfortunately, there are no logs in the build system's directory for these arches, and so I can't tell if they are just stuck or simply taking an enormously long time to download/install the buildroot. Normally these builds tend to take only about 15 minutes or so... Detail for Job ID 28667 (epiphany-extensions): ---------------------------------------------- Source: epiphany-extensions-2_17_92-1 Target: fedora-development-extras Submitter: peter at thecodergeek.com Status: building/ Archjobs: i386: xenbuilder2.fedora.redhat.com running/prepping x86_64: xenbuilder2.fedora.redhat.com running/prepping ppc: ppc3.fedora.redhat.com done/done Thanks! -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Mar 3 02:16:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 Mar 2007 18:16:00 -0800 Subject: Proposed guideline for init script files In-Reply-To: <45E8997D.5090609@fedoraproject.org> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> <1172866038.20343.105.camel@localhost.localdomain> <1172867417.22136.172.camel@localhost.localdomain> <45E8997D.5090609@fedoraproject.org> Message-ID: <1172888160.20343.151.camel@localhost.localdomain> On Sat, 2007-03-03 at 03:09 +0530, Rahul Sundaram wrote: > Adam Jackson wrote: > > On Fri, 2007-03-02 at 12:07 -0800, Toshio Kuratomi wrote: > >> On Thu, 2007-03-01 at 20:27 -0900, Jeff Spaleta wrote: > >>> On 2/28/07, Michael Schwendt wrote: > >>>> It's called "to mess around in a system". Admins, who do that, often > >>>> forget what files they've changed, and "rpm -Va" only reports the changed > >>>> checksum, not a diff. > >>> Hmmm, how much secret sauce would it take to make it easy to get a > >>> diff of changes for scripts files which fail an rpm -V check. Probably > >>> not really worth the pain of attempting to kludge together. > >>> > >>> -jef"goes off to sandwhich yumdownloader, rpm -V, rpm2cpio and diff > >>> together inside a delicious perl wrapper"spaleta > >>> > >> Luke Macken, Will Woods, and I were talking about something just a > >> little less ambitious at FudCON. Just keeping a history of config > >> files. Here's a bit of a hack that could get you started. The one > >> glaring problem that I see with it is that it doesn't keep a copy of the > >> original file. ie: When I want to see the change, I probably want a > >> diff3 between the original file, my modified file, and the file rpm is > >> going to install. Without the original, I can only see the changes > >> between my modified file and the new one. > > > > The last time this discussion came up, I suggested someone just go steal > > code and/or ideas from Gentoo's etc-update, and no one seems to have > > done so. > > > > It's not like this is a new problem. > > From the discussion, etc-update seemed to lack the ability to do diff3 with the original file as well. Looking at the home page on gentoo's site, it looks like etc-update is just a merge tool, not a history tool. So you're often lacking context on a change (especially if it's a system that you've only recently taken over maintenance of.) Keeping a copy of each config file in a revision control system might be overkill but it would solve these kinds of problems. Keeping just original, modified, and new versions would go a long way. > http://www.redhat.com/archives/fedora-devel-list/2006-July/msg00286.html > > It is available as RPM even for Fedora is some third party repositories. The link posted there doesn't work, but www.rpmfind.net still has working links: http://www.rpmfind.net//linux/RPM/mandriva/10.0/contrib/i586/etc-update-20020731-5mdk.noarch.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sat Mar 3 04:10:32 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 02 Mar 2007 23:10:32 -0500 Subject: Would someone please kick the build system? :) In-Reply-To: <1172893144.3544.8.camel@tuxhugs> References: <1172893144.3544.8.camel@tuxhugs> Message-ID: <1172895032.3544.10.camel@tuxhugs> I killed and requeued it with plague-client and it seems to be chugging along now. Hopefully it completes this time. :O -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sat Mar 3 04:38:43 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 02 Mar 2007 20:38:43 -0800 Subject: Would someone please kick the build system? :) In-Reply-To: <1172895032.3544.10.camel@tuxhugs> References: <1172893144.3544.8.camel@tuxhugs> <1172895032.3544.10.camel@tuxhugs> Message-ID: <1172896723.3544.15.camel@tuxhugs> On Fri, 2007-03-02 at 23:10 -0500, Peter Gordon wrote: > I killed and requeued it with plague-client and it seems to be chugging > along now. Hopefully it completes this time. :O It went okay until it couldn't download the buildroot fully: > [...] > Trying other mirror. > Error: failure: Fedora/RPMS/libart_lgpl-devel-2.3.18-1.fc7.i386.rpm from core: [Errno 256] No more mirrors to try. > Cleaning up... *sigh* I suspect that this is merely a repo-syncing issue (though would greatly appreciate an official confirmation of that). I'll try it again tomorrow morning, or later tonight if I'm still awake. Thanks. -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sat Mar 3 06:24:50 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 02 Mar 2007 22:24:50 -0800 Subject: [Resolved] Re: Would someone please kick the build system? :) In-Reply-To: <1172893144.3544.8.camel@tuxhugs> References: <1172893144.3544.8.camel@tuxhugs> Message-ID: <1172903090.3544.22.camel@tuxhugs> It went through nicely now. Thanks to whoever gave it a good kicking. :) -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 3 10:36:42 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 03 Mar 2007 11:36:42 +0100 Subject: Fonts scriptlet for CORE packages In-Reply-To: (Parag N.'s message of "Fri, 2 Mar 2007 12:32:42 +0530") References: Message-ID: <87ejo6txz9.fsf@kosh.bigo.ensc.de> panemade at gmail.com (""Parag N(~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: -------------- next part -------------- ?)"") writes: > touch %{ttfontdir} 2> /dev/null && { > /usr/bin/ttmkfdir -d %{ttfontdir} -o %{ttfontdir}/fonts.scale > mkfontdir %{ttfontdir} > /usr/sbin/chkfontpath -q -a %{ttfontdir} > } > mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} This should expressed in a way that it does not fail when /usr is mounted read-only. E.g. | ! touch %ttfontdir 2>/dev/null || { ... | mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} || : Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Mar 3 17:49:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 3 Mar 2007 12:49:39 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-03-03 Message-ID: <20070303174939.D8C2615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) eclipse FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) andreas.bierfert AT lowlatency.de: claws-mail-plugins FE5 > FE7 (0:2.8.0-1.fc5 > 0:2.7.1-2.fc7) FE6 > FE7 (0:2.8.0-1.fc6 > 0:2.7.1-2.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) paul AT city-fan.org: grepmail FE5 > FE7 (0:5.3033-1.fc5 > 0:5.3032-5.fc7) FE6 > FE7 (0:5.3033-1.fc6 > 0:5.3032-5.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rc040203 AT freenet.de: perl-DBIx-SearchBuilder FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) claws-mail-plugins: andreas.bierfert AT lowlatency.de FE5 > FE7 (0:2.8.0-1.fc5 > 0:2.7.1-2.fc7) FE6 > FE7 (0:2.8.0-1.fc6 > 0:2.7.1-2.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) grepmail: paul AT city-fan.org FE5 > FE7 (0:5.3033-1.fc5 > 0:5.3032-5.fc7) FE6 > FE7 (0:5.3033-1.fc6 > 0:5.3032-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) perl-DBIx-SearchBuilder: rc040203 AT freenet.de FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive: rc040203 AT freenet.de FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util: rc040203 AT freenet.de FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted: rc040203 AT freenet.de FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From bpepple at fedoraproject.org Sun Mar 4 18:00:40 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 04 Mar 2007 13:00:40 -0500 Subject: FESCo Meeting Summary for 2007-03-01 Message-ID: <1173031240.9205.6.camel@Chuck> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Josh Boyer (jwb) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) === Absent === * Tom Callaway (spot) * Warren Togami (warren) == Summary == repo-creation using new createrepo * f13 is currently working on using the new createrepo in the development branch. * There is no plan to use the new createrepo in FC6. Sponsor Nominations * Fernando Nasser was nominated and accepted as a new sponsor. Fedora 7 preparation * the plan is not to do a mass rebuild of extras packages. * nirik is going to setup a page on the wiki to track other preparation issues that we need to track for F7. Packaging Committee Report * FESCo approved the Packaging Committee's guidelines regarding: * InitScripts proposal: http://fedoraproject.org/wiki/PackagingDrafts/InitScripts * BuildRoot proposal: http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Mar 4 18:23:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Mar 2007 19:23:35 +0100 Subject: FPC Meeting Summaries? (Re: FESCo Meeting Summary for 2007-03-01) In-Reply-To: <1173031240.9205.6.camel@Chuck> References: <1173031240.9205.6.camel@Chuck> Message-ID: <45EB0EA7.8030405@leemhuis.info> Brian Pepple schrieb: > [...] > Packaging Committee Report > * FESCo approved the Packaging Committee's guidelines regarding: > * InitScripts proposal: > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts > * BuildRoot proposal: > http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot Just wondering: Why isn't the PC sending any reports/summaries to fedora-maintainers anymore (or did I miss them all in the past weeks?)? That was part of the arrangement between FESCo and FPC iirc; to quote http://www.fedoraproject.org/wiki/Extras/Schedule "A representative from the packaging committee will send a report after each committee meeting to fedora-maintainers at redhat.com for public discussion. In order to give ample discussion time, this report should be sent no less than 24 hours before the next FESCo meeting; if the report is late, the veto period will be extended by one additional FESCo meeting. FESCo may also extend the veto period if there is still ongoing discussion." That text should be adjusted if the arrangement got changed. But I think Meeting summaries from the FPC with a short notice what got accepted (like Brian did in his FESCo report) are quite important. Yes, I know that it's hard work (I did FESCo reports myself for quite some time), and no, I'm not volunteering to do it myself, as I don't follow the FPCs meetings/discussions that closely (and that's the reasons why I'd like to have a summary). CU thl From jkeating at redhat.com Sun Mar 4 20:50:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Mar 2007 15:50:40 -0500 Subject: FPC Meeting Summaries? (Re: FESCo Meeting Summary for 2007-03-01) In-Reply-To: <45EB0EA7.8030405@leemhuis.info> References: <1173031240.9205.6.camel@Chuck> <45EB0EA7.8030405@leemhuis.info> Message-ID: <200703041550.40349.jkeating@redhat.com> On Sunday 04 March 2007 13:23:35 Thorsten Leemhuis wrote: > Just wondering: Why isn't the PC sending any reports/summaries to > fedora-maintainers anymore (or did I miss them all in the past weeks?)? > That was part of the arrangement between FESCo and FPC iirc; to quote > http://www.fedoraproject.org/wiki/Extras/Schedule It's supposed to be the person bringing the draft to the PC that takes care of sending information regarding passed drafts to Maintainers list. In my case, I did communicate about the initscript draft. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Mon Mar 5 02:46:30 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 04 Mar 2007 20:46:30 -0600 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <1173062790.18771.37.camel@localhost.localdomain> Down this path lies only sorrow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Mon Mar 5 03:47:18 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 04 Mar 2007 22:47:18 -0500 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <20070302104652.GF17966@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> Message-ID: <1173066438.3896.12.camel@localhost.localdomain> How exactly do you propose packages should install anything under /usr if its readonlyness is so sacrosanct ? Does it at least occur to you that it cannot be readonly at install time ? From guthrie at counterexample.org Mon Mar 5 05:47:49 2007 From: guthrie at counterexample.org (John T. Guthrie) Date: Mon, 05 Mar 2007 00:47:49 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: <1173073669.4441.11.camel@euler.counterexample.org> On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > The Packaging Committee has been discussing guidelines for init scripts for a > while. Currently there is a split between init scripts being marked > as %config and many that aren't. We (the PC) with input from various folks > feel it is best to not mark init scripts as %config, and instead promote > configuration to happen in an /etc/sysconfig/ file. Mostly the reason > being that init scripts are just that, scripts to run and not config files to > edit. As such I've drafted a proposal for the guidelines and the PC approved > it. There is time now for a wider audience to review the proposed change and > comment. > > Please take a moment to read through > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some > feedback. If nobody has major objections or reasonable adjustments, this > will become policy in a week's time. I apologize for the slightly late reply. I've been trying to get caught up on email. I do like this idea with two provisos: 1) That a recommendation be put in about each init script needs to include an OPTIONS or PROGOPTS or similar variable on its command-line. This allows customization through addition of command-line arguments. 2) That initscripts be discouraged from putting command-line arguments directly in the scripts. Instead they should be placed in the variable from part 1) in /etc/sysconfig/progname. Putting command-line arguments directly into the init script means that I can't remove those arguments without modifying the init script. There could be some exceptions to this guideline. An example would be something to set the uid of the program in question, such as adding "-u named" in the script to start named. To my current memory, these two situations cover every time that I have needed to modify an init script. (There might be others I can't think of, though.) -- John Guthrie guthrie at counterexample.org From fedora at leemhuis.info Mon Mar 5 05:55:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 06:55:40 +0100 Subject: FPC Meeting Summaries? (Re: FESCo Meeting Summary for 2007-03-01) In-Reply-To: <200703041550.40349.jkeating@redhat.com> References: <1173031240.9205.6.camel@Chuck> <45EB0EA7.8030405@leemhuis.info> <200703041550.40349.jkeating@redhat.com> Message-ID: <45EBB0DC.3080803@leemhuis.info> On 04.03.2007 21:50, Jesse Keating wrote: > On Sunday 04 March 2007 13:23:35 Thorsten Leemhuis wrote: >> Just wondering: Why isn't the PC sending any reports/summaries to >> fedora-maintainers anymore (or did I miss them all in the past weeks?)? >> That was part of the arrangement between FESCo and FPC iirc; to quote >> http://www.fedoraproject.org/wiki/Extras/Schedule > It's supposed to be the person bringing the draft to the PC that takes care of > sending information regarding passed drafts to Maintainers list. In my case, > I did communicate about the initscript draft. Thx for doing this. Nevertheless I think having at least rough meeting summaries is normally (?) a must -- especially when things got approved/voted upon. There are not even the IRC logs in the wiki from the past two meetings afaics: http://www.fedoraproject.org/wiki/Packaging/Minutes CU thl (?) -- sometimes meetings are more a general chat and then it might not make to much sense trying to sum them up From enrico.scholz at informatik.tu-chemnitz.de Mon Mar 5 06:55:16 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 05 Mar 2007 07:55:16 +0100 Subject: The FHS /usr song In-Reply-To: <1173066438.3896.12.camel@localhost.localdomain> (Matthias Clasen's message of "Sun, 04 Mar 2007 22:47:18 -0500") References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> Message-ID: <87bqj8i3hn.fsf@kosh.bigo.ensc.de> Matthias Clasen writes: > How exactly do you propose packages should install anything under /usr > if its readonlyness is so sacrosanct ? Does it at least occur to you > that it cannot be readonly at install time ? Add | %_netsharedpath /usr to /etc/rpm/macros Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Mar 5 08:33:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 Mar 2007 09:33:27 +0100 (CET) Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <1173066438.3896.12.camel@localhost.localdomain> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> Message-ID: <31398.192.54.193.51.1173083607.squirrel@rousalka.dyndns.org> Le Lun 5 mars 2007 04:47, Matthias Clasen a ?crit : > How exactly do you propose packages should install anything under /usr > if its readonlyness is so sacrosanct ? Does it at least occur to you > that it cannot be readonly at install time ? And besides install != config time (Bis repetita) -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Mon Mar 5 11:11:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:11:44 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <1173066438.3896.12.camel@localhost.localdomain> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> Message-ID: <20070305111144.GH29562@neu.nirvana> On Sun, Mar 04, 2007 at 10:47:18PM -0500, Matthias Clasen wrote: > How exactly do you propose packages should install anything under /usr > if its readonlyness is so sacrosanct ? Does it at least occur to you > that it cannot be readonly at install time ? Please don't be so literate, we already looped twice around the world explaining this. If you read it letter by letter and ignore FHS' intentions you may indeed logically conclude that /usr would be an empty filesystem, but try reading the full context. The bottom line is: Don't %config/%config(noreplace) files under /usr. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 5 11:14:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:14:40 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <31398.192.54.193.51.1173083607.squirrel@rousalka.dyndns.org> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <31398.192.54.193.51.1173083607.squirrel@rousalka.dyndns.org> Message-ID: <20070305111440.GI29562@neu.nirvana> On Mon, Mar 05, 2007 at 09:33:27AM +0100, Nicolas Mailhot wrote: > > Le Lun 5 mars 2007 04:47, Matthias Clasen a ?crit : > > How exactly do you propose packages should install anything under /usr > > if its readonlyness is so sacrosanct ? Does it at least occur to you > > that it cannot be readonly at install time ? > > And besides install != config time > (Bis repetita) ... non placet ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Mar 5 11:39:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Mar 2007 12:39:09 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <20070305111144.GH29562@neu.nirvana> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> Message-ID: <1173094749.25839.16.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 12:11 +0100, Axel Thimm wrote: > On Sun, Mar 04, 2007 at 10:47:18PM -0500, Matthias Clasen wrote: > > How exactly do you propose packages should install anything under /usr > > if its readonlyness is so sacrosanct ? Does it at least occur to you > > that it cannot be readonly at install time ? > > Please don't be so literate, we already looped twice around the world > explaining this. If you read it letter by letter and ignore FHS' > intentions you may indeed logically conclude that /usr would be an > empty filesystem, but try reading the full context. > > The bottom line is: Don't %config/%config(noreplace) files under /usr. 1. When will you finally understand that rpm's %config has nothing to do with configurating a system. %config only specifies rpm's behavior upon handling of backups upon install. 2. When a file-system is read-only, rpm can neither install the files, nor create backups => The fact a file is marked %config is completely irrelevant. From Axel.Thimm at ATrpms.net Mon Mar 5 11:52:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:52:33 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <1173094749.25839.16.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> Message-ID: <20070305115233.GL29562@neu.nirvana> On Mon, Mar 05, 2007 at 12:39:09PM +0100, Ralf Corsepius wrote: > On Mon, 2007-03-05 at 12:11 +0100, Axel Thimm wrote: > > On Sun, Mar 04, 2007 at 10:47:18PM -0500, Matthias Clasen wrote: > > > How exactly do you propose packages should install anything under /usr > > > if its readonlyness is so sacrosanct ? Does it at least occur to you > > > that it cannot be readonly at install time ? > > > > Please don't be so literate, we already looped twice around the world > > explaining this. If you read it letter by letter and ignore FHS' > > intentions you may indeed logically conclude that /usr would be an > > empty filesystem, but try reading the full context. > > > > The bottom line is: Don't %config/%config(noreplace) files under /usr. > > 1. When will you finally understand that rpm's %config has nothing to do > with configurating a system. %config only specifies rpm's behavior upon > handling of backups upon install. First of all, since I didn't even mention the word "configuration" in the above (fully quoted), please stop jumping to conclusions. Secondly if a packager specifies %config* in the specfile he assumes that something outside his control will regularily modify this file, so rpm needs to properly cater for that. And that's what's relevant *the assumption that this file has to be outside of the packager's control*. Now you tell me what kind of files these are. We don't usually %config* stuff under /var (in fcat we don't even mention 99% of the logfiles in package manifests), so that leaves us with ...? Yes, say it ... It's not that difficult ... No? Well, I tried. But you are the one that would %config all bash/python/perl/init scripts anyway, so no use in trying to convince you, I guess. > 2. When a file-system is read-only, rpm can neither install the files, > nor create backups => The fact a file is marked %config is completely > irrelevant. What's the above got to do with anything? Sounds a bit like your X11 quote ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Mar 5 12:05:05 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 Mar 2007 13:05:05 +0100 (CET) Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <1173094749.25839.16.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> Message-ID: <26536.192.54.193.51.1173096305.squirrel@rousalka.dyndns.org> Le Lun 5 mars 2007 12:39, Ralf Corsepius a ?crit : > On Mon, 2007-03-05 at 12:11 +0100, Axel Thimm wrote: >> On Sun, Mar 04, 2007 at 10:47:18PM -0500, Matthias Clasen wrote: >> > How exactly do you propose packages should install anything under /usr >> > if its readonlyness is so sacrosanct ? Does it at least occur to you >> > that it cannot be readonly at install time ? >> >> Please don't be so literate, we already looped twice around the world >> explaining this. If you read it letter by letter and ignore FHS' >> intentions you may indeed logically conclude that /usr would be an >> empty filesystem, but try reading the full context. >> >> The bottom line is: Don't %config/%config(noreplace) files under /usr. > > 1. When will you finally understand that rpm's %config has nothing to do > with configurating a system. %config only specifies rpm's behavior upon > handling of backups upon install. %config marks files that rpm needs to "preserve" because they can be modified legitimately outside of its control. One of the main FHS arguments for making /usr ro is it doesn't need to be backup-ed. When you use %config on a /usr file you're explicitely asking rpm to do something the FHS told you should not be necessary on a well-designed system. Not having to hunt modified files everywhere on the filesystem and knowing /usr can be recreated from the install media is a major sysadmin boon. -- Nicolas Mailhot From enrico.scholz at informatik.tu-chemnitz.de Mon Mar 5 13:52:15 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 05 Mar 2007 14:52:15 +0100 Subject: The FHS /usr song In-Reply-To: <20070305115233.GL29562@neu.nirvana> (Axel Thimm's message of "Mon, 5 Mar 2007 12:52:33 +0100") References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <20070305115233.GL29562@neu.nirvana> Message-ID: <87d53ng5m8.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> > The bottom line is: Don't %config/%config(noreplace) files under /usr. >> >> 1. When will you finally understand that rpm's %config has nothing to do >> with configurating a system. %config only specifies rpm's behavior upon >> handling of backups upon install. > > First of all, since I didn't even mention the word "configuration" in > the above (fully quoted), please stop jumping to conclusions. Secondly > if a packager specifies %config* in the specfile he assumes that > something outside his control will regularily modify this file, so rpm > needs to properly cater for that. > > And that's what's relevant *the assumption that this file has to be > outside of the packager's control*. Now you tell me what kind of files > these are. We don't usually %config* stuff under /var (in fcat we > don't even mention 99% of the logfiles in package manifests), so that > leaves us with ...? Yes, say it ... It's not that difficult ... Files which are touched by rpm %scriptlets. In some cases (e.g. fonts.dir), the relocating to /var would be a cleaner solution but would require lot of work. But e.g. for /usr/lib/locale/locale-archive and perhaps the icon-caches this would be just overkill. Such files are handled best with %config and some %verify magic. %ghost might work too but it is some kind of exotic rpm feature with sometimes unexpected/unspecified behavior. Enrico From jkeating at redhat.com Mon Mar 5 14:14:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 09:14:12 -0500 Subject: Proposed guideline for init script files In-Reply-To: <1173073669.4441.11.camel@euler.counterexample.org> References: <200702271537.36532.jkeating@redhat.com> <1173073669.4441.11.camel@euler.counterexample.org> Message-ID: <200703050914.12391.jkeating@redhat.com> On Monday 05 March 2007 00:47:49 John T. Guthrie wrote: > I do like this idea with two provisos: > > 1) That a recommendation be put in about each init script needs to > include an OPTIONS or PROGOPTS or similar variable on its command-line. > This allows customization through addition of command-line arguments. > > 2) That initscripts be discouraged from putting command-line arguments > directly in the scripts. ?Instead they should be placed in the variable > from part 1) in /etc/sysconfig/progname. ?Putting command-line arguments > directly into the init script means that I can't remove those arguments > without modifying the init script. ?There could be some exceptions to > this guideline. ?An example would be something to set the uid of the > program in question, such as adding "-u named" in the script to start > named. > > To my current memory, these two situations cover every time that I have > needed to modify an init script. ?(There might be others I can't think > of, though.) I'm more than happy to extend the init scripts guidelines, perhaps into their own breakout page that can be read if init scripts are used or ignored if they aren't. However some of this feels more like development guidelines rather than packaging. That's OK I guess, but the line is getting fuzzy. Feel free to come up with a draft for such guidelines, I'll most likely be too busy over the next while to do it on my own. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 5 14:18:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 09:18:01 -0500 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <1173094749.25839.16.camel@mccallum.corsepiu.local> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> Message-ID: <200703050918.01521.jkeating@redhat.com> On Monday 05 March 2007 06:39:09 Ralf Corsepius wrote: > 1. When will you finally understand that rpm's %config has nothing to do > with configurating a system. %config only specifies rpm's behavior upon > handling of backups upon install. A side effect of marking something %config is that an rpm -qc (show me config files) will spit out that file and lead the user to believe he can edit said file to do further configuration. Perhaps you're trying to use the %config hammer because there is no other way of doing file preservation without marking it as a configuration file. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 5 14:32:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 15:32:54 +0100 Subject: The FHS /usr song In-Reply-To: <87d53ng5m8.fsf@fc5.bigo.ensc.de> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <20070305115233.GL29562@neu.nirvana> <87d53ng5m8.fsf@fc5.bigo.ensc.de> Message-ID: <20070305143254.GV29562@neu.nirvana> On Mon, Mar 05, 2007 at 02:52:15PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> > The bottom line is: Don't %config/%config(noreplace) files under /usr. > >> > >> 1. When will you finally understand that rpm's %config has nothing to do > >> with configurating a system. %config only specifies rpm's behavior upon > >> handling of backups upon install. > > > > First of all, since I didn't even mention the word "configuration" in > > the above (fully quoted), please stop jumping to conclusions. Secondly > > if a packager specifies %config* in the specfile he assumes that > > something outside his control will regularily modify this file, so rpm > > needs to properly cater for that. > > > > And that's what's relevant *the assumption that this file has to be > > outside of the packager's control*. Now you tell me what kind of files > > these are. We don't usually %config* stuff under /var (in fcat we > > don't even mention 99% of the logfiles in package manifests), so that > > leaves us with ...? Yes, say it ... It's not that difficult ... > > Files which are touched by rpm %scriptlets. In some cases > (e.g. fonts.dir), the relocating to /var would be a cleaner solution but > would require lot of work. We need that work to happen. /usr has seen worse times like for example when texmf fonts were created on the fly in there. The big issues are gone, let's fix the remaining ones. BTW this is something to put up in a spec, not to block F7 with it. If something cannot be fixed until then it should be grandfathered. But the long term plan needs to be to keep /usr %config-free. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Mar 5 15:24:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 5 Mar 2007 16:24:56 +0100 Subject: The FHS /usr song In-Reply-To: <20070305143254.GV29562@neu.nirvana> References: <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <20070305115233.GL29562@neu.nirvana> <87d53ng5m8.fsf@fc5.bigo.ensc.de> <20070305143254.GV29562@neu.nirvana> Message-ID: <20070305152455.GB3397@free.fr> On Mon, Mar 05, 2007 at 03:32:54PM +0100, Axel Thimm wrote: > > We need that work to happen. /usr has seen worse times like for > example when texmf fonts were created on the fly in there. The big > issues are gone, let's fix the remaining ones. > > BTW this is something to put up in a spec, not to block F7 with it. If > something cannot be fixed until then it should be grandfathered. But > the long term plan needs to be to keep /usr %config-free. This seems like a good idea to me. Is there a repoquery or similar call that could show problematic files associated with package name? -- Pat From rc040203 at freenet.de Mon Mar 5 15:47:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Mar 2007 16:47:55 +0100 Subject: The FHS /usr song (was: Core packages are using %config for files being installed under /usr) In-Reply-To: <200703050918.01521.jkeating@redhat.com> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <200703050918.01521.jkeating@redhat.com> Message-ID: <1173109676.25839.48.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 09:18 -0500, Jesse Keating wrote: > On Monday 05 March 2007 06:39:09 Ralf Corsepius wrote: > > 1. When will you finally understand that rpm's %config has nothing to do > > with configurating a system. %config only specifies rpm's behavior upon > > handling of backups upon install. > > A side effect of marking something %config is that an rpm -qc (show me config > files) will spit out that file and lead the user to believe he can edit said > file to do further configuration. Yes, ... and it's good this way. > Perhaps you're trying to use the %config > hammer because there is no other way of doing file preservation without > marking it as a configuration file. Yes, ... because there is no need to do so in "another way". %config/%config(noreplace) exactly do what they are supposed to do: create backups upon update/upgrade, because the packager has acknowledged a user/admin might have customized a file. Ralf From rc040203 at freenet.de Mon Mar 5 15:55:26 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Mar 2007 16:55:26 +0100 Subject: The FHS /usr song In-Reply-To: <87d53ng5m8.fsf@fc5.bigo.ensc.de> References: <87y7mi129i.fsf@kosh.bigo.ensc.de> <200703020843.19562@rineau.tsetse> <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <20070305115233.GL29562@neu.nirvana> <87d53ng5m8.fsf@fc5.bigo.ensc.de> Message-ID: <1173110126.25839.53.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 14:52 +0100, Enrico Scholz wrote: > >> > The bottom line is: Don't %config/%config(noreplace) files under /usr. > >> > >> 1. When will you finally understand that rpm's %config has nothing to do > >> with configurating a system. %config only specifies rpm's behavior upon > >> handling of backups upon install. > > > > First of all, since I didn't even mention the word "configuration" in > > the above (fully quoted), please stop jumping to conclusions. Secondly > > if a packager specifies %config* in the specfile he assumes that > > something outside his control will regularily modify this file, so rpm > > needs to properly cater for that. > > > > And that's what's relevant *the assumption that this file has to be > > outside of the packager's control*. Now you tell me what kind of files > > these are. We don't usually %config* stuff under /var (in fcat we > > don't even mention 99% of the logfiles in package manifests), so that > > leaves us with ...? Yes, say it ... It's not that difficult ... > > Files which are touched by rpm %scriptlets. In some cases > (e.g. fonts.dir), the relocating to /var would be a cleaner solution but Similar, but more interesting: /usr/share/info/dir If you have a close look into it, it is an ordinary info-document. i.e. customizable, partially containing static contents, partially containing dynamic contents (Note: customizable text! It is not automatically generated - You can put your company's "intro blurb" into it, if you like to.) In a similar situation are the various other "doc" systems (html indexes etc.) Also worth mentioning: alternatives, ldconfig and prelink. > would require lot of work. Whether you like it or not, the X11-mkfontdir stuff is a very simple, but effective way of implementing a simple distributed database. So yes, if you'd want to change this, upstream would be the correct address to change this. > But e.g. for /usr/lib/locale/locale-archive > and perhaps the icon-caches this would be just overkill. > > Such files are handled best with %config and some %verify magic. %ghost > might work too but it is some kind of exotic rpm feature with sometimes > unexpected/unspecified behavior. Exactly. Ralf From seg at haxxed.com Mon Mar 5 19:18:42 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 05 Mar 2007 13:18:42 -0600 Subject: Proposed guideline for init script files In-Reply-To: <1172669919.15418.163.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> Message-ID: <1173122322.18771.40.camel@localhost.localdomain> On Wed, 2007-02-28 at 14:38 +0100, Ralf Corsepius wrote: > On Wed, 2007-02-28 at 07:59 -0500, Christopher Blizzard wrote: > > +1. In general if you have to edit an init startup file, it's a bug. > > Exactly ... and what can users do about it? Edit them. > > With them not being marked %config users can only hope that RH/upstream > fixes it before the next update blows away their edits :( > > > Configuration should be in /etc/sysconfig/foo. > But real bugs and missing features init scripts suffer from can't. > > As I've said many times before, I consider not marking init scripts > %config a regression, Fedora will regret. cp -a /etc/init.d/foo /etc/init.d/foo-custom chkconfig foo off chkconfig foo-custom on Jesus !@#$ing christ, Ralf. Do you ever stop and think before ranting? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Mar 5 19:28:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 Mar 2007 11:28:41 -0800 Subject: Proposed guideline for init script files In-Reply-To: <1173073669.4441.11.camel@euler.counterexample.org> References: <200702271537.36532.jkeating@redhat.com> <1173073669.4441.11.camel@euler.counterexample.org> Message-ID: <1173122921.20343.238.camel@localhost.localdomain> On Mon, 2007-03-05 at 00:47 -0500, John T. Guthrie wrote: > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > > The Packaging Committee has been discussing guidelines for init scripts for a > > while. Currently there is a split between init scripts being marked > > as %config and many that aren't. We (the PC) with input from various folks > > feel it is best to not mark init scripts as %config, and instead promote > > configuration to happen in an /etc/sysconfig/ file. Mostly the reason > > being that init scripts are just that, scripts to run and not config files to > > edit. As such I've drafted a proposal for the guidelines and the PC approved > > it. There is time now for a wider audience to review the proposed change and > > comment. > > > > Please take a moment to read through > > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some > > feedback. If nobody has major objections or reasonable adjustments, this > > will become policy in a week's time. > > I apologize for the slightly late reply. I've been trying to get caught > up on email. > > I do like this idea with two provisos: > > 1) That a recommendation be put in about each init script needs to > include an OPTIONS or PROGOPTS or similar variable on its command-line. > This allows customization through addition of command-line arguments. > > 2) That initscripts be discouraged from putting command-line arguments > directly in the scripts. Instead they should be placed in the variable > from part 1) in /etc/sysconfig/progname. Putting command-line arguments > directly into the init script means that I can't remove those arguments > without modifying the init script. There could be some exceptions to > this guideline. An example would be something to set the uid of the > program in question, such as adding "-u named" in the script to start > named. > #2 isn't necessary as long as you can override an option through /etc/sysconfig/progname. For instance, if the program allows options that come later on the commandline to override ones that come earlier and the PROGOPTS variable is the last thing on the commandline. However, it does make it simpler for maintainers and reviewers if the rule is just to put them into the sysconfig file. (Else we'd have to test every program whose initscript had options in the initscript just in case... and there'd be a chance that major upstream rewrites would change the behaviour.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Mar 5 19:31:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 Mar 2007 11:31:04 -0800 Subject: FPC Meeting Summaries? (Re: FESCo Meeting Summary for 2007-03-01) In-Reply-To: <45EBB0DC.3080803@leemhuis.info> References: <1173031240.9205.6.camel@Chuck> <45EB0EA7.8030405@leemhuis.info> <200703041550.40349.jkeating@redhat.com> <45EBB0DC.3080803@leemhuis.info> Message-ID: <1173123065.20343.241.camel@localhost.localdomain> On Mon, 2007-03-05 at 06:55 +0100, Thorsten Leemhuis wrote: > On 04.03.2007 21:50, Jesse Keating wrote: > > On Sunday 04 March 2007 13:23:35 Thorsten Leemhuis wrote: > >> Just wondering: Why isn't the PC sending any reports/summaries to > >> fedora-maintainers anymore (or did I miss them all in the past weeks?)? > >> That was part of the arrangement between FESCo and FPC iirc; to quote > >> http://www.fedoraproject.org/wiki/Extras/Schedule > > It's supposed to be the person bringing the draft to the PC that takes care of > > sending information regarding passed drafts to Maintainers list. In my case, > > I did communicate about the initscript draft. > > Thx for doing this. Nevertheless I think having at least rough meeting > summaries is normally (?) a must -- especially when things got > approved/voted upon. > > There are not even the IRC logs in the wiki from the past two meetings > afaics: > http://www.fedoraproject.org/wiki/Packaging/Minutes > > CU > thl > > (?) -- sometimes meetings are more a general chat and then it might not > make to much sense trying to sum them up FPC is too disorganized. There's no one responsible for taking minutes and no one responsible for writing and sending the summaries. Somethings are also confusing as the last time sending summaries came up (in FPC, not FESCo) it seemed that people wanted to send the summaries after the writeup, not after the draft was ratified by FPC. Solutions: * Someone volunteers to send URLs for proposals approved by the FPC to -maintainers on the day of the FPC meetings. [I'll take this one starting with tomorrow's meeting.] * We need someone to volunteer to post the Packaging Committee IRC Logs at the very least. Having minutes would be nice too. You don't have to be a member of the Packaging Committee as we don't discuss anything in private, you just have to be able to show up for the meetings and post them later. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Mar 5 20:27:58 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 5 Mar 2007 22:27:58 +0200 Subject: Proposed guideline for init script files In-Reply-To: <1173122921.20343.238.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1173073669.4441.11.camel@euler.counterexample.org> <1173122921.20343.238.camel@localhost.localdomain> Message-ID: <200703052227.58951.ville.skytta@iki.fi> On Monday 05 March 2007, Toshio Kuratomi wrote: > On Mon, 2007-03-05 at 00:47 -0500, John T. Guthrie wrote: > > > > 2) That initscripts be discouraged from putting command-line arguments > > directly in the scripts. Instead they should be placed in the variable > > from part 1) in /etc/sysconfig/progname. Putting command-line arguments > > directly into the init script means that I can't remove those arguments > > without modifying the init script. There could be some exceptions to > > this guideline. An example would be something to set the uid of the > > program in question, such as adding "-u named" in the script to start > > named. > > #2 isn't necessary as long as you can override an option > through /etc/sysconfig/progname. For instance, if the program allows > options that come later on the commandline to override ones that come > earlier and the PROGOPTS variable is the last thing on the commandline. True, but there are cases where overriding certain options in the config file would be better off made explictly impossible. For example various daemonization related options or lack of them may break the init script by making it never return from daemon(), and cases that should be prevented where feasible. From Axel.Thimm at ATrpms.net Mon Mar 5 23:09:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 00:09:55 +0100 Subject: The FHS /usr song In-Reply-To: <20070305152455.GB3397@free.fr> References: <20070302101753.GD17966@neu.nirvana> <200703021126.40172@rineau.tsetse> <20070302104652.GF17966@neu.nirvana> <1173066438.3896.12.camel@localhost.localdomain> <20070305111144.GH29562@neu.nirvana> <1173094749.25839.16.camel@mccallum.corsepiu.local> <20070305115233.GL29562@neu.nirvana> <87d53ng5m8.fsf@fc5.bigo.ensc.de> <20070305143254.GV29562@neu.nirvana> <20070305152455.GB3397@free.fr> Message-ID: <20070305230955.GA8070@neu.nirvana> On Mon, Mar 05, 2007 at 04:24:56PM +0100, Patrice Dumas wrote: > On Mon, Mar 05, 2007 at 03:32:54PM +0100, Axel Thimm wrote: > > > > We need that work to happen. /usr has seen worse times like for > > example when texmf fonts were created on the fly in there. The big > > issues are gone, let's fix the remaining ones. > > > > BTW this is something to put up in a spec, not to block F7 with it. If > > something cannot be fixed until then it should be grandfathered. But > > the long term plan needs to be to keep /usr %config-free. > > This seems like a good idea to me. Is there a repoquery or similar call > that could show problematic files associated with package name? You can get the %config files under /usr with rpm -qca | grep ^/usr I think there is no repoquery analogon for the -c switch. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From panemade at gmail.com Mon Mar 5 04:43:35 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 5 Mar 2007 10:13:35 +0530 Subject: Fonts scriptlet for CORE packages In-Reply-To: <87ejo6txz9.fsf@kosh.bigo.ensc.de> References: <87ejo6txz9.fsf@kosh.bigo.ensc.de> Message-ID: Hi, On 3/3/07, Enrico Scholz wrote: > panemade at gmail.com (""Parag N(~~~ > ?)"") writes: > > > touch %{ttfontdir} 2> /dev/null && { > > /usr/bin/ttmkfdir -d %{ttfontdir} -o %{ttfontdir}/fonts.scale > > mkfontdir %{ttfontdir} > > /usr/sbin/chkfontpath -q -a %{ttfontdir} > > } > > mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} > > This should expressed in a way that it does not fail when /usr is mounted > read-only. > > E.g. > > | ! touch %ttfontdir 2>/dev/null || { ... > | mkfontdir %{bmpfontdir} && /usr/sbin/chkfontpath -q -a %{bmpfontdir} || : > Thanks all for your comments here. So i can take above way of writing a scriptlet for Core X11 font packages right? Regards, Parag. From guthrie at counterexample.org Tue Mar 6 01:41:23 2007 From: guthrie at counterexample.org (John T. Guthrie) Date: Mon, 05 Mar 2007 20:41:23 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200703050914.12391.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> <1173073669.4441.11.camel@euler.counterexample.org> <200703050914.12391.jkeating@redhat.com> Message-ID: <1173145283.4441.14.camel@euler.counterexample.org> On Mon, 2007-03-05 at 09:14 -0500, Jesse Keating wrote: > I'm more than happy to extend the init scripts guidelines, perhaps into their > own breakout page that can be read if init scripts are used or ignored if > they aren't. However some of this feels more like development guidelines > rather than packaging. That's OK I guess, but the line is getting fuzzy. > > Feel free to come up with a draft for such guidelines, I'll most likely be too > busy over the next while to do it on my own. I would be glad to help with this, but I think that I need to be added to the EditGroup on the wiki. Thanks. -- John Guthrie guthrie at counterexample.org From rc040203 at freenet.de Tue Mar 6 03:33:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 04:33:28 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1173122322.18771.40.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> Message-ID: <1173152008.25839.75.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 13:18 -0600, Callum Lerwick wrote: > On Wed, 2007-02-28 at 14:38 +0100, Ralf Corsepius wrote: > > On Wed, 2007-02-28 at 07:59 -0500, Christopher Blizzard wrote: > > > +1. In general if you have to edit an init startup file, it's a bug. > > > > Exactly ... and what can users do about it? Edit them. > > > > With them not being marked %config users can only hope that RH/upstream > > fixes it before the next update blows away their edits :( > > > > > Configuration should be in /etc/sysconfig/foo. > > But real bugs and missing features init scripts suffer from can't. > > > > As I've said many times before, I consider not marking init scripts > > %config a regression, Fedora will regret. > > cp -a /etc/init.d/foo /etc/init.d/foo-custom > chkconfig foo off > chkconfig foo-custom on This is exactly the same, %config(noreplace) would do automatically. Ralf From bugs.michael at gmx.net Tue Mar 6 10:56:43 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 11:56:43 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1173152008.25839.75.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> <1173152008.25839.75.camel@mccallum.corsepiu.local> Message-ID: <20070306115643.13c32d4a.bugs.michael@gmx.net> On Tue, 06 Mar 2007 04:33:28 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-05 at 13:18 -0600, Callum Lerwick wrote: > > On Wed, 2007-02-28 at 14:38 +0100, Ralf Corsepius wrote: > > > On Wed, 2007-02-28 at 07:59 -0500, Christopher Blizzard wrote: > > > > +1. In general if you have to edit an init startup file, it's a bug. > > > > > > Exactly ... and what can users do about it? Edit them. > > > > > > With them not being marked %config users can only hope that RH/upstream > > > fixes it before the next update blows away their edits :( > > > > > > > Configuration should be in /etc/sysconfig/foo. > > > But real bugs and missing features init scripts suffer from can't. > > > > > > As I've said many times before, I consider not marking init scripts > > > %config a regression, Fedora will regret. > > > > cp -a /etc/init.d/foo /etc/init.d/foo-custom > > chkconfig foo off > > chkconfig foo-custom on > This is exactly the same, %config(noreplace) would do automatically. Turning on a renamed service script will decouple any rpm scriptlets from the service name. You don't get a condrestart and things like that for the renamed service after package upgrades, for instance. Pray that the modified service still restarts after an unexpected reboot (power-outage). It's better to use the init-script that is provided in the packages and keep it customised with the help of a separate config file. Suggesting that init-scripts are a place where to %config something is wrong already. From bugs.michael at gmx.net Tue Mar 6 10:58:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 11:58:09 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1173145283.4441.14.camel@euler.counterexample.org> References: <200702271537.36532.jkeating@redhat.com> <1173073669.4441.11.camel@euler.counterexample.org> <200703050914.12391.jkeating@redhat.com> <1173145283.4441.14.camel@euler.counterexample.org> Message-ID: <20070306115809.4d4e2c31.bugs.michael@gmx.net> On Mon, 05 Mar 2007 20:41:23 -0500, John T. Guthrie wrote: > I would be glad to help with this, but I think that I need to be added > to the EditGroup on the wiki. http://fedoraproject.org/wiki/EditGroupQueue From fedora at camperquake.de Tue Mar 6 11:12:47 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 6 Mar 2007 12:12:47 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172867417.22136.172.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <604aa7910703012127w6bfd32a7h470f6805c7b889a@mail.gmail.com> <1172866038.20343.105.camel@localhost.localdomain> <1172867417.22136.172.camel@localhost.localdomain> Message-ID: <20070306121247.35426214@banea.int.addix.net> Hi. On Fri, 02 Mar 2007 15:30:17 -0500, Adam Jackson wrote: > The last time this discussion came up, I suggested someone just go > steal code and/or ideas from Gentoo's etc-update, and no one seems to > have done so. > > It's not like this is a new problem. This kind of functionality belongs in the file system. Since ext4 is in the making this could be added somewhere. From rc040203 at freenet.de Tue Mar 6 11:51:21 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 12:51:21 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070306115643.13c32d4a.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> <1173152008.25839.75.camel@mccallum.corsepiu.local> <20070306115643.13c32d4a.bugs.michael@gmx.net> Message-ID: <1173181882.25839.81.camel@mccallum.corsepiu.local> On Tue, 2007-03-06 at 11:56 +0100, Michael Schwendt wrote: > On Tue, 06 Mar 2007 04:33:28 +0100, Ralf Corsepius wrote: > > > On Mon, 2007-03-05 at 13:18 -0600, Callum Lerwick wrote: > > > On Wed, 2007-02-28 at 14:38 +0100, Ralf Corsepius wrote: > > > > On Wed, 2007-02-28 at 07:59 -0500, Christopher Blizzard wrote: > > > > > +1. In general if you have to edit an init startup file, it's a bug. > > > > > > > > Exactly ... and what can users do about it? Edit them. > > > > > > > > With them not being marked %config users can only hope that RH/upstream > > > > fixes it before the next update blows away their edits :( > > > > > > > > > Configuration should be in /etc/sysconfig/foo. > > > > But real bugs and missing features init scripts suffer from can't. > > > > > > > > As I've said many times before, I consider not marking init scripts > > > > %config a regression, Fedora will regret. > > > > > > cp -a /etc/init.d/foo /etc/init.d/foo-custom > > > chkconfig foo off > > > chkconfig foo-custom on > > This is exactly the same, %config(noreplace) would do automatically. > > Turning on a renamed service script will decouple any rpm scriptlets from > the service name. You don't get a condrestart and things like that for the > renamed service after package upgrades, for instance. Pray that the > modified service still restarts after an unexpected reboot (power-outage). How many times do I have to reiterate it? In practice, this is not an issue! > It's better to use the init-script that is provided in the packages > and keep it customised with the help of a separate config file. How many times do I have to reiterate this: This only helps if the init script isn't broken itself. If you want to test: Just insert a typo into an init script and imagine Fedora doesn't fix it with the next upgrade. > Suggesting that init-scripts are a place where to %config something > is wrong already. I could not disagree more. You guys are religious about something that isn't an issue, but are gradually degrading usability towards NULL. Ralf From bugs.michael at gmx.net Tue Mar 6 12:26:25 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 13:26:25 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1173181882.25839.81.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> <1173152008.25839.75.camel@mccallum.corsepiu.local> <20070306115643.13c32d4a.bugs.michael@gmx.net> <1173181882.25839.81.camel@mccallum.corsepiu.local> Message-ID: <20070306132625.55e48bd7.bugs.michael@gmx.net> On Tue, 06 Mar 2007 12:51:21 +0100, Ralf Corsepius wrote: > > > > cp -a /etc/init.d/foo /etc/init.d/foo-custom > > > > chkconfig foo off > > > > chkconfig foo-custom on > > > This is exactly the same, %config(noreplace) would do automatically. > > > > Turning on a renamed service script will decouple any rpm scriptlets from > > the service name. You don't get a condrestart and things like that for the > > renamed service after package upgrades, for instance. Pray that the > > modified service still restarts after an unexpected reboot (power-outage). > How many times do I have to reiterate it? > > In practice, this is not an issue! > > > It's better to use the init-script that is provided in the packages > > and keep it customised with the help of a separate config file. > How many times do I have to reiterate this: This only helps if the init > script isn't broken itself. The script is made for the binaries. The script ought to stay in sync with changes in the binaries. Else it would be broken. Configuration options ought to be separated from the code (= the shell script), so when you change the options, you still get updates to the code. (which won't be the case for *.rpmnew) > If you want to test: Just insert a typo into an init script and imagine > Fedora doesn't fix it with the next upgrade. Is this a theoretical problem? Or has this a historical background in bugzilla? From rc040203 at freenet.de Tue Mar 6 12:52:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 13:52:06 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070306132625.55e48bd7.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> <1173152008.25839.75.camel@mccallum.corsepiu.local> <20070306115643.13c32d4a.bugs.michael@gmx.net> <1173181882.25839.81.camel@mccallum.corsepiu.local> <20070306132625.55e48bd7.bugs.michael@gmx.net> Message-ID: <1173185526.25839.91.camel@mccallum.corsepiu.local> On Tue, 2007-03-06 at 13:26 +0100, Michael Schwendt wrote: > On Tue, 06 Mar 2007 12:51:21 +0100, Ralf Corsepius wrote: > > > > > > cp -a /etc/init.d/foo /etc/init.d/foo-custom > > > > > chkconfig foo off > > > > > chkconfig foo-custom on > > > > This is exactly the same, %config(noreplace) would do automatically. > > > > > > Turning on a renamed service script will decouple any rpm scriptlets from > > > the service name. You don't get a condrestart and things like that for the > > > renamed service after package upgrades, for instance. Pray that the > > > modified service still restarts after an unexpected reboot (power-outage). > > How many times do I have to reiterate it? > > > > In practice, this is not an issue! > > If you want to test: Just insert a typo into an init script and imagine > > Fedora doesn't fix it with the next upgrade. > > Is this a theoretical problem? No, it's a practical problem, I've been hit by dozens of times ever since I am using Fedora/RHL. > Or has this a historical background in > bugzilla? Dunno, ATM, I feel too fed up with this topic to be wanting to waste further time on digging bugzilla for it. You are not fixing any issue nor bug by dropping %config, you are degrading usability. When it hits again, I will remind all those of you who currently are for it (You, Michael, will be the first). Ralf From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 12:57:18 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 13:57:18 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070306132625.55e48bd7.bugs.michael@gmx.net> (Michael Schwendt's message of "Tue, 6 Mar 2007 13:26:25 +0100") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1173122322.18771.40.camel@localhost.localdomain> <1173152008.25839.75.camel@mccallum.corsepiu.local> <20070306115643.13c32d4a.bugs.michael@gmx.net> <1173181882.25839.81.camel@mccallum.corsepiu.local> <20070306132625.55e48bd7.bugs.michael@gmx.net> Message-ID: <87vehe8r81.fsf@fc5.bigo.ensc.de> Michael Schwendt writes: > Configuration options ought to be separated from the code (= the shell > script), Then move the initscript to /lib, but do not break the /etc-can-be-configured paradigm. Enrico From bugs.michael at gmx.net Tue Mar 6 13:24:56 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 14:24:56 +0100 Subject: Extras repoclosure heads up Message-ID: <20070306142456.dde698fe.bugs.michael@gmx.net> Running Extras repoclosure on released packages _and_ unreleased packages in the needsign queue may lead to confusing results: In the report, it doesn't become obvious that it is an _unreleased_ package in the needsign queue that would break dependencies _if_ it were released. Instead, the report reads as if something in the public repository is broken already. On the contrary, if something _in_ the needsign queue contains broken deps, the repository names in the report start with "fedora-extras-needsign-". In either case, pushing the packages from the needsign queue would break something unless fixed packages are built. From mmcgrath at redhat.com Tue Mar 6 14:28:48 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 08:28:48 -0600 Subject: Fedora User Management (revisited) Message-ID: <45ED7AA0.6070109@redhat.com> We've been discussing Fedora User Management in EPEL. I propose a vote, all maintainers are welcome to vote. The outcome is FINAL. If we chose not to use fedora user management, it dies and packages that currently use it will have bugs filed to remove it. If we vote to use it. It becomes mandatory. Having two systems is amateur and confusing. -Mike -Mike From pertusus at free.fr Tue Mar 6 14:36:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 15:36:59 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45ED7AA0.6070109@redhat.com> References: <45ED7AA0.6070109@redhat.com> Message-ID: <20070306143659.GA2942@free.fr> On Tue, Mar 06, 2007 at 08:28:48AM -0600, Mike McGrath wrote: > We've been discussing Fedora User Management in EPEL. I propose a vote, > all maintainers are welcome to vote. The outcome is FINAL. If we chose A vote isn't the way to go in my opinion. The number of people is not relevant when it comes to technical issues. Collecting people thoughts on that matter would be interesting though, but I think having FESCo or FPC choose would be better. > not to use fedora user management, it dies and packages that currently > use it will have bugs filed to remove it. If we vote to use it. It > becomes mandatory. Having two systems is amateur and confusing. It may be confusing, but not amateur. Having choice is right. My personal opinion is that using one or the other system should be left to the packager, until one possibility clearly showed to be superior. If an alternative appears to be better, stick to that alternative, but the agreement should be more than a mere vote. -- Pat From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 14:45:31 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 15:45:31 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45ED7AA0.6070109@redhat.com> (Mike McGrath's message of "Tue, 06 Mar 2007 08:28:48 -0600") References: <45ED7AA0.6070109@redhat.com> Message-ID: <87abyqbfck.fsf@fc5.bigo.ensc.de> Mike McGrath writes: > We've been discussing Fedora User Management in EPEL. Won't work. 'rpm' in RHEL is too old and misses features required by fedora-usermgmt. Enrico From mmcgrath at redhat.com Tue Mar 6 14:50:02 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 08:50:02 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87abyqbfck.fsf@fc5.bigo.ensc.de> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> Message-ID: <45ED7F9A.3050906@redhat.com> Enrico Scholz wrote: > Mike McGrath writes: > > >> We've been discussing Fedora User Management in EPEL. >> > > Won't work. 'rpm' in RHEL is too old and misses features required by > fedora-usermgmt. > So we're stuck having to fix a bunch of packages so they'll work in another dist other than Fedora? I wish someone had seen this coming. -Mike From pertusus at free.fr Tue Mar 6 14:42:42 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 15:42:42 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87abyqbfck.fsf@fc5.bigo.ensc.de> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> Message-ID: <20070306144242.GB2942@free.fr> On Tue, Mar 06, 2007 at 03:45:31PM +0100, Enrico Scholz wrote: > Mike McGrath writes: > > > We've been discussing Fedora User Management in EPEL. > > Won't work. 'rpm' in RHEL is too old and misses features required by > fedora-usermgmt. Maybe RHEL 4, but not RHEL 5. -- Pat From rdieter at math.unl.edu Tue Mar 6 14:53:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Mar 2007 08:53:44 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45ED7F9A.3050906@redhat.com> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <45ED7F9A.3050906@redhat.com> Message-ID: <45ED8078.6010505@math.unl.edu> Mike McGrath wrote: > Enrico Scholz wrote: >> Mike McGrath writes: >> >> >>> We've been discussing Fedora User Management in EPEL. >>> >> >> Won't work. 'rpm' in RHEL is too old and misses features required by >> fedora-usermgmt. >> > So we're stuck having to fix a bunch of packages so they'll work in > another dist other than Fedora? I wish someone had seen this coming. On the bright side, it makes the decision on whether to use fedora-usermgmt in epel(4) easier. Enrico, could you enlighten us what exactly doesn't work with el4's rpm? -- Rex From fedora at leemhuis.info Tue Mar 6 14:53:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Mar 2007 15:53:52 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070306143659.GA2942@free.fr> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> Message-ID: <45ED8080.9070802@leemhuis.info> On 06.03.2007 15:36, Patrice Dumas wrote: > On Tue, Mar 06, 2007 at 08:28:48AM -0600, Mike McGrath wrote: >> We've been discussing Fedora User Management in EPEL. I propose a vote, >> all maintainers are welcome to vote. The outcome is FINAL. If we chose > A vote isn't the way to go in my opinion. The number of people is not > relevant when it comes to technical issues. Agreed -- it's important that the people that make the decision know the pros and cons of the different proposed solutions. That's IMHO often not the case for complicated technical issues like this if the group that is voting is big. > Collecting people thoughts > on that matter would be interesting though, but I think having FESCo > or FPC choose would be better. +1 -- they finally have to ratify the solution anyway. But the issue nevertheless can and of course should get discussed in public. > [...] CU thl From mmcgrath at redhat.com Tue Mar 6 14:59:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 08:59:45 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45ED8078.6010505@math.unl.edu> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <45ED7F9A.3050906@redhat.com> <45ED8078.6010505@math.unl.edu> Message-ID: <45ED81E1.5060701@redhat.com> Rex Dieter wrote: > > On the bright side, it makes the decision on whether to use > fedora-usermgmt in epel(4) easier. > > Enrico, could you enlighten us what exactly doesn't work with el4's rpm? I know we have "must not replace core packages" in the guidelines... But they're just guidelines, I really think the only right way to do this is to have a package that completely replaces /usr/sbin/useradd. I know its against the guidelines but there's got to be some way to make it transparent to the packager and the user, and replacing useradd is the only way to do that. -Mike From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 15:14:49 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 16:14:49 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45ED8078.6010505@math.unl.edu> (Rex Dieter's message of "Tue, 06 Mar 2007 08:53:44 -0600") References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <45ED7F9A.3050906@redhat.com> <45ED8078.6010505@math.unl.edu> Message-ID: <87649ebdzq.fsf@fc5.bigo.ensc.de> Rex Dieter writes: >>>> We've been discussing Fedora User Management in EPEL. >>>> >>> Won't work. 'rpm' in RHEL is too old and misses features required by >>> fedora-usermgmt. > > Enrico, could you enlighten us what exactly doesn't work with el4's rpm? This rpm version does not know the '%bcond_with*' macros. Hence | %bcond_without fedora and the related logic will fail. I am not sure whether the %FE_USERADD_REQ macro works; line breaks with '\' in .spec files are definitively not supported, but it might work in the shipped /etc/rpm/macros.fedora-usermgmt. Enrico From jwboyer at jdub.homelinux.org Tue Mar 6 15:02:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 06 Mar 2007 09:02:10 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45ED8080.9070802@leemhuis.info> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> Message-ID: <1173193330.6561.37.camel@zod.rchland.ibm.com> On Tue, 2007-03-06 at 15:53 +0100, Thorsten Leemhuis wrote: > On 06.03.2007 15:36, Patrice Dumas wrote: > > On Tue, Mar 06, 2007 at 08:28:48AM -0600, Mike McGrath wrote: > >> We've been discussing Fedora User Management in EPEL. I propose a vote, > >> all maintainers are welcome to vote. The outcome is FINAL. If we chose > > A vote isn't the way to go in my opinion. The number of people is not > > relevant when it comes to technical issues. > > Agreed -- it's important that the people that make the decision know the > pros and cons of the different proposed solutions. That's IMHO often not > the case for complicated technical issues like this if the group that is > voting is big. > > > Collecting people thoughts > > on that matter would be interesting though, but I think having FESCo > > or FPC choose would be better. > > +1 -- they finally have to ratify the solution anyway. But the issue > nevertheless can and of course should get discussed in public. I'd want to know the outcome of an EPEL SIG vote before trying to decide anything on this. That's what SIGs are for. josh From Christian.Iseli at licr.org Tue Mar 6 16:50:09 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 6 Mar 2007 17:50:09 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45ED81E1.5060701@redhat.com> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <45ED7F9A.3050906@redhat.com> <45ED8078.6010505@math.unl.edu> <45ED81E1.5060701@redhat.com> Message-ID: <20070306175009.08e0de43@ludwig-alpha.unil.ch> On Tue, 06 Mar 2007 08:59:45 -0600, Mike McGrath wrote: > I really think the only right way to do this is > to have a package that completely replaces /usr/sbin/useradd. That's my opinion too. Why not put the necessary bits in shadow-utils and be done with this ? C From SteveD at redhat.com Tue Mar 6 17:37:34 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 06 Mar 2007 12:37:34 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: <45EDA6DE.5010702@RedHat.com> I truly apologize for getting into this so late... but... Jesse Keating wrote: > Please take a moment to read through > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts Question: what right do we have to destroy our users initscripts when they changed? There has been an expectation for a number of years, in a number of packages that if an initscript that has changed it will be preserved on updates.. So why should we change that? After reading through this entire thread, I just really don't not see *any* valid reason or justification why packages maintainer can do anything (and everything!) to preserver things like initscripts, if and only if they have changed... especially since thats has been the expectation for many, many years... So to than end... if even if this initscript policy stands, there is a very real chance I am simply going to ignore it... for one reason and one reason only.... I *care* more about my users configuration files (including their initscripts) that I do some *#$S policy... And I bet my users will thank me for that.. esp the ones what have there initscirpts save! steved. From jkeating at redhat.com Tue Mar 6 18:05:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 13:05:31 -0500 Subject: Proposed guideline for init script files In-Reply-To: <45EDA6DE.5010702@RedHat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> Message-ID: <200703061305.31477.jkeating@redhat.com> On Tuesday 06 March 2007 12:37:34 Steve Dickson wrote: > Question: what right do we have to destroy our users initscripts > when they changed? There has been an expectation for a number of > years, in a number of packages that if an initscript that has > changed it will be preserved on updates.. So why should we change that? For the simple fact that init scripts should _not_ be configuration files, _at_ _all_, and the packaging system should not encourage people to treat them as such. Configuration must happen in real config files so that it can be preserved while things in the init script like binary name and necessary options can change when the application changes. I personally feel that the init script needs to live somewhere outside of /etc to make this even more clear, but that's a much larger change that I can't necessarily drive right now. If your customers have to do configuration in the init script, that is a bug in your software that needs to be fixed. If they have to work around some bug that we haven't fixed yet, they really should copy the init script to a new name and disable the old script, or exclude that package from being updated. We're really trying to clean up the system and consolidate configuration into concise areas rather than scattered about the file system. These are the changes that Fedora can make moving forward. If RHEL doesn't want to play along, that's their choice. The Packaging Committee, the Fedora Engineering Steering Committee, and your own peers within Red Hat have approved this guideline, and it will be moved in hopefully today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 18:28:50 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 19:28:50 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200703061305.31477.jkeating@redhat.com> (Jesse Keating's message of "Tue, 6 Mar 2007 13:05:31 -0500") References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> Message-ID: <87irde8bvh.fsf@kosh.bigo.ensc.de> Jesse Keating writes: > I personally feel that the init script needs to live somewhere outside > of /etc to make this even more clear, but that's a much larger change > that I can't necessarily drive right now. Wouldn't it be better to aim at this target (move initscripts to somewhere else) instead of trying to establish some interim rules which are breaking existing installations? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jkeating at redhat.com Tue Mar 6 18:37:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 13:37:42 -0500 Subject: Proposed guideline for init script files In-Reply-To: <87irde8bvh.fsf@kosh.bigo.ensc.de> References: <200702271537.36532.jkeating@redhat.com> <200703061305.31477.jkeating@redhat.com> <87irde8bvh.fsf@kosh.bigo.ensc.de> Message-ID: <200703061337.42668.jkeating@redhat.com> On Tuesday 06 March 2007 13:28:50 Enrico Scholz wrote: > Wouldn't it be better to aim at this target (move initscripts to somewhere > else) instead of trying to establish some interim rules which are breaking > existing installations? The guideline has built in exceptions for init scripts that currently have config in them. Any other init script which currently is marked as %config will save any modifications when upgraded to a version of the package that doesn't mark it as %config. While it may or may not be feasible to move the scripts out of /etc/, it IS feasible to establish guidelines around how we wish these scripts operate within Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Mar 6 18:38:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 19:38:23 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173193330.6561.37.camel@zod.rchland.ibm.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> Message-ID: <20070306183823.GC7703@neu.nirvana> On Tue, Mar 06, 2007 at 09:02:10AM -0600, Josh Boyer wrote: > On Tue, 2007-03-06 at 15:53 +0100, Thorsten Leemhuis wrote: > > On 06.03.2007 15:36, Patrice Dumas wrote: > > > On Tue, Mar 06, 2007 at 08:28:48AM -0600, Mike McGrath wrote: > > >> We've been discussing Fedora User Management in EPEL. I propose a vote, > > >> all maintainers are welcome to vote. The outcome is FINAL. If we chose > > > A vote isn't the way to go in my opinion. The number of people is not > > > relevant when it comes to technical issues. > > > > Agreed -- it's important that the people that make the decision know the > > pros and cons of the different proposed solutions. That's IMHO often not > > the case for complicated technical issues like this if the group that is > > voting is big. > > > > > Collecting people thoughts > > > on that matter would be interesting though, but I think having FESCo > > > or FPC choose would be better. > > > > +1 -- they finally have to ratify the solution anyway. But the issue > > nevertheless can and of course should get discussed in public. > > I'd want to know the outcome of an EPEL SIG vote before trying to decide > anything on this. That's what SIGs are for. The EPEL seems to be mostly against this tool, but doesn't vote because it considers it a Fedora issue that needs to be resolved in Fedora land. So waiting for a vote from the EPEL sig while this is waiting for this vote may look like a dead-lock. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjanouse at redhat.com Tue Mar 6 18:42:28 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Tue, 6 Mar 2007 19:42:28 +0100 Subject: Move libwrap.so.whatever to /lib Message-ID: <20070306184228.GA2718@redhat.com> Hello, one of the upcoming features of syslog-ng is, as far as I've been told, the support for tcp_wrappers. This would require the tcp_wrappers library to be in /lib instead of /usr/lib (details in [1]). Is this move ok in Fedora? E.g. in Debian, it's in /lib, so I suppose it is, I just want to be sure I may do the move. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230871 Regards, -- TJ., BaseOS, Brno, CZ From Axel.Thimm at ATrpms.net Tue Mar 6 18:42:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 19:42:12 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87abyqbfck.fsf@fc5.bigo.ensc.de> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> Message-ID: <20070306184212.GD7703@neu.nirvana> On Tue, Mar 06, 2007 at 03:45:31PM +0100, Enrico Scholz wrote: > Mike McGrath writes: > > > We've been discussing Fedora User Management in EPEL. > > Won't work. 'rpm' in RHEL is too old and misses features required by > fedora-usermgmt. what exactly does this tool solve? Especially if this defaults to normal useradd -r behaviour (does it really default to this behaviour?), which means that it is not really *required*. If it tries to solve the need for *fixed* system uid/gid then we need to find another solution than a flaotion uid/gid window. If it tried to solve *random* system uid/gid allocation then what's better than useradd -r? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From SteveD at redhat.com Tue Mar 6 18:43:19 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 06 Mar 2007 13:43:19 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200703061305.31477.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> Message-ID: <45EDB647.2090808@RedHat.com> Jesse Keating wrote: > On Tuesday 06 March 2007 12:37:34 Steve Dickson wrote: >> Question: what right do we have to destroy our users initscripts >> when they changed? There has been an expectation for a number of >> years, in a number of packages that if an initscript that has >> changed it will be preserved on updates.. So why should we change that? > > For the simple fact that init scripts should _not_ be configuration files, > _at_ _all_, and the packaging system should not encourage people to treat > them as such. Configuration must happen in real config files so that it can > be preserved while things in the init script like binary name and necessary > options can change when the application changes. I personally feel that the > init script needs to live somewhere outside of /etc to make this even more > clear, but that's a much larger change that I can't necessarily drive right > now. If your customers have to do configuration in the init script, that is > a bug in your software that needs to be fixed. Maybe... but our customer will not be our customers for very long if we continue to not care about their world... Why should they? If they have to work around > some bug that we haven't fixed yet, they really should copy the init script > to a new name and disable the old script, or exclude that package from being > updated. We're really trying to clean up the system and consolidate > configuration into concise areas rather than scattered about the file system. > These are the changes that Fedora can make moving forward. If RHEL doesn't > want to play along, that's their choice. Please don't forget... Fedora lives for RHEL... and as soon as a RHEL customer loses a piece of valuable information do some uneducated Fedora policy... That policy will change... > > The Packaging Committee, the Fedora Engineering Steering Committee, and your > own peers within Red Hat have approved this guideline, and it will be moved > in hopefully today. So be it... There is an old saying... Never let management get in the way of doing your job... which I think truly applies here... So my loyalties will stay with what is best for my users and their environments, a philosophy that I'm sure my users will definitely appreciate! steved. From pertusus at free.fr Tue Mar 6 18:38:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 19:38:55 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173193330.6561.37.camel@zod.rchland.ibm.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> Message-ID: <20070306183855.GD2942@free.fr> On Tue, Mar 06, 2007 at 09:02:10AM -0600, Josh Boyer wrote: > > I'd want to know the outcome of an EPEL SIG vote before trying to decide > anything on this. That's what SIGs are for. At this point of non existence of EPEL I really can't see what is the legitimacy of an EPEL SIG vote compared with Fedora instances. People interested in EPEL should raise their concerns, though, as always. But maybe a vote isn't a real vote but something like +1 -1 0 from people on the list showing their preferences? -- Pat From mmcgrath at redhat.com Tue Mar 6 18:47:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 12:47:28 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <20070306183855.GD2942@free.fr> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183855.GD2942@free.fr> Message-ID: <45EDB740.4060407@redhat.com> Patrice Dumas wrote: > On Tue, Mar 06, 2007 at 09:02:10AM -0600, Josh Boyer wrote: > >> I'd want to know the outcome of an EPEL SIG vote before trying to decide >> anything on this. That's what SIGs are for. >> > > At this point of non existence of EPEL I really can't see what is the > legitimacy of an EPEL SIG vote compared with Fedora instances. People > interested in EPEL should raise their concerns, though, as always. > But maybe a vote isn't a real vote but something like +1 -1 0 from > people on the list showing their preferences? > huh? http://download.fedora.redhat.com/pub/epel/ We're real. -Mike From rdieter at math.unl.edu Tue Mar 6 18:47:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Mar 2007 12:47:17 -0600 Subject: Proposed guideline for init script files In-Reply-To: <45EDB647.2090808@RedHat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> <45EDB647.2090808@RedHat.com> Message-ID: <45EDB735.1070305@math.unl.edu> Steve Dickson wrote: > Please don't forget... Fedora lives for RHEL... and as soon as a > RHEL customer loses a piece of valuable information do some > uneducated Fedora policy... That policy will change... Don't be so melodramatic. If it's currently marked %config, nothing will be lost, but saved as foo.rpmsave. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 18:47:57 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 19:47:57 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200703061337.42668.jkeating@redhat.com> (Jesse Keating's message of "Tue, 6 Mar 2007 13:37:42 -0500") References: <200702271537.36532.jkeating@redhat.com> <200703061305.31477.jkeating@redhat.com> <87irde8bvh.fsf@kosh.bigo.ensc.de> <200703061337.42668.jkeating@redhat.com> Message-ID: <87ps7mdx9e.fsf@kosh.bigo.ensc.de> Jesse Keating writes: > While it may or may not be feasible to move the scripts out of /etc/, > it IS feasible to establish guidelines around how we wish these scripts > operate within Fedora. Then, it would be enough to write a guideline, that initscripts must be configurable through /etc/sysconfig entries. Again: when something is in /etc, then this means, that it can be edited and does not lose manual changes silently. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Mar 6 18:51:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 19:51:48 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <20070227160652.GC3516@neu.nirvana> References: <1172526825.16039.5.camel@Chuck> <20070227144214.12a7ab41@python3.es.egwn.lan> <20070227143947.GU9953@neu.nirvana> <20070227164451.4fe85864@python3.es.egwn.lan> <20070227160652.GC3516@neu.nirvana> Message-ID: <20070306185148.GF7703@neu.nirvana> On Tue, Feb 27, 2007 at 05:06:52PM +0100, Axel Thimm wrote: > On Tue, Feb 27, 2007 at 04:44:51PM +0100, Matthias Saou wrote: > > Axel Thimm wrote : > > > > > > No news about the possible reverting of the MANDATORY build root tag? > > > > It's still blocking a few of my submissions... Rejoice, the proposal was voted on, was ratified by fesco and is now written in the guidelines, so you can unblock your reviews. > > > spot asked me to write something up and it will hopefully be voted on > > > today: > > > > > > http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot > > > > > > Feel free to stop by on #fedora-packaging at 17:00 UTC to manipulate > > > your favourite representative. :) > > > > > > If it passes it will have to be ratified on Thursday by fesco, so if > > > all go well, you'll be able to finish up those packages (me also). > > > > Neat. Thanks. I've make a few corrections, slightly changed a few > > biased sentences and added some minor details. Please check my changes, > > and feel free to revert anything you wouldn't agree with. > > Thanks, it all looks good, and I stand embarrassed of making so many > typos in such little space ;) > > I don't see any biased stuff changed, but maybe I didn't even notice > the orginal wording was biased. For what it's worth the whole thing > *is* biased otherwise it wouldn't start with > > "has been too much talk about this topic. This topic is not a rebel > topic. This topic is BuildRoot, Bloody BuildRoot" ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Mar 6 18:47:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 19:47:15 +0100 Subject: Proposed guideline for init script files In-Reply-To: <45EDB647.2090808@RedHat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> <45EDB647.2090808@RedHat.com> Message-ID: <20070306184715.GE2942@free.fr> On Tue, Mar 06, 2007 at 01:43:19PM -0500, Steve Dickson wrote: > > > >The Packaging Committee, the Fedora Engineering Steering Committee, and > >your own peers within Red Hat have approved this guideline, and it will be > >moved in hopefully today. > So be it... There is an old saying... Never let management get in > the way of doing your job... which I think truly applies here... > So my loyalties will stay with what is best for my users and their > environments, a philosophy that I'm sure my users will definitely > appreciate! I wouldn't describe people in the FPC and FESCO as managers. They are fellow packagers, developpers and release engineers. There could be managers there, but currently it isn't the case. -- Pat From pertusus at free.fr Tue Mar 6 18:51:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 19:51:03 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45EDB740.4060407@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183855.GD2942@free.fr> <45EDB740.4060407@redhat.com> Message-ID: <20070306185103.GF2942@free.fr> On Tue, Mar 06, 2007 at 12:47:28PM -0600, Mike McGrath wrote: > > > huh? http://download.fedora.redhat.com/pub/epel/ We're real. Indeed, but very new, compared with Fedora (extras). I am not intending to say that people in EPEL aren't good people (they are basically the same than in Fedora ;-) but that the whole is still a bit immature. -- Pat From SteveD at redhat.com Tue Mar 6 19:06:40 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 06 Mar 2007 14:06:40 -0500 Subject: Proposed guideline for init script files In-Reply-To: <45EDB735.1070305@math.unl.edu> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> <45EDB647.2090808@RedHat.com> <45EDB735.1070305@math.unl.edu> Message-ID: <45EDBBC0.6010209@RedHat.com> Rex Dieter wrote: > Steve Dickson wrote: > >> Please don't forget... Fedora lives for RHEL... and as soon as a >> RHEL customer loses a piece of valuable information do some >> uneducated Fedora policy... That policy will change... > > Don't be so melodramatic. If it's currently marked %config, nothing > will be lost, but saved as foo.rpmsave. Unless I've misunderstood... '%config initscripts' are no longer legal so if a customer has valuable information in that script it will be lost... But that will be THEIR fault for putting there!!!!! And the Fedora community will teach them that lesson... Unfortunately the hard way... :-\ With policies like this (i.e. not allowing maintainers to preserver existing environments) truly give the appearance that this community really don't give a damn about anything but their own way of doing things... Very similar to Microsoft... Won't you say? steved. From rdieter at math.unl.edu Tue Mar 6 19:11:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Mar 2007 13:11:20 -0600 Subject: Proposed guideline for init script files In-Reply-To: <45EDBBC0.6010209@RedHat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> <45EDB647.2090808@RedHat.com> <45EDB735.1070305@math.unl.edu> <45EDBBC0.6010209@RedHat.com> Message-ID: <45EDBCD8.1000005@math.unl.edu> Steve Dickson wrote: > > > Rex Dieter wrote: >> Steve Dickson wrote: >> >>> Please don't forget... Fedora lives for RHEL... and as soon as a >>> RHEL customer loses a piece of valuable information do some >>> uneducated Fedora policy... That policy will change... >> >> Don't be so melodramatic. If it's currently marked %config, nothing >> will be lost, but saved as foo.rpmsave. > Unless I've misunderstood... I think so. >'%config initscripts' are no longer legal > so if a customer has valuable information in that script it will be > lost... My understanding is when upgrading from a package *with* %config foo to a package *without* %config foo will result in foo.rpmsave (if foo had been modified). -- Rex From jkeating at redhat.com Tue Mar 6 19:17:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 14:17:27 -0500 Subject: Proposed guideline for init script files In-Reply-To: <45EDBBC0.6010209@RedHat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDB735.1070305@math.unl.edu> <45EDBBC0.6010209@RedHat.com> Message-ID: <200703061417.27816.jkeating@redhat.com> On Tuesday 06 March 2007 14:06:40 Steve Dickson wrote: > Unless I've misunderstood... '%config initscripts' are no longer legal > so if a customer has valuable information in that script it will be > lost... But that will be THEIR fault for putting there!!!!! And the > Fedora community will teach them that lesson... Unfortunately > the hard way... :-\ > > With policies like this (i.e. not allowing maintainers to preserver > existing environments) truly give the appearance that this community > really don't give a damn about anything but their own way of > doing things... Very similar to Microsoft... Won't you say? In case you missed it, existing configuration (if it was properly marked, many of our current init scripts do NOT mark them as %config) will be saved when the package drops the %config attribute for the init script. Yes, future configuration should go elsewhere, and that is all in documentation. In order to clean up the distribution and make things more consolidated, some historical assumptions have to be broken. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Mar 6 19:47:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 06 Mar 2007 13:47:24 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <20070306183823.GC7703@neu.nirvana> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> Message-ID: <1173210444.6561.47.camel@zod.rchland.ibm.com> On Tue, 2007-03-06 at 19:38 +0100, Axel Thimm wrote: > On Tue, Mar 06, 2007 at 09:02:10AM -0600, Josh Boyer wrote: > > On Tue, 2007-03-06 at 15:53 +0100, Thorsten Leemhuis wrote: > > > On 06.03.2007 15:36, Patrice Dumas wrote: > > > > On Tue, Mar 06, 2007 at 08:28:48AM -0600, Mike McGrath wrote: > > > >> We've been discussing Fedora User Management in EPEL. I propose a vote, > > > >> all maintainers are welcome to vote. The outcome is FINAL. If we chose > > > > A vote isn't the way to go in my opinion. The number of people is not > > > > relevant when it comes to technical issues. > > > > > > Agreed -- it's important that the people that make the decision know the > > > pros and cons of the different proposed solutions. That's IMHO often not > > > the case for complicated technical issues like this if the group that is > > > voting is big. > > > > > > > Collecting people thoughts > > > > on that matter would be interesting though, but I think having FESCo > > > > or FPC choose would be better. > > > > > > +1 -- they finally have to ratify the solution anyway. But the issue > > > nevertheless can and of course should get discussed in public. > > > > I'd want to know the outcome of an EPEL SIG vote before trying to decide > > anything on this. That's what SIGs are for. > > The EPEL seems to be mostly against this tool, but doesn't vote > because it considers it a Fedora issue that needs to be resolved in > Fedora land. Um... why? EPEL can't support it in RHEL 4 anyway. I see the two sets being disjoint. It's not a "Fedora" problem. It's an EPEL problem. josh From mmcgrath at redhat.com Tue Mar 6 20:03:04 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 14:03:04 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <1173210444.6561.47.camel@zod.rchland.ibm.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> Message-ID: <45EDC8F8.8060606@redhat.com> Josh Boyer wrote: > > Um... why? EPEL can't support it in RHEL 4 anyway. I see the two sets > being disjoint. It's not a "Fedora" problem. It's an EPEL problem. > This statement is very nearsighted. -Mike From jwboyer at jdub.homelinux.org Tue Mar 6 20:07:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 06 Mar 2007 14:07:36 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45EDC8F8.8060606@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> Message-ID: <1173211656.6561.51.camel@zod.rchland.ibm.com> On Tue, 2007-03-06 at 14:03 -0600, Mike McGrath wrote: > Josh Boyer wrote: > > > > Um... why? EPEL can't support it in RHEL 4 anyway. I see the two sets > > being disjoint. It's not a "Fedora" problem. It's an EPEL problem. > > > This statement is very nearsighted. How so? Without an explanation I'll never learn. It's going to continue to be a trend for EPEL. Fedora will have new shiny things it wants to use, but EPEL will not be able to support them given it's lifecycle and stability goals. Trying to constantly "converge" the packages/policies for the sake of commonality is going to be an ongoing battle. So, EPEL has their own branches. Why can't there be a differing solution between Fedora and EPEL? josh From mmcgrath at redhat.com Tue Mar 6 20:15:21 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 14:15:21 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <1173211656.6561.51.camel@zod.rchland.ibm.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> Message-ID: <45EDCBD9.6080102@redhat.com> Josh Boyer wrote: > How so? Without an explanation I'll never learn. > > It's going to continue to be a trend for EPEL. Fedora will have new > shiny things it wants to use, but EPEL will not be able to support them > given it's lifecycle and stability goals. Trying to constantly > "converge" the packages/policies for the sake of commonality is going to > be an ongoing battle. > > So, EPEL has their own branches. Why can't there be a differing > solution between Fedora and EPEL? > There can be different solutions though its not optimum and should be avoided when possible. The fact is fedora user management is proprietary. No one else uses it, and there's a reason for that. It's not shiny, it's not new, it's a hacked together script that the community is very split on. It only solves a few rare use cases and it's causing real problems. I'm not going to beat around the bush about it, if it can't be done transparently it shouldn't be done. EPEL or not, there's many out there that don't want it which is why I suggested a vote. -Mike From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 20:14:40 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 21:14:40 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070306184212.GD7703@neu.nirvana> (Axel Thimm's message of "Tue, 6 Mar 2007 19:42:12 +0100") References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <20070306184212.GD7703@neu.nirvana> Message-ID: <87lkiadt8v.fsf@kosh.bigo.ensc.de> Axel Thimm writes: >> Won't work. 'rpm' in RHEL is too old and misses features required by >> fedora-usermgmt. > > what exactly does this tool solve? I require it in the following cases: * lot of servers are sharing a bind-mounted directory with unix(7)-sockets (e.g. sendmail-mta and milter servers); access restrictions are solved best with filesystem permissions and this requires consistent uids in each server * the 'apache-dav' user which writes on an NFS share; NFS4 was promised as a solution years ago but I never got it to run correctly * consistent output in logfiles (e.g. iptables -j LOG --log-uid) * there does not exist a reliable way to add system users manually; nightly 'yum upgrade' can add new users silently and repository can not be queried which/whether users will be added Then, I like it, when: * machines with identical setup are having identical uid <-> user mappings; e.g. two kickstart installations should create the same output but do not have to depend on package order (which might be different due to updated packages) * I do not have to 'chown -R -h' partitions when I reinstall a system Then, 'fedora-usermgmt' was designed in a way which would allow things like adding the new user to an LDAP directory instead into the local /etc/passwd. But this is an exotic feature since system users should not be kept in NIS/LDAP. For FC4/5, some workarounds were added which solved problems with incorrect nscd cache-invalidating. The FC6 version got some enhancements which removed error-prone stuff (e.g. 'test "$1" = 0' checks, correct 'Requires(...):') from the scriptlets which have to be written by the packagers. Same enhancements are making it possible to establish rules like 'do not remove user during uninstallation'. I admit, that rpm should handle user creation completely without manual scripts. But because this thread is about EPEL, this is not an option. > Especially if this defaults to normal useradd -r behaviour (does it > really default to this behaviour?), yes, it does. > which means that it is not really *required*. Is Fedora or ATrpm really *required*? Fact is, 'fedora-usermgmt' solves some of my problems and does not have technical drawbacks. > If it tries to solve the need for *fixed* system uid/gid then we need > to find another solution than a flaotion uid/gid window. I can not imagine which solution this could be. The only available window for fixed system uids (0-99) is nearly full. Rest was/is free for everybody's use and probably every single uid between 100 and 65535 exists on some system. We could have more luck in the upper 2^32 range, but I guess this breaks interaction with other Unixes. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Mar 6 20:27:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 06 Mar 2007 14:27:54 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45EDCBD9.6080102@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> Message-ID: <1173212874.6561.56.camel@zod.rchland.ibm.com> On Tue, 2007-03-06 at 14:15 -0600, Mike McGrath wrote: > > The fact is fedora user management is proprietary. No one else uses > it, and there's a reason for that. It's not shiny, it's not new, it's a > hacked together script that the community is very split on. It only > solves a few rare use cases and it's causing real problems. I'm not > going to beat around the bush about it, if it can't be done > transparently it shouldn't be done. EPEL or not, there's many out there > that don't want it which is why I suggested a vote. You should have lead with this in your initial email. Calling for a vote (which arguably sounded like a call for a vote about EPEL and not Fedora+EPEL) without something like the above is fairly ambiguous. That being said, rock on. josh From nicolas.mailhot at laposte.net Tue Mar 6 20:28:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 Mar 2007 21:28:46 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45EDCBD9.6080102@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> Message-ID: <1173212926.4189.1.camel@rousalka.dyndns.org> Le mardi 06 mars 2007 ? 14:15 -0600, Mike McGrath a ?crit : > It only > solves a few rare use cases and it's causing real problems. If you call "rare use cases" every server that didn't snatch a sub-100 uid while there where some room left -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mattdm at mattdm.org Tue Mar 6 20:34:06 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Mar 2007 15:34:06 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173212926.4189.1.camel@rousalka.dyndns.org> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <1173212926.4189.1.camel@rousalka.dyndns.org> Message-ID: <20070306203406.GA30666@jadzia.bu.edu> On Tue, Mar 06, 2007 at 09:28:46PM +0100, Nicolas Mailhot wrote: > > It only > > solves a few rare use cases and it's causing real problems. > If you call "rare use cases" every server that didn't snatch a sub-100 > uid while there where some room left To be clear, I'm only in favor of getting rid of it if some other way of rationally assigning fixed user ids is phased in. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Tue Mar 6 20:34:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Mar 2007 14:34:23 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45EDCBD9.6080102@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> Message-ID: <45EDD04F.9020009@math.unl.edu> Mike McGrath wrote: > It only solves a few rare use cases and it's causing real problems. Honestly, I've yet to see/hear of anything except theoretical problems based on ignorance of how fedora-usermngt works. You're now the second person on related threads to claim real problems exist. I'm curious, what are they? -- Rex From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 6 20:45:49 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 06 Mar 2007 21:45:49 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45EDCBD9.6080102@redhat.com> (Mike McGrath's message of "Tue, 06 Mar 2007 14:15:21 -0600") References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> Message-ID: <87hcsydrsy.fsf@kosh.bigo.ensc.de> Mike McGrath writes: > it's causing real problems. To which (technical) problems are you refering here? Run/installtime requirements for 'fedora-usermgmt' can be disabled by building with a '--without fedora' switch. I do not think that a non-trivial spec file can be shared across distributions or even between different versions of a distribution. Therefore, either remove the fedora-usermgmt code completely from the EPEL packages and write them in in a merge-friendly way, or create a small fedora-usermgmt-devel replacement (without the features requiring newer rpm) and expand the macros to the plain shadow-utils variant. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Mar 6 20:50:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 14:50:01 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45EDD04F.9020009@math.unl.edu> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> Message-ID: <45EDD3F9.9030707@redhat.com> Rex Dieter wrote: > Mike McGrath wrote: >> It only solves a few rare use cases and it's causing real problems. > > Honestly, I've yet to see/hear of anything except theoretical problems > based on ignorance of how fedora-usermngt I'm not ignorant of how it works. But in the many years I've been using Linux, even in environments of thousands of machines I've never run into a use case that needed to be solved by fedora user mgmt. Having said that, I understand that some have. I'm not against something. As long as that something is completely transparent. The current system isn't. > You're now the second person on related threads to claim real problems > exist. I'm curious, what are they? I'll give you 3 1) It doesn't work in epel 2) It ties us to something proprietary. No one else uses it, even dists that are downstream from us remove it, which is embarrassing if nothing else. 3) It's not universal, only some packages use it, some don't. So only some of the use cases for some of the packages are covered. -Mike From mmcgrath at redhat.com Tue Mar 6 21:07:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 15:07:07 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87hcsydrsy.fsf@kosh.bigo.ensc.de> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> Message-ID: <45EDD7FB.5020406@redhat.com> Enrico Scholz wrote: > To which (technical) problems are you refering here? Run/installtime > requirements for 'fedora-usermgmt' can be disabled by building with a > '--without fedora' switch. > How convenient for us. > I do not think that a non-trivial spec file can be shared across > distributions or even between different versions of a distribution. > The thing that makes it non-trivial is fedora-usermgmt. > Therefore, either remove the fedora-usermgmt code completely from the > EPEL packages and write them in in a merge-friendly way, or create a > small fedora-usermgmt-devel replacement (without the features requiring > newer rpm) and expand the macros to the plain shadow-utils variant. > Again, you can pretend that no problems exist and that no one is complaining just because its convenient for your needs but the fact is we've traded one set of problems for another. I'm still pushing for a vote because I think there's more people that would prefer to remove fedora-usermgmt then keep it. I've even offered my preferred way which would work for everyone; make it transparent and replace useradd. Anything less than that is a hack. -Mike -Mike From nicolas.mailhot at laposte.net Tue Mar 6 21:21:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 Mar 2007 22:21:04 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45EDD7FB.5020406@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> Message-ID: <1173216064.3698.1.camel@rousalka.dyndns.org> Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > I've even offered my preferred way which > would work for everyone; make it transparent and replace useradd. > Anything less than that is a hack. Or bite the bullet and reserve a new fixed uid range Anything but the current "there's no problem" song -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From smooge at gmail.com Tue Mar 6 21:35:42 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 6 Mar 2007 14:35:42 -0700 Subject: Fedora User Management (revisited) In-Reply-To: <45EDD04F.9020009@math.unl.edu> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> Message-ID: <80d7e4090703061335j7c80b94ak5b98f781b87e7252@mail.gmail.com> On 3/6/07, Rex Dieter wrote: > Mike McGrath wrote: > > It only solves a few rare use cases and it's causing real problems. > > Honestly, I've yet to see/hear of anything except theoretical problems > based on ignorance of how fedora-usermngt works. > > You're now the second person on related threads to claim real problems > exist. I'm curious, what are they? > I had a problem on a cluster of systems that for some reason ended up with multiple different UID's for the same application. I did not know why it happened.. but it caused me enough problems cleaning it up it got on my bad list. [This was early on in FUM so I expect I hit a bug.] I then ran into a problem where I needed to have various FE items working on RHEL-2,3,4 systems. Running into the fact it used items not supported by those OS's added more to my dis-temper. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Tue Mar 6 21:44:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 15:44:49 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <1173216064.3698.1.camel@rousalka.dyndns.org> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> Message-ID: <45EDE0D1.4020200@redhat.com> Nicolas Mailhot wrote: > Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > >> I've even offered my preferred way which >> would work for everyone; make it transparent and replace useradd. >> Anything less than that is a hack. >> > > Or bite the bullet and reserve a new fixed uid range > > Anything but the current "there's no problem" song > My issues have nothing to do with uid's. And I'm not the one asking what the problem is, I've stating there is one. -Mike From mmcgrath at redhat.com Tue Mar 6 22:15:36 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 16:15:36 -0600 Subject: Extras pushes Message-ID: <45EDE808.80508@redhat.com> Extras pushes are on hold for the moment while we re-order the push process. It should be transparent to both the users and the pushers when its back online. We're expecting it to be back up and running later tonight or early tomorrow. -Mike From bugs.michael at gmx.net Tue Mar 6 22:43:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 23:43:51 +0100 Subject: Extras pushes In-Reply-To: <45EDE808.80508@redhat.com> References: <45EDE808.80508@redhat.com> Message-ID: <20070306234351.1544b194.bugs.michael@gmx.net> On Tue, 06 Mar 2007 16:15:36 -0600, Mike McGrath wrote: > Extras pushes are on hold for the moment while we re-order the push > process. It should be transparent to both the users and the pushers > when its back online. We're expecting it to be back up and running > later tonight or early tomorrow. What are you going to change? And why is it a secret? From mmcgrath at redhat.com Tue Mar 6 22:48:35 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 16:48:35 -0600 Subject: Extras pushes In-Reply-To: <20070306234351.1544b194.bugs.michael@gmx.net> References: <45EDE808.80508@redhat.com> <20070306234351.1544b194.bugs.michael@gmx.net> Message-ID: <45EDEFC3.9060700@redhat.com> Michael Schwendt wrote: > On Tue, 06 Mar 2007 16:15:36 -0600, Mike McGrath wrote: > > >> Extras pushes are on hold for the moment while we re-order the push >> process. It should be transparent to both the users and the pushers >> when its back online. We're expecting it to be back up and running >> later tonight or early tomorrow. >> > > What are you going to change? And why is it a secret? > What: We're removing fpserv from the mix. Its just a middle man Secret: Lots of stuff happens in Fedora. Right now the build process goes from buildsys to fpserv to a box in RH via rsync. Jeremy and I are looking to have red hat get it directly from buildsys. We've been discussing this in #fedora-admin. Those wishing to learn about whats going on in infrastructure would be wise to sit and examine that public room as many secrets are shared. -Mike From bugs.michael at gmx.net Tue Mar 6 22:54:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Mar 2007 23:54:17 +0100 Subject: Extras pushes In-Reply-To: <45EDEFC3.9060700@redhat.com> References: <45EDE808.80508@redhat.com> <20070306234351.1544b194.bugs.michael@gmx.net> <45EDEFC3.9060700@redhat.com> Message-ID: <20070306235417.3de7743d.bugs.michael@gmx.net> On Tue, 06 Mar 2007 16:48:35 -0600, Mike McGrath wrote: > Michael Schwendt wrote: > > On Tue, 06 Mar 2007 16:15:36 -0600, Mike McGrath wrote: > > > > > >> Extras pushes are on hold for the moment while we re-order the push > >> process. It should be transparent to both the users and the pushers > >> when its back online. We're expecting it to be back up and running > >> later tonight or early tomorrow. > >> > > > > What are you going to change? And why is it a secret? > > > What: > We're removing fpserv from the mix. Its just a middle man > > Secret: > Lots of stuff happens in Fedora. > > Right now the build process goes from buildsys to fpserv to a box in RH > via rsync. Jeremy and I are looking to have red hat get it directly > from buildsys. We've been discussing this in #fedora-admin. This short summary is sufficiently detailed. Thanks. It would have been wise to include it in your original post. > Those > wishing to learn about whats going on in infrastructure would be wise to > sit and examine that public room as many secrets are shared. Observing an IRC channel 24/7 may work for you as a Red Hat employee working on Fedora, but doesn't work for many community members. From mmcgrath at redhat.com Tue Mar 6 23:00:37 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 17:00:37 -0600 Subject: Extras pushes In-Reply-To: <20070306235417.3de7743d.bugs.michael@gmx.net> References: <45EDE808.80508@redhat.com> <20070306234351.1544b194.bugs.michael@gmx.net> <45EDEFC3.9060700@redhat.com> <20070306235417.3de7743d.bugs.michael@gmx.net> Message-ID: <45EDF295.1030403@redhat.com> Michael Schwendt wrote: >> Those >> wishing to learn about whats going on in infrastructure would be wise to >> sit and examine that public room as many secrets are shared. >> > > Observing an IRC channel 24/7 may work for you as a Red Hat employee > working on Fedora, but doesn't work for many community members. > I don't want to make a thing of this but the infrastructure team is extremely busy, if we sent a notice out for everything we did people would just ignore it anyway.... Many community members do keep up on #fedora-admin and know whats going on, just as I did before I became a Red Hat employee, I take offense when people claim we're being secret just because a notice isn't sent out with a complete summery of everything we do. The fact is stuff happens, if you care what happens to the infrastructure join the team, otherwise you'll get the "need to know" information like this outage notice. -Mike From rc040203 at freenet.de Wed Mar 7 03:31:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Mar 2007 04:31:04 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200703061305.31477.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDA6DE.5010702@RedHat.com> <200703061305.31477.jkeating@redhat.com> Message-ID: <1173238264.25839.227.camel@mccallum.corsepiu.local> On Tue, 2007-03-06 at 13:05 -0500, Jesse Keating wrote: > On Tuesday 06 March 2007 12:37:34 Steve Dickson wrote: > > Question: what right do we have to destroy our users initscripts > > when they changed? There has been an expectation for a number of > > years, in a number of packages that if an initscript that has > > changed it will be preserved on updates.. So why should we change that? > > For the simple fact that init scripts should _not_ be configuration files, > _at_ _all_, and the packaging system should not encourage people to treat > them as such. Configuration must happen in real config files so that it can > be preserved while things in the init script like binary name and necessary > options can change when the application changes. I personally feel that the > init script needs to live somewhere outside of /etc to make this even more > clear, but that's a much larger change that I can't necessarily drive right > now. If your customers have to do configuration in the init script, that is > a bug in your software that needs to be fixed. If they have to work around > some bug that we haven't fixed yet, they really should copy the init script > to a new name and disable the old script, or exclude that package from being > updated. We're really trying to clean up the system and consolidate > configuration into concise areas rather than scattered about the file system. > These are the changes that Fedora can make moving forward. If RHEL doesn't > want to play along, that's their choice. > > The Packaging Committee, the Fedora Engineering Steering Committee, and your > own peers within Red Hat have approved this guideline, and it will be moved > in hopefully today. Yes, they all failed - It's a serious mistake. Ralf From peter at thecodergeek.com Wed Mar 7 06:13:44 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Mar 2007 22:13:44 -0800 Subject: Is referencing the GPL in the package's README enough of a "license"? Message-ID: <1173248024.3932.12.camel@tuxhugs> Hi, all. I have a question about the legal status of a package I'm working on. I'm nearly done with writing a nice package of Tavis Ormandy's scanmem utility [1]. However, it contains no full license text, and the headers in the source files only contain author/version informations. The only reference to a license aside from what's on the website is that the README file (which I include as %doc) contains the following line: License: GPL Is this reference enough, or should I also include a full copy of the GPL as %doc as well? (If so, I'll email Tavis and bug him about including it in the tarball.) Thanks. [1] http://taviso.decsystem.org/scanmem.html -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Mar 7 06:51:28 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 07 Mar 2007 00:51:28 -0600 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: <1173248024.3932.12.camel@tuxhugs> References: <1173248024.3932.12.camel@tuxhugs> Message-ID: <1173250288.5456.15.camel@localhost.localdomain> On Tue, 2007-03-06 at 22:13 -0800, Peter Gordon wrote: > Hi, all. > > I have a question about the legal status of a package I'm working on. > I'm nearly done with writing a nice package of Tavis Ormandy's scanmem > utility [1]. However, it contains no full license text, and the headers > in the source files only contain author/version informations. The only > reference to a license aside from what's on the website is that the > README file (which I include as %doc) contains the following line: > > License: GPL > > Is this reference enough, or should I also include a full copy of the > GPL as %doc as well? (If so, I'll email Tavis and bug him about > including it in the tarball.) So, here's the best answer that I have (IANAL, this is just what I've picked up from observation): The best way is for all of the source code to document the full license (or if the full license is long, an abridged version) in a header comment: /* This code is under the Foo Bar License. * You may Foo with this license, or Bar if you choose. * Yadda, yadda, yadda, abridged license text here. */ The next best way is for the source code itself to refer to the license in a dedicated file: /* This code is under the Foo Bar License. * This code should have included a copy of the Foo Bar * License in LICENSE. */ If the code doesn't say what license it is under, strictly speaking, its not legally under that license. Unfortunately, lots of code doesn't license itself this way, so we have to assume the intent of the author/authors. When assuming the intent, we look for files called "COPYRIGHT" or "LICENSE", that contain the full license text(s) for the code within the software component. Barring that, we look for README files that contain the full license text(s) for the code within the software component. Worst case scenario: There is nothing but a reference to the license on a website in a README file (or COPYING/LICENSE). Actually, worst case is when there is no documentation anywhere on the license within the source tarball. Then we have to trust the website distributing it. This is really not ok for Fedora. The reference to the license is a good start, but its really not what Fedora (or in this specific case, what the FSF) wants. Ask upstream if they are willing to at least include a full copy of the license text(s) in the tarball, if not reference/include in the source code. See: http://www.gnu.org/licenses/gpl.html#SEC4 (If for whatever reason they say no, you're not required to artificially insert a copy of the GPL license text into the package. Depending on the ilegal interpretation, this may introduce legal liability on you. You need to decide whether you are comfortable with that or not. This is why it is ideal for upstream to add it, so this is a non-issue. If upstream says no, and you decide not to add it, but upstream clarifies that it is indeed under the license noted in the README, you can put it in Fedora as is.) ~spot From peter at thecodergeek.com Wed Mar 7 07:28:37 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Mar 2007 23:28:37 -0800 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: <1173250288.5456.15.camel@localhost.localdomain> References: <1173248024.3932.12.camel@tuxhugs> <1173250288.5456.15.camel@localhost.localdomain> Message-ID: <1173252517.22626.2.camel@tuxhugs> On Wed, 2007-03-07 at 00:51 -0600, Tom 'spot' Callaway wrote: > [... Snipped a huge amount of useful information and explanation...] That's a great explanation - thanks! I will bug Tavis about it to be certain, then. :) -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gauret at free.fr Wed Mar 7 09:15:16 2007 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 7 Mar 2007 10:15:16 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200703061417.27816.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> <45EDB735.1070305@math.unl.edu> <45EDBBC0.6010209@RedHat.com> <200703061417.27816.jkeating@redhat.com> Message-ID: Imagine we move from traditional SysVinit to a new init system (it won't be for F7, but it's been said before: http://fedoraproject.org/wiki/Releases/FeatureNewInit) That new init system will have to be configured by config files, since it will probably not use one shell scripts by service. If we manage to move all the configuration into proper config files, it will make the transition to this future init system much easier. > Please don't forget... Fedora lives for RHEL... Great. Let me post that on /. right now. From rdieter at math.unl.edu Wed Mar 7 16:33:08 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 07 Mar 2007 10:33:08 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <45EDD3F9.9030707@redhat.com> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> <45EDD3F9.9030707@redhat.com> Message-ID: <45EEE944.8080908@math.unl.edu> Mike McGrath wrote: > Rex Dieter wrote: >> You're now the second person on related threads to claim real problems >> exist. I'm curious, what are they? > I'll give you 3 > 1) It doesn't work in epel > 2) It ties us to something proprietary. No one else uses it, even dists > that are downstream from us remove it, which is embarrassing if nothing > else. > 3) It's not universal, only some packages use it, some don't. So only > some of the use cases for some of the packages are covered. OK, I guess my definition of "real problems" is different than yours. Mine is: it's broken and doesn't work. Other than 1 (which can potentially be fixed/worked-around), the rest are comments around the idea that fedora-usermgmt may not be the *ideal* solution. And I agree it's not ideal. What I disagree with is the notion that fedora-usermnmt be rejected before a better, working solution is ready to take its place(1). -- Rex (1) This is frustrating to me a bit lately on a wider variety of subjects, when *working* solutions are rejected because they are less-than-ideal or not perfect. This leads to great debates and discourse, which more often than not, results in no consensus or definitive right answers. In the meantime, months go by... and that just plain sucks, big time. From a.badger at gmail.com Wed Mar 7 17:16:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Mar 2007 09:16:56 -0800 Subject: Fedora User Management (revisited) In-Reply-To: <45EEE944.8080908@math.unl.edu> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> <45EDD3F9.9030707@redhat.com> <45EEE944.8080908@math.unl.edu> Message-ID: <1173287816.3329.68.camel@localhost.localdomain> On Wed, 2007-03-07 at 10:33 -0600, Rex Dieter wrote: > Mike McGrath wrote: > > Rex Dieter wrote: > > >> You're now the second person on related threads to claim real problems > >> exist. I'm curious, what are they? > > > I'll give you 3 > > 1) It doesn't work in epel > > 2) It ties us to something proprietary. No one else uses it, even dists > > that are downstream from us remove it, which is embarrassing if nothing > > else. > > 3) It's not universal, only some packages use it, some don't. So only > > some of the use cases for some of the packages are covered. > > OK, I guess my definition of "real problems" is different than yours. > Mine is: it's broken and doesn't work. > > Other than 1 (which can potentially be fixed/worked-around), the rest > are comments around the idea that fedora-usermgmt may not be the *ideal* > solution. And I agree it's not ideal. > > What I disagree with is the notion that fedora-usermnmt be rejected > before a better, working solution is ready to take its place(1). > I agree 100%. Peter Vrabec pvrabec at r.c seems to be the shadow-utils maintainer. If we really want to get the functionality into shadow-utils so we don't have to do it in a separate package, someone needs to get him to comment on: 1) Can we implement this in shadow-utils 2) If not, does he have a suggestion for dealing with expanding the set of static userids? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Mar 7 17:22:21 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 7 Mar 2007 10:22:21 -0700 Subject: Fedora User Management (revisited) In-Reply-To: <45EEE944.8080908@math.unl.edu> References: <45ED7AA0.6070109@redhat.com> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> <45EDD3F9.9030707@redhat.com> <45EEE944.8080908@math.unl.edu> Message-ID: <80d7e4090703070922i5ef1c32br67b4cb0937be4777@mail.gmail.com> On 3/7/07, Rex Dieter wrote: > Mike McGrath wrote: > > Rex Dieter wrote: > > >> You're now the second person on related threads to claim real problems > >> exist. I'm curious, what are they? > > > I'll give you 3 > > 1) It doesn't work in epel > > 2) It ties us to something proprietary. No one else uses it, even dists > > that are downstream from us remove it, which is embarrassing if nothing > > else. > > 3) It's not universal, only some packages use it, some don't. So only > > some of the use cases for some of the packages are covered. > > OK, I guess my definition of "real problems" is different than yours. > Mine is: it's broken and doesn't work. > > -- Rex > > (1) This is frustrating to me a bit lately on a wider variety of > subjects, when *working* solutions are rejected because they are > less-than-ideal or not perfect. This leads to great debates and > discourse, which more often than not, results in no consensus or > definitive right answers. In the meantime, months go by... and that > just plain sucks, big time. I was reading a history of the Greek democracies and their eventual downfall. The reason that many of them failed in the end was the constant bickering over ideal solutions that could not be reached. There was the apocryphal story of the city argueing about defense plans while the army was inside the city wall. One argument that came from this was that republics scale better than democracies on large scale decisions because democracies tend towards mob-rule as people get swayed by emotions of the street. Another book I am reading is the "Zen and the Art of Systems Analysis: Meditations on Computer Systems Development" by Patrick McDermott. I won't say its a great read, but it did have a good point on team building (I do not have the book with me so this is an indirect quote): When there are multiple ideas, then you need to build consensus. Consensus meaning the pure term that "even though I do not agree with the answer, I will support it for the betterment of the team." Consensus is desirable when you want a sense of involvement and need commitment from those involved. When there is one idea, appoint a dictator and follow them. My biggest problem with the fedora-user tools is that neither one of these was used. If fedora-usermanagement is going to be the one way, then we need to use it all the way through. If it isnt, then the lack of consensus behind it in the first place means that it will keep coming up like a bad lunch. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From bpepple at fedoraproject.org Wed Mar 7 20:58:37 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 07 Mar 2007 15:58:37 -0500 Subject: Plan for tomorrows (20070308) FESCO meeting Message-ID: <1173301117.31536.7.camel@Chuck> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- Core Package Review Process - Tracker Bugs -- warren /topic FESCO-Meeting -- sponsor nominations -- Jarod Wilson, nominated by Dennis Gilmore /topic FESCO-Meeting -- MISC -- cvs-import changes - c4chris /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- EPEL Report /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed Mar 7 21:11:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Mar 2007 15:11:02 -0600 Subject: Summary of 2007-03-06 Packaging Committee meeting Message-ID: I intended to get this out yesterday and indeed had the wiki pages up then; hopefully once I'm used to the format I can get these done much more quickly. (Note to self: It's not in the wiki until you click "Save Changes".) Meeting minutes and full logs of the packaging meeting which occurred on 2007.03.06 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070306 http://fedoraproject.org/wiki/Packaging/IRCLog20070306 Executive summary: Issues pending FESCO ratification: * Firmware packaging guidelines accepted (6 yea, 0 nay): https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html * Draft disallowing %config files under /usr accepted (5 yea, 1 nay): http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs Misc business: * tibbs will provide summaries and minutes for meetings * Meetings will henceforth be held in #fedora-meeting * #fedora-packaging is closed and will redirect to #fedora-devel Please see the minutes and log for full information. Comments regarding the format of this summary and of the minutes are appreciated. - J< From mmcgrath at redhat.com Wed Mar 7 21:33:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 15:33:06 -0600 Subject: Extras pushes In-Reply-To: <45EDE808.80508@redhat.com> References: <45EDE808.80508@redhat.com> Message-ID: <45EF2F92.3030609@redhat.com> Everything seems to be working now. The RH Mirror now gets signed packages directly from the build master. Let someone in the infrastructure team know if anything is amiss. -Mike Mike McGrath wrote: > Extras pushes are on hold for the moment while we re-order the push > process. It should be transparent to both the users and the pushers > when its back online. We're expecting it to be back up and running > later tonight or early tomorrow. > > -Mike > From notting at redhat.com Wed Mar 7 22:37:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:37:12 -0500 Subject: Move libwrap.so.whatever to /lib In-Reply-To: <20070306184228.GA2718@redhat.com> References: <20070306184228.GA2718@redhat.com> Message-ID: <20070307223712.GF25018@nostromo.devel.redhat.com> Tomas Janousek (tjanouse at redhat.com) said: > one of the upcoming features of syslog-ng is, as far as I've been told, the > support for tcp_wrappers. This would require the tcp_wrappers library to be in > /lib instead of /usr/lib (details in [1]). > > Is this move ok in Fedora? E.g. in Debian, it's in /lib, so I suppose it is, > I just want to be sure I may do the move. Makes sense to me. Bill From buildsys at fedoraproject.org Wed Mar 7 23:30:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 7 Mar 2007 18:30:00 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-03-07 Message-ID: <20070307233000.E3F7D152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) eclipse FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) ekiga FC6-updates > FC7 (0:2.0.5-3.fc6 > 0:2.0.5-2.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) nspr FC6-updates > FC7 (0:4.6.6-0.6.0.fc6 > 0:4.6.5-2) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) andreas AT bawue.net: GraphicsMagick FE5 > FE7 (0:1.1.7-7.fc5 > 0:1.1.7-6.fc7) FE6 > FE7 (0:1.1.7-7.fc6 > 0:1.1.7-6.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) foolish AT guezz.net: gtk-recordmydesktop FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) paul AT city-fan.org: grepmail FE5 > FE7 (0:5.3033-1.fc5 > 0:5.3032-5.fc7) FE6 > FE7 (0:5.3033-1.fc6 > 0:5.3032-5.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rc040203 AT freenet.de: perl-DBIx-SearchBuilder FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) paps FC6-updates > FC7 (0:0.6.6-18.fc6 > 0:0.6.6-17.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) ekiga: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.0.5-3.fc6 > 0:2.0.5-2.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) GraphicsMagick: andreas AT bawue.net FE5 > FE7 (0:1.1.7-7.fc5 > 0:1.1.7-6.fc7) FE6 > FE7 (0:1.1.7-7.fc6 > 0:1.1.7-6.fc7) grepmail: paul AT city-fan.org FE5 > FE7 (0:5.3033-1.fc5 > 0:5.3032-5.fc7) FE6 > FE7 (0:5.3033-1.fc6 > 0:5.3032-5.fc7) gtk-recordmydesktop: foolish AT guezz.net FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) nspr: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:4.6.6-0.6.0.fc6 > 0:4.6.5-2) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) paps: tagoh AT redhat.com FC6-updates > FC7 (0:0.6.6-18.fc6 > 0:0.6.6-17.fc7) perl-DBIx-SearchBuilder: rc040203 AT freenet.de FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive: rc040203 AT freenet.de FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util: rc040203 AT freenet.de FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted: rc040203 AT freenet.de FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From seg at haxxed.com Thu Mar 8 05:47:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 23:47:47 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <1173216064.3698.1.camel@rousalka.dyndns.org> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> Message-ID: <1173332867.3617.127.camel@max.booze> On Tue, 2007-03-06 at 22:21 +0100, Nicolas Mailhot wrote: > Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > > I've even offered my preferred way which > > would work for everyone; make it transparent and replace useradd. > > Anything less than that is a hack. > > Or bite the bullet and reserve a new fixed uid range Been done. Add 300 to these: http://fedoraproject.org/wiki/PackageUserRegistry If anyone has special requirements for system UID ranges, they can pre-create users *before* installing packages. Presumably in this situation LDAP or something is being used anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Mar 8 05:53:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 23:53:01 -0600 Subject: Extras pushes In-Reply-To: <45EDF295.1030403@redhat.com> References: <45EDE808.80508@redhat.com> <20070306234351.1544b194.bugs.michael@gmx.net> <45EDEFC3.9060700@redhat.com> <20070306235417.3de7743d.bugs.michael@gmx.net> <45EDF295.1030403@redhat.com> Message-ID: <1173333181.3617.132.camel@max.booze> On Tue, 2007-03-06 at 17:00 -0600, Mike McGrath wrote: > I don't want to make a thing of this but the infrastructure team is > extremely busy, if we sent a notice out for everything we did people > would just ignore it anyway.... Many community members do keep up on > #fedora-admin and know whats going on, just as I did before I became a > Red Hat employee, I take offense when people claim we're being secret > just because a notice isn't sent out with a complete summery of > everything we do. The fact is stuff happens, if you care what happens > to the infrastructure join the team, otherwise you'll get the "need to > know" information like this outage notice. I think the point is, an IRC channel may not be the best place to discuss this stuff. A mailing list with an archive that can be linked to would be more appropriate. You apparently have enough time to chat on IRC, would it be so hard to switch the important stuff to a mailing list instead? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Mar 8 04:54:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 08 Mar 2007 05:54:34 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173332867.3617.127.camel@max.booze> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> Message-ID: <1173329674.25839.347.camel@mccallum.corsepiu.local> On Wed, 2007-03-07 at 23:47 -0600, Callum Lerwick wrote: > On Tue, 2007-03-06 at 22:21 +0100, Nicolas Mailhot wrote: > > Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > > > I've even offered my preferred way which > > > would work for everyone; make it transparent and replace useradd. > > > Anything less than that is a hack. > > > > Or bite the bullet and reserve a new fixed uid range > > Been done. Add 300 to these: > > http://fedoraproject.org/wiki/PackageUserRegistry > > If anyone has special requirements for system UID ranges, they can > pre-create users *before* installing packages. This is inapplicable, because the system being used to administrate users might not be accessible/available during installation of a package. > Presumably in this > situation LDAP or something is being used anyway. In my case it's yp/nis - it's only available when the network is up, which doesn't apply in certain situations (eg. offline CD-installs). Ralf From fedora at leemhuis.info Thu Mar 8 06:00:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Mar 2007 07:00:42 +0100 Subject: Plan for tomorrows (20070308) FESCO meeting In-Reply-To: <1173301117.31536.7.camel@Chuck> References: <1173301117.31536.7.camel@Chuck> Message-ID: <45EFA68A.600@leemhuis.info> On 07.03.2007 21:58, Brian Pepple wrote: > /topic FESCO-Meeting -- EPEL Report Meeting summary has the detail; see: https://www.redhat.com/archives/epel-devel-list/2007-March/msg00058.html Not much news; we plan to have a list in the wiki which Extras packagers that are willing to work on EPEL and which not -- but that list (?) will be announced to the world properly *after* the "EPEL Package maintenance and update policy" is in place and the RHEL5 builder up2date with RHEL5 final, so that people can actually start for real then and know what to build for EPEL4 and EPEL5. > /topic FESCo meeting -- Free discussion around Fedora I'd like to hear FESCo's take on the fedora-usermgmt stuff. Would be ideal if it could try create and guide a working group (if there are enough people(?) that are willing to be part of it) that looks closer at the problem and solves it once and for all. Cu thl (?) -- okay, the place is not that hard to find and you can actually change your status in it already, but I'll send a proper announcement for it later when EPEL really is ready (?) -- no, I'm not interested, I don't care much about it -- but it seems a lot of people do, so those would probably be ideal for the job ;-) From fedora at leemhuis.info Thu Mar 8 06:18:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Mar 2007 07:18:39 +0100 Subject: Summary of 2007-03-06 Packaging Committee meeting In-Reply-To: References: Message-ID: <45EFAABF.2070000@leemhuis.info> On 07.03.2007 22:11, Jason L Tibbitts III wrote: > Meeting minutes and full logs of the packaging meeting which occurred > on 2007.03.06 are online: thx tibbs for writing the meeting. Your work is much appreciated. > http://fedoraproject.org/wiki/Packaging/Minutes > http://fedoraproject.org/wiki/Packaging/Minutes20070306 > http://fedoraproject.org/wiki/Packaging/IRCLog20070306 On minor suggestion: why not put the full IRC log below the minutes on the same wiki page, just like it is done for FESCo reports? See http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 That would result in only one page per meeting and not two -- one page less the wiki has to take care of (might be a bit quicker during wikie searches and is less cruft in general afaics). CU thl From fedora at leemhuis.info Thu Mar 8 06:22:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Mar 2007 07:22:06 +0100 Subject: Plan for tomorrows (20070308) FESCO meeting In-Reply-To: <1173301117.31536.7.camel@Chuck> References: <1173301117.31536.7.camel@Chuck> Message-ID: <45EFAB8E.2090205@leemhuis.info> On 07.03.2007 21:58, Brian Pepple wrote: > /topic FESCo meeting -- Free discussion around Fedora Two other things: * could FESCO please discuss/vote about closing fedora-extras-list? See discussion at https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00004.html If FESCo agrees I'll work on closing that list with the list-admins once buildsys at fedoraproject.org is allowed to post to fedora-devel and the scripts got pointed there. * what does FESCo think about the garbage-collector.rpm idea discussed in https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html Or is this something for the Packaging Committee? CU thl From bugs.michael at gmx.net Thu Mar 8 07:10:21 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Mar 2007 08:10:21 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173332867.3617.127.camel@max.booze> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> Message-ID: <20070308081021.85de3735.bugs.michael@gmx.net> On Wed, 07 Mar 2007 23:47:47 -0600, Callum Lerwick wrote: > On Tue, 2007-03-06 at 22:21 +0100, Nicolas Mailhot wrote: > > Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > > > I've even offered my preferred way which > > > would work for everyone; make it transparent and replace useradd. > > > Anything less than that is a hack. > > > > Or bite the bullet and reserve a new fixed uid range > > Been done. Add 300 to these: > > http://fedoraproject.org/wiki/PackageUserRegistry That table [has been and] still is only for "fedora-usermgmt". From bugs.michael at gmx.net Thu Mar 8 07:43:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Mar 2007 08:43:19 +0100 Subject: Extras pushes In-Reply-To: <1173333181.3617.132.camel@max.booze> References: <45EDE808.80508@redhat.com> <20070306234351.1544b194.bugs.michael@gmx.net> <45EDEFC3.9060700@redhat.com> <20070306235417.3de7743d.bugs.michael@gmx.net> <45EDF295.1030403@redhat.com> <1173333181.3617.132.camel@max.booze> Message-ID: <20070308084319.37112db1.bugs.michael@gmx.net> On Wed, 07 Mar 2007 23:53:01 -0600, Callum Lerwick wrote: > I think the point is, an IRC channel may not be the best place to > discuss this stuff. A mailing list with an archive that can be linked to > would be more appropriate. You apparently have enough time to chat on > IRC, would it be so hard to switch the important stuff to a mailing list > instead? A lot of the chatting on IRC is irrelevant. It only creates big log files, which make such channels inappropriate for constant monitoring. The fact that a few dozen people do lurk on some IRC channels for various reasons (such as finding the topics and the people entertaining) is not equal to saying "this is the most efficient way to communicate something inside a larger project". The key problem with the notice, which started this particular thread, is that it reads like a riddle, even for those at the front of the push process. From bugs.michael at gmx.net Thu Mar 8 07:52:32 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Mar 2007 08:52:32 +0100 Subject: Plan for tomorrows (20070308) FESCO meeting In-Reply-To: <45EFAB8E.2090205@leemhuis.info> References: <1173301117.31536.7.camel@Chuck> <45EFAB8E.2090205@leemhuis.info> Message-ID: <20070308085232.487b6b04.bugs.michael@gmx.net> On Thu, 08 Mar 2007 07:22:06 +0100, Thorsten Leemhuis wrote: > * what does FESCo think about the garbage-collector.rpm idea discussed > in > https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html > Or is this something for the Packaging Committee? It's shocking to see that some commenters question the use of versioned Obsoletes. And meanwhile, there's another request for removal of a package that is still in FC-6 and FC-5 and creates wreckage during/after a dist-upgrade. http://fedoraproject.org/wiki/Extras/RepoRequests?action=diff&rev2=74&rev1=73 From panemade at gmail.com Thu Mar 8 09:31:37 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Thu, 8 Mar 2007 15:01:37 +0530 Subject: Plan for tomorrows (20070308) FESCO meeting In-Reply-To: <20070308085232.487b6b04.bugs.michael@gmx.net> References: <1173301117.31536.7.camel@Chuck> <45EFAB8E.2090205@leemhuis.info> <20070308085232.487b6b04.bugs.michael@gmx.net> Message-ID: Hi, On 3/8/07, Michael Schwendt wrote: > On Thu, 08 Mar 2007 07:22:06 +0100, Thorsten Leemhuis wrote: > > > * what does FESCo think about the garbage-collector.rpm idea discussed > > in > > https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html > > Or is this something for the Packaging Committee? > > It's shocking to see that some commenters question the use of versioned > Obsoletes. Is that wrong thing to ask maintainers to have versioned Obsoletes? If yes then we got a bug against rpmlint's warning message "unversioned-explicit-obsoletes" Whose description is given as-> The specfile contains an unversioned Obsoletes: token, which will match all older, equal and newer versions of the obsoleted thing. This may cause update problems, restrict future package/provides naming, and may match something it was originally not inteded to match -- make the Obsoletes versioned if possible. So what is the correct way for handling above rpmlint warning message? May be i am wrong in my understanding. Kindly correct me. Regards, Parag. From Axel.Thimm at ATrpms.net Thu Mar 8 13:46:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 14:46:36 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173332867.3617.127.camel@max.booze> References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> Message-ID: <20070308134636.GA30136@neu.nirvana> On Wed, Mar 07, 2007 at 11:47:47PM -0600, Callum Lerwick wrote: > On Tue, 2007-03-06 at 22:21 +0100, Nicolas Mailhot wrote: > > Le mardi 06 mars 2007 ? 15:07 -0600, Mike McGrath a ?crit : > > > I've even offered my preferred way which > > > would work for everyone; make it transparent and replace useradd. > > > Anything less than that is a hack. > > > > Or bite the bullet and reserve a new fixed uid range > > Been done. Add 300 to these: > > http://fedoraproject.org/wiki/PackageUserRegistry That is exactly the issue with this approach: These uid/guid have been silently reserved. And even worse: # smart install fedora-usermgmt # /usr/sbin/fedora-useradd 42 delme # id delme uid=5214(delme) gid=5214(delme) groups=5214(delme) That is in the middle of my user accounts! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 14:45:54 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 15:45:54 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070308134636.GA30136@neu.nirvana> (Axel Thimm's message of "Thu, 8 Mar 2007 14:46:36 +0100") References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> Message-ID: <87odn3aj4t.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> http://fedoraproject.org/wiki/PackageUserRegistry > > That is exactly the issue with this approach: These uid/guid have been > silently reserved. What do you expect here else? I do not see a problem with this when consecutive uids are used. Most systems will have a range of perhaps 500-1000 free uids which can be used for system accounts. > # smart install fedora-usermgmt > # /usr/sbin/fedora-useradd 42 delme > # id delme > uid=5214(delme) gid=5214(delme) groups=5214(delme) > > That is in the middle of my user accounts! fedora-usermgmt does not protect against broken rpm %scriptlets... (ok; when there is really need to test for missing '-r', some sanity checks can be added...). | # useradd delme will cause exactly the same brokeness. You probably wanted to do | # fedora-useradd 42 -r delme ~~ Enrico From ssorce at redhat.com Thu Mar 8 14:48:29 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 08 Mar 2007 09:48:29 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <20070306203406.GA30666@jadzia.bu.edu> References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <1173212926.4189.1.camel@rousalka.dyndns.org> <20070306203406.GA30666@jadzia.bu.edu> Message-ID: <1173365309.4114.2.camel@localhost.localdomain> On Tue, 2007-03-06 at 15:34 -0500, Matthew Miller wrote: > On Tue, Mar 06, 2007 at 09:28:46PM +0100, Nicolas Mailhot wrote: > > > It only > > > solves a few rare use cases and it's causing real problems. > > If you call "rare use cases" every server that didn't snatch a sub-100 > > uid while there where some room left > > To be clear, I'm only in favor of getting rid of it if some other way of > rationally assigning fixed user ids is phased in. Sorry to jump in in the middle of the discussion, but I really don't get why you should have fixed uids. Sure 1-100 is a too tiny space, Fedora should probably begin to reserve 1-1000 or maybe 1-10000 for "system/packages" uids. You can't fix the size problem switching from dynamic to fixed uids so I don't see the point. Simo. From mmcgrath at redhat.com Thu Mar 8 14:51:03 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 08:51:03 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87odn3aj4t.fsf@fc5.bigo.ensc.de> References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> Message-ID: <45F022D7.4010203@redhat.com> Enrico Scholz wrote: > "I do not see a problem with this when > consecutive uids are used." This is what I've been talking about, just because you don't see it doesn't mean its not there. Your fix is causing others a headache, admitting it is the first step to recovery. Has any progress been made on making fedora usermgmt part of the shadow-utils? Have you contacted the packager? -Mike From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 14:56:10 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 15:56:10 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <80d7e4090703061335j7c80b94ak5b98f781b87e7252@mail.gmail.com> (Stephen John Smoogen's message of "Tue, 6 Mar 2007 14:35:42 -0700") References: <45ED7AA0.6070109@redhat.com> <20070306143659.GA2942@free.fr> <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <45EDD04F.9020009@math.unl.edu> <80d7e4090703061335j7c80b94ak5b98f781b87e7252@mail.gmail.com> Message-ID: <87k5xrainp.fsf@fc5.bigo.ensc.de> "Stephen John Smoogen" writes: > I had a problem on a cluster of systems that for some reason ended up > with multiple different UID's for the same application. This is definitively *not* caused by fedora-usermgmt. Enrico From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 15:19:37 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 16:19:37 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45F022D7.4010203@redhat.com> (Mike McGrath's message of "Thu, 08 Mar 2007 08:51:03 -0600") References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> Message-ID: <87fy8fahkm.fsf@fc5.bigo.ensc.de> Mike McGrath writes: >> "I do not see a problem with this when consecutive uids are used." > This is what I've been talking about, just because you don't see it > doesn't mean its not there. Just because you don't see the Flying Spaghetti Monster it doesn't mean its not there... Please, stop the FUD about problems without naming them! > Your fix is causing others a headache, admitting it is the first step > to recovery. Has any progress been made on making fedora usermgmt > part of the shadow-utils? Adding an '--hint ' option to user/groupadd and giving this to a configurable 'translate-id' script might be possible. But there is so much resistance against fedora-usermgmt that I do not have desire to fight this battle outside of Fedora. > Have you contacted the packager? about what? Enrico From rdieter at math.unl.edu Thu Mar 8 15:24:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Mar 2007 09:24:07 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8fahkm.fsf@fc5.bigo.ensc.de> References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> <87fy8fahkm.fsf@fc5.bigo.ensc.de> Message-ID: <45F02A97.2060809@math.unl.edu> Enrico Scholz wrote: > Mike McGrath writes: >> Have you contacted the packager? > > about what? integrating these ideas with shadow-utils. -- Rex From mmcgrath at redhat.com Thu Mar 8 15:52:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 09:52:32 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8fahkm.fsf@fc5.bigo.ensc.de> References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> <87fy8fahkm.fsf@fc5.bigo.ensc.de> Message-ID: <45F03140.2070705@redhat.com> Enrico Scholz wrote: > Mike McGrath writes: > > >>> "I do not see a problem with this when consecutive uids are used." >>> >> This is what I've been talking about, just because you don't see it >> doesn't mean its not there. >> > > Just because you don't see the Flying Spaghetti Monster it doesn't mean > its not there... > > Please, stop the FUD about problems without naming them! > > Please see the archives of this thread, not just my comments but others as well. Ignoring the shortcomings of fedora-usermgmt won't make it go away. 1) Doesn't work in any other distro other than fedora 2) Only solves a small problem for a few packages since not all packages use it 3) Its proprietary. 4) Very few people use it 5) Its been controversial ever since its inception (otherwise it'd be mandatory by now) 6) Most sysadmins solve this problem on their own using well defined, tested tools 7) Its author doesn't seem to want to send it upstream to shadow-utils for reasons unknown 8) It hasn't gained any other foothold besides fedora 9) Its use isn't easy. Just in the last two days this thread and the EPEL thread have found people using it incorrectly or having it create UID's in an unpredictable fashion, and these are smart people. >> Your fix is causing others a headache, admitting it is the first step >> to recovery. Has any progress been made on making fedora usermgmt >> part of the shadow-utils? >> > > Adding an '--hint ' option to user/groupadd and giving this to a > configurable 'translate-id' script might be possible. But there is so > much resistance against fedora-usermgmt that I do not have desire to > fight this battle outside of Fedora. > Why should we have to do extra work to get around your hack that seems to work well for you and 5 other fedora users? >> Have you contacted the packager? >> > > about what? > About making this transparent to us. I actually suggested a way for all parties involved to be happy but for some reason you're ignoring it. Get this integrated into shadow-utils, otherwise its a hack specific to fedora. This isn't that hard, if this was a patch for useradd all of our complaints go away because it would just work then. I've even CC'd him on it so you don't have to, your welcome. -Mike From Axel.Thimm at ATrpms.net Thu Mar 8 15:53:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 16:53:44 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87odn3aj4t.fsf@fc5.bigo.ensc.de> References: <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> Message-ID: <20070308155344.GC31094@neu.nirvana> On Thu, Mar 08, 2007 at 03:45:54PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> http://fedoraproject.org/wiki/PackageUserRegistry > > > > That is exactly the issue with this approach: These uid/guid have been > > silently reserved. > > What do you expect here else? I do not see a problem with this when > consecutive uids are used. Most systems will have a range of perhaps > 500-1000 free uids which can be used for system accounts. This problem can't be solved on a *per site* basis, by asking the admin to reserve some space. How many admins are aware that there is such a mechanism at all? If at all then probably long after the first such packages have been installed by the fallback mechanism which doesn't really buy them much, since by then all machines will be de-synced in the uid/gid space anyway due to different ordering of the package installs. > > # smart install fedora-usermgmt > > # /usr/sbin/fedora-useradd 42 delme > > # id delme > > uid=5214(delme) gid=5214(delme) groups=5214(delme) > > > > That is in the middle of my user accounts! > > fedora-usermgmt does not protect against broken rpm %scriptlets... (ok; > when there is really need to test for missing '-r', some sanity checks > can be added...). > > | # useradd delme > > will cause exactly the same brokeness. You probably wanted to do > > | # fedora-useradd 42 -r delme I was just following the README which comes with the package ... > | fedora-useradd 42 -d /home/joe joe > > will create the user 'joe' having '/home/joe' as homedirectory. The > number '42' specifies an UID which is added to a configured, > system-wide base. By default, this base is '300' so that 'joe' will > have the uid 342. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 8 16:00:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 17:00:03 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173365309.4114.2.camel@localhost.localdomain> References: <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <1173212926.4189.1.camel@rousalka.dyndns.org> <20070306203406.GA30666@jadzia.bu.edu> <1173365309.4114.2.camel@localhost.localdomain> Message-ID: <20070308160003.GD31094@neu.nirvana> On Thu, Mar 08, 2007 at 09:48:29AM -0500, Simo Sorce wrote: > On Tue, 2007-03-06 at 15:34 -0500, Matthew Miller wrote: > > On Tue, Mar 06, 2007 at 09:28:46PM +0100, Nicolas Mailhot wrote: > > > > It only > > > > solves a few rare use cases and it's causing real problems. > > > If you call "rare use cases" every server that didn't snatch a sub-100 > > > uid while there where some room left > > > > To be clear, I'm only in favor of getting rid of it if some other way of > > rationally assigning fixed user ids is phased in. > > > Sorry to jump in in the middle of the discussion, but I really don't get > why you should have fixed uids. > Sure 1-100 is a too tiny space, Fedora should probably begin to reserve > 1-1000 or maybe 1-10000 for "system/packages" uids. > You can't fix the size problem switching from dynamic to fixed uids so I > don't see the point. FWIW we do have reserved space of up to 499. It's just that we call the first 100 fixed and the rest is randomly assigned (in a sequential bottom-to-top order). Note that there is an ancient discussion/bugzilla about having useradd -r assing from top to bottom. That would be a first step in allowing to lift the crossover line from fixed to non-fixed system accounts from say 100 to 150 or 200 after some transition time (counted in years probably). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190523#c4: | And if /usr/share/doc/setup-*/uidgids reserves a new slot in the | future it is very likely that useradd -r will already have a | dynamical user from another package sitting on it. E.g. the setup is | not future-proof. | | So in order to not let this conflict happen neither with outsynced | packages vs /usr/share/doc/setup-*/uidgids or any futrure new static | uids/gids it makes sense to have useradd -r reserve dynamic | udis/gids from the top of the available range. We do have ~400 | uids/gids reserved for dynamical assignment and starting at 100 is | asking for trouble now that the first 100 static id have been | assigned. Alternatively you could raise the starting uid/gid bar | from 100 to 150 or 200, but starting at the top and eating through | to the bottom is better IMHO. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 16:15:40 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 17:15:40 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070308155344.GC31094@neu.nirvana> (Axel Thimm's message of "Thu, 8 Mar 2007 16:53:44 +0100") References: <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <20070308155344.GC31094@neu.nirvana> Message-ID: <87bqj3aez7.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> >> http://fedoraproject.org/wiki/PackageUserRegistry >> > >> > That is exactly the issue with this approach: These uid/guid have been >> > silently reserved. >> >> What do you expect here else? I do not see a problem with this when >> consecutive uids are used. Most systems will have a range of perhaps >> 500-1000 free uids which can be used for system accounts. > > This problem can't be solved on a *per site* basis, by asking the > admin to reserve some space. It must be solved on a *per site* basis because the generally reserved space for fixed uids is too small (0-100). > How many admins are aware that there is such a mechanism at all? ok; there is a documentation and marketing problem... :( > If at all then probably long after the first such packages have been > installed by the fallback mechanism which doesn't really buy them > much, since by then all machines will be de-synced in the uid/gid > space anyway due to different ordering of the package installs. I solved the problem for *me* in a way which can be useful for others too and does not have technical drawbacks. >> > # smart install fedora-usermgmt >> > # /usr/sbin/fedora-useradd 42 delme >> > # id delme >> > uid=5214(delme) gid=5214(delme) groups=5214(delme) >> > >> > That is in the middle of my user accounts! > ... > I was just following the README which comes with the package ... Ooops, sorry. You just found a bug in the documentation. Thx for the report. In the meantime, please see http://fedoraproject.org/wiki/PackageUserCreation Enrico From coldwell at redhat.com Thu Mar 8 17:02:52 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 12:02:52 -0500 (EST) Subject: emacs and /etc/alternatives Message-ID: Currently, there are two versions of GNU emacs that can be installed: emacs and emacs-nox. The latter runs in a terminal emulator, the former uses X windows. I'm cleaning up the emacs spec file to meet the Fedora review requirements, and I think the right thing to do would be to have /usr/bin/emacs-22.0.95 /usr/bin/emacs-22.0.95-nox /usr/bin/emacs -> /etc/alternatives/emacs /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95[-nox] In other words, let the /etc/alternatives symlink select which of the two versions runs by default. Is this the right thing to do? If so, should the emacs-nox package have a "Conflicts: emacs" and vice-versa? Your help is appreciated. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 17:20:53 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 18:20:53 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45F03140.2070705@redhat.com> (Mike McGrath's message of "Thu, 08 Mar 2007 09:52:32 -0600") References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> <87fy8fahkm.fsf@fc5.bigo.ensc.de> <45F03140.2070705@redhat.com> Message-ID: <877itrabyi.fsf@fc5.bigo.ensc.de> Mike McGrath writes: >> Please, stop the FUD about problems without naming them! >> > Please see the archives of this thread, not just my comments but > others as well. I found exactly one problem report in this thread. This one is caused by buggy documentation. > Ignoring the shortcomings of fedora-usermgmt won't make it go away. > > 1) Doesn't work in any other distro other than fedora fedora-usermgmt operates at the packaging-level (required only by %scripts, not at runtime). Since spec files are distribution specific, why should I spend much effort into thoughts about other distributions? And btw, why do you think that fedora-usermgmt does not work in any other distribution? At least Mandriva and RHEL5 seem to provide the required environment. > 2) Only solves a small problem for a few packages since not all > packages use it chicken-egg problem > 3) Its proprietary. ... like ... anaconda? > 4) Very few people use it chicken-egg problem > 5) Its been controversial ever since its inception (otherwise it'd be > mandatory by now) vim vs. emacs are controversial too... I do not see a problem there > 6) Most sysadmins solve this problem on their own using well defined, > tested tools most things can be solved in multiple ways... I do not see a problem there > 7) Its author doesn't seem to want to send it upstream to shadow-utils > for reasons unknown There was no constructive criticism which showed technical problems or ways how to enhance/generalize fedora-usermgmt. One goal of fedora-usermgmt (support for creating users in LDAP instead of /etc/shadow) does not seem solvable by shadow-utils patches either. > 8) It hasn't gained any other foothold besides fedora ... like ... anaconda? > 9) Its use isn't easy. Just in the last two days this thread and the > EPEL thread have found people using it incorrectly or having it create > UID's in an unpredictable fashion, and these are smart people. yes; there is a bug in the documentation. This can/will be solved. In the meantime, use http://fedoraproject.org/wiki/PackageUserCreation >>> Have you contacted the packager? >> >> about what? >> > About making this transparent to us. I actually suggested a way for > all parties involved to be happy but for some reason you're ignoring > it. I just do not have enough time to write patches (without a good reason) which are replacing a working and eixsting solution. I am wasting enough time in this and previous threads. But ok... I will take a look at shadow-utils and see what there can be done... Enrico From skvidal at linux.duke.edu Thu Mar 8 17:24:39 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 08 Mar 2007 12:24:39 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <877itrabyi.fsf@fc5.bigo.ensc.de> References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> <87fy8fahkm.fsf@fc5.bigo.ensc.de> <45F03140.2070705@redhat.com> <877itrabyi.fsf@fc5.bigo.ensc.de> Message-ID: <1173374679.20206.91.camel@cutter> On Thu, 2007-03-08 at 18:20 +0100, Enrico Scholz wrote: > > > 3) Its proprietary. > > ... like ... anaconda? anaconda is used in: fedora rhel centos rpath linux the short-lived distro that installed debian via anaconda that I can't remember its name. oracle linux -sv From jdennis at redhat.com Thu Mar 8 17:27:44 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Mar 2007 12:27:44 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: Message-ID: <1173374864.1641.312.camel@finch.boston.redhat.com> On Thu, 2007-03-08 at 12:02 -0500, Chip Coldwell wrote: > Currently, there are two versions of GNU emacs that can be installed: > emacs and emacs-nox. The latter runs in a terminal emulator, the > former uses X windows. I'm cleaning up the emacs spec file to meet > the Fedora review requirements, and I think the right thing to do > would be to have > > /usr/bin/emacs-22.0.95 > /usr/bin/emacs-22.0.95-nox > /usr/bin/emacs -> /etc/alternatives/emacs > /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95[-nox] > > In other words, let the /etc/alternatives symlink select which of the > two versions runs by default. > > Is this the right thing to do? > If so, should the emacs-nox package have a "Conflicts: emacs" and > vice-versa? My first question is why we have both an X capable and non-X capable version. The X capable version can run in a terminal emulator just fine with the -nw (no window) option. If DISPLAY is not set it defaults to using -nw, the user is never aware. The only reason I can think of for emacs-nox is linkage bloat and pulling in X dependencies during install (see below) I'm not a big fan of "alternatives", most users don't know about it, it's a bit arcane, and if you're savvy enough to use alternatives you can probably handle invoking emacs with -nw in those instances where DISPLAY is set. Alternatives is not buying much other than a lot of complications. It also seems to me the nox package exists for a very small subset of installations (those without any GUI, i.e. servers). In that case the installer should have enough smarts to install the nox version, in all other cases just install the version of emacs which has the capacity to run in other mode. Emacs will interrogate the environment when it's invoked and in 99% of the cases it will just do the right thing, for the other 1% the command line option exists. -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From mclasen at redhat.com Thu Mar 8 17:35:44 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 08 Mar 2007 12:35:44 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: Message-ID: <1173375345.3432.1.camel@localhost.localdomain> On Thu, 2007-03-08 at 12:02 -0500, Chip Coldwell wrote: > Currently, there are two versions of GNU emacs that can be installed: > emacs and emacs-nox. The latter runs in a terminal emulator, the > former uses X windows. I'm cleaning up the emacs spec file to meet > the Fedora review requirements, and I think the right thing to do > would be to have > > /usr/bin/emacs-22.0.95 > /usr/bin/emacs-22.0.95-nox > /usr/bin/emacs -> /etc/alternatives/emacs > /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95[-nox] > > In other words, let the /etc/alternatives symlink select which of the > two versions runs by default. > > Is this the right thing to do? > If so, should the emacs-nox package have a "Conflicts: emacs" and > vice-versa? > If the two packages conflict, they cannot be installed in parallel, and thus you don't need the alternatives mechanism to pick one... But thats probably the best solution: just let the two packages conflict. From jkeating at redhat.com Thu Mar 8 17:59:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 12:59:58 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173375345.3432.1.camel@localhost.localdomain> References: <1173375345.3432.1.camel@localhost.localdomain> Message-ID: <200703081259.58892.jkeating@redhat.com> On Thursday 08 March 2007 12:35:44 Matthias Clasen wrote: > If the two packages conflict, they cannot be installed in parallel, and > thus you don't need the alternatives mechanism to pick one... Or simply name the binary of one emacs-nox and the other emacs. If nothing else conflicts that is. > But thats probably the best solution: just let the two packages > conflict. Sorry no, we don't want any conflicts if at all possible in the package collection. They are ugly and present the user with very confusing and hard to deal with error screens. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Thu Mar 8 18:01:16 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Mar 2007 18:01:16 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703081259.58892.jkeating@redhat.com> References: <1173375345.3432.1.camel@localhost.localdomain> <200703081259.58892.jkeating@redhat.com> Message-ID: <17904.20332.603536.636088@zebedee.pink> Jesse Keating writes: > On Thursday 08 March 2007 12:35:44 Matthias Clasen wrote: > > If the two packages conflict, they cannot be installed in parallel, and > > thus you don't need the alternatives mechanism to pick one... > > Or simply name the binary of one emacs-nox and the other emacs. If nothing > else conflicts that is. Mmm, but that surely means that if you type "emacs foo.c" it'll just say "command not found". Andrew. From jkeating at redhat.com Thu Mar 8 18:32:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 13:32:23 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17904.20332.603536.636088@zebedee.pink> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> Message-ID: <200703081332.26695.jkeating@redhat.com> On Thursday 08 March 2007 13:01:16 Andrew Haley wrote: > Mmm, but that surely means that if you type "emacs foo.c" it'll just > say "command not found". Which leads us back to the other question, why can't there just be one, that defaults to x if you have x, but alternatively does --nox as a cli option. Package 'emacs' provides just the text method, package 'emacs-x' allows for gui or some such without replacing /usr/bin/emacs. Just thinking out loud here. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Thu Mar 8 18:32:33 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 13:32:33 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <1173374864.1641.312.camel@finch.boston.redhat.com> References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: On Thu, 8 Mar 2007, John Dennis wrote: > > My first question is why we have both an X capable and non-X capable > version. Well, you answered your own question: emacs-nox exists for installations that don't include X, such as servers. > I'm not a big fan of "alternatives", most users don't know about it, > it's a bit arcane, and if you're savvy enough to use alternatives you > can probably handle invoking emacs with -nw in those instances where > DISPLAY is set. Alternatives is not buying much other than a lot of > complications. The "alternatives" stuff would by handled by the rpm %post script, so users wouldn't have to know about it. Whichever of the two packages you installed last becomes the default (assuming they don't conflict as Jesse requested). That seems reasonable to me, but I'm interested in learning what the standard practice for Fedora is. > It also seems to me the nox package exists for a very small subset of > installations (those without any GUI, i.e. servers). Servers may be a small subset of Fedora installs, but they are the majority of RHEL installs. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From ianburrell at gmail.com Thu Mar 8 18:33:17 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 8 Mar 2007 10:33:17 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <17904.20332.603536.636088@zebedee.pink> References: <1173375345.3432.1.camel@localhost.localdomain> <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> Message-ID: On 3/8/07, Andrew Haley wrote: > Jesse Keating writes: > > > > Or simply name the binary of one emacs-nox and the other emacs. If nothing > > else conflicts that is. > > Mmm, but that surely means that if you type "emacs foo.c" it'll just > say "command not found". > Which is why /usr/bin/emacs is currently a shell script that chooses between emacs-x and emacs-nox. The alternatives system is the standard way of choosing between two different versions of a command and might work beter for this. - Ian From aph at redhat.com Thu Mar 8 18:34:07 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Mar 2007 18:34:07 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703081332.26695.jkeating@redhat.com> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> Message-ID: <17904.22303.67243.405364@zebedee.pink> Jesse Keating writes: > On Thursday 08 March 2007 13:01:16 Andrew Haley wrote: > > Mmm, but that surely means that if you type "emacs foo.c" it'll just > > say "command not found". > > Which leads us back to the other question, why can't there just be one, that > defaults to x if you have x, but alternatively does --nox as a cli option. "emacs -nw" does that. Andrew. From coldwell at redhat.com Thu Mar 8 18:35:28 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 13:35:28 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <200703081332.26695.jkeating@redhat.com> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Jesse Keating wrote: > On Thursday 08 March 2007 13:01:16 Andrew Haley wrote: > > Mmm, but that surely means that if you type "emacs foo.c" it'll just > > say "command not found". > > Which leads us back to the other question, why can't there just be one, that > defaults to x if you have x, but alternatively does --nox as a cli option. > Package 'emacs' provides just the text method, package 'emacs-x' allows for > gui or some such without replacing /usr/bin/emacs. Just thinking out loud > here. The "--nox" cli option already exists as "-nw". But that's not the problem. The problem is that emacs-22 is now linked to the entire GNOME infrastructure, so if you install the GUI emacs, you suck in a lot of stuff. So if your intention is to run a headless server, you prefer emacs-nox. But in both cases, you expect to be able to run "emacs foo.c" from the bash prompt and it will DTRT. So /usr/bin/emacs *must* be either a symlink or a wrapper script (currently, it's a symlink to a wrapper script). Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From ianburrell at gmail.com Thu Mar 8 18:36:22 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 8 Mar 2007 10:36:22 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: On 3/8/07, Chip Coldwell wrote: > > I'm not a big fan of "alternatives", most users don't know about it, > > it's a bit arcane, and if you're savvy enough to use alternatives you > > can probably handle invoking emacs with -nw in those instances where > > DISPLAY is set. Alternatives is not buying much other than a lot of > > complications. > > The "alternatives" stuff would by handled by the rpm %post script, so > users wouldn't have to know about it. Whichever of the two packages > you installed last becomes the default (assuming they don't conflict > as Jesse requested). That seems reasonable to me, but I'm interested > in learning what the standard practice for Fedora is. > I thought alternatives had a priority mechanism where the highest priority link is used. emacs-x could be made higher priority than emacs-nox and would be used if it is installed. - Ian From coldwell at redhat.com Thu Mar 8 18:40:23 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 13:40:23 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Chip Coldwell wrote: > > But in both cases, you expect to be able to run "emacs foo.c" from the > bash prompt and it will DTRT. So /usr/bin/emacs *must* be either a > symlink or a wrapper script (currently, it's a symlink to a wrapper > script). Let me clarify this -- /usr/bin/emacs must be either a symlink or a wrapper script unless the emacs and emacs-nox packages conflict. Given that, it seems to me like /etc/alternatives is the preferred solution -- at least it's a standard way to set up a symlink. It is definitely the right thing to do on Debian systems. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Thu Mar 8 18:43:26 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 13:43:26 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: On Thu, 8 Mar 2007, Ian Burrell wrote: > > I thought alternatives had a priority mechanism where the highest > priority link is used. emacs-x could be made higher priority than > emacs-nox and would be used if it is installed. You're right. So that's an argument in favor of using the /etc/alternatives stuff. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mattdm at mattdm.org Thu Mar 8 18:53:23 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 13:53:23 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> Message-ID: <20070308185323.GA13742@jadzia.bu.edu> On Thu, Mar 08, 2007 at 01:40:23PM -0500, Chip Coldwell wrote: > Let me clarify this -- /usr/bin/emacs must be either a symlink or a > wrapper script unless the emacs and emacs-nox packages conflict. > Given that, it seems to me like /etc/alternatives is the preferred > solution -- at least it's a standard way to set up a symlink. It is > definitely the right thing to do on Debian systems. I don't think it's preferred at all, and particularly not in this case. This isn't a matter of chosing between two equivalent options -- it's just trying to address the linked-with-GNOME thing. So it seems like the right thing to do is use a simple script that runs the big version if it's installed, and falls back to the svelte one otherwise. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Mar 8 18:54:09 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 13:54:09 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: <20070308185409.GB13742@jadzia.bu.edu> On Thu, Mar 08, 2007 at 01:43:26PM -0500, Chip Coldwell wrote: > > I thought alternatives had a priority mechanism where the highest > > priority link is used. emacs-x could be made higher priority than > > emacs-nox and would be used if it is installed. > You're right. So that's an argument in favor of using the > /etc/alternatives stuff. What's the advantage, though? Increased complexity in and of itself is not a goal now, is it? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Thu Mar 8 19:01:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Mar 2007 13:01:32 -0600 Subject: emacs and /etc/alternatives In-Reply-To: <20070308185323.GA13742@jadzia.bu.edu> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <20070308185323.GA13742@jadzia.bu.edu> Message-ID: <45F05D8C.6020008@math.unl.edu> Matthew Miller wrote: > On Thu, Mar 08, 2007 at 01:40:23PM -0500, Chip Coldwell wrote: >> Let me clarify this -- /usr/bin/emacs must be either a symlink or a >> wrapper script unless the emacs and emacs-nox packages conflict. >> Given that, it seems to me like /etc/alternatives is the preferred >> solution -- at least it's a standard way to set up a symlink. It is >> definitely the right thing to do on Debian systems. > > I don't think it's preferred at all, and particularly not in this case. This > isn't a matter of chosing between two equivalent options -- it's just trying > to address the linked-with-GNOME thing. So it seems like the right thing to > do is use a simple script that runs the big version if it's installed, and > falls back to the svelte one otherwise. True, that's exactly what alternatives would accomplish too, just in a more complicated way. -- Rex From jdennis at redhat.com Thu Mar 8 19:16:25 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Mar 2007 14:16:25 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: <1173381385.1641.349.camel@finch.boston.redhat.com> On Thu, 2007-03-08 at 13:32 -0500, Chip Coldwell wrote: > The "alternatives" stuff would by handled by the rpm %post script, so > users wouldn't have to know about it. Whichever of the two packages > you installed last becomes the default (assuming they don't conflict > as Jesse requested). That seems reasonable to me, but I'm interested > in learning what the standard practice for Fedora is. Hmm... which program is run when a user types a command being tied to (arbitrary) package installation order does not seem reasonable to me because of the high astonishment factor. I personally dislike hidden obscure changes to my system. Things suddenly work vastly differently because something occurred on my system I might not have any awareness of or ability to correlate to a specific change. I can easily imagine a scenario where someone does an install, they may not be aware it pulled in one of the emacs packages, or they might have done the install a few days earlier, or someone else might have done the install and now for no apparent reason from their perspective emacs stops working. Arghh!!! They might spend considerable time tracking it down and discover it's all due to convoluted symbolic link munging courtesy of alternatives. They probably never heard of alternatives, or even if they know of it would not consider this as the first place to look when their editor mysteriously stops working. Silently breaking previously working functionality is not a good design choice IMHO. I think the right behavior is if emacs-nox is installed on a system without X then the command 'emacs' invokes emacs-nox. If emacs with X support is installed the command 'emacs' invokes the X capable version (makes sense because that version of emacs can operate in either mode, it is obviously the preferred version). The alternatives system could be used to implement this because it does address the issue of RPM conflicts, but it would never be "last install wins", rather it would be "most capable wins" in %post. This has the least astonishment factor, satisfies the majority of use cases, and still allows switching if an advanced user is savvy enough to want to do that (but there really wouldn't be any reason to use alternative switching, the use of alternatives in this case is almost entirely to avoid RPM conflicts, not select vastly different implementations of a command e.g. sendmail vs. postfix, etc.) -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From Axel.Thimm at ATrpms.net Thu Mar 8 19:20:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 20:20:55 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87bqj3aez7.fsf@fc5.bigo.ensc.de> References: <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <20070308155344.GC31094@neu.nirvana> <87bqj3aez7.fsf@fc5.bigo.ensc.de> Message-ID: <20070308192055.GD10906@neu.nirvana> On Thu, Mar 08, 2007 at 05:15:40PM +0100, Enrico Scholz wrote: > It must be solved on a *per site* basis because the generally reserved > space for fixed uids is too small (0-100). so the purpose of this tool is to aid packages that *require* a fixed uid/gid. But then the package by default acts like simple useradd and 99.99% of installs just reflect that. Isn't this a contradiction? Either the packages do not really need a fixed uid/gid or the current deployment defaulting to useradd is bogus. > I solved the problem for *me* in a way which can be useful for others > too and does not have technical drawbacks. Only as long as no one configures the system and it defaults to plain useradd. The same would apply to bash being redirected to zsh iff a certain env var were set. Wouldn't break anything in the default config, but would not be an argument to keep this behaviour. > >> > # smart install fedora-usermgmt > >> > # /usr/sbin/fedora-useradd 42 delme > >> > # id delme > >> > uid=5214(delme) gid=5214(delme) groups=5214(delme) > >> > > >> > That is in the middle of my user accounts! > > ... > > I was just following the README which comes with the package ... > > Ooops, sorry. You just found a bug in the documentation. Thx for the > report. In the meantime, please see Well, the fact that the core operation of this (old) package was documented wrongly should give some hint on how many users/packagers/admins have been reading it. I think fedora-usermgmt tries to solve a problem that in today's Fedora either does not exist or is not solvable by this method. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 8 19:24:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 20:24:56 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <1173374864.1641.312.camel@finch.boston.redhat.com> References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: <20070308192456.GE10906@neu.nirvana> On Thu, Mar 08, 2007 at 12:27:44PM -0500, John Dennis wrote: > On Thu, 2007-03-08 at 12:02 -0500, Chip Coldwell wrote: > > Currently, there are two versions of GNU emacs that can be installed: > > emacs and emacs-nox. The latter runs in a terminal emulator, the > > former uses X windows. I'm cleaning up the emacs spec file to meet > > the Fedora review requirements, and I think the right thing to do > > would be to have > > > > /usr/bin/emacs-22.0.95 > > /usr/bin/emacs-22.0.95-nox > > /usr/bin/emacs -> /etc/alternatives/emacs > > /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95[-nox] > > > > In other words, let the /etc/alternatives symlink select which of the > > two versions runs by default. > > > > Is this the right thing to do? > > If so, should the emacs-nox package have a "Conflicts: emacs" and > > vice-versa? > > My first question is why we have both an X capable and non-X capable > version. Good question, I guess emacs-nox has the benefit of not pulling in half of the X11 libs and is therefore well suited for an X-less minimal system. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Thu Mar 8 19:30:42 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 14:30:42 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <20070308185323.GA13742@jadzia.bu.edu> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <20070308185323.GA13742@jadzia.bu.edu> Message-ID: On Thu, 8 Mar 2007, Matthew Miller wrote: > On Thu, Mar 08, 2007 at 01:40:23PM -0500, Chip Coldwell wrote: > > Let me clarify this -- /usr/bin/emacs must be either a symlink or a > > wrapper script unless the emacs and emacs-nox packages conflict. > > Given that, it seems to me like /etc/alternatives is the preferred > > solution -- at least it's a standard way to set up a symlink. It is > > definitely the right thing to do on Debian systems. > > I don't think it's preferred at all, and particularly not in this case. This > isn't a matter of chosing between two equivalent options -- it's just trying > to address the linked-with-GNOME thing. So it seems like the right thing to > do is use a simple script that runs the big version if it's installed, and > falls back to the svelte one otherwise. If all we want to do is provide users with a version of emacs that doesn't require the entire GNOME+X infrastructure, then I think two conflicting packages is the simplest thing to do. I see a wrapper script as being functionally equivalent to a symlink -- it chooses the GUI emacs unless it's not installed. The only difference is that it makes that decision at the time /usr/bin/emacs is invoked, whereas the symlink is created when the package is installed. So should I infer that Fedora has an ambivalent attitude toward the /etc/alternatives mechanism? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mattdm at mattdm.org Thu Mar 8 19:36:55 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 14:36:55 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <20070308185323.GA13742@jadzia.bu.edu> Message-ID: <20070308193655.GA19544@jadzia.bu.edu> On Thu, Mar 08, 2007 at 02:30:42PM -0500, Chip Coldwell wrote: > So should I infer that Fedora has an ambivalent attitude toward the > /etc/alternatives mechanism? I can't speak for everyone, but in general, yes -- it's a necessary evil for complex compatibile systems like postfix/sendmail/exim, but shouldn't be used as a general hammer when there's no good reason. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From coldwell at redhat.com Thu Mar 8 19:44:21 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 14:44:21 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <20070308193655.GA19544@jadzia.bu.edu> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <20070308185323.GA13742@jadzia.bu.edu> <20070308193655.GA19544@jadzia.bu.edu> Message-ID: On Thu, 8 Mar 2007, Matthew Miller wrote: > On Thu, Mar 08, 2007 at 02:30:42PM -0500, Chip Coldwell wrote: > > So should I infer that Fedora has an ambivalent attitude toward the > > /etc/alternatives mechanism? > > I can't speak for everyone, but in general, yes -- it's a necessary evil for > complex compatibile systems like postfix/sendmail/exim, but shouldn't be > used as a general hammer when there's no good reason. In that case, I guess my preference is to have the two packages conflict with each other. As has already been mentioned, if you install the GUI emacs, you can still run it in a terminal by specifying the "-nw" switch. The only reason to install emacs-nox is to avoid sucking in all the dependencies, so you should never install it if you already have the GUI emacs. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From a.badger at gmail.com Thu Mar 8 20:00:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Mar 2007 12:00:05 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> Message-ID: <1173384005.3329.106.camel@localhost.localdomain> On Thu, 2007-03-08 at 13:40 -0500, Chip Coldwell wrote: > On Thu, 8 Mar 2007, Chip Coldwell wrote: > > > > But in both cases, you expect to be able to run "emacs foo.c" from the > > bash prompt and it will DTRT. So /usr/bin/emacs *must* be either a > > symlink or a wrapper script (currently, it's a symlink to a wrapper > > script). > > Let me clarify this -- /usr/bin/emacs must be either a symlink or a > wrapper script unless the emacs and emacs-nox packages conflict. > > Given that, it seems to me like /etc/alternatives is the preferred > solution -- at least it's a standard way to set up a symlink. It is > definitely the right thing to do on Debian systems. > No. alternatives is definitely suitable for specific implementations of servers which are drop in replacements for other specific implementations. With anything else, you have to ask these questions: * Does it support the same command line options? * Does it make sense for the system administrator to set this or is it really an end-user preference? Having alternatives manage a generic /usr/bin/editor that can be switched between /usr/bin/vim and /usr/bin/emacs (and /bin/ed for that matter) is clearly a violation of both these guidelines so its easy to see why they are unsupported. emacs-x vs emacs-nox does not (apparently) violate the first guideline so one might think that alternatives is an okay place for it. However, it does violate the second guideline. If both versions of emacs are installed, it's really up to the end user to decide which version should be "emacs". Perhaps they always run in a terminal and feel that starting the X version is bloat. Perhaps they're a KDE user on a multiuser system. Perhaps they have an automated emacs script that they run as a cron job to grab their mail, check for rss updates, and then popup a notification via dbus before exiting. None of these are unworkable with /usr/bin/emacs defined via alternatives (you can use aliases, explicitly calling emacs-nox, etc) but none of them are really speaking to alternatives' strong points. IMHO, a /usr/bin/emacs script which does autodetection and looks in an ENV variable for a user defined preference is a cleaner interface for the user. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Mar 8 20:02:09 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 15:02:09 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173384005.3329.106.camel@localhost.localdomain> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> Message-ID: <20070308200209.GA22082@jadzia.bu.edu> On Thu, Mar 08, 2007 at 12:00:05PM -0800, Toshio Kuratomi wrote: > alternatives (you can use aliases, explicitly calling emacs-nox, etc) > but none of them are really speaking to alternatives' strong points. > IMHO, a /usr/bin/emacs script which does autodetection and looks in an > ENV variable for a user defined preference is a cleaner interface for > the user. You don't even need the environment variable, as the user can set an alias if need be. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 20:05:21 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 21:05:21 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070308192055.GD10906@neu.nirvana> (Axel Thimm's message of "Thu, 8 Mar 2007 20:20:55 +0100") References: <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <20070308155344.GC31094@neu.nirvana> <87bqj3aez7.fsf@fc5.bigo.ensc.de> <20070308192055.GD10906@neu.nirvana> Message-ID: <87mz2nmrge.fsf@kosh.bigo.ensc.de> Axel Thimm writes: > Well, the fact that the core operation of this (old) package was documented > wrongly should give some hint on how many users/packagers/admins have been > reading it. I do not have numbers here, but I think that most users of fedora-usermgmt are reading the documentation from the wiki. Especially, because it is linked at the PackageUserRegistry page and contains ready-to-use templates. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ajackson at redhat.com Thu Mar 8 19:58:45 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 08 Mar 2007 14:58:45 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070308192456.GE10906@neu.nirvana> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <20070308192456.GE10906@neu.nirvana> Message-ID: <1173383925.20896.24.camel@localhost.localdomain> On Thu, 2007-03-08 at 20:24 +0100, Axel Thimm wrote: > On Thu, Mar 08, 2007 at 12:27:44PM -0500, John Dennis wrote: > > On Thu, 2007-03-08 at 12:02 -0500, Chip Coldwell wrote: > > > Currently, there are two versions of GNU emacs that can be installed: > > > emacs and emacs-nox. The latter runs in a terminal emulator, the > > > former uses X windows. I'm cleaning up the emacs spec file to meet > > > the Fedora review requirements, and I think the right thing to do > > > would be to have > > > > > > /usr/bin/emacs-22.0.95 > > > /usr/bin/emacs-22.0.95-nox > > > /usr/bin/emacs -> /etc/alternatives/emacs > > > /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95[-nox] > > > > > > In other words, let the /etc/alternatives symlink select which of the > > > two versions runs by default. > > > > > > Is this the right thing to do? > > > If so, should the emacs-nox package have a "Conflicts: emacs" and > > > vice-versa? > > > > My first question is why we have both an X capable and non-X capable > > version. > > Good question, I guess emacs-nox has the benefit of not pulling in > half of the X11 libs and is therefore well suited for an X-less > minimal system. Er, not as such. The total disk footprint of _every_ base X library is about 6M, which includes several that emacs does not depend on. emacs-nox weighs in at about 5M, but plain emacs is closer to 22M. So although emacs-nox is smaller than emacs, you drop more from the emacs package itself than from the dependency chain. I would posit, however, that machines where the extra ~20M of disk reclaimed is meaningful have larger problems than whether to install the X libs. - ajax From coldwell at redhat.com Thu Mar 8 20:25:06 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 15:25:06 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <1173383925.20896.24.camel@localhost.localdomain> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <20070308192456.GE10906@neu.nirvana> <1173383925.20896.24.camel@localhost.localdomain> Message-ID: On Thu, 8 Mar 2007, Adam Jackson wrote: > > I would posit, however, that machines where the extra ~20M of disk > reclaimed is meaningful have larger problems than whether to install the > X libs. This is not just X; emacs-22 links to GNOME also. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jkeating at redhat.com Thu Mar 8 20:28:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 15:28:17 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081332.26695.jkeating@redhat.com> Message-ID: <200703081528.17627.jkeating@redhat.com> On Thursday 08 March 2007 13:35:28 Chip Coldwell wrote: > The "--nox" cli option already exists as "-nw". ?But that's not the > problem. ?The problem is that emacs-22 is now linked to the entire > GNOME infrastructure, so if you install the GUI emacs, you suck in a > lot of stuff. ?So if your intention is to run a headless server, you > prefer emacs-nox. obviously you need an emacs-gnome subpackage that introduces the gnome capabilities, while the emacs main package provides you with emacs, without gnome. This may take significant upstream work, but so be it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Mar 8 20:30:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 15:30:19 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <20070308193655.GA19544@jadzia.bu.edu> Message-ID: <200703081530.19535.jkeating@redhat.com> On Thursday 08 March 2007 14:44:21 Chip Coldwell wrote: > In that case, I guess my preference is to have the two packages > conflict with each other. ?As has already been mentioned, if you > install the GUI emacs, you can still run it in a terminal by > specifying the "-nw" switch. ?The only reason to install emacs-nox is > to avoid sucking in all the dependencies, so you should never install > it if you already have the GUI emacs. Except that we don't allow for conflicting packages in Fedora. Extremely horrible user experience if they happen to select both or with a glob to have a ugly "CONFLICT" popup. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mitr at redhat.com Thu Mar 8 20:31:41 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Thu, 08 Mar 2007 21:31:41 +0100 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> <20070308192456.GE10906@neu.nirvana> <1173383925.20896.24.camel@localhost.localdomain> Message-ID: <45F072AD.2020001@redhat.com> Chip Coldwell napsal(a): > This is not just X; emacs-22 links to GNOME also. Does it? I have your FC6 package installed, and it seems to require only the GTK+ stack, nothing GNOME-specific. Mirek From mattdm at mattdm.org Thu Mar 8 20:36:25 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 15:36:25 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <200703081530.19535.jkeating@redhat.com> References: <20070308193655.GA19544@jadzia.bu.edu> <200703081530.19535.jkeating@redhat.com> Message-ID: <20070308203625.GA25694@jadzia.bu.edu> On Thu, Mar 08, 2007 at 03:30:19PM -0500, Jesse Keating wrote: > Except that we don't allow for conflicting packages in Fedora. Extremely > horrible user experience if they happen to select both or with a glob to have > a ugly "CONFLICT" popup. For example, if you decide, "hey, I want everything emacs related" and do "yum install '*emacs*'". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From coldwell at redhat.com Thu Mar 8 20:36:33 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 15:36:33 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <45F072AD.2020001@redhat.com> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <20070308192456.GE10906@neu.nirvana> <1173383925.20896.24.camel@localhost.localdomain> <45F072AD.2020001@redhat.com> Message-ID: On Thu, 8 Mar 2007, Miloslav Trmac wrote: > Chip Coldwell napsal(a): > > This is not just X; emacs-22 links to GNOME also. > Does it? I have your FC6 package installed, and it seems to require > only the GTK+ stack, nothing GNOME-specific. Sorry. Obviously, I have no idea how all the eye-candy on the desktop gets glued together, nor even what it's named. Here are the libraries that emacs with X links: linux-gate.so.1 => (0x003b6000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x06413000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x06034000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00676000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00694000) libm.so.6 => /lib/libm.so.6 (0x0060e000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x0024e000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x0020d000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00400000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00110000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x003c0000) libdl.so.2 => /lib/libdl.so.2 (0x00637000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x002df000) libpthread.so.0 => /lib/libpthread.so.0 (0x0063d000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00d93000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00d67000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x05d3d000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00daf000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00961000) libz.so.1 => /usr/lib/libz.so.1 (0x00656000) libungif.so.4 => /usr/lib/libungif.so.4 (0x00acb000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00b3e000) libXft.so.2 => /usr/lib/libXft.so.2 (0x002bf000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00b55000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00925000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x008a3000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00723000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x0311f000) libc.so.6 => /lib/libc.so.6 (0x004cf000) libgif.so.4 => /usr/lib/libgif.so.4 (0x00acf000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00282000) libXext.so.6 => /usr/lib/libXext.so.6 (0x001cb000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00d9e000) libXi.so.6 => /usr/lib/libXi.so.6 (0x0026c000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00ac5000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00276000) /lib/ld-linux.so.2 (0x004b2000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x001dd000) libexpat.so.0 => /lib/libexpat.so.0 (0x00868000) libXau.so.6 => /usr/lib/libXau.so.6 (0x0071e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00716000) vs emacs-nox: linux-gate.so.1 => (0x00189000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x0311f000) libm.so.6 => /lib/libm.so.6 (0x0060e000) libc.so.6 => /lib/libc.so.6 (0x004cf000) libdl.so.2 => /lib/libdl.so.2 (0x00637000) /lib/ld-linux.so.2 (0x004b2000) You can see what somebody might prefer the latter. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Thu Mar 8 20:43:15 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 15:43:15 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <1173384005.3329.106.camel@localhost.localdomain> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> Message-ID: On Thu, 8 Mar 2007, Toshio Kuratomi wrote: > > IMHO, a /usr/bin/emacs script which does autodetection and looks in an > ENV variable for a user defined preference is a cleaner interface for > the user. Why is a script that checks a user-defined ENV variable preferable to a user-defined shell alias? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Thu Mar 8 20:43:31 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 15:43:31 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <200703081530.19535.jkeating@redhat.com> References: <20070308193655.GA19544@jadzia.bu.edu> <200703081530.19535.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Jesse Keating wrote: > On Thursday 08 March 2007 14:44:21 Chip Coldwell wrote: > > In that case, I guess my preference is to have the two packages > > conflict with each other. ?As has already been mentioned, if you > > install the GUI emacs, you can still run it in a terminal by > > specifying the "-nw" switch. ?The only reason to install emacs-nox is > > to avoid sucking in all the dependencies, so you should never install > > it if you already have the GUI emacs. > > Except that we don't allow for conflicting packages in Fedora. Extremely > horrible user experience if they happen to select both or with a glob to have > a ugly "CONFLICT" popup. Then that brings us full circle back to the symbolic link and /etc/alternatives, because we have two packages that install /usr/bin/emacs. In that case, I think /etc/alternatives is the way to go, since at least the symlink management is automatic. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 8 20:47:00 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 08 Mar 2007 21:47:00 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45F022D7.4010203@redhat.com> (Mike McGrath's message of "Thu, 08 Mar 2007 08:51:03 -0600") References: <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <1173332867.3617.127.camel@max.booze> <20070308134636.GA30136@neu.nirvana> <87odn3aj4t.fsf@fc5.bigo.ensc.de> <45F022D7.4010203@redhat.com> Message-ID: <87irdbmpiz.fsf@kosh.bigo.ensc.de> Mike McGrath writes: > Has any progress been made on making fedora usermgmt part of the > shadow-utils? Have you contacted the packager? See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231525 This adds a '--hint' option to user/groupadd so you can use old: | fedora-useradd 42 -r joe new: | useradd --hint 42 -r joe Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Thu Mar 8 20:50:39 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 15:50:39 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <20070308193655.GA19544@jadzia.bu.edu> <200703081530.19535.jkeating@redhat.com> Message-ID: <20070308205039.GA26817@jadzia.bu.edu> On Thu, Mar 08, 2007 at 03:43:31PM -0500, Chip Coldwell wrote: > Then that brings us full circle back to the symbolic link and > /etc/alternatives, because we have two packages that install > /usr/bin/emacs. > In that case, I think /etc/alternatives is the way to go, since at > least the symlink management is automatic. Or the script. Which is *even better* than automatic. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Mar 8 21:27:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 16:27:46 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081530.19535.jkeating@redhat.com> Message-ID: <200703081627.46290.jkeating@redhat.com> On Thursday 08 March 2007 15:43:31 Chip Coldwell wrote: > Then that brings us full circle back to the symbolic link and > /etc/alternatives, because we have two packages that install > /usr/bin/emacs. > > In that case, I think /etc/alternatives is the way to go, since at > least the symlink management is automatic. Or the even more preferable packaging of emacs that allows the x/gtk functionality to be split into a subpackage and callable with an option. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Thu Mar 8 21:31:23 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 16:31:23 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <200703081627.46290.jkeating@redhat.com> References: <200703081530.19535.jkeating@redhat.com> <200703081627.46290.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Jesse Keating wrote: > > Or the even more preferable packaging of emacs that allows the x/gtk > functionality to be split into a subpackage and callable with an option. I really don't understand the difference between two packages emacs: with GTK+, etc. emacs-nox: without GTK+, etc. and two packages: emacs-gnome: with GTK+, etc. emacs: without GTK+, etc. Aside from the renaming, how is this different from the present situation? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From wtogami at redhat.com Thu Mar 8 21:45:39 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Mar 2007 16:45:39 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> Message-ID: <45F08403.3090302@redhat.com> Chip Coldwell wrote: > On Thu, 8 Mar 2007, Ian Burrell wrote: >> I thought alternatives had a priority mechanism where the highest >> priority link is used. emacs-x could be made higher priority than >> emacs-nox and would be used if it is installed. > > You're right. So that's an argument in favor of using the > /etc/alternatives stuff. > > Chip > If both are functionally similar, yet the script solution avoids changes to the filesystem *and* is much simpler, why not stick to the script solution? alternatives *only* makes sense if there are numerous other programs that provide "emacs" functionality that can be reasonably expected to be called emacs. The other variants of emacs have had other names for ages. This makes sense for sendmail/postfix/exim but not emacs. Please avoid this unnecessary complication. Warren Togami wtogami at redhat.com From notting at redhat.com Thu Mar 8 21:43:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 16:43:39 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <200703081528.17627.jkeating@redhat.com> References: <200703081332.26695.jkeating@redhat.com> <200703081528.17627.jkeating@redhat.com> Message-ID: <20070308214339.GB5337@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > obviously you need an emacs-gnome subpackage that introduces the gnome > capabilities, while the emacs main package provides you with emacs, without > gnome. This may take significant upstream work, but so be it. It's not GNOME, per se, but it uses gtk as the widget set for the menus and (IIRC) pango as the text renderer, as opposed to the obsolete Xaw widgets & core fonts. Now, what I wonder is: GUI: notting 8220 22.5 0.9 39952 14228 pts/5 S 16:39 0:00 emacs GUI with -nw: notting 8089 0.1 0.4 36112 7244 pts/4 S+ 16:35 0:00 emacs -nw -nox: notting 8042 0.1 0.3 9644 5816 pts/2 S+ 16:35 0:00 emacs-nox Some of the additional memory usage is shared, of course, but it's a neat trick that the supposedly equivalent -nw version uses four times the memory. Of course, the binary is also 4x the size, so that may make sense. FWIW, I'm of the opinion that no one should be using alternatives unless they absolutely have to, so I'd prefer the wrapper approach. Bill From mitr at redhat.com Thu Mar 8 21:52:33 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Thu, 08 Mar 2007 22:52:33 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <45F08403.3090302@redhat.com> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> Message-ID: <45F085A1.9040001@redhat.com> Warren Togami napsal(a): > If both are functionally similar, yet the script solution avoids changes > to the filesystem *and* is much simpler, why not stick to the script > solution? If you completely ignore the original purpose of alternatives and focus only on the mechanism, following a few symlinks set up by alternatives is actually both more effective and simpler than starting bash to execute the script. Mirek From jkeating at redhat.com Thu Mar 8 21:55:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 16:55:01 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081627.46290.jkeating@redhat.com> Message-ID: <200703081655.01890.jkeating@redhat.com> On Thursday 08 March 2007 16:31:23 Chip Coldwell wrote: > I really don't understand the difference between two packages > > emacs: with GTK+, etc. > emacs-nox: without GTK+, etc. > > and two packages: > > emacs-gnome: with GTK+, etc. > emacs: without GTK+, etc. > > Aside from the renaming, how is this different from the present > situation? One would hope that you can do this in such a way that you could install 'emacs' and not drag in gnome, and it would do text mode only, and then install emacs-gnome which gives emacs the ability to do gui. Perhaps emacs supplies a /usr/bin/emacs script that defaults to /usr/bin/emacs-tui, and if you try to pass it -x it will note the lack of /usr/bin/emacs-gnome and tell you no, but if you install emacs-gnome subpackage, the libraries and deps are then installed and emacs -x would launch the gui emacs. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Thu Mar 8 21:59:36 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 8 Mar 2007 16:59:36 -0500 (EST) Subject: emacs and /etc/alternatives In-Reply-To: <200703081655.01890.jkeating@redhat.com> References: <200703081627.46290.jkeating@redhat.com> <200703081655.01890.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Jesse Keating wrote: > On Thursday 08 March 2007 16:31:23 Chip Coldwell wrote: > > I really don't understand the difference between two packages > > > > emacs: with GTK+, etc. > > emacs-nox: without GTK+, etc. > > > > and two packages: > > > > emacs-gnome: with GTK+, etc. > > emacs: without GTK+, etc. > > > > Aside from the renaming, how is this different from the present > > situation? > > One would hope that you can do this in such a way that you could > install 'emacs' and not drag in gnome, and it would do text mode only, and > then install emacs-gnome which gives emacs the ability to do gui. Perhaps > emacs supplies a /usr/bin/emacs script that defaults to /usr/bin/emacs-tui, > and if you try to pass it -x it will note the lack of /usr/bin/emacs-gnome > and tell you no, but if you install emacs-gnome subpackage, the libraries and > deps are then installed and emacs -x would launch the gui emacs. What you describe reverses the default from GUI to terminal. Right now: if you install emacs it drags in gtk/gdk/atk/etc, but you can invoke it with "-nw" and it will run in a terminal. Or you can install emacs-nox which does not drag in gtk/gdk/atk/etc, and it will only run in a terminal. So is your recommendation rename emacs to emacs-gnome, rename emacs-nox to emacs, and add a "-x" command line switch to emacs (renamed from emacs-nox) whose purpose is to emit an error message? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mattdm at mattdm.org Thu Mar 8 22:04:53 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 17:04:53 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <45F085A1.9040001@redhat.com> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> Message-ID: <20070308220453.GA2305@jadzia.bu.edu> On Thu, Mar 08, 2007 at 10:52:33PM +0100, Miloslav Trmac wrote: > > If both are functionally similar, yet the script solution avoids changes > > to the filesystem *and* is much simpler, why not stick to the script > > solution? > If you completely ignore the original purpose of alternatives and focus > only on the mechanism, following a few symlinks set up by alternatives > is actually both more effective and simpler than starting bash to > execute the script. The overhead of bash vs. a symlink is negligible when we're talking about launching *emacs*. The real difference is: one is trivial and self-contained, whereas the other relies on an whole infrastructure. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From a.badger at gmail.com Thu Mar 8 22:05:42 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Mar 2007 14:05:42 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> Message-ID: <1173391542.3329.137.camel@localhost.localdomain> On Thu, 2007-03-08 at 15:43 -0500, Chip Coldwell wrote: > On Thu, 8 Mar 2007, Toshio Kuratomi wrote: > > > > IMHO, a /usr/bin/emacs script which does autodetection and looks in an > > ENV variable for a user defined preference is a cleaner interface for > > the user. > > Why is a script that checks a user-defined ENV variable preferable to > a user-defined shell alias? > Example: network shared home directories. When mounted on the server, I might have emacs-nox, on the lab computer emacs-gtk and emacs-nox, and on my workstation emacs-gtk only. If the home directory is nfs mounted how can I set the alias in this environment? Having a script that does autodetection and has a "user prefers" setting makes more sense. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From garrick at usc.edu Thu Mar 8 22:06:44 2007 From: garrick at usc.edu (Garrick Staples) Date: Thu, 8 Mar 2007 14:06:44 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> Message-ID: <20070308220644.GH2378@polop.usc.edu> On Thu, Mar 08, 2007 at 03:43:15PM -0500, Chip Coldwell alleged: > On Thu, 8 Mar 2007, Toshio Kuratomi wrote: > > > > IMHO, a /usr/bin/emacs script which does autodetection and looks in an > > ENV variable for a user defined preference is a cleaner interface for > > the user. > > Why is a script that checks a user-defined ENV variable preferable to > a user-defined shell alias? Shell aliases aren't exportable, so it only helps if the user defines an alias for the *correct* shell. Env vars export nicely down through any child processes. -- Garrick Staples, GNU/Linux HPCC SysAdmin University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Mar 8 22:09:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:09:11 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173216064.3698.1.camel@rousalka.dyndns.org> References: <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> Message-ID: <20070308220911.GE5337@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > Or bite the bullet and reserve a new fixed uid range +100 Just do it, have a registry. When we get to a situation that requires 500 separate system UIDs, we'll deal with it then. I don't want to be the "640k should be enough for everyone" guy, but I'd have to think that by the time we get to that point, we will have gone way beyond the point of diminishing returns in additional packages. Bill From notting at redhat.com Thu Mar 8 22:11:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:11:43 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87649ebdzq.fsf@fc5.bigo.ensc.de> References: <45ED7AA0.6070109@redhat.com> <87abyqbfck.fsf@fc5.bigo.ensc.de> <45ED7F9A.3050906@redhat.com> <45ED8078.6010505@math.unl.edu> <87649ebdzq.fsf@fc5.bigo.ensc.de> Message-ID: <20070308221143.GF5337@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > This rpm version does not know the '%bcond_with*' macros. Hence > > | %bcond_without fedora Good. Most new macro stuff is extraneous noise pollution that complicates spec files anyway. Bill From mattdm at mattdm.org Thu Mar 8 22:16:57 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 17:16:57 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173391542.3329.137.camel@localhost.localdomain> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> <1173391542.3329.137.camel@localhost.localdomain> Message-ID: <20070308221657.GA2680@jadzia.bu.edu> On Thu, Mar 08, 2007 at 02:05:42PM -0800, Toshio Kuratomi wrote: > > Why is a script that checks a user-defined ENV variable preferable to > > a user-defined shell alias? > Example: network shared home directories. When mounted on the server, I > might have emacs-nox, on the lab computer emacs-gtk and emacs-nox, and > on my workstation emacs-gtk only. If the home directory is nfs mounted > how can I set the alias in this environment? Having a script that does > autodetection and has a "user prefers" setting makes more sense. But it's trivial. If you always want the text version: alias emacs "emacs -nw" and if you want the GUI version when available, don't alias anything. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From a.badger at gmail.com Thu Mar 8 22:46:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Mar 2007 14:46:57 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <20070308221657.GA2680@jadzia.bu.edu> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> <1173391542.3329.137.camel@localhost.localdomain> <20070308221657.GA2680@jadzia.bu.edu> Message-ID: <1173394017.3329.154.camel@localhost.localdomain> On Thu, 2007-03-08 at 17:16 -0500, Matthew Miller wrote: > On Thu, Mar 08, 2007 at 02:05:42PM -0800, Toshio Kuratomi wrote: > > > Why is a script that checks a user-defined ENV variable preferable to > > > a user-defined shell alias? > > Example: network shared home directories. When mounted on the server, I > > might have emacs-nox, on the lab computer emacs-gtk and emacs-nox, and > > on my workstation emacs-gtk only. If the home directory is nfs mounted > > how can I set the alias in this environment? Having a script that does > > autodetection and has a "user prefers" setting makes more sense. > > > But it's trivial. If you always want the text version: > > alias emacs "emacs -nw" > > and if you want the GUI version when available, don't alias anything. > Depends on your reason for wanting the text version :-) If you just want to use it within a terminal then -nw works. If you don't want to load the gtk libraries then you have to actually use -nox. (Not as much of an issue in these days of openoffice, firefox, and evolution, I know :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Mar 8 23:16:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 18:16:16 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> Message-ID: <200703081816.23690.jkeating@redhat.com> On Thursday 08 March 2007 16:59:36 Chip Coldwell wrote: > Right now: if you install emacs it drags in gtk/gdk/atk/etc, but you > can invoke it with "-nw" and it will run in a terminal. ?Or you can > install emacs-nox which does not drag in gtk/gdk/atk/etc, and it will > only run in a terminal. > > So is your recommendation rename emacs to emacs-gnome, rename > emacs-nox to emacs, and add a "-x" command line switch to emacs > (renamed from emacs-nox) whose purpose is to emit an error message? my recommendation is to find a way to consolidate the two distinct binaries into one that can optionally load gui libraries if A) they exist and B) an option was passed to load them. Or we just throw out the non-gui emacs and only ship the one that can do both, to be damned with pulling in a gtk stack. I don't want conflicts and I don't want to involve alternatives if at all possible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Mar 8 23:27:42 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 17:27:42 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <20070308220911.GE5337@nostromo.devel.redhat.com> References: <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> Message-ID: <45F09BEE.7090909@redhat.com> Bill Nottingham wrote: > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > >> Or bite the bullet and reserve a new fixed uid range >> > > +100 > > Just do it, have a registry. When we get to a situation that requires 500 > separate system UIDs, we'll deal with it then. I don't want to be > the "640k should be enough for everyone" guy, but I'd have to think that > by the time we get to that point, we will have gone way beyond the > point of diminishing returns in additional packages. > > Bill > > Just so we do know the numbers: $ repoquery --whatrequires '/usr/sbin/useradd' --qf='%{name}' | sort | uniq | wc -l 54 $ repoquery --whatrequires 'fedora-usermgmt' --qf='%{name}' | sort | uniq | wc -l 25 Total of 79. This is actually fewer users then I thought and a larger adoption rate of fedora usermgmt then I thought. Anywho, its not 640k :-D but that's our number -Mike From mattdm at mattdm.org Fri Mar 9 00:09:19 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 19:09:19 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173394017.3329.154.camel@localhost.localdomain> References: <200703081259.58892.jkeating@redhat.com> <17904.20332.603536.636088@zebedee.pink> <200703081332.26695.jkeating@redhat.com> <1173384005.3329.106.camel@localhost.localdomain> <1173391542.3329.137.camel@localhost.localdomain> <20070308221657.GA2680@jadzia.bu.edu> <1173394017.3329.154.camel@localhost.localdomain> Message-ID: <20070309000919.GA12716@jadzia.bu.edu> On Thu, Mar 08, 2007 at 02:46:57PM -0800, Toshio Kuratomi wrote: > > But it's trivial. If you always want the text version: > > alias emacs "emacs -nw" > > and if you want the GUI version when available, don't alias anything. > Depends on your reason for wanting the text version :-) If you just > want to use it within a terminal then -nw works. If you don't want to > load the gtk libraries then you have to actually use -nox. (Not as much > of an issue in these days of openoffice, firefox, and evolution, I > know :-) Right, I think that point is pretty much lost. :) Fedora is not a low-resource distribution. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From petersen at redhat.com Fri Mar 9 00:20:44 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 09 Mar 2007 10:20:44 +1000 Subject: naming scheme for fonts packages? In-Reply-To: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Message-ID: <45F0A85C.5000504@redhat.com> Nicolas Mailhot wrote: > IMHO (which if worth what it's worth) you're not packaging generic fonts > for tibetan but a specific font project, and it deserves name recognition > just like any other upstream. So upstreamname-fonts seems more respectful > for me. Then a followup question: if there is only 1 (truetype) font in a font package should the package name be "upstreamname-fonts" or "upstreamname-font"? :) The latter seems semantically more logical, the former more syntactically consistent. It is easy to search for /most/ fonts packages now with "rpm -qa '*fonts*'", but on the other hand it is a bit strange to call something *-fonts if it only contains a single font? So which gives? :) Any comments on this? Thanks, Jens ps I guess another aspect is one can never be sure that a project with one font now, in the future will not have more than one, or vice versa even. (Debian uses package names like "ttf-name" for truetype fonts.) From tgl at redhat.com Fri Mar 9 04:05:47 2007 From: tgl at redhat.com (Tom Lane) Date: Thu, 08 Mar 2007 23:05:47 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <200703081816.23690.jkeating@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> Message-ID: <20974.1173413147@sss.pgh.pa.us> Jesse Keating writes: > Or we just throw out the non-gui emacs and only ship the one that can do both +1. Building emacs without X support was pretty pointless a dozen years ago, and it is far more so now. What other packages do we build multiple versions of to avoid pulling in dependencies? regards, tom lane From aoliva at redhat.com Fri Mar 9 08:27:55 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 09 Mar 2007 05:27:55 -0300 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: <1173248024.3932.12.camel@tuxhugs> (Peter Gordon's message of "Tue\, 06 Mar 2007 22\:13\:44 -0800") References: <1173248024.3932.12.camel@tuxhugs> Message-ID: On Mar 7, 2007, Peter Gordon wrote: > However, it contains no full license text, and the headers in the > source files only contain author/version informations. The only > reference to a license aside from what's on the website is that the > README file (which I include as %doc) contains the following line: > License: GPL > Is this reference enough, IANAL. It's enough for you to tell that you can use any version of the GPL, but it's not enough for you to be allowed to distribute the program without a copy of the GPL, because the GPL itself requires it to be included. > or should I also include a full copy of the > GPL as %doc as well? (If so, I'll email Tavis and bug him about > including it in the tarball.) Yes, and you may want to point the author at section 1 of the GPLv2, that says: 1. You may copy and distribute [...] provided that you [...] give any other recipients of the Program a copy of this License along with the Program -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rc040203 at freenet.de Fri Mar 9 08:35:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Mar 2007 09:35:33 +0100 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: References: <1173248024.3932.12.camel@tuxhugs> Message-ID: <1173429334.25839.421.camel@mccallum.corsepiu.local> On Fri, 2007-03-09 at 05:27 -0300, Alexandre Oliva wrote: > On Mar 7, 2007, Peter Gordon wrote: > > > However, it contains no full license text, and the headers in the > > source files only contain author/version informations. The only > > reference to a license aside from what's on the website is that the > > README file (which I include as %doc) contains the following line: > > > License: GPL > > > Is this reference enough, > > IANAL. It's enough for you to tell that you can use any version of > the GPL, but it's not enough for you to be allowed to distribute the > program without a copy of the GPL, because the GPL itself requires it > to be included. IANAL, IMO, this is an upstream-issue, because it's legally irrelevant/legally not bind to _upstream_ whether a packager adds a copy of the GPL or not. Ralf From Axel.Thimm at ATrpms.net Fri Mar 9 08:43:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 09:43:25 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45F09BEE.7090909@redhat.com> References: <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> Message-ID: <20070309084325.GD19382@neu.nirvana> On Thu, Mar 08, 2007 at 05:27:42PM -0600, Mike McGrath wrote: > Bill Nottingham wrote: > >Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > >>Or bite the bullet and reserve a new fixed uid range > >> > > > >+100 > > > >Just do it, have a registry. When we get to a situation that requires 500 > >separate system UIDs, we'll deal with it then. I don't want to be > >the "640k should be enough for everyone" guy, but I'd have to think that > >by the time we get to that point, we will have gone way beyond the > >point of diminishing returns in additional packages. > > > >Bill > > > > > Just so we do know the numbers: > $ repoquery --whatrequires '/usr/sbin/useradd' --qf='%{name}' | sort | > uniq | wc -l > 54 I get more like 126: # (repoquery --whatrequires shadow-utils; repoquery --whatrequires /usr/sbin/useradd) | sort -u | wc -l Many packages like rpm, ntp, mlocate etc don't have a file dependency, but a package dependency. So with the currently reserved 500 system uid/gids we are already rather fine. The questions is do any of these packages really need *fixed* uid/gids? I really doubt it. But for whatever its worth let's raise the fixed/non-fixed cross-over from uid/gid 100 to 200 for F8 or F9. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Mar 9 09:19:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 10:19:10 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <20974.1173413147@sss.pgh.pa.us> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> Message-ID: <20070309091910.GC2866@free.fr> On Thu, Mar 08, 2007 at 11:05:47PM -0500, Tom Lane wrote: > Jesse Keating writes: > > Or we just throw out the non-gui emacs and only ship the one that can do both > > +1. Building emacs without X support was pretty pointless a dozen years > ago, and it is far more so now. What other packages do we build > multiple versions of to avoid pulling in dependencies? There is also vim. I guess it is not exactly the same split, but it seems to be split to keep a minimal vim-minimal. In my opinion it would be right to build 2 versions of all the packages that have a console version and a X version to minimize deps for the console version, such that it may be installed on X-less computers. It is really not pointless, I don't install X and even less gtk on some servers, and I may want emacs (now I use vi, but I used emacs in the past ;-). This is not going to be a lot of packages anyway. -- Pat From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 09:29:24 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 10:29:24 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070309084325.GD19382@neu.nirvana> (Axel Thimm's message of "Fri, 9 Mar 2007 09:43:25 +0100") References: <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> Message-ID: <87fy8erci3.fsf@fc5.bigo.ensc.de> Axel Thimm writes: > So with the currently reserved 500 system uid/gids we are already > rather fine. > > The questions is do any of these packages really need *fixed* uid/gids? > I really doubt it. It depends on the use case. E.g. 'ntp' does not need fixed uids in standard installations. But enhancing it and putting it into a chroot might change situation. Whether you assign predictable uids for all or only the really required services does not make a difference for fedora-usermgmt. The suggested window size of perhaps 500-1000 free users will cope with both. Wrapper script can be modified to translate the hint into non-continous areas too (e.g. hint 0-300 -> window 63000-66000, 301-2000 -> window 40000-41699) > But for whatever its worth let's raise > the fixed/non-fixed cross-over from uid/gid 100 to 200 for F8 or F9. I suggest 500-999; should not break LSB more than the 100-200 idea. But reuid'ing normal users is much easier than doing this for services. Enrico From tjanouse at redhat.com Fri Mar 9 09:40:22 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 9 Mar 2007 10:40:22 +0100 Subject: vim and /etc/alternatives In-Reply-To: <20070309091910.GC2866@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> Message-ID: <20070309094022.GA8331@redhat.com> Hi, On Fri, Mar 09, 2007 at 10:19:10AM +0100, Patrice Dumas wrote: > There is also vim. I guess it is not exactly the same split, but it > seems to be split to keep a minimal vim-minimal. In fact, the vim split is much more nonsense imo. I didn't find any option to run gvim in text mode so I just ended up replacing vim-minimal and vim-enhanced packages by my own that provide just a bunch of symlinks to gvim. Honestly, the alternatives approach in debian is one thousand times better. If anyone wonders why did I do that -- the -ehnanced version does not support xterm mouse and X clipboard. Sucks, doesn't it? -- TJ., BaseOS, Brno, CZ From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 09:41:55 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 10:41:55 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8erci3.fsf@fc5.bigo.ensc.de> (Enrico Scholz's message of "Fri, 09 Mar 2007 10:29:24 +0100") References: <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> Message-ID: <87bqj2rbx8.fsf@fc5.bigo.ensc.de> Enrico Scholz writes: > Wrapper script can be modified to translate the hint into non-continous > areas too (e.g. hint 0-300 -> window 63000-66000 ~~~~~ should be 'window 63000-63300' From Axel.Thimm at ATrpms.net Fri Mar 9 10:01:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 11:01:01 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8erci3.fsf@fc5.bigo.ensc.de> References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> Message-ID: <20070309100101.GA5557@neu.nirvana> On Fri, Mar 09, 2007 at 10:29:24AM +0100, Enrico Scholz wrote: > > But for whatever its worth let's raise the fixed/non-fixed > > cross-over from uid/gid 100 to 200 for F8 or F9. > > I suggest 500-999; should not break LSB more than the 100-200 idea. But > reuid'ing normal users is much easier than doing this for services. We can only mess with below 500. There are far too many large scale user deployments relying on putting their existing users to 500 upwards. Breaking this is not an option. Moving the bar from 100 to 200/anything will already break applications that randomly were allocated to some uid there, and this needs to be fixed per package, that's why we need a F8/F9 timeframe for doing that. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 10:15:51 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 11:15:51 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070309100101.GA5557@neu.nirvana> (Axel Thimm's message of "Fri, 9 Mar 2007 11:01:01 +0100") References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> Message-ID: <877itqraco.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> > But for whatever its worth let's raise the fixed/non-fixed >> > cross-over from uid/gid 100 to 200 for F8 or F9. >> >> I suggest 500-999; should not break LSB more than the 100-200 idea. But >> reuid'ing normal users is much easier than doing this for services. > > We can only mess with below 500. to be more exact: below 100 > Moving the bar from 100 to 200/anything will already break > applications that randomly were allocated to some uid there, and this > needs to be fixed per package, that's why we need a F8/F9 timeframe > for doing that. Why do we want to break existing installations overall? We could use exisisting solutions like fedora-usermgmt after ironing out documentation issues. When my shadow-utils patch gets accepted, shadow-util's '--hint' option can be used too. Enrico From Axel.Thimm at ATrpms.net Fri Mar 9 11:03:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 12:03:39 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <877itqraco.fsf@fc5.bigo.ensc.de> References: <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> Message-ID: <20070309110339.GB5557@neu.nirvana> On Fri, Mar 09, 2007 at 11:15:51AM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> > But for whatever its worth let's raise the fixed/non-fixed > >> > cross-over from uid/gid 100 to 200 for F8 or F9. > >> > >> I suggest 500-999; should not break LSB more than the 100-200 idea. But > >> reuid'ing normal users is much easier than doing this for services. > > > > We can only mess with below 500. > > to be more exact: below 100 You do seem to contracdict yourself, is it now 500-999 or below 100 ;) Anyway, the correct answer is still below 500: # grep 500 /etc/login.defs UID_MIN 500 GID_MIN 500 > When my shadow-utils patch gets accepted, shadow-util's '--hint' option > can be used too. That's just fedora-usermgmt merged upstream, right? So it will have the same flaws like fedora-usermgmt (other than not being merged upstream). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 11:15:01 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 12:15:01 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070309110339.GB5557@neu.nirvana> (Axel Thimm's message of "Fri, 9 Mar 2007 12:03:39 +0100") References: <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> Message-ID: <873b4er7m2.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> >> > But for whatever its worth let's raise the fixed/non-fixed >> >> > cross-over from uid/gid 100 to 200 for F8 or F9. >> >> >> >> I suggest 500-999; should not break LSB more than the 100-200 idea. But >> >> reuid'ing normal users is much easier than doing this for services. >> > >> > We can only mess with below 500. >> >> to be more exact: below 100 > > You do seem to contracdict yourself, is it now 500-999 or below 100 ;) you and notting are wanting to break the LSB by using an area which must not be used for fixed uids. I outlined an alternative which breaks LSB too but is much less painless on most systems. >> When my shadow-utils patch gets accepted, shadow-util's '--hint' option >> can be used too. > > That's just fedora-usermgmt merged upstream, right? basically, yes. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231525 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231540 There are missing some options to allow customization at repository level, but I will wait for a response to these two tickets first. > So it will have the same flaws like fedora-usermgmt About which flaws are you speaking? The example in the documentation which misleaded you, should be fixed. And since applied upstream or in RH shadow-utils, it will not be "proprietary" anymore. Enrico From aph at redhat.com Fri Mar 9 11:22:20 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 11:22:20 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <20070308220453.GA2305@jadzia.bu.edu> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> Message-ID: <17905.17260.372000.126744@zebedee.pink> Matthew Miller writes: > On Thu, Mar 08, 2007 at 10:52:33PM +0100, Miloslav Trmac wrote: > > > If both are functionally similar, yet the script solution avoids changes > > > to the filesystem *and* is much simpler, why not stick to the script > > > solution? > > If you completely ignore the original purpose of alternatives and focus > > only on the mechanism, following a few symlinks set up by alternatives > > is actually both more effective and simpler than starting bash to > > execute the script. > > The overhead of bash vs. a symlink is negligible when we're talking about > launching *emacs*. The real difference is: one is trivial and > self-contained, whereas the other relies on an whole infrastructure. Exactly. This is a change without a purpose. The existing solution works perfectly well: it ain't broken, so don't fix it. Andrew. From Axel.Thimm at ATrpms.net Fri Mar 9 11:32:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 12:32:10 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <873b4er7m2.fsf@fc5.bigo.ensc.de> References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> Message-ID: <20070309113210.GF5557@neu.nirvana> On Fri, Mar 09, 2007 at 12:15:01PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> >> > But for whatever its worth let's raise the fixed/non-fixed > >> >> > cross-over from uid/gid 100 to 200 for F8 or F9. > >> >> > >> >> I suggest 500-999; should not break LSB more than the 100-200 idea. But > >> >> reuid'ing normal users is much easier than doing this for services. > >> > > >> > We can only mess with below 500. > >> > >> to be more exact: below 100 > > > > You do seem to contracdict yourself, is it now 500-999 or below 100 ;) > > you and notting are wanting to break the LSB by using an area which must > not be used for fixed uids. I outlined an alternative which breaks LSB > too but is much less painless on most systems. OK, let's keep LSB compliance: Let's convert the 30 packages (Mike counted 25 I think) using fedora-usermgmt to plain useradd -r which is what they effectively do anyway since the very beginning. And which 126 other packages do with plain useradd -r. > > So it will have the same flaws like fedora-usermgmt > > About which flaws are you speaking? Please, repeating that you don't recognize any flaw is not making them go away. The reason why fedora-usermgmt doesn't boom on users' faces is that it defaults to useradd -r. Since this happens for all millions of users of Fedora, but for the dozen being aware of this mechanism *and* using it, it looks like the few packages using fedora-usermgmt don't really need any fixed/predicted etc ids, but can cope with plain old and simple useradd -r. And we metioned several cases where fedora-usermgmt will boom, if the package really relies on not getting a random uid, for example when the admin notices that such a mechanism exists after the first fedora-usermgmt packages have been installed. Or if the admin thinks he can move the floating window to a new position, and is not aware that the config is once-set-never-unset. And many other examples that just show that floatng uid windows is A Bad Idea. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 11:43:25 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 12:43:25 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070309113210.GF5557@neu.nirvana> (Axel Thimm's message of "Fri, 9 Mar 2007 12:32:10 +0100") References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <20070309113210.GF5557@neu.nirvana> Message-ID: <87y7m6prqa.fsf@fc5.bigo.ensc.de> Axel Thimm writes: >> > So it will have the same flaws like fedora-usermgmt >> >> About which flaws are you speaking? > > Please, repeating that you don't recognize any flaw is not making them > go away. Please, just because you do not recognize that the Flying Spaghetti Monster exists, it is not making it go away. Please, stop mentioning that there are flaws in fedora-usermgmt without naming them! > And we metioned several cases where fedora-usermgmt will boom, ... /me must be reading the wrong thread ... > if the package really relies on not getting a random uid, for example > when the admin notices that such a mechanism exists after the first > fedora-usermgmt packages have been installed. Or if the admin thinks > he can move the floating window to a new position, and is not aware > that the config is once-set-never-unset. Aieee.... when admin thinks, he can do 'rm -rf /', he will have some trouble too... > And many other examples that just show that floatng uid windows is A > Bad Idea. many == 0? Enrico From fedora at camperquake.de Fri Mar 9 11:55:17 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 9 Mar 2007 12:55:17 +0100 Subject: naming scheme for fonts packages? In-Reply-To: <45F0A85C.5000504@redhat.com> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> <45F0A85C.5000504@redhat.com> Message-ID: <20070309125517.2ccb7465@banea.int.addix.net> Hi. On Fri, 09 Mar 2007 10:20:44 +1000, Jens Petersen wrote: > The latter seems semantically more logical, the former more > syntactically consistent. It is easy to search for /most/ fonts > packages now with "rpm -qa '*fonts*'", but on the other hand it is a > bit strange to call something *-fonts if it only contains a single > font? So which gives? :) Call it fonts. It makes life easier for those who know how to use command line tools like that, those who do not probably do not care one way or the other anyway. From Axel.Thimm at ATrpms.net Fri Mar 9 12:00:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 13:00:07 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87y7m6prqa.fsf@fc5.bigo.ensc.de> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <20070309113210.GF5557@neu.nirvana> <87y7m6prqa.fsf@fc5.bigo.ensc.de> Message-ID: <20070309120007.GG5557@neu.nirvana> On Fri, Mar 09, 2007 at 12:43:25PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> > So it will have the same flaws like fedora-usermgmt > >> > >> About which flaws are you speaking? > > > > Please, repeating that you don't recognize any flaw is not making them > > go away. > > Please, just because you do not recognize that the Flying Spaghetti > Monster exists, it is not making it go away. I do recognize that the Flying Spaghetti Monster, we just call it fedora-usermgmt on Earth. So now that it was recognized, how will it go away, or do we need green krypto-sauce to defend ourselves? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Fri Mar 9 13:28:34 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 9 Mar 2007 14:28:34 +0100 Subject: FE Package Status of Mar 9, 2007 Message-ID: <20070309142834.7ea3f83c@ludwig-alpha.unil.ch> Hi folks, Here is the package status update... The number of unavailable packages seems to be increasing for some reason... Question 1: should this rather be posted to fedora-devel ? Question 2: should the /Extras be dropped from the wiki path ? Cheers, Christian ==== FE Package Status of Mar 9, 2007 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2975 packages - 4342 binary rpms in devel - 99 orphans - 51 packages not available in extras devel or release aconway at redhat dot com qpidc andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem bojan at rexursive dot com viewvc cbalint at redhat dot com gdal dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask fitzsim at redhat dot com classpathx-jaxp gauret at free dot fr pdftohtml guillaume dot thouvenin at bull dot net elsa jhrozek at redhat dot com dwdiff jkeating at redhat dot com koji lxtnow at gmail dot com specto mcepl at redhat dot com gstreamer-plugins-pulseaudio mwringe at redhat dot com plexus-velocity mwringe at redhat dot com plexus-container-default mwringe at redhat dot com nekohtml mwringe at redhat dot com qdox mwringe at redhat dot com plexus-utils mwringe at redhat dot com piccolo mwringe at redhat dot com msv notting at redhat dot com gnucash-docs nsantos at redhat dot com relaxngDatatype nsantos at redhat dot com xpp2 nsantos at redhat dot com dtdparser nsantos at redhat dot com gnu-regexp nsantos at redhat dot com xmldb-api nsantos at redhat dot com ws-jaxme nsantos at redhat dot com classworlds nsantos at redhat dot com xpp3 nsantos at redhat dot com jtidy nsantos at redhat dot com xom overholt at redhat dot com jython paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com jakarta-commons-net pcheung at redhat dot com plexus-i18n pcheung at redhat dot com asm2 pcheung at redhat dot com plexus-archiver pertusus at free dot fr ivman peter at thecodergeek dot com blam rdieter at math dot unl dot edu libkexiv2 rnorwood at redhat dot com perl-RPM2 steve at silug dot org perl-Devel-Leak steve at silug dot org perl-Module-Compile steve at silug dot org perl-Devel-Caller tcallawa at redhat dot com SimGear vivekl at redhat dot com saxon8 vivekl at redhat dot com saxon vivekl at redhat dot com jaxen-bootstrap wolfy at nobugconsulting dot ro tcpxtract - 4 packages not available in extras devel but present in release andreas dot bierfert at lowlatency dot de sylpheed-claws-plugins andreas dot bierfert at lowlatency dot de sylpheed-claws jmp at safe dot ca clement lmacken at redhat dot com python-TurboMail - 6 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=196837 php-pear-PHPUnit chris.stone at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,227091,227096,227107,227111 dkms Matt_Domsch at dell.com objectweb-anttask rafaels at redhat.com plexus-archiver rafaels at redhat.com plexus-velocity rafaels at redhat.com qdox rafaels at redhat.com - 2 packages present in the development repo which have no owners entry cycle gstreamer-plugins-pulse - 2 orphaned packages, yet available in extras devel luks-tools udftools - 45 packages that moved to core FE-ACCEPT packages stats: - 2019 accepted, closed package reviews - 24 accepted, closed package reviews not in repo - 5 accepted, closed package reviews not in owners - 37 accepted, open package reviews older than 4 weeks; - 97 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 235 open tickets - 23 tickets with no activity in eight weeks - 55 tickets with no activity in four weeks - 7 closed tickets FE-NEW packages stats: - 1129 open tickets - 40 tickets with no activity in eight weeks - 857 tickets with no activity in four weeks - 13 closed tickets FE-NEEDSPONSOR packages stats: - 49 open tickets - 9 tickets with no activity in eight weeks - 14 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets FE-GUIDELINES packages stats: - open tickets OPEN-BUGS packages stats: - 223 open tickets - 105 tickets with no activity in eight weeks - 38 tickets with no activity in four weeks CVS stats: - 2974 packages with a devel directory - 8 packages with no owners entry EL4 EL5 cycle gstreamer-plugins-pulse isorelax-0-0.1.release20050331.1jpp.1.src.rpm postgis postgresql-dbi-link tdma - 2 packages in CVS devel *and* Core gnucash libnl - 194 packages were dropped from extras Maintainers stats: - 273 maintainers - 10 inactive maintainers with open bugs - 45 inactive maintainers Dropped FC packages: - 293 packages were dropped from core since FC 1 Comps.xml files stats: - 957 packages in comps-fe7 file - 589 packages missing from comps-fe7 file - 11 packages in comps-fe7 but not in repo - 949 packages in comps-fe6 file - 583 packages missing from comps-fe6 file - 4 packages in comps-fe6 but not in repo From coldwell at redhat.com Fri Mar 9 14:12:31 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 09:12:31 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <200703081816.23690.jkeating@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> Message-ID: On Thu, 8 Mar 2007, Jesse Keating wrote: > On Thursday 08 March 2007 16:59:36 Chip Coldwell wrote: > > Right now: if you install emacs it drags in gtk/gdk/atk/etc, but you > > can invoke it with "-nw" and it will run in a terminal. ?Or you can > > install emacs-nox which does not drag in gtk/gdk/atk/etc, and it will > > only run in a terminal. > > > > So is your recommendation rename emacs to emacs-gnome, rename > > emacs-nox to emacs, and add a "-x" command line switch to emacs > > (renamed from emacs-nox) whose purpose is to emit an error message? > > my recommendation is to find a way to consolidate the two distinct binaries > into one that can optionally load gui libraries if A) they exist and B) an > option was passed to load them. The GUI libraries will be required by the dynamic linker in order to run the binary if the GUI was enabled at compile time. IOW, there are two completely different binaries. I would be nice if it worked the way you describe, but I think it would be many man-years of work to implement all the changes in emacs required. > Or we just throw out the non-gui emacs and only ship the one that can do both, > to be damned with pulling in a gtk stack. I don't want conflicts and I don't > want to involve alternatives if at all possible. Well, then I guess my preference would be to eliminate the -nox subpackage from Fedora. We can continue to support it for RHEL, since there will be headless servers, etc, that don't need all the GUI infrastructure. FWIW, on Debian, there are /etc/alternatives/vi /etc/alternatives/emacs etc, etc. So Debian uses the alternatives mechanism heavily in this respect. I'm not suggesting that Fedora should emulate this, just making the observation. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Fri Mar 9 14:14:48 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 09:14:48 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <17905.17260.372000.126744@zebedee.pink> References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: On Fri, 9 Mar 2007, Andrew Haley wrote: > Matthew Miller writes: > > On Thu, Mar 08, 2007 at 10:52:33PM +0100, Miloslav Trmac wrote: > > > > If both are functionally similar, yet the script solution avoids changes > > > > to the filesystem *and* is much simpler, why not stick to the script > > > > solution? > > > If you completely ignore the original purpose of alternatives and focus > > > only on the mechanism, following a few symlinks set up by alternatives > > > is actually both more effective and simpler than starting bash to > > > execute the script. > > > > The overhead of bash vs. a symlink is negligible when we're talking about > > launching *emacs*. The real difference is: one is trivial and > > self-contained, whereas the other relies on an whole infrastructure. > > Exactly. This is a change without a purpose. The existing solution > works perfectly well: it ain't broken, so don't fix it. It is broken in the sense that rpmlint pukes on the current emacs spec file, and a lot of the jiggery-pokery in there is done to support the two different versions of emacs and the wrapper script+symlinks currently being used. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mmcgrath at redhat.com Fri Mar 9 14:22:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 09 Mar 2007 08:22:51 -0600 Subject: Fedora User Management (revisited) In-Reply-To: <87y7m6prqa.fsf@fc5.bigo.ensc.de> References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <20070309113210.GF5557@neu.nirvana> <87y7m6prqa.fsf@fc5.bigo.ensc.de> Message-ID: <45F16DBB.9040109@redhat.com> Enrico Scholz wrote: > Axel Thimm writes: > > >>>> So it will have the same flaws like fedora-usermgmt >>>> >>> About which flaws are you speaking? >>> >> Please, repeating that you don't recognize any flaw is not making them >> go away. >> > > Please, just because you do not recognize that the Flying Spaghetti > Monster exists, it is not making it go away. > > Please, stop mentioning that there are flaws in fedora-usermgmt without > naming them! > > You're joking right? I don't want to get all ad-hominem here but multiple people have mentioned multiple issues / flaws and aside from a documentation mistype you basically told them "There is no flaw" If there "is no flaw" why is this thread still going on? Why does our downstream EPEL still not know what to do? Do you really think Axel and I have made up issues in the software and implementation for our own amusement? There are issues in the implementation please stop ignoring our message, we aren't stupid people quit treating us as such. -Mike From pvrabec at redhat.com Fri Mar 9 14:51:27 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Fri, 9 Mar 2007 15:51:27 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070308220911.GE5337@nostromo.devel.redhat.com> References: <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> Message-ID: <20070309155127.698b6893@wrabco.brq.redhat.com> Hi folks, I wrote a patch for useradd and groupadd, so they start assigning system UID and GID at the top of the available system slots (499). I hope it helps to create some space for static registration. I'll take a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231525 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231540 On Thu, 8 Mar 2007 17:09:11 -0500 Bill Nottingham wrote: > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > Or bite the bullet and reserve a new fixed uid range > > +100 > > Just do it, have a registry. When we get to a situation that requires > 500 separate system UIDs, we'll deal with it then. I don't want to be > the "640k should be enough for everyone" guy, but I'd have to think > that by the time we get to that point, we will have gone way beyond > the point of diminishing returns in additional packages. > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 14:52:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 15:52:05 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <45F16DBB.9040109@redhat.com> (Mike McGrath's message of "Fri, 09 Mar 2007 08:22:51 -0600") References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <20070309113210.GF5557@neu.nirvana> <87y7m6prqa.fsf@fc5.bigo.ensc.de> <45F16DBB.9040109@redhat.com> Message-ID: <87r6rypizu.fsf@fc5.bigo.ensc.de> Mike McGrath writes: >> Please, stop mentioning that there are flaws in fedora-usermgmt >> without naming them! >> > You're joking right? I don't want to get all ad-hominem here but > multiple people have mentioned multiple issues / flaws Are you working for SCO, or why do you not give an example for such an (technical) issue and/or point me to the posting(s)? > and aside from a documentation mistype you basically told them "There > is no flaw" If there "is no flaw" why is this thread still going on? I do not know why e.g. Axel posted several messages about fedora-usermgmt before he tried it the first time. > Why does our downstream EPEL still not know what to do? dunno > Do you really think Axel and I have made up issues in the software > and implementation for our own amusement? Dunno, perhaps you like the clicking of your keyboard when you are writing mails? Enrico From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 9 15:13:45 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Mar 2007 16:13:45 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070309155127.698b6893@wrabco.brq.redhat.com> (Peter Vrabec's message of "Fri, 9 Mar 2007 15:51:27 +0100") References: <45ED8080.9070802@leemhuis.info> <1173193330.6561.37.camel@zod.rchland.ibm.com> <20070306183823.GC7703@neu.nirvana> <1173210444.6561.47.camel@zod.rchland.ibm.com> <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <20070309155127.698b6893@wrabco.brq.redhat.com> Message-ID: <87mz2mphzq.fsf@fc5.bigo.ensc.de> Peter Vrabec writes: > I wrote a patch for useradd and groupadd, so they start assigning > system UID and GID at the top of the available system slots (499). > I hope it helps to create some space for static registration. Probably not. General static registration is only possible within 0-99 and this room is nearly full. Enrico From ajackson at redhat.com Fri Mar 9 15:57:57 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 09 Mar 2007 10:57:57 -0500 Subject: vim and /etc/alternatives In-Reply-To: <20070309094022.GA8331@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> Message-ID: <1173455877.20555.3.camel@localhost.localdomain> On Fri, 2007-03-09 at 10:40 +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 09, 2007 at 10:19:10AM +0100, Patrice Dumas wrote: > > There is also vim. I guess it is not exactly the same split, but it > > seems to be split to keep a minimal vim-minimal. > > In fact, the vim split is much more nonsense imo. I didn't find any option to > run gvim in text mode so I just ended up replacing vim-minimal and > vim-enhanced packages by my own that provide just a bunch of symlinks to > gvim. Honestly, the alternatives approach in debian is one thousand times > better. > > If anyone wonders why did I do that -- the -ehnanced version does not support > xterm mouse and X clipboard. Sucks, doesn't it? The one major reason to not want X support in your editor is so you don't block on the XOpenDisplay, which can take much longer than you want when using ssh with a forwarded display. But I'd assert that the right way to fix that is to teach vim about xcb so the open can fail asynchronously. - ajax From fche at redhat.com Fri Mar 9 16:41:57 2007 From: fche at redhat.com (Frank Ch. Eigler) Date: 09 Mar 2007 11:41:57 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: Chip Coldwell writes: > [...] > > Exactly. This is a change without a purpose. The existing solution > > works perfectly well: it ain't broken, so don't fix it. > > It is broken in the sense that rpmlint pukes on the current emacs spec > file Perhaps that's a problem better solved in rpmlint proper. > and a lot of the jiggery-pokery in there is done to support the two > different versions of emacs and the wrapper script+symlinks > currently being used. Is that jiggery-pokery in need of effortful upkeep? - FChE From coldwell at redhat.com Fri Mar 9 16:50:52 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 11:50:52 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: On Fri, 9 Mar 2007, Frank Ch. Eigler wrote: > Chip Coldwell writes: > > > and a lot of the jiggery-pokery in there is done to support the two > > different versions of emacs and the wrapper script+symlinks > > currently being used. > > Is that jiggery-pokery in need of effortful upkeep? Yes. In order to meet the merge review requirements for Fedora 7 I must silence rpmlint. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mattdm at mattdm.org Fri Mar 9 16:53:09 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 11:53:09 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: <20070309165309.GA22110@jadzia.bu.edu> On Fri, Mar 09, 2007 at 11:50:52AM -0500, Chip Coldwell wrote: > > > and a lot of the jiggery-pokery in there is done to support the two > > > different versions of emacs and the wrapper script+symlinks > > > currently being used. > > Is that jiggery-pokery in need of effortful upkeep? > Yes. In order to meet the merge review requirements for Fedora 7 I must > silence rpmlint. Except in cases where rpmlint is being stupid. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pertusus at free.fr Fri Mar 9 16:51:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 17:51:50 +0100 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> Message-ID: <20070309165150.GB25722@free.fr> On Fri, Mar 09, 2007 at 09:12:31AM -0500, Chip Coldwell wrote: > > Well, then I guess my preference would be to eliminate the -nox subpackage > from Fedora. We can continue to support it for RHEL, since there will be > headless servers, etc, that don't need all the GUI infrastructure. What! There couldn't be headless servers or X-less workstations running fedora? This seems to go in the opposite direction of sane objectives for fedora, and also there has been some very interesting innovations that should simplify installing fedora in such setups (say the minimal or server spin). -- Pat From fche at redhat.com Fri Mar 9 16:59:51 2007 From: fche at redhat.com (Frank Ch. Eigler) Date: Fri, 9 Mar 2007 11:59:51 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: <20070309165951.GM27273@redhat.com> Hi - On Fri, Mar 09, 2007 at 11:50:52AM -0500, Chip Coldwell wrote: > > Is that jiggery-pokery in need of effortful upkeep? > > Yes. In order to meet the merge review requirements for Fedora 7 I must > silence rpmlint. Perhaps a patch for rpmlint is then in order. My pet package (systemtap) has aspects that rpmlint mistakenly deems offensive. It would be a shame if that tool were not fixable and its decision were treated as final. - FChE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 9 17:04:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 12:04:26 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309165951.GM27273@redhat.com> References: <20070309165951.GM27273@redhat.com> Message-ID: <200703091204.26924.jkeating@redhat.com> On Friday 09 March 2007 11:59:51 Frank Ch. Eigler wrote: > > Yes. ?In order to meet the merge review requirements for Fedora 7 I must > > silence rpmlint. > > Perhaps a patch for rpmlint is then in order. ?My pet package > (systemtap) has aspects that rpmlint mistakenly deems offensive. ?It > would be a shame if that tool were not fixable and its decision were > treated as final. rpmlint is a handy tool to point out potential problems. If there are reasonable exceptions to the rpmlint Errors, those should be considered and waived for the review (so long as comments in the spec file clearly state why something is triggering rpmlint and why it is necessary) rpmlint is not supposed to be the be all / end all review tool, it's output is _not_ final. It is a tool to generate discussion points for further investigation and the reviewer/reviewee need to discuss/come to an agreement. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 9 17:05:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 12:05:17 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309165150.GB25722@free.fr> References: <20070309165150.GB25722@free.fr> Message-ID: <200703091205.17545.jkeating@redhat.com> On Friday 09 March 2007 11:51:50 Patrice Dumas wrote: > What! There couldn't be headless servers or X-less workstations running > fedora? This seems to go in the opposite direction of sane objectives > for fedora, and also there has been some very interesting innovations that > should simplify installing fedora in such setups (say the minimal or > server spin). X-less != no x libraries. Same with headless. With a few X libraries one has the ability to run graphical applications over an ssh tunnel to a machine with X on it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Mar 9 17:08:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 09:08:06 -0800 Subject: vim and /etc/alternatives In-Reply-To: <20070309094022.GA8331@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> Message-ID: <1173460086.3329.168.camel@localhost.localdomain> On Fri, 2007-03-09 at 10:40 +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 09, 2007 at 10:19:10AM +0100, Patrice Dumas wrote: > > There is also vim. I guess it is not exactly the same split, but it > > seems to be split to keep a minimal vim-minimal. > > In fact, the vim split is much more nonsense imo. I didn't find any option to > run gvim in text mode so I just ended up replacing vim-minimal and > vim-enhanced packages by my own that provide just a bunch of symlinks to > gvim. Honestly, the alternatives approach in debian is one thousand times > better. > The vim split has another purpose: To keep the X, perl, and python libraries off of /. We need /bin/vi to run if /usr is not mounted. So we have to compile a version of vim that doesn't drag in the kitchen sink. > If anyone wonders why did I do that -- the -ehnanced version does not support > xterm mouse and X clipboard. Sucks, doesn't it? Uhm. No it doesn't. I hate how gvim moves the cursor when I click in it with a mouse (I just want to select the text to paste into evolution or firefox, not move my editing cursor) and I have three buttons for a reason :-) (Unlike the vim-minimal split, I understand that vim's interaction with the mouse is a matter of personal taste.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Fri Mar 9 17:08:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 12:08:46 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309165150.GB25722@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20070309165150.GB25722@free.fr> Message-ID: <20070309170846.GA24050@jadzia.bu.edu> On Fri, Mar 09, 2007 at 05:51:50PM +0100, Patrice Dumas wrote: > > Well, then I guess my preference would be to eliminate the -nox subpackage > > from Fedora. We can continue to support it for RHEL, since there will be > > headless servers, etc, that don't need all the GUI infrastructure. > What! There couldn't be headless servers or X-less workstations running > fedora? This seems to go in the opposite direction of sane objectives ??? All you need is to have the libraries installed. You can still be as headless as you like. And of course this gives the advantage of being able to run in GUI mode over ssh from your administrative workstation if you like. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cra at WPI.EDU Fri Mar 9 17:09:17 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 9 Mar 2007 12:09:17 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309165150.GB25722@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20070309165150.GB25722@free.fr> Message-ID: <20070309170917.GW3334@angus.ind.WPI.EDU> On Fri, Mar 09, 2007 at 05:51:50PM +0100, Patrice Dumas wrote: > On Fri, Mar 09, 2007 at 09:12:31AM -0500, Chip Coldwell wrote: > > > > Well, then I guess my preference would be to eliminate the -nox subpackage > > from Fedora. We can continue to support it for RHEL, since there will be > > headless servers, etc, that don't need all the GUI infrastructure. > > What! There couldn't be headless servers or X-less workstations running > fedora? This seems to go in the opposite direction of sane objectives > for fedora, and also there has been some very interesting innovations that > should simplify installing fedora in such setups (say the minimal or > server spin). Not to mention blind users for whom emacs without a GUI could *be* their desktop environment. From coldwell at redhat.com Fri Mar 9 17:15:13 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:15:13 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <20070309170917.GW3334@angus.ind.WPI.EDU> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20070309165150.GB25722@free.fr> <20070309170917.GW3334@angus.ind.WPI.EDU> Message-ID: On Fri, 9 Mar 2007, Chuck Anderson wrote: > > Not to mention blind users for whom emacs without a GUI could *be* > their desktop environment. Actually, no. They would need atk to get a screenreader, which sucks in the entire gtk/gdk infrastructure. However, emacs and atk are not getting along right now, see bug 224611. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Fri Mar 9 17:18:13 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:18:13 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20070309165150.GB25722@free.fr> <20070309170917.GW3334@angus.ind.WPI.EDU> Message-ID: On Fri, 9 Mar 2007, Chip Coldwell wrote: > On Fri, 9 Mar 2007, Chuck Anderson wrote: > > > > Not to mention blind users for whom emacs without a GUI could *be* > > their desktop environment. > > Actually, no. They would need atk to get a screenreader, which sucks in > the entire gtk/gdk infrastructure. However, emacs and atk are not > getting along right now, see bug 224611. I take it back. I forgot about emacspeak. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From a.badger at gmail.com Fri Mar 9 17:18:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 09:18:13 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> Message-ID: <1173460693.3329.175.camel@localhost.localdomain> On Fri, 2007-03-09 at 09:12 -0500, Chip Coldwell wrote: > On Thu, 8 Mar 2007, Jesse Keating wrote: > > > On Thursday 08 March 2007 16:59:36 Chip Coldwell wrote: > > > Right now: if you install emacs it drags in gtk/gdk/atk/etc, but you > > > can invoke it with "-nw" and it will run in a terminal. Or you can > > > install emacs-nox which does not drag in gtk/gdk/atk/etc, and it will > > > only run in a terminal. > > > > > > So is your recommendation rename emacs to emacs-gnome, rename > > > emacs-nox to emacs, and add a "-x" command line switch to emacs > > > (renamed from emacs-nox) whose purpose is to emit an error message? > > > > my recommendation is to find a way to consolidate the two distinct binaries > > into one that can optionally load gui libraries if A) they exist and B) an > > option was passed to load them. > > The GUI libraries will be required by the dynamic linker in order to run > the binary if the GUI was enabled at compile time. IOW, there are two > completely different binaries. I would be nice if it worked the way you > describe, but I think it would be many man-years of work to implement all > the changes in emacs required. > > > Or we just throw out the non-gui emacs and only ship the one that can do both, > > to be damned with pulling in a gtk stack. I don't want conflicts and I don't > > want to involve alternatives if at all possible. > > Well, then I guess my preference would be to eliminate the -nox subpackage > from Fedora. We can continue to support it for RHEL, since there will be > headless servers, etc, that don't need all the GUI infrastructure. > You're going to find that some reviewers balk heavily at this. Perhaps even enough to veto a package that another reviewer is willing to approve. Luckily I don't use emacs so I don't have to get involved with that one :-) What would be most productive in this conversation, though, is posting the reason that you're thinking of changing the way emacs builds and installs. You've said it's because of rpmlint warnings but those warnings aren't posted here or in the review [1]_. Without being able to see those, no one can help you and the reviewer evaluate whether rpmlint is pointing out a valid concern, is being overly picky for this package, or should be fixed in a way that we aren't even considering. As always, rpmlint is a tool that helps reviewers pick out bad practices but there can be cases where a bad practice in general is the best practice for this case. Reviewers and other packagers need specifics in order to help you determine what to do. [1]_: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225726 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri Mar 9 17:20:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 18:20:06 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <200703091205.17545.jkeating@redhat.com> References: <20070309165150.GB25722@free.fr> <200703091205.17545.jkeating@redhat.com> Message-ID: <20070309172006.GE25722@free.fr> On Fri, Mar 09, 2007 at 12:05:17PM -0500, Jesse Keating wrote: > On Friday 09 March 2007 11:51:50 Patrice Dumas wrote: > > What! There couldn't be headless servers or X-less workstations running > > fedora? This seems to go in the opposite direction of sane objectives > > for fedora, and also there has been some very interesting innovations that > > should simplify installing fedora in such setups (say the minimal or > > server spin). > > X-less != no x libraries. Same with headless. With a few X libraries one has > the ability to run graphical applications over an ssh tunnel to a machine > with X on it. I wanted to say without X libraries. I think having a setup without X libraries should be perfectly fine in fedora, with emacs (though I prefer vi ;-). -- Pat From coldwell at redhat.com Fri Mar 9 17:27:11 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:27:11 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <1173460693.3329.175.camel@localhost.localdomain> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> Message-ID: On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > On Fri, 2007-03-09 at 09:12 -0500, Chip Coldwell wrote: > > > > Well, then I guess my preference would be to eliminate the -nox subpackage > > from Fedora. We can continue to support it for RHEL, since there will be > > headless servers, etc, that don't need all the GUI infrastructure. > > > You're going to find that some reviewers balk heavily at this. Perhaps > even enough to veto a package that another reviewer is willing to > approve. Luckily I don't use emacs so I don't have to get involved with > that one :-) If you've been following this thread, you must realize that I am just blowing with the wind here. My initial notion was to use the /etc/alternatives infrastructure. That's what Debian does, and it seems like this is precisely the sort of thing that /etc/alternatives was meant to handle: two alternative methods of providing the same (or nearly the same) functionality. We could even fold in xemacs. That met with strenous objections. Then I suggested having two packages that conflict with each other. That met with strenous objections. Then I suggested dropping the emacs-nox package. That met with strenous objections. > What would be most productive in this conversation, though, is posting > the reason that you're thinking of changing the way emacs builds and > installs. I suppose I could, but given how this thread on a much narrower topic has gone, what hope is there of reaching consensus on the entire rpmlint output? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Fri Mar 9 17:28:56 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:28:56 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> Message-ID: On Fri, 9 Mar 2007, Chip Coldwell wrote: > > strenous I can't believe I misspelled that word three times in one email. "strenuous". Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mclasen at redhat.com Fri Mar 9 17:35:56 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 09 Mar 2007 12:35:56 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20070309165150.GB25722@free.fr> <20070309170917.GW3334@angus.ind.WPI.EDU> Message-ID: <1173461756.3428.4.camel@localhost.localdomain> On Fri, 2007-03-09 at 12:15 -0500, Chip Coldwell wrote: > On Fri, 9 Mar 2007, Chuck Anderson wrote: > > > > Not to mention blind users for whom emacs without a GUI could *be* > > their desktop environment. > > Actually, no. They would need atk to get a screenreader, which sucks in > the entire gtk/gdk infrastructure. Not true. [mclasen at localhost ~]$ rpm -q --requires atk /sbin/ldconfig /sbin/ldconfig libatk-1.0.so.0 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libdl.so.2 libglib-2.0.so.0 libgmodule-2.0.so.0 libgobject-2.0.so.0 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) Of course, to use GUI a11y tools, you need at least the GTK+ stack, but that shouldn't be a surprise... From jkeating at redhat.com Fri Mar 9 17:33:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 12:33:12 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173460693.3329.175.camel@localhost.localdomain> Message-ID: <200703091233.12990.jkeating@redhat.com> On Friday 09 March 2007 12:27:11 Chip Coldwell wrote: > Then I suggested dropping the emacs-nox package. > > That met with strenous objections. Where? I saw one objection. You could also keep the emacs-nox package and just name it emacs-nox. If you're purposefully setting up a box without X libs and with emacs-nox, you probably are capable of running emacs-nox instead of 'emacs'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Fri Mar 9 17:35:00 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 12:35:00 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> Message-ID: <20070309173500.GA26593@jadzia.bu.edu> On Fri, Mar 09, 2007 at 12:27:11PM -0500, Chip Coldwell wrote: > blowing with the wind here. My initial notion was to use the > /etc/alternatives infrastructure. That's what Debian does, and it seems > like this is precisely the sort of thing that /etc/alternatives was meant > to handle: two alternative methods of providing the same (or nearly the > same) functionality. We could even fold in xemacs. Your point about xemacs is a very strong argument for not using alternatives. That's *exactly* what it's not for. > That met with strenous objections. Right. :) > Then I suggested having two packages that conflict with each other. > That met with strenous objections. Right, there's no really good reason to do that. > Then I suggested dropping the emacs-nox package. > That met with strenous objections. But, not very convincing ones. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From aph at redhat.com Fri Mar 9 17:35:16 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 17:35:16 +0000 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> Message-ID: <17905.39636.508338.748699@zebedee.pink> Chip Coldwell writes: > On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > If you've been following this thread, you must realize that I am just > blowing with the wind here. My initial notion was to use the > /etc/alternatives infrastructure. That's what Debian does, and it seems > like this is precisely the sort of thing that /etc/alternatives was meant > to handle: two alternative methods of providing the same (or nearly the > same) functionality. We could even fold in xemacs. > > That met with strenous objections. > > Then I suggested having two packages that conflict with each other. > > That met with strenous objections. > > Then I suggested dropping the emacs-nox package. > > That met with strenous objections. > > > What would be most productive in this conversation, though, is posting > > the reason that you're thinking of changing the way emacs builds and > > installs. > > I suppose I could, but given how this thread on a much narrower topic has > gone, what hope is there of reaching consensus on the entire rpmlint > output? The problem is that the suggested changes are disproportionate. We already have a neat and painless solution to the problem. However, rpmlint can't cope with it. But rpmlint is to help people to find out when something is wrong and change things, not to force people to change things that aren't wrong. At the moment, the only thing that is wrong with the solution we have is that rpmlint can't grok it. Andrew. From aph at redhat.com Fri Mar 9 17:36:10 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 17:36:10 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703091233.12990.jkeating@redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> Message-ID: <17905.39690.100754.74843@zebedee.pink> Jesse Keating writes: > On Friday 09 March 2007 12:27:11 Chip Coldwell wrote: > > Then I suggested dropping the emacs-nox package. > > > > That met with strenous objections. > > Where? I saw one objection. > > You could also keep the emacs-nox package and just name it emacs-nox. If > you're purposefully setting up a box without X libs and with emacs-nox, you > probably are capable of running emacs-nox instead of 'emacs'. Huh? How would you even know it was there? You may not have setp up the box yourself, you may not even have used a Red Hat box before. Andrew. From coldwell at redhat.com Fri Mar 9 17:36:14 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:36:14 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <200703091233.12990.jkeating@redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> Message-ID: On Fri, 9 Mar 2007, Jesse Keating wrote: > On Friday 09 March 2007 12:27:11 Chip Coldwell wrote: > > Then I suggested dropping the emacs-nox package. > > > > That met with strenous objections. > > Where? I saw one objection. Patrice and Toshio at least. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From aph at redhat.com Fri Mar 9 17:39:16 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 17:39:16 +0000 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> Message-ID: <17905.39876.950488.122070@zebedee.pink> Chip Coldwell writes: > On Fri, 9 Mar 2007, Jesse Keating wrote: > > > On Friday 09 March 2007 12:27:11 Chip Coldwell wrote: > > > Then I suggested dropping the emacs-nox package. > > > > > > That met with strenous objections. > > > > Where? I saw one objection. > > Patrice and Toshio at least. Me too. I'd like to continue to use Fedora on headless servers. Andrew. From jkeating at redhat.com Fri Mar 9 17:41:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 12:41:09 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17905.39876.950488.122070@zebedee.pink> References: <17905.39876.950488.122070@zebedee.pink> Message-ID: <200703091241.09349.jkeating@redhat.com> On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > Me too. ?I'd like to continue to use Fedora on headless servers. Specifically with out the few megs that X libs would require? You can still run emacs with the option to not do graphical. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Mar 9 17:37:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 18:37:15 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <20070309173500.GA26593@jadzia.bu.edu> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> Message-ID: <20070309173715.GG25722@free.fr> On Fri, Mar 09, 2007 at 12:35:00PM -0500, Matthew Miller wrote: > > But, not very convincing ones. :) If having a fedora box without X installed but still functionnal is not convincing I don't know where we are heading. -- Pat From a.badger at gmail.com Fri Mar 9 17:43:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 09:43:55 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> Message-ID: <1173462235.3329.183.camel@localhost.localdomain> On Fri, 2007-03-09 at 12:27 -0500, Chip Coldwell wrote: > On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > > > On Fri, 2007-03-09 at 09:12 -0500, Chip Coldwell wrote: > > > > > > Well, then I guess my preference would be to eliminate the -nox subpackage > > > from Fedora. We can continue to support it for RHEL, since there will be > > > headless servers, etc, that don't need all the GUI infrastructure. > > > > > You're going to find that some reviewers balk heavily at this. Perhaps > > even enough to veto a package that another reviewer is willing to > > approve. Luckily I don't use emacs so I don't have to get involved with > > that one :-) > > If you've been following this thread, you must realize that I am just > blowing with the wind here. My initial notion was to use the > /etc/alternatives infrastructure. That's what Debian does, and it seems > like this is precisely the sort of thing that /etc/alternatives was meant > to handle: two alternative methods of providing the same (or nearly the > same) functionality. We could even fold in xemacs. > > That met with strenous objections. > > Then I suggested having two packages that conflict with each other. > > That met with strenous objections. > > Then I suggested dropping the emacs-nox package. > > That met with strenous objections. > Right. The scripted approach, that is already implemented, is the one that people support. If you're just going to bow to the will of the people, then that's what you need to do. > > What would be most productive in this conversation, though, is posting > > the reason that you're thinking of changing the way emacs builds and > > installs. > > I suppose I could, but given how this thread on a much narrower topic has > gone, what hope is there of reaching consensus on the entire rpmlint > output? Because it's incredibly easy for people to argue in the abstract about what's "right" and what's "wrong". Give people some concrete objectives that they need to solve (reconcile rpmlint's output with the needs of this package) and they'll contribute something useful rather than just spouting ideas that other people shoot down. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From coldwell at redhat.com Fri Mar 9 17:47:17 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:47:17 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <20070309173500.GA26593@jadzia.bu.edu> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> Message-ID: On Fri, 9 Mar 2007, Matthew Miller wrote: > On Fri, Mar 09, 2007 at 12:27:11PM -0500, Chip Coldwell wrote: > > blowing with the wind here. My initial notion was to use the > > /etc/alternatives infrastructure. That's what Debian does, and it seems > > like this is precisely the sort of thing that /etc/alternatives was meant > > to handle: two alternative methods of providing the same (or nearly the > > same) functionality. We could even fold in xemacs. > > Your point about xemacs is a very strong argument for not using > alternatives. That's *exactly* what it's not for. I don't see your point. With /etc/alternatives, you could have both GNU emacs (X and no-X versions) and Lucid/XEmacs installed simultaneously and each user could run the one he prefers. Those who have no preference would get the systemwide default set in /etc/alternatives. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From mattdm at mattdm.org Fri Mar 9 17:50:04 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 12:50:04 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17905.39876.950488.122070@zebedee.pink> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <17905.39876.950488.122070@zebedee.pink> Message-ID: <20070309175004.GA28399@jadzia.bu.edu> On Fri, Mar 09, 2007 at 05:39:16PM +0000, Andrew Haley wrote: > > > Where? I saw one objection. > > Patrice and Toshio at least. > Me too. I'd like to continue to use Fedora on headless servers. And you still could. And you could still run emacs. This is a non-issue. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jdennis at redhat.com Fri Mar 9 17:50:57 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Mar 2007 12:50:57 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <200703091233.12990.jkeating@redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> Message-ID: <1173462658.30268.30.camel@junko.usersys.redhat.com> On Fri, 2007-03-09 at 12:33 -0500, Jesse Keating wrote: > On Friday 09 March 2007 12:27:11 Chip Coldwell wrote: > > Then I suggested dropping the emacs-nox package. > > > > That met with strenous objections. > > Where? I saw one objection. > > You could also keep the emacs-nox package and just name it emacs-nox. If > you're purposefully setting up a box without X libs and with emacs-nox, you > probably are capable of running emacs-nox instead of 'emacs'. No, bad idea. Too many humans, scripts, environment variables, etc. depend on the 'emacs' name. Here is the summary as I see it: There is nothing wrong with rpmlint, it is properly complaining about two packages which both claim to own the same file, that's a conflict and we don't want conflicts. To get us to a situation where there can be two versions of emacs (a reasonable goal) we have the following choices: * have a package which owns /usr/bin/emacs and install a script to start the preferred version. emacs and emacs-nox both require this package. * use alternatives (yuck!), I don't think it's appropriate for this purpose and its just plain nasty, but it solves the file conflict problem. I think the first solution is preferable, a master package, plus there are many files in emacs which would be shared between X version and the nox version, these can all go in the master package. -- John Dennis From coldwell at redhat.com Fri Mar 9 17:51:45 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:51:45 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <200703091241.09349.jkeating@redhat.com> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> Message-ID: On Fri, 9 Mar 2007, Jesse Keating wrote: > On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > > Me too. ?I'd like to continue to use Fedora on headless servers. > > Specifically with out the few megs that X libs would require? You can still > run emacs with the option to not do graphical. Really, there's much more to it than just the space on disk and in the RSS that the libraries occupy. By linking emacs to the entire GUI infracstructure, you expose it to all of the bugs in those libraries (e.g. 224611). There's more to the minimalist approach than megabytes. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From pertusus at free.fr Fri Mar 9 17:50:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 18:50:08 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <200703091241.09349.jkeating@redhat.com> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> Message-ID: <20070309175008.GH25722@free.fr> On Fri, Mar 09, 2007 at 12:41:09PM -0500, Jesse Keating wrote: > On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > > Me too. ?I'd like to continue to use Fedora on headless servers. > > Specifically with out the few megs that X libs would require? You can still > run emacs with the option to not do graphical. The issue is not the size. On some servers (or even workstations) I don't want to have X libs installed at all. -- Pat From coldwell at redhat.com Fri Mar 9 17:56:01 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 12:56:01 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <1173462658.30268.30.camel@junko.usersys.redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: On Fri, 9 Mar 2007, John Dennis wrote: > > Here is the summary as I see it: Good summary, thanks. > and we don't want conflicts. > > To get us to a situation where there can be two versions of emacs (a > reasonable goal) we have the following choices: > > * have a package which owns /usr/bin/emacs and install a script to start > the preferred version. emacs and emacs-nox both require this package. > > * use alternatives (yuck!), I don't think it's appropriate for this > purpose and its just plain nasty, but it solves the file conflict > problem. I really don't understand the reaction alternatives is getting. Is it really preferable to have every package create its own script, using its own environment variables and its own priorities, than to use a common infracstructure like alternatives? At least once the SA has learned alternatives, he knows what to expect from the different packages that use it. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jdennis at redhat.com Fri Mar 9 17:57:42 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Mar 2007 12:57:42 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> Message-ID: <1173463062.30268.34.camel@junko.usersys.redhat.com> On Fri, 2007-03-09 at 12:47 -0500, Chip Coldwell wrote: > On Fri, 9 Mar 2007, Matthew Miller wrote: > > Your point about xemacs is a very strong argument for not using > > alternatives. That's *exactly* what it's not for. > > I don't see your point. With /etc/alternatives, you could have both GNU > emacs (X and no-X versions) and Lucid/XEmacs installed simultaneously and > each user could run the one he prefers. Those who have no preference > would get the systemwide default set in /etc/alternatives. With alternatives the commands are supposed to be functionally identical. To the best of my knowledge this is not true with the different emacs variants. -- John Dennis From jkeating at redhat.com Fri Mar 9 17:59:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 12:59:58 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: <200703091259.58115.jkeating@redhat.com> On Friday 09 March 2007 12:56:01 Chip Coldwell wrote: > I really don't understand the reaction alternatives is getting. ?Is it > really preferable to have every package create its own script, using its > own environment variables and its own priorities, than to use a common > infracstructure like alternatives? ?At least once the SA has learned > alternatives, he knows what to expect from the different packages that use > it. Forgive my ignorance, but isn't alternatives a sitewide thing, where preference for emacs vs emacs-nox might be a per user thing? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Fri Mar 9 18:00:39 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 13:00:39 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <1173463062.30268.34.camel@junko.usersys.redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <1173463062.30268.34.camel@junko.usersys.redhat.com> Message-ID: On Fri, 9 Mar 2007, John Dennis wrote: > > With alternatives the commands are supposed to be functionally > identical. To the best of my knowledge this is not true with the > different emacs variants. The differences between GNU emacs and Lucid/XEmacs are subtle, anyway. Certainly, the command line switches (except those specifically related to the GUI like -geometry or -display) are the same between emacs and emacs-nox. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From aph at redhat.com Fri Mar 9 18:00:48 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:00:48 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703091241.09349.jkeating@redhat.com> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> Message-ID: <17905.41168.619070.622134@zebedee.pink> Jesse Keating writes: > On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > > Me too. ?I'd like to continue to use Fedora on headless servers. > > Specifically with out the few megs that X libs would require? You can still > run emacs with the option to not do graphical. I suppose so, but it would be odd after installing suddenly to discover a bunch of X libraries. -- "What the hell are these libraries for? I didn't ask for them!" -- "Well, it's all because of the way rpmlint works." -- "Sorry? Say that again..." :-) Andrew. From aph at redhat.com Fri Mar 9 18:01:53 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:01:53 +0000 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: <17905.41233.617861.627997@zebedee.pink> Chip Coldwell writes: > > I really don't understand the reaction alternatives is getting. Is > it really preferable to have every package create its own script, > using its own environment variables and its own priorities, than to > use a common infracstructure like alternatives? At least once the > SA has learned alternatives, he knows what to expect from the > different packages that use it. I'm coming down on your side. It's certainly preferable to having emacs depend on X libraries. Andrew. From mattdm at mattdm.org Fri Mar 9 18:02:52 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 13:02:52 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309173715.GG25722@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> Message-ID: <20070309180252.GB28399@jadzia.bu.edu> On Fri, Mar 09, 2007 at 06:37:15PM +0100, Patrice Dumas wrote: > > But, not very convincing ones. :) > If having a fedora box without X installed but still functionnal is not > convincing I don't know where we are heading. As mentioned, you don't need to have an X server installed. The argument for saving the few megs of disk space used by the X libraries themselves *isn't* convincing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From coldwell at redhat.com Fri Mar 9 18:03:07 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 13:03:07 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <200703091259.58115.jkeating@redhat.com> References: <1173462658.30268.30.camel@junko.usersys.redhat.com> <200703091259.58115.jkeating@redhat.com> Message-ID: On Fri, 9 Mar 2007, Jesse Keating wrote: > On Friday 09 March 2007 12:56:01 Chip Coldwell wrote: > > I really don't understand the reaction alternatives is getting. ?Is it > > really preferable to have every package create its own script, using its > > own environment variables and its own priorities, than to use a common > > infracstructure like alternatives? ?At least once the SA has learned > > alternatives, he knows what to expect from the different packages that use > > it. > > Forgive my ignorance, but isn't alternatives a sitewide thing, where > preference for emacs vs emacs-nox might be a per user thing? How is that different from a shell script in /usr/bin/emacs that chooses a sitewide default? If there is /usr/bin/emacs -> /etc/alternatives/emacs /etc/alternatives/emacs -> /usr/bin/emacs-22.0.95 and /usr/bin/xemacs /usr/bin/emacs-22.0.95-nox The user can still "alias emacs=xemacs" or put a wrapper script in $HOME/bin. Functionally, the /etc/alternatives is only setting a systemwide default, precisely the same thing the systemwide wrapper script does, but does it in a standardized way instead of making up our own per-package standard. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From aph at redhat.com Fri Mar 9 18:05:20 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:05:20 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703091259.58115.jkeating@redhat.com> References: <1173462658.30268.30.camel@junko.usersys.redhat.com> <200703091259.58115.jkeating@redhat.com> Message-ID: <17905.41440.648292.477461@zebedee.pink> Jesse Keating writes: > On Friday 09 March 2007 12:56:01 Chip Coldwell wrote: > > I really don't understand the reaction alternatives is getting. ?Is it > > really preferable to have every package create its own script, using its > > own environment variables and its own priorities, than to use a common > > infracstructure like alternatives? ?At least once the SA has learned > > alternatives, he knows what to expect from the different packages that use > > it. > > Forgive my ignorance, but isn't alternatives a sitewide thing, where > preference for emacs vs emacs-nox might be a per user thing? alternatives just provides a master symlink called "emacs" pointing to emacs-foo, emacs-bar, and do on. You can still invoke emacs-foo and emacs-bar directly. Andrew. From jdennis at redhat.com Fri Mar 9 18:05:30 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Mar 2007 13:05:30 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17905.41168.619070.622134@zebedee.pink> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> <17905.41168.619070.622134@zebedee.pink> Message-ID: <1173463530.30268.37.camel@junko.usersys.redhat.com> On Fri, 2007-03-09 at 18:00 +0000, Andrew Haley wrote: > Jesse Keating writes: > > On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > > > Me too. I'd like to continue to use Fedora on headless servers. > > > > Specifically with out the few megs that X libs would require? You can still > > run emacs with the option to not do graphical. > > I suppose so, but it would be odd after installing suddenly to > discover a bunch of X libraries. > > -- "What the hell are these libraries for? I didn't ask for them!" > > -- "Well, it's all because of the way rpmlint works." > > -- "Sorry? Say that again..." No, you're missing the point. This is not about rpmlint, the issue is two packages cannot own the same file. That restriction is a good thing. All rpmlint is doing is enforcing the sane requirement that rpm files do not conflict. -- John Dennis From mattdm at mattdm.org Fri Mar 9 18:06:10 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 13:06:10 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173462658.30268.30.camel@junko.usersys.redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: <20070309180610.GC28399@jadzia.bu.edu> On Fri, Mar 09, 2007 at 12:50:57PM -0500, John Dennis wrote: > There is nothing wrong with rpmlint, it is properly complaining about > two packages which both claim to own the same file, that's a conflict > and we don't want conflicts. It's not a conflict if the file is identical. > To get us to a situation where there can be two versions of emacs (a > reasonable goal) we have the following choices: > * have a package which owns /usr/bin/emacs and install a script to start > the preferred version. emacs and emacs-nox both require this package. What, like, say, "emacs-common"? > I think the first solution is preferable, a master package, plus there > are many files in emacs which would be shared between X version and the > nox version, these can all go in the master package. Revolutionary! :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From a.badger at gmail.com Fri Mar 9 18:07:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 10:07:37 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <1173462658.30268.30.camel@junko.usersys.redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: <1173463657.3329.188.camel@localhost.localdomain> On Fri, 2007-03-09 at 12:50 -0500, John Dennis wrote: > Here is the summary as I see it: > > There is nothing wrong with rpmlint, it is properly complaining about > two packages which both claim to own the same file, that's a conflict > and we don't want conflicts. > > To get us to a situation where there can be two versions of emacs (a > reasonable goal) we have the following choices: > > * have a package which owns /usr/bin/emacs and install a script to start > the preferred version. emacs and emacs-nox both require this package. > > * use alternatives (yuck!), I don't think it's appropriate for this > purpose and its just plain nasty, but it solves the file conflict > problem. > > I think the first solution is preferable, a master package, plus there > are many files in emacs which would be shared between X version and the > nox version, these can all go in the master package. Ugh. Is that the rpmlint warning that this is all about? You already have an emacs-common package for files shared between emacs with x and emacs without x. Move the /usr/bin/emacs script into the emacs-common package and have done already. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From coldwell at redhat.com Fri Mar 9 18:11:06 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 13:11:06 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <1173463657.3329.188.camel@localhost.localdomain> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> <1173463657.3329.188.camel@localhost.localdomain> Message-ID: On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > > Ugh. Is that the rpmlint warning that this is all about? You already > have an emacs-common package for files shared between emacs with x and > emacs without x. Move the /usr/bin/emacs script into the emacs-common > package and have done already. That leads to a circular dependency. The shell script requires that one of the two "emacs" and "emacs-nox" packages be installed. If emacs-common requires one of those two, and they each require emacs-common .... Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jkeating at redhat.com Fri Mar 9 18:11:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 13:11:24 -0500 Subject: emacs and /etc/alternatives In-Reply-To: References: <200703091259.58115.jkeating@redhat.com> Message-ID: <200703091311.24826.jkeating@redhat.com> On Friday 09 March 2007 13:03:07 Chip Coldwell wrote: > The user can still "alias emacs=xemacs" or put a wrapper script in > $HOME/bin. ?Functionally, the /etc/alternatives is only setting a > systemwide default, precisely the same thing the systemwide wrapper script > does, but does it in a standardized way instead of making up our own > per-package standard. And I think neither of these are suitable solutions for something that is really a user preference not a site preference. But *shrug* I just hate this problem. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Fri Mar 9 18:13:41 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 13:13:41 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <200703091311.24826.jkeating@redhat.com> References: <200703091259.58115.jkeating@redhat.com> <200703091311.24826.jkeating@redhat.com> Message-ID: On Fri, 9 Mar 2007, Jesse Keating wrote: > On Friday 09 March 2007 13:03:07 Chip Coldwell wrote: > > The user can still "alias emacs=xemacs" or put a wrapper script in > > $HOME/bin. ??Functionally, the /etc/alternatives is only setting a > > systemwide default, precisely the same thing the systemwide wrapper script > > does, but does it in a standardized way instead of making up our own > > per-package standard. > > And I think neither of these are suitable solutions for something that is > really a user preference not a site preference. But *shrug* I just hate this > problem. It's unavoidable. If there are several versions of emacs, and we expect something sensible to happen when we type "emacs" at the command prompt, then there must be a default. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From pertusus at free.fr Fri Mar 9 18:13:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 19:13:02 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <20070309180252.GB28399@jadzia.bu.edu> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> Message-ID: <20070309181302.GJ25722@free.fr> On Fri, Mar 09, 2007 at 01:02:52PM -0500, Matthew Miller wrote: > On Fri, Mar 09, 2007 at 06:37:15PM +0100, Patrice Dumas wrote: > > > But, not very convincing ones. :) > > If having a fedora box without X installed but still functionnal is not > > convincing I don't know where we are heading. > > As mentioned, you don't need to have an X server installed. The argument for > saving the few megs of disk space used by the X libraries themselves *isn't* > convincing. This is not an issue of space, but of having the choice not to install the X libs. -- Pat From aph at redhat.com Fri Mar 9 18:27:39 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:27:39 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <1173463530.30268.37.camel@junko.usersys.redhat.com> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> <17905.41168.619070.622134@zebedee.pink> <1173463530.30268.37.camel@junko.usersys.redhat.com> Message-ID: <17905.42779.17112.430690@zebedee.pink> John Dennis writes: > On Fri, 2007-03-09 at 18:00 +0000, Andrew Haley wrote: > > Jesse Keating writes: > > > On Friday 09 March 2007 12:39:16 Andrew Haley wrote: > > > > Me too. I'd like to continue to use Fedora on headless servers. > > > > > > Specifically with out the few megs that X libs would require? You can still > > > run emacs with the option to not do graphical. > > > > I suppose so, but it would be odd after installing suddenly to > > discover a bunch of X libraries. > > > > -- "What the hell are these libraries for? I didn't ask for them!" > > > > -- "Well, it's all because of the way rpmlint works." > > > > -- "Sorry? Say that again..." > > No, you're missing the point. This is not about rpmlint, the issue is > two packages cannot own the same file. I thought they could, as long as the files were the identical. And, at the present time, the file /usr/bin/emacs does not cause a conflict. As fasr as I've been told, the problem is that rpmlint gets confused, not that there really is a conflict. Andrew. From jkeating at redhat.com Fri Mar 9 18:32:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 13:32:59 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17905.42779.17112.430690@zebedee.pink> References: <1173463530.30268.37.camel@junko.usersys.redhat.com> <17905.42779.17112.430690@zebedee.pink> Message-ID: <200703091332.59371.jkeating@redhat.com> On Friday 09 March 2007 13:27:39 Andrew Haley wrote: > I thought they could, as long as the files were the identical. ?And, > at the present time, the file /usr/bin/emacs does not cause a > conflict. If /usr/bin/emacs is exactly the same across the two packages, how does it decide what to launch? On my rawhide install, /usr/bin/emacs is a symlink to /usr/bin/emacs-22.0.93. I can't imagine the emacs-nox package provides a symlink to /usr/bin/emacs-22.0.93. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Fri Mar 9 18:33:45 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 13:33:45 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309181302.GJ25722@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> Message-ID: <20070309183345.GA650@jadzia.bu.edu> On Fri, Mar 09, 2007 at 07:13:02PM +0100, Patrice Dumas wrote: > > > If having a fedora box without X installed but still functionnal is not > > > convincing I don't know where we are heading. > > As mentioned, you don't need to have an X server installed. The argument for > > saving the few megs of disk space used by the X libraries themselves *isn't* > > convincing. > This is not an issue of space, but of having the choice not to install > the X libs. Which isn't, as I said, very convincing. They're not running as root, and they're not installed setuid, they need to don't do wacky things with memory and hardware access, etc. -- in short, they don't fall under the basic reasons for wanting to avoid installing X. They're just some more libraries, nothing special to worry about. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From aph at redhat.com Fri Mar 9 18:35:22 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:35:22 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <200703091332.59371.jkeating@redhat.com> References: <1173463530.30268.37.camel@junko.usersys.redhat.com> <17905.42779.17112.430690@zebedee.pink> <200703091332.59371.jkeating@redhat.com> Message-ID: <17905.43242.507518.326634@zebedee.pink> Jesse Keating writes: > On Friday 09 March 2007 13:27:39 Andrew Haley wrote: > > I thought they could, as long as the files were the identical. ?And, > > at the present time, the file /usr/bin/emacs does not cause a > > conflict. > > If /usr/bin/emacs is exactly the same across the two packages, how does it > decide what to launch? zebedee:~/.Trash $ cat /usr/bin/emacs #!/bin/sh PROG_NAME=`basename $0` for i in x nox; do [ -x "/usr/bin/${PROG_NAME}-$i" ] && exec -a ${PROG_NAME} /usr/bin/${PROG_NAME}-$i "$@" done echo "Can't find $PROG_NAME" 1>&2 exit 1 From jdennis at redhat.com Fri Mar 9 18:48:26 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Mar 2007 13:48:26 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <17905.42779.17112.430690@zebedee.pink> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> <17905.41168.619070.622134@zebedee.pink> <1173463530.30268.37.camel@junko.usersys.redhat.com> <17905.42779.17112.430690@zebedee.pink> Message-ID: <1173466106.30268.47.camel@junko.usersys.redhat.com> On Fri, 2007-03-09 at 18:27 +0000, Andrew Haley wrote: > John Dennis writes: > > No, you're missing the point. This is not about rpmlint, the issue is > > two packages cannot own the same file. > > I thought they could, as long as the files were the identical. And, > at the present time, the file /usr/bin/emacs does not cause a > conflict. Is that true? Files are not considered conflicts by RPM if they are identical? If two packages own the same file is RPM smart enough to not remove the file until no package owns it? What happens when multiple packages own the same file, but one of the packages which owns the file is newly installed/updated and it changes the file as compared to the other owners? Sounds to me like a recipe for problems. Note, I'm not saying this would happen in the emacs case, just that it sounds like a mine field in general. BTW, multiple owners of directories is another issue altogether. -- John Dennis From aph at redhat.com Fri Mar 9 18:55:21 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Mar 2007 18:55:21 +0000 Subject: emacs and /etc/alternatives In-Reply-To: <1173462658.30268.30.camel@junko.usersys.redhat.com> References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> Message-ID: <17905.44441.452268.33434@zebedee.pink> John Dennis writes: > > To get us to a situation where there can be two versions of emacs (a > reasonable goal) we have the following choices: > > * have a package which owns /usr/bin/emacs and install a script to start > the preferred version. emacs and emacs-nox both require this package. That's an OK solution. > * use alternatives (yuck!), I don't think it's appropriate for this > purpose and its just plain nasty, but it solves the file conflict > problem. That's an OK solution too. Andrew. From pertusus at free.fr Fri Mar 9 18:53:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 19:53:05 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <20070309183345.GA650@jadzia.bu.edu> References: <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> <20070309183345.GA650@jadzia.bu.edu> Message-ID: <20070309185305.GL25722@free.fr> On Fri, Mar 09, 2007 at 01:33:45PM -0500, Matthew Miller wrote: > > Which isn't, as I said, very convincing. They're not running as root, and > they're not installed setuid, they need to don't do wacky things with memory > and hardware access, etc. -- in short, they don't fall under the basic > reasons for wanting to avoid installing X. They're just some more libraries, > nothing special to worry about. They are unusefull code lying around which is better avoided when possible. Less code installed less issues to worry about. Of course having an X server lying around would be even worse. -- Pat From jkeating at redhat.com Fri Mar 9 18:58:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 13:58:58 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173466106.30268.47.camel@junko.usersys.redhat.com> References: <17905.42779.17112.430690@zebedee.pink> <1173466106.30268.47.camel@junko.usersys.redhat.com> Message-ID: <200703091358.58884.jkeating@redhat.com> On Friday 09 March 2007 13:48:26 John Dennis wrote: > Is that true? Files are not considered conflicts by RPM if they are > identical? by-product of multilib stuff I think. > If two packages own the same file is RPM smart enough to not remove the > file until no package owns it? Supposed to be. In practice...? > What happens when multiple packages own the same file, but one of the > packages which owns the file is newly installed/updated and it changes > the file as compared to the other owners? Sounds to me like a recipe for > problems. Right, there are lots of 'unknowns' around here. I hate to say it, but to accomplish the goal that Chip and others have, alternatives may be the best way to go about it, no matter how fugly alternatives is :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Mar 9 19:02:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 11:02:13 -0800 Subject: emacs and /etc/alternatives In-Reply-To: References: <1173460693.3329.175.camel@localhost.localdomain> <200703091233.12990.jkeating@redhat.com> <1173462658.30268.30.camel@junko.usersys.redhat.com> <1173463657.3329.188.camel@localhost.localdomain> Message-ID: <1173466933.3329.203.camel@localhost.localdomain> On Fri, 2007-03-09 at 13:11 -0500, Chip Coldwell wrote: > On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > > > > Ugh. Is that the rpmlint warning that this is all about? You already > > have an emacs-common package for files shared between emacs with x and > > emacs without x. Move the /usr/bin/emacs script into the emacs-common > > package and have done already. > > That leads to a circular dependency. The shell script requires that one > of the two "emacs" and "emacs-nox" packages be installed. If emacs-common > requires one of those two, and they each require emacs-common .... > I don't believe circular depenencies per se are problems. Certain instances are. (Someone please correct me if I'm wrong, here.) In this case, breaking out the dependency into a virtual provides would be the standard way to show that emacs-common requires one of /usr/bin/emacs-x or /usr/bin/emacs-nox. ### Main package is old emacs-common Requires: binemacs = %{version}-%{release} %package x Provides: binemacs = %{version}-%{release} Requires: %{name} = %{version}-%{release} %package nox Provides: binemacs = %{version}-%{release} Requires: %{name} = %{version}-%{release} s/binemacs/WhateverVirtualProvideStrikesYourFancy/ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Fri Mar 9 18:53:42 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 09 Mar 2007 13:53:42 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309185305.GL25722@free.fr> References: <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> <20070309183345.GA650@jadzia.bu.edu> <20070309185305.GL25722@free.fr> Message-ID: <1173466422.20555.14.camel@localhost.localdomain> On Fri, 2007-03-09 at 19:53 +0100, Patrice Dumas wrote: > On Fri, Mar 09, 2007 at 01:33:45PM -0500, Matthew Miller wrote: > > > > Which isn't, as I said, very convincing. They're not running as root, and > > they're not installed setuid, they need to don't do wacky things with memory > > and hardware access, etc. -- in short, they don't fall under the basic > > reasons for wanting to avoid installing X. They're just some more libraries, > > nothing special to worry about. > > They are unusefull code lying around which is better avoided when > possible. Less code installed less issues to worry about. It amazes me that people can say things like this with a straight face when talking about an editor with a built-in Eliza. - ajax From jkeating at redhat.com Fri Mar 9 19:12:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Mar 2007 14:12:29 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173466933.3329.203.camel@localhost.localdomain> References: <1173466933.3329.203.camel@localhost.localdomain> Message-ID: <200703091412.32945.jkeating@redhat.com> On Friday 09 March 2007 14:02:13 Toshio Kuratomi wrote: > I don't believe circular depenencies per se are problems. ?Certain > instances are. ?(Someone please correct me if I'm wrong, here.) ?In this > case, breaking out the dependency into a virtual provides would be the > standard way to show that emacs-common requires one of /usr/bin/emacs-x > or /usr/bin/emacs-nox. > > ### Main package is old emacs-common > Requires: binemacs = %{version}-%{release} > > %package x > Provides: binemacs = %{version}-%{release} > Requires: %{name} = %{version}-%{release} > > %package nox > Provides: binemacs = %{version}-%{release} > Requires: %{name} = %{version}-%{release} > > s/binemacs/WhateverVirtualProvideStrikesYourFancy/ I thought about this, but what stopped me was I kept thinking that one would want to set a preference in the /usr/bin/emacs file, and that would require modification of the file, or an /etc/ file to set preference which led be back to well, we have alternatives.... Of course, if we don't give a care what /usr/bin/emacs runs, so long as it runs, then we could keep the script as is and use this Provides method and move on. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Fri Mar 9 19:13:29 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 9 Mar 2007 14:13:29 -0500 (Eastern Standard Time) Subject: emacs and /etc/alternatives In-Reply-To: <1173466422.20555.14.camel@localhost.localdomain> References: <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> <20070309183345.GA650@jadzia.bu.edu> <20070309185305.GL25722@free.fr> <1173466422.20555.14.camel@localhost.localdomain> Message-ID: On Fri, 9 Mar 2007, Adam Jackson wrote: > On Fri, 2007-03-09 at 19:53 +0100, Patrice Dumas wrote: > > > > They are unusefull code lying around which is better avoided when > > possible. Less code installed less issues to worry about. > > It amazes me that people can say things like this with a straight face > when talking about an editor with a built-in Eliza. Touche. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From pertusus at free.fr Fri Mar 9 19:12:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 20:12:23 +0100 Subject: emacs and /etc/alternatives In-Reply-To: <1173466422.20555.14.camel@localhost.localdomain> References: <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> <20070309183345.GA650@jadzia.bu.edu> <20070309185305.GL25722@free.fr> <1173466422.20555.14.camel@localhost.localdomain> Message-ID: <20070309191223.GM25722@free.fr> On Fri, Mar 09, 2007 at 01:53:42PM -0500, Adam Jackson wrote: > On Fri, 2007-03-09 at 19:53 +0100, Patrice Dumas wrote: > > On Fri, Mar 09, 2007 at 01:33:45PM -0500, Matthew Miller wrote: > > > > > > Which isn't, as I said, very convincing. They're not running as root, and > > > they're not installed setuid, they need to don't do wacky things with memory > > > and hardware access, etc. -- in short, they don't fall under the basic > > > reasons for wanting to avoid installing X. They're just some more libraries, > > > nothing special to worry about. > > > > They are unusefull code lying around which is better avoided when > > possible. Less code installed less issues to worry about. > > It amazes me that people can say things like this with a straight face > when talking about an editor with a built-in Eliza. ;-) -- Pat From a.badger at gmail.com Fri Mar 9 22:17:40 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 14:17:40 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <200703091412.32945.jkeating@redhat.com> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> Message-ID: <1173478660.3329.217.camel@localhost.localdomain> On Fri, 2007-03-09 at 14:12 -0500, Jesse Keating wrote: > On Friday 09 March 2007 14:02:13 Toshio Kuratomi wrote: > > I don't believe circular depenencies per se are problems. Certain > > instances are. (Someone please correct me if I'm wrong, here.) In this > > case, breaking out the dependency into a virtual provides would be the > > standard way to show that emacs-common requires one of /usr/bin/emacs-x > > or /usr/bin/emacs-nox. > > > > ### Main package is old emacs-common > > Requires: binemacs = %{version}-%{release} > > > > %package x > > Provides: binemacs = %{version}-%{release} > > Requires: %{name} = %{version}-%{release} > > > > %package nox > > Provides: binemacs = %{version}-%{release} > > Requires: %{name} = %{version}-%{release} > > > > s/binemacs/WhateverVirtualProvideStrikesYourFancy/ > > I thought about this, but what stopped me was I kept thinking that one would > want to set a preference in the /usr/bin/emacs file, and that would require > modification of the file, or an /etc/ file to set preference which led be > back to well, we have alternatives.... > > Of course, if we don't give a care what /usr/bin/emacs runs, so long as it > runs, then we could keep the script as is and use this Provides method and > move on. As we've seen from the discussion about alternatives setting the preference at the wrong level; setting the preference in /usr/bin/emacs is pushing a user-preference out to the system where it doesn't belong. We want the user to set the preference. The script needs slight modification to have a preferred value passed in via ENV VAR. #!/bin/sh PROG_NAME=`basename $0` for i in $PREFERRED_EMACS x nox; do [ -x "/usr/bin/${PROG_NAME}-$i" ] && exec -a ${PROG_NAME} /usr/bin/${PROG_NAME}-$i "$@" done echo "Can't find $PROG_NAME" 1>&2 exit 1 The user can set PREFERRED_EMACS to x or nox or kde or wx or whatever interfaces the future GNU emacs supports. If its installed on this system, it'll be invoked, else the script falls back to looking for an emacs to run. If there were a multitude of options, you could even set your own fallback order. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cworth at redhat.com Sat Mar 10 00:32:31 2007 From: cworth at redhat.com (Carl Worth) Date: Fri, 09 Mar 2007 16:32:31 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <1173478660.3329.217.camel@localhost.localdomain> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> <1173478660.3329.217.camel@localhost.localdomain> Message-ID: <87hcsu9bvk.wl%cworth@cworth.org> On Fri, 09 Mar 2007 14:17:40 -0800, Toshio Kuratomi wrote: > The user can set PREFERRED_EMACS to x or nox or kde or wx or whatever > interfaces the future GNU emacs supports. If its installed on this > system, it'll be invoked, else the script falls back to looking for an > emacs to run. > > If there were a multitude of options, you could even set your own > fallback order. And people have complained about /etc/alternatives as being "unclean" somehow? What possible benefit is there to re-inventing all of its functionality on a package-by-package basis like this? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Sat Mar 10 00:35:04 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 9 Mar 2007 17:35:04 -0700 Subject: emacs and /etc/alternatives In-Reply-To: <1173478660.3329.217.camel@localhost.localdomain> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> <1173478660.3329.217.camel@localhost.localdomain> Message-ID: <20070309173504.02426ed0@ghistelwchlohm.scrye.com> On Fri, 09 Mar 2007 14:17:40 -0800 a.badger at gmail.com (Toshio Kuratomi) wrote: At the risk of adding to a already too lengthy discussion... > As we've seen from the discussion about alternatives setting the > preference at the wrong level; setting the preference > in /usr/bin/emacs is pushing a user-preference out to the system > where it doesn't belong. We want the user to set the preference. The > script needs slight modification to have a preferred value passed in > via ENV VAR. ...snipp script... Instead of re-inventing something like this, how about using the already existing "environment-modules" package? http://modules.sourceforge.net/ A lot of places already use this in cluster sites or sites with lots of users that need different gcc, etc. You could have emacs-nox put in a default module, if emacs-x11 was installed it could change the default, but in the end, the user could change what they would prefer to run from the choices available to them installed by their sysadmin. I haven't used modules extensively, so I might be missing why it won't work in this case, but I thought I would throw the idea out there. > -Toshio kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Sat Mar 10 00:59:30 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 9 Mar 2007 17:59:30 -0700 Subject: FE Package Status of Mar 9, 2007 In-Reply-To: <20070309142834.7ea3f83c@ludwig-alpha.unil.ch> References: <20070309142834.7ea3f83c@ludwig-alpha.unil.ch> Message-ID: <20070309175930.3dcbbba4@ghistelwchlohm.scrye.com> On Fri, 9 Mar 2007 14:28:34 +0100 Christian.Iseli at licr.org (Christian Iseli) wrote: > Hi folks, > > Here is the package status update... The number of unavailable > packages seems to be increasing for some reason... You mean "Packages not present in the development repo" ? Many of these look like merge requests that are not yet imported over to the formerly extras CVS I think... > Question 1: should this rather be posted to fedora-devel ? I don't know. It might generate more comment there or get people interested in helping to fix problems that show up in the report... > Question 2: should the /Extras be dropped from the wiki path ? Yeah, but once we move all the wiki stuff around. I would leave it until then. Thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Sat Mar 10 01:21:15 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 17:21:15 -0800 Subject: emacs and /etc/alternatives In-Reply-To: <87hcsu9bvk.wl%cworth@cworth.org> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> <1173478660.3329.217.camel@localhost.localdomain> <87hcsu9bvk.wl%cworth@cworth.org> Message-ID: <1173489675.3329.227.camel@localhost.localdomain> On Fri, 2007-03-09 at 16:32 -0800, Carl Worth wrote: > On Fri, 09 Mar 2007 14:17:40 -0800, Toshio Kuratomi wrote: > > The user can set PREFERRED_EMACS to x or nox or kde or wx or whatever > > interfaces the future GNU emacs supports. If its installed on this > > system, it'll be invoked, else the script falls back to looking for an > > emacs to run. > > > > If there were a multitude of options, you could even set your own > > fallback order. > > And people have complained about /etc/alternatives as being "unclean" > somehow? > > What possible benefit is there to re-inventing all of its > functionality on a package-by-package basis like this? > There's no benefit to solving it package by package but alternatives doesn't solve it at all. alternatives takes a user preference and makes it a system preference. However you solve this, do it in a way that the user can select their preferred version. BTW, in case it wasn't clear, my change is the addition of one variable on one line over what is currently in the emacs package. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Sat Mar 10 02:14:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 21:14:34 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173478660.3329.217.camel@localhost.localdomain> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> <1173478660.3329.217.camel@localhost.localdomain> Message-ID: <20070310021434.GA5195@jadzia.bu.edu> On Fri, Mar 09, 2007 at 02:17:40PM -0800, Toshio Kuratomi wrote: > We want the user to set the preference. The script needs slight > modification to have a preferred value passed in via ENV VAR. Well, the argument that emacs-nox has a benefit over emacs -nw may have some merit on a system-wide basis, but is almost zero on a per-user basis. The script should clearly prefer the X version if available, because then it's easy to set a per-user preference via `alias emacs='emacs -nw'`. I don't think introducing a Fedora-specific environment variable really helps anything. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ed at eh3.com Sat Mar 10 02:31:54 2007 From: ed at eh3.com (Ed Hill) Date: Fri, 9 Mar 2007 21:31:54 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309173504.02426ed0@ghistelwchlohm.scrye.com> References: <1173466933.3329.203.camel@localhost.localdomain> <200703091412.32945.jkeating@redhat.com> <1173478660.3329.217.camel@localhost.localdomain> <20070309173504.02426ed0@ghistelwchlohm.scrye.com> Message-ID: <20070309213154.47954bc3@ernie> On Fri, 9 Mar 2007 17:35:04 -0700 Kevin Fenzi wrote: > On Fri, 09 Mar 2007 14:17:40 -0800 > a.badger at gmail.com (Toshio Kuratomi) wrote: > > At the risk of adding to a already too lengthy discussion... > > > As we've seen from the discussion about alternatives setting the > > preference at the wrong level; setting the preference > > in /usr/bin/emacs is pushing a user-preference out to the system > > where it doesn't belong. We want the user to set the preference. > > The script needs slight modification to have a preferred value > > passed in via ENV VAR. > > ...snipp script... > > Instead of re-inventing something like this, how about using the > already existing "environment-modules" package? > http://modules.sourceforge.net/ > > A lot of places already use this in cluster sites or sites with lots > of users that need different gcc, etc. > > You could have emacs-nox put in a default module, if emacs-x11 was > installed it could change the default, but in the end, the user could > change what they would prefer to run from the choices available to > them installed by their sysadmin. > > I haven't used modules extensively, so I might be missing why it won't > work in this case, but I thought I would throw the idea out there. Yes !!! Unlike alternatives (which is system-oriented), environment-modules is user-oriented. It solves exactly the sort of user-oriented (and multiple-user-oriented) problems that alternatives just can't. As mentioned above, its *so* convenient for cases involving, for example, multiple MPI or compiler or other tool installations. It allows *EACH* user to, at any point in time, select the version of each tool that they want. So please folks -- take a good look at environment-modules before re-inventing that particular wheel. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Sat Mar 10 03:08:02 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 09 Mar 2007 22:08:02 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <877itqraco.fsf@fc5.bigo.ensc.de> References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> Message-ID: <1173496082.3466.17.camel@localhost.localdomain> On Fri, 2007-03-09 at 11:15 +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> > But for whatever its worth let's raise the fixed/non-fixed > >> > cross-over from uid/gid 100 to 200 for F8 or F9. > >> > >> I suggest 500-999; should not break LSB more than the 100-200 idea. But > >> reuid'ing normal users is much easier than doing this for services. > > > > We can only mess with below 500. > > to be more exact: below 100 > > > > Moving the bar from 100 to 200/anything will already break > > applications that randomly were allocated to some uid there, and this > > needs to be fixed per package, that's why we need a F8/F9 timeframe > > for doing that. > > Why do we want to break existing installations overall? We could use > exisisting solutions like fedora-usermgmt after ironing out documentation > issues. Why do we need fixed uids at all? is it so difficult to use getpwnam() ?? > When my shadow-utils patch gets accepted, shadow-util's '--hint' option > can be used too. I don't see grabbing random areas above 500 to serve any useful purpose, if they are not fixed, than you can easily just do dynamic allocation, from the app point of view it is exactly the same. I really do not understand what you think you fix by creating a range variable fixed scheme. Either an application needs a fixed uid/gid for some particular reason or it just can allocate an uid/gid dynamically. So where is really the problem?? Simo. From mattdm at mattdm.org Sat Mar 10 03:12:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 22:12:42 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173496082.3466.17.camel@localhost.localdomain> References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> Message-ID: <20070310031242.GA10735@jadzia.bu.edu> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > Why do we need fixed uids at all? is it so difficult to use > getpwnam() ?? Because the name isn't stored on the filesystem; just the number. Anything which owns files rather than just running as the given username should have a fixed UID. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ssorce at redhat.com Sat Mar 10 03:20:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 09 Mar 2007 22:20:58 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <20070309181302.GJ25722@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <1173460693.3329.175.camel@localhost.localdomain> <20070309173500.GA26593@jadzia.bu.edu> <20070309173715.GG25722@free.fr> <20070309180252.GB28399@jadzia.bu.edu> <20070309181302.GJ25722@free.fr> Message-ID: <1173496858.3466.19.camel@localhost.localdomain> On Fri, 2007-03-09 at 19:13 +0100, Patrice Dumas wrote: > On Fri, Mar 09, 2007 at 01:02:52PM -0500, Matthew Miller wrote: > > On Fri, Mar 09, 2007 at 06:37:15PM +0100, Patrice Dumas wrote: > > > > But, not very convincing ones. :) > > > If having a fedora box without X installed but still functionnal is not > > > convincing I don't know where we are heading. > > > > As mentioned, you don't need to have an X server installed. The argument for > > saving the few megs of disk space used by the X libraries themselves *isn't* > > convincing. > > This is not an issue of space, but of having the choice not to install > the X libs. What about the choice of not installing the glibc? Please can you provide me only statically compiled binaries ? :-) From ssorce at redhat.com Sat Mar 10 03:27:12 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 09 Mar 2007 22:27:12 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <20070310031242.GA10735@jadzia.bu.edu> References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> Message-ID: <1173497232.3466.22.camel@localhost.localdomain> On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > > Why do we need fixed uids at all? is it so difficult to use > > getpwnam() ?? > > Because the name isn't stored on the filesystem; just the number. It does not matter unless the application must be able to run with /etc/passwd being absent. > Anything which owns files rather than just running as the given > username should have a fixed UID. Why? Simo. From notting at redhat.com Sat Mar 10 03:36:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Mar 2007 22:36:39 -0500 Subject: emacs and /etc/alternatives In-Reply-To: <1173466106.30268.47.camel@junko.usersys.redhat.com> References: <17905.39876.950488.122070@zebedee.pink> <200703091241.09349.jkeating@redhat.com> <17905.41168.619070.622134@zebedee.pink> <1173463530.30268.37.camel@junko.usersys.redhat.com> <17905.42779.17112.430690@zebedee.pink> <1173466106.30268.47.camel@junko.usersys.redhat.com> Message-ID: <20070310033639.GB23633@nostromo.devel.redhat.com> John Dennis (jdennis at redhat.com) said: > Is that true? Files are not considered conflicts by RPM if they are > identical? Correct. > If two packages own the same file is RPM smart enough to not remove the > file until no package owns it? Correct. > What happens when multiple packages own the same file, but one of the > packages which owns the file is newly installed/updated and it changes > the file as compared to the other owners? Sounds to me like a recipe for > problems. A conflict is raised, IIRC. Generally, the rule should be that two packages can own the same file IFF they're built from the same source package (so they can't get out of sync.) Bill From tgl at redhat.com Sat Mar 10 08:30:34 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 10 Mar 2007 03:30:34 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173497232.3466.22.camel@localhost.localdomain> References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> Message-ID: <9234.1173515434@sss.pgh.pa.us> Simo Sorce writes: > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: >>> Why do we need fixed uids at all? is it so difficult to use >>> getpwnam() ?? >> >> Because the name isn't stored on the filesystem; just the number. > It does not matter unless the application must be able to run > with /etc/passwd being absent. Yes, it does matter, because if you uninstall and reinstall the package then any files that might have been owned by that UID should still be owned by that UID. I run into this quite often with the database packages for instance. (Oh, you didn't want your mysql update to wipe out your database?) regards, tom lane From Axel.Thimm at ATrpms.net Sat Mar 10 09:54:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 10:54:00 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <9234.1173515434@sss.pgh.pa.us> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> Message-ID: <20070310095400.GB17717@neu.nirvana> On Sat, Mar 10, 2007 at 03:30:34AM -0500, Tom Lane wrote: > Simo Sorce writes: > > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > >>> Why do we need fixed uids at all? is it so difficult to use > >>> getpwnam() ?? Indeed, most of the packages we're talking about (if not all) don't need a fixed uid/gid at all. > >> Because the name isn't stored on the filesystem; just the number. > > > It does not matter unless the application must be able to run > > with /etc/passwd being absent. > > Yes, it does matter, because if you uninstall and reinstall the package > then any files that might have been owned by that UID should still be > owned by that UID. I run into this quite often with the database > packages for instance. What databases are you talking about? Because neither mysql, nor postgresql do that horrible things you say they would. > (Oh, you didn't want your mysql update to wipe out your database?) That *is* plain *FUD*. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 10:16:47 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 11:16:47 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310095400.GB17717@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 10:54:00 +0100") References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> Message-ID: <87ejnxflo0.fsf@kosh.bigo.ensc.de> Axel Thimm writes: > Indeed, most of the packages we're talking about (if not all) don't > need a fixed uid/gid at all. When a package/daemon writes files and/or reads files which are protected by file permissions, it is a good candidate for fixed uids. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Mar 10 10:40:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Mar 2007 11:40:55 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310095400.GB17717@neu.nirvana> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> Message-ID: <20070310114055.d89e2cab.bugs.michael@gmx.net> On Sat, 10 Mar 2007 10:54:00 +0100, Axel Thimm wrote: > On Sat, Mar 10, 2007 at 03:30:34AM -0500, Tom Lane wrote: > > Simo Sorce writes: > > > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > > >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > > >>> Why do we need fixed uids at all? is it so difficult to use > > >>> getpwnam() ?? > > Indeed, most of the packages we're talking about (if not all) don't > need a fixed uid/gid at all. Once and for all: if they require a fixed (= constant) uid/gid and still use fedora-usermgmt, the packages are broken. From Axel.Thimm at ATrpms.net Sat Mar 10 11:04:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 12:04:32 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310114055.d89e2cab.bugs.michael@gmx.net> References: <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <20070310114055.d89e2cab.bugs.michael@gmx.net> Message-ID: <20070310110432.GC20977@neu.nirvana> On Sat, Mar 10, 2007 at 11:40:55AM +0100, Michael Schwendt wrote: > On Sat, 10 Mar 2007 10:54:00 +0100, Axel Thimm wrote: > > > On Sat, Mar 10, 2007 at 03:30:34AM -0500, Tom Lane wrote: > > > Simo Sorce writes: > > > > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > > > >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > > > >>> Why do we need fixed uids at all? is it so difficult to use > > > >>> getpwnam() ?? > > > > Indeed, most of the packages we're talking about (if not all) don't > > need a fixed uid/gid at all. > > Once and for all: if they require a fixed (= constant) uid/gid and still > use fedora-usermgmt, the packages are broken. Fully agreed. And if they don't they are more then adequately served by plain useradd. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 11:06:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 12:06:10 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87ejnxflo0.fsf@kosh.bigo.ensc.de> References: <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> Message-ID: <20070310110610.GD20977@neu.nirvana> On Sat, Mar 10, 2007 at 11:16:47AM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > > Indeed, most of the packages we're talking about (if not all) don't > > need a fixed uid/gid at all. > > When a package/daemon writes files and/or reads files which are protected > by file permissions, it is a good candidate for fixed uids. Don't userdel the user. That's all there is to it. Check out httpd, a prominent package which can have sensitive data underneath its user. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 11:19:08 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 12:19:08 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310110610.GD20977@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 12:06:10 +0100") References: <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> Message-ID: <871wjxfis3.fsf@kosh.bigo.ensc.de> Axel Thimm writes: >> > Indeed, most of the packages we're talking about (if not all) don't >> > need a fixed uid/gid at all. >> >> When a package/daemon writes files and/or reads files which are protected >> by file permissions, it is a good candidate for fixed uids. > > Don't userdel the user. ??? When I install a package on machine A and machine B, I do not use 'userdel' overall. > Check out httpd, a prominent package which can have sensitive data > underneath its user. 'httpd' has the comfort to have a really fixed uid < 100... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 11:16:28 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 12:16:28 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173496082.3466.17.camel@localhost.localdomain> (Simo Sorce's message of "Fri, 09 Mar 2007 22:08:02 -0500") References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> Message-ID: <876499fiwj.fsf@kosh.bigo.ensc.de> Simo Sorce writes: > Why do we need fixed uids at all? is it so difficult to use > getpwnam() ?? Most filesystems store only the uid/gid, not the name of a user. >> When my shadow-utils patch gets accepted, shadow-util's '--hint' option >> can be used too. > > I don't see grabbing random areas above 500 to serve any useful > purpose, if they are not fixed, than you can easily just do dynamic > allocation, from the app point of view it is exactly the same. I > really do not understand what you think you fix by creating a range > variable fixed scheme. I create predictable uids; when I install a package which creates user 'foo' on machine A and on machine B, user 'foo' should have the same uid (e.g. because they share filesystem resources). I like it too, to reinstall a system without the need of complicated 'chown -rh' orgies to make huge data partitions from previous installation usable. > Either an application needs a fixed uid/gid for some particular reason > or it just can allocate an uid/gid dynamically. Most daemons are candidates for fixed uid/gid; unfortunately, there is only a small range (0-100) available. 'fedora-usermgmt' *allows* the administrator to use a free range of uids for service users. 'fedora-usermgmt' is completely transparent transparent: either you know about it and use it, or it behaves like a plain 'useradd'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 11:27:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 12:27:15 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <871wjxfis3.fsf@kosh.bigo.ensc.de> References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> Message-ID: <20070310112715.GF20977@neu.nirvana> On Sat, Mar 10, 2007 at 12:19:08PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> > Indeed, most of the packages we're talking about (if not all) don't > >> > need a fixed uid/gid at all. > >> > >> When a package/daemon writes files and/or reads files which are protected > >> by file permissions, it is a good candidate for fixed uids. > > > > Don't userdel the user. > > ??? When I install a package on machine A and machine B, I do not use > 'userdel' overall. "a package/daemon writes files and/or reads files which are protected by file permissions" does not do so by default from machine A to machine B, right? > > Check out httpd, a prominent package which can have sensitive data > > underneath its user. > > 'httpd' has the comfort to have a really fixed uid < 100... Even if not, it would not relocate the uid because it simply does not delete the user when uninstalling. See nx or torrent for similar examples with non-fixed uid. We *do* have methods for dealing with both fixed and non-fixed uids. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 11:45:36 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 12:45:36 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310112715.GF20977@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 12:27:15 +0100") References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> Message-ID: <87wt1pe2zj.fsf@kosh.bigo.ensc.de> Axel Thimm writes: >> >> When a package/daemon writes files and/or reads files which are protected >> >> by file permissions, it is a good candidate for fixed uids. >> > >> > Don't userdel the user. >> >> ??? When I install a package on machine A and machine B, I do not use >> 'userdel' overall. > > "a package/daemon writes files and/or reads files which are protected > by file permissions" does not do so by default from machine A to > machine B, right? Perhaps not "by default"; but this package might be used in a setup which shares network resources betwen A and B. >> > Check out httpd, a prominent package which can have sensitive data >> > underneath its user. >> >> 'httpd' has the comfort to have a really fixed uid < 100... > > Even if not, it would not relocate the uid because it simply does not > delete the user when uninstalling. I do not see why you want to delete the user resp. why you are speaking about this. Problem happens when 'httpd' has uid 100 on A, uid 101 on B and both are using a common, NFS-shared /srv/www. Or, when /srv/www is on the local machine, contains an huge amount of data, and the system must be reinstalled for some reason. 'fedora-usermgmt' solves this problem by allowing the adminstrator to use a fixed window for daemon uids. With this setup, 'httpd' will have same uid on machine A and B, and after the reinstallation. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 12:04:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 13:04:01 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87wt1pe2zj.fsf@kosh.bigo.ensc.de> References: <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> Message-ID: <20070310120401.GA23762@neu.nirvana> On Sat, Mar 10, 2007 at 12:45:36PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> >> When a package/daemon writes files and/or reads files which are protected > >> >> by file permissions, it is a good candidate for fixed uids. > >> > > >> > Don't userdel the user. > >> > >> ??? When I install a package on machine A and machine B, I do not use > >> 'userdel' overall. > > > > "a package/daemon writes files and/or reads files which are protected > > by file permissions" does not do so by default from machine A to > > machine B, right? > > Perhaps not "by default"; but this package might be used in a setup > which shares network resources betwen A and B. Ok, let's bite. Please name a couple that would be candiates for doing so. Looking at the package registry for fedora-useradd I don't see anything but perhaps twiki that would use shared networked folders (and I'm not even sure about twiki either). For example having clamav using a shared networked database for virus signatures is out of question. Or zaptel would never mount its device nodes from another machine. If there are *real* use cases for sharing data across machines the packager should request a fixed uid/gid. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sat Mar 10 12:05:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Mar 2007 07:05:03 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <876499fiwj.fsf@kosh.bigo.ensc.de> References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <876499fiwj.fsf@kosh.bigo.ensc.de> Message-ID: <20070310120503.GA13774@jadzia.bu.edu> On Sat, Mar 10, 2007 at 12:16:28PM +0100, Enrico Scholz wrote: > Most daemons are candidates for fixed uid/gid; unfortunately, there is > only a small range (0-100) available. 'fedora-usermgmt' *allows* the > administrator to use a free range of uids for service users. The main problems I see are 1) the package portability annoyance and 2) the serious issue of how to configure it *before* installation. To solve #2, we need to have a static registry (i.e. preconfigure the package), and if we're doing that, we might as well do away with it completely. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 12:18:32 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 13:18:32 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310120503.GA13774@jadzia.bu.edu> (Matthew Miller's message of "Sat, 10 Mar 2007 07:05:03 -0500") References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <876499fiwj.fsf@kosh.bigo.ensc.de> <20070310120503.GA13774@jadzia.bu.edu> Message-ID: <87slcde1gn.fsf@kosh.bigo.ensc.de> Matthew Miller writes: >> Most daemons are candidates for fixed uid/gid; unfortunately, there is >> only a small range (0-100) available. 'fedora-usermgmt' *allows* the >> administrator to use a free range of uids for service users. > > The main problems I see are 1) the package portability annoyance and The '--hint' patch for useradd should remove the need for 'Requires(): fedora-usermgmt'. But it will require further changes to the shadow-utils package and perhaps anaconda to solve your point 2. > 2) the serious issue of how to configure it *before* installation. https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00793.html In short: you do not have to change or remove anything but have to add a new package which is installed instead of the 'fedora-usermgmt-default-fedora-setup' package. Sure, it will be possible to make the hint-translator configurable in other, not 'alternatives' using ways. I am open for suggestions there. > To solve #2, we need to have a static registry (i.e. preconfigure the > package), and if we're doing that, we might as well do away with it > completely. How? There is no way to determine whether next nighly 'yum upgrade' will install a previously unknown user and to do the required steps to create this user. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From opensource at till.name Sat Mar 10 12:30:49 2007 From: opensource at till.name (Till Maas) Date: Sat, 10 Mar 2007 13:30:49 +0100 Subject: virtualbox - automatically loaded kernel module Message-ID: <200703101331.00320.opensource@till.name> Aloas, I am building a spec file for virtualbox, which is an emulations software like vmware. It needs its own kernel module loaded, before it starts. Should I write an initscript for this that loads the module when booted or is it somehow possible to configure which modules should be loaded at bootime? Or even only whenever someone tries to access it? Or this this something that needs to be programmed into the module / application, because for kqemu it works this way afaik. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 12:34:09 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 13:34:09 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310120401.GA23762@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 13:04:01 +0100") References: <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> Message-ID: <87odn1e0qm.fsf@kosh.bigo.ensc.de> Axel Thimm writes: >> >> >> When a package/daemon writes files and/or reads files which are >> >> >> protected by file permissions, it is a good candidate for fixed >> >> >> uids. > ... > Ok, let's bite. Please name a couple that would be candiates for doing > so. * The *milt* and defang users; they are using unix sockets shared between several vservers. * fnord (http server), twiki, tclhttpd sounds like a candidate I do not know the other applications; but I can not exclude that there exist a setup where they might share network resources. 'fedora-usermgmt' deals both with users who must have predictable uids, who need predictable uids under some circumstances and who never need predictable uids (although: say never "never"). Its flaws (causes lot of discussion, is proprietary, nobody else uses it) are of non-technical nature and negligible and I do not see why it should not be used for all users. > If there are *real* use cases for sharing data across machines the > packager should request a fixed uid/gid. I am really in doubt that the remaining free entries < 100 are enough. And when can a uid be reserved there? When there is at least 1 installation which needs a predictable uid, when there are 10, 100, 1000? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tjanouse at redhat.com Sat Mar 10 12:49:07 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 13:49:07 +0100 Subject: vim and /etc/alternatives In-Reply-To: <1173455877.20555.3.camel@localhost.localdomain> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> Message-ID: <20070310124907.GA22861@redhat.com> Hi, On Fri, Mar 09, 2007 at 10:57:57AM -0500, Adam Jackson wrote: > The one major reason to not want X support in your editor is so you > don't block on the XOpenDisplay, which can take much longer than you > want when using ssh with a forwarded display. But I'd assert that the > right way to fix that is to teach vim about xcb so the open can fail > asynchronously. I want vim to open an X connection over forwarded X. And it does not fail. Also, I don't say that it should be the default, I just want to be able to have vim symlinked to gvim binary without having to use ugly hacks. -- TJ., BaseOS, Brno, CZ From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 12:50:54 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 13:50:54 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87slcde1gn.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 10 Mar 2007 13:18:32 +0100") References: <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <876499fiwj.fsf@kosh.bigo.ensc.de> <20070310120503.GA13774@jadzia.bu.edu> <87slcde1gn.fsf@kosh.bigo.ensc.de> Message-ID: <87k5xpdzyp.fsf@kosh.bigo.ensc.de> Enrico Scholz writes: >> 2) the serious issue of how to configure it *before* installation. > > https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00793.html > > In short: you do not have to change or remove anything but have to add a > new package which is installed instead of the > 'fedora-usermgmt-default-fedora-setup' package. See http://ensc.de/fedora/fedora-usermgmt-my.spec for an example. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From pertusus at free.fr Sat Mar 10 12:52:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 13:52:59 +0100 Subject: vim and /etc/alternatives In-Reply-To: <20070310124907.GA22861@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> <20070310124907.GA22861@redhat.com> Message-ID: <20070310125259.GE3153@free.fr> On Sat, Mar 10, 2007 at 01:49:07PM +0100, Tomas Janousek wrote: > I want vim to open an X connection over forwarded X. And it does not fail. Why do you want that? vim is a console app, it just needs a terminal. > Also, I don't say that it should be the default, I just want to be able to > have vim symlinked to gvim binary without having to use ugly hacks. Why don't you want to use gvim for gvim and vim for the console vim? There are 2 different apps with different names, what is the problem? -- Pat From Axel.Thimm at ATrpms.net Sat Mar 10 13:03:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 14:03:02 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87odn1e0qm.fsf@kosh.bigo.ensc.de> References: <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> Message-ID: <20070310130302.GA26349@neu.nirvana> On Sat, Mar 10, 2007 at 01:34:09PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > >> >> >> When a package/daemon writes files and/or reads files which are > >> >> >> protected by file permissions, it is a good candidate for fixed > >> >> >> uids. > > ... > > Ok, let's bite. Please name a couple that would be candiates for doing > > so. > > * The *milt* and defang users; they are using unix sockets shared between > several vservers. vservers and chroots? Is this what this is all about? I'd say whoever setups vservers and chroots *himself* and keeps different passwd/group files across them should be able to deal with this. And this is really a very, tiny, infinitesimal small group of users. > * fnord (http server), twiki, tclhttpd sounds like a candidate For what it's worth, most http content is not placed under ownership of apache or similar, but under a different user's id. So even here this would need further investigation. twiki for example places its contents in a versioned db, and I don't even know if it supports multiple concurrent frontends. I know mediawiki for example doesn't (and doesn't even need a uid of its own either). > 'fedora-usermgmt' deals both with users who must have predictable uids, > who need predictable uids under some circumstances and who never need > predictable uids (although: say never "never"). Its flaws (causes lot of > discussion, is proprietary, nobody else uses it) are of non-technical > nature and negligible and I do not see why it should not be used for all > users. That's your POV. Exactly a year ago there was the same discussion about it draining brain power and volunteer time. And if we don't get it resolved again, we'll be reevaluating this next year again. > > If there are *real* use cases for sharing data across machines the > > packager should request a fixed uid/gid. > > I am really in doubt that the remaining free entries < 100 are enough. And > when can a uid be reserved there? When there is at least 1 installation > which needs a predictable uid, when there are 10, 100, 1000? Since we can't count it, it needs to be weighted on a case by case basis. But keep in mind, that we passed the 2 mio marker, so even 1000 users make 0.05%, and I doubt that 1000 users are even aware of fedora-usermgmt. I guess the number of admins using this mechanism is far less than 100, maybe even only you. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjanouse at redhat.com Sat Mar 10 13:09:59 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 14:09:59 +0100 Subject: vim and /etc/alternatives In-Reply-To: <1173460086.3329.168.camel@localhost.localdomain> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173460086.3329.168.camel@localhost.localdomain> Message-ID: <20070310130959.GB22861@redhat.com> Hi, On Fri, Mar 09, 2007 at 09:08:06AM -0800, Toshio Kuratomi wrote: > The vim split has another purpose: To keep the X, perl, and python > libraries off of /. > > We need /bin/vi to run if /usr is not mounted. So we have to compile a > version of vim that doesn't drag in the kitchen sink. http://people.redhat.com/tjanouse/tmp/launchvim.c Probably something like this may do the job? (yeah, I see a huge flame on this, but if they don't want /etc/alternatives, they asked for this!) > Uhm. No it doesn't. I hate how gvim moves the cursor when I click in > it with a mouse (I just want to select the text to paste into evolution > or firefox, not move my editing cursor) and I have three buttons for a > reason :-) (Unlike the vim-minimal split, I understand that vim's > interaction with the mouse is a matter of personal taste.) That's the way how mouse works in vim GUI, that's not my problem. In terminal, you can always just use the shift key. -- TJ., BaseOS, Brno, CZ From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 13:11:28 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 14:11:28 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310130302.GA26349@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 14:03:02 +0100") References: <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> Message-ID: <87fy8ddz0f.fsf@kosh.bigo.ensc.de> Axel Thimm writes: > vservers and chroots? Is this what this is all about? I'd say whoever > setups vservers and chroots *himself* and keeps different passwd/group > files across them should be able to deal with this. I did this. And it was a pain to deal with it. 'fedora-usermgmt' solved this once and forever. > And this is really a very, tiny, infinitesimal small group of users. Dunno; but this group is non-empty. >> 'fedora-usermgmt' deals both with users who must have predictable >> uids, who need predictable uids under some circumstances and who >> never need predictable uids (although: say never "never"). Its flaws >> (causes lot of discussion, is proprietary, nobody else uses it) are >> of non-technical nature and negligible and I do not see why it should >> not be used for all users. > > That's your POV. Exactly a year ago there was the same discussion > about it draining brain power and volunteer time. Yes; there posted lot of people too who never took a look at fedora-usermgmt... :( > Since we can't count it, it needs to be weighted on a case by case > basis. Why not use 'fedora-usermgmt'? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tjanouse at redhat.com Sat Mar 10 13:12:15 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 14:12:15 +0100 Subject: vim and /etc/alternatives In-Reply-To: <20070310125259.GE3153@free.fr> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> <20070310124907.GA22861@redhat.com> <20070310125259.GE3153@free.fr> Message-ID: <20070310131215.GC22861@redhat.com> Zdar, On Sat, Mar 10, 2007 at 01:52:59PM +0100, Patrice Dumas wrote: > Why do you want that? vim is a console app, it just needs a terminal. Because I love the ability to pass huge amounts of text using the X clipboard. > Why don't you want to use gvim for gvim and vim for the console vim? > There are 2 different apps with different names, what is the problem? No, they are not. They are two same apps compiled with different options. And I _do_ want every single command that runs a vim to run the vim-X11 version. -- TJ., BaseOS, Brno, CZ From mattdm at mattdm.org Sat Mar 10 13:13:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Mar 2007 08:13:32 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87odn1e0qm.fsf@kosh.bigo.ensc.de> References: <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> Message-ID: <20070310131332.GA19079@jadzia.bu.edu> On Sat, Mar 10, 2007 at 01:34:09PM +0100, Enrico Scholz wrote: > I am really in doubt that the remaining free entries < 100 are enough. And > when can a uid be reserved there? When there is at least 1 installation > which needs a predictable uid, when there are 10, 100, 1000? We're going to need to go up to 499 sooner or later. Now seems as good a time as any to me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Sat Mar 10 13:20:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Mar 2007 08:20:39 -0500 Subject: vim and /etc/alternatives In-Reply-To: <20070310131215.GC22861@redhat.com> References: <20070310125259.GE3153@free.fr> <20070310131215.GC22861@redhat.com> Message-ID: <200703100820.39443.jkeating@redhat.com> On Saturday 10 March 2007 08:12:15 Tomas Janousek wrote: > Because I love the ability to pass huge amounts of text using the X > clipboard. er, how is this not possible by ssh foo; vim bar in a terminal on your local machine? You still have access to the X clipboard to paste in. For faster pasting you can even do vim ssh://foo/bar.file -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjanouse at redhat.com Sat Mar 10 13:36:29 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 14:36:29 +0100 Subject: vim and /etc/alternatives In-Reply-To: <200703100820.39443.jkeating@redhat.com> References: <20070310125259.GE3153@free.fr> <20070310131215.GC22861@redhat.com> <200703100820.39443.jkeating@redhat.com> Message-ID: <20070310133629.GA24292@redhat.com> Hi, On Sat, Mar 10, 2007 at 08:20:39AM -0500, Jesse Keating wrote: > er, how is this not possible by ssh foo; vim bar in a terminal on your local > machine? You still have access to the X clipboard to paste in. For faster > pasting you can even do vim ssh://foo/bar.file I'm talking about huge amounts of text. Ever looked on the scrollbar of your terminal while vim is running? Also, doing :set paste, paste, :set nopaste is a more work than "*p. And at last -- why the hell does anyone care how I copy my text. I want to have /usr/bin/vim with X compiled in. Full stop. -- TJ., BaseOS, Brno, CZ From Axel.Thimm at ATrpms.net Sat Mar 10 13:51:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 14:51:30 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8ddz0f.fsf@kosh.bigo.ensc.de> References: <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> Message-ID: <20070310135130.GC26349@neu.nirvana> On Sat, Mar 10, 2007 at 02:11:28PM +0100, Enrico Scholz wrote: > > Since we can't count it, it needs to be weighted on a case by case > > basis. > > Why not use 'fedora-usermgmt'? Argh, you removed the context. Because fedora-usermgmt can't solve the issue of fixed uid? And because the smei-static, but almost always random method of fedora-usermgmt would be of no help? Either it makes sense for a package to have a fixed uid/gid or not. There is nothing in between, and all fedora-usermgmt does is ship the packages as random uid allocating pushing any possible problem with needed fixed uids to the users. And please don't start again with predictable vs fixed uid. If an admin really wants a "predictable" uid on his systems for daemon foo he can useradd -u 666 foo before installing a the package. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 14:11:19 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 15:11:19 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310135130.GC26349@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 14:51:30 +0100") References: <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <20070310135130.GC26349@neu.nirvana> Message-ID: <87bqj1dw8o.fsf@kosh.bigo.ensc.de> Axel Thimm writes: > And because the smei-static, but almost always random method of > fedora-usermgmt would be of no help? fedora-usermgmt does not assign random uids; please read how fedora-usermgmt works. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 14:29:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 15:29:06 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <87bqj1dw8o.fsf@kosh.bigo.ensc.de> References: <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <20070310135130.GC26349@neu.nirvana> <87bqj1dw8o.fsf@kosh.bigo.ensc.de> Message-ID: <20070310142906.GA29953@neu.nirvana> On Sat, Mar 10, 2007 at 03:11:19PM +0100, Enrico Scholz wrote: > Axel Thimm writes: > > > And because the smei-static, but almost always random method of > > fedora-usermgmt would be of no help? > > fedora-usermgmt does not assign random uids; please read how > fedora-usermgmt works. Please be as kind as to not remove relevant context! On Sat, Mar 10, 2007 at 02:51:30PM +0100, Axel Thimm wrote: > On Sat, Mar 10, 2007 at 02:11:28PM +0100, Enrico Scholz wrote: > > > Since we can't count it, it needs to be weighted on a case by > > > case basis. > > > > Why not use 'fedora-usermgmt'? > > Argh, you removed the context. Because fedora-usermgmt can't solve > the issue of fixed uid? And because the smei-static, but almost > always random method of fedora-usermgmt would be of no help? Let me clarify: It's not random as per a random number generator chosen, but random as in not-predictable. Maybe non-deterministic and non-predictable would had been the better wording, let's not play games with words, the context was unambiguous (which is why you cutting the context is A Bad Thing): # fedora-useradd 42 -r iwant42 # fedora-useradd 666 -r iwant666 # id -u iwant42; id -u iwant666 103 104 So no gain for a package that really required fixed uid/gid. In fact if it required a fixed uid/gid it would be hosed now. BTW is there an upper limit to what you register with fedora-useradd? What happens if the package wants to register into the user reserved space? Is there any check that my user Bob won't suddenly become the master of the web server or any other accidentally overlapping daemon? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 15:15:39 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 16:15:39 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <20070310142906.GA29953@neu.nirvana> (Axel Thimm's message of "Sat, 10 Mar 2007 15:29:06 +0100") References: <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <20070310135130.GC26349@neu.nirvana> <87bqj1dw8o.fsf@kosh.bigo.ensc.de> <20070310142906.GA29953@neu.nirvana> Message-ID: <873b4ddt9g.fsf@kosh.bigo.ensc.de> Axel Thimm writes: >> Argh, you removed the context. Because fedora-usermgmt can't solve >> the issue of fixed uid? And because the smei-static, but almost >> always random method of fedora-usermgmt would be of no help? > > Let me clarify: It's not random as per a random number generator > chosen, but random as in not-predictable. Maybe non-deterministic and > non-predictable would had been the better wording, let's not play > games with words, the context was unambiguous (which is why you > cutting the context is A Bad Thing): > > # fedora-useradd 42 -r iwant42 > # fedora-useradd 666 -r iwant666 > # id -u iwant42; id -u iwant666 > 103 > 104 Fedora-usermgmt was not configured by you and I can not preconfigure it because there is no free room for the uids. My MUA would not send mails before I set correct values and my /home would not be mounted before I add corresponding /etc/fstab entries either. So I think, a system should be configured before things are evaluated which are only available after configuration. When you would: 1. look for a free uid space in your environment (e.g. 63000-64000) 2. make this know to fedora-usermgmt: | # echo 63000 >/etc/fedora/usermgmt/baseuid | # echo 63000 >/etc/fedora/usermgmt/basegid 3. enable the predictable-mode of fedora-usermgmt | # /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils Then, you will get predictable user <-> uid mappings: | $ for i in athen apadana db mailhost mail-filter www-cache; do \ | ssh root@$i 'export LANG=C; fedora-useradd 1500 -r foobar; id foobar; fedora-userdel foobar'; done | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) | uid=64500(foobar) gid=64500(foobar) groups=64500(foobar) Plain useradd will give unpredictable results | $ for i in athen apadana db mailhost mail-filter www-cache; do \ | ssh root@$i 'export LANG=C; useradd -r foobar; id foobar; userdel foobar'; done | uid=102(foobar) gid=103(foobar) groups=103(foobar) | uid=100(foobar) gid=101(foobar) groups=101(foobar) | uid=100(foobar) gid=101(foobar) groups=101(foobar) | uid=101(foobar) gid=102(foobar) groups=102(foobar) | uid=100(foobar) gid=101(foobar) groups=101(foobar) | uid=100(foobar) gid=101(foobar) groups=101(foobar) (I admit that the test was manipulated by me by adding some users on 'athen' and 'mailhost' ;) > BTW is there an upper limit to what you register with fedora-useradd? Around 500-1000; for my local system I use a policy (window for service uids) of | Service (Fedora RPM-package) 63000-63999 | Service (local RPM-package) 64000-64999 > What happens if the package wants to register into the user reserved > space? Should not happen resp. detected during the review (cry loudly when hint-id is out of order) Else, when fedora-usermgmt tries to override an existing user, it will fail: | $ ssh root at athen "LANG=C fedora-useradd -62495 -r foobar" | useradd: UID 505 is not unique > Is there any check that my user Bob won't suddenly become the master > of the web server or any other accidentally overlapping daemon? ok; when the assigned window is in the middle of the normal user space, this will be a problem indeed. Solutions: * choose a window above UID_MAX (/etc/login.defs) resp. adapt this value. ditto for GID_MAX * teach the tool which creates the users that the window is tabooed Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ssorce at redhat.com Sat Mar 10 15:31:34 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:31:34 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <9234.1173515434@sss.pgh.pa.us> References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> Message-ID: <1173540694.3403.6.camel@localhost.localdomain> On Sat, 2007-03-10 at 03:30 -0500, Tom Lane wrote: > Simo Sorce writes: > > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > >>> Why do we need fixed uids at all? is it so difficult to use > >>> getpwnam() ?? > >> > >> Because the name isn't stored on the filesystem; just the number. > > > It does not matter unless the application must be able to run > > with /etc/passwd being absent. > > Yes, it does matter, because if you uninstall and reinstall the package > then any files that might have been owned by that UID should still be > owned by that UID. I run into this quite often with the database > packages for instance. > > (Oh, you didn't want your mysql update to wipe out your database?) I think that's a packaging error. >From my point of view, once a user is created it should never be deleted. The admin can decide to delete some users by itself. The rationale is that if there are still files owned by that user on the filesystem, the wrong thing is "deleting the user" not "not having a fixed uid". The admin may still want to know after the uninstall what user owned what files and to do that you should leave uid/gid in place so that on ls the admin can see the user/group name. Besides, there are countries (Italy for example, but I think Sarbanes-Oaxley in the US may say something similar) where there are laws that dictate how to manage users and declare that users should never deleted but disabled. So any package that delete the user on removal is going against these policies dictated by laws. If you do not delete the user on removal you don't have this problem at all, and you can happily use dynamic uid allocation. Simo. From ssorce at redhat.com Sat Mar 10 15:33:30 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:33:30 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87ejnxflo0.fsf@kosh.bigo.ensc.de> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> Message-ID: <1173540810.3403.9.camel@localhost.localdomain> On Sat, 2007-03-10 at 11:16 +0100, Enrico Scholz wrote: > Axel Thimm writes: > > > Indeed, most of the packages we're talking about (if not all) don't > > need a fixed uid/gid at all. > > When a package/daemon writes files and/or reads files which are protected > by file permissions, it is a good candidate for fixed uids. Please can you reserve a uid for myself in Fedora, I build packages that read files protected by file permissions, oh btw also reserve an uid for any 6 billion users on the earth that may one day use a Fedora machine, they will surely use packages that read/write files protected by permissions as well :-) From ssorce at redhat.com Sat Mar 10 15:34:33 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:34:33 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <20070310114055.d89e2cab.bugs.michael@gmx.net> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <20070310114055.d89e2cab.bugs.michael@gmx.net> Message-ID: <1173540873.3403.11.camel@localhost.localdomain> On Sat, 2007-03-10 at 11:40 +0100, Michael Schwendt wrote: > On Sat, 10 Mar 2007 10:54:00 +0100, Axel Thimm wrote: > > > On Sat, Mar 10, 2007 at 03:30:34AM -0500, Tom Lane wrote: > > > Simo Sorce writes: > > > > On Fri, 2007-03-09 at 22:12 -0500, Matthew Miller wrote: > > > >> On Fri, Mar 09, 2007 at 10:08:02PM -0500, Simo Sorce wrote: > > > >>> Why do we need fixed uids at all? is it so difficult to use > > > >>> getpwnam() ?? > > > > Indeed, most of the packages we're talking about (if not all) don't > > need a fixed uid/gid at all. > > Once and for all: if they require a fixed (= constant) uid/gid and still > use fedora-usermgmt, the packages are broken. +1 Without flame intentions, I think fedora-usermgmt is simply a bad idea in any possible case. Simo. From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 15:40:52 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 16:40:52 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173540810.3403.9.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 10:33:30 -0500") References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> Message-ID: <87y7m5cdiz.fsf@kosh.bigo.ensc.de> Simo Sorce writes: >> When a package/daemon writes files and/or reads files which are protected >> by file permissions, it is a good candidate for fixed uids. > > Please can you reserve a uid for myself in Fedora, Unless, you are a bot who puts in his two cents, I can not help. fedora-usermgmt handles service users only; for natural persons, the local admin must be contacted. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ssorce at redhat.com Sat Mar 10 15:47:39 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:47:39 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <876499fiwj.fsf@kosh.bigo.ensc.de> References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <876499fiwj.fsf@kosh.bigo.ensc.de> Message-ID: <1173541659.3403.24.camel@localhost.localdomain> On Sat, 2007-03-10 at 12:16 +0100, Enrico Scholz wrote: > Simo Sorce writes: > > > Why do we need fixed uids at all? is it so difficult to use > > getpwnam() ?? > > Most filesystems store only the uid/gid, not the name of a user. Do you read what people write at all? Do you know what getpwnam() do ? > I create predictable uids; when I install a package which creates user > 'foo' on machine A and on machine B, user 'foo' should have the same > uid (e.g. because they share filesystem resources). I like it too, to > reinstall a system without the need of complicated 'chown -rh' orgies > to make huge data partitions from previous installation usable. Your package worsen the problem does not solve it. If I specify 2 different ranges on 2 machines the UID/GID space still do not match, and you have both the problems of a dynamic uid/gid and those of a variable uid/gid. To me, your solution is still plain broken. Instead if you force packages to use A) dynamic uid/gids, B) to not delete user/groups on removal, then you force them to check for the existing user on installation (just in case you do a reinstall. This way all you have to do on machines that have to share the uid/gid space is to synchronized /etc/passwd and /etc/group _before_ you install the packages on the second machine, and the second machine will be automagically ok. And this is the only system the make any sense to me. > > Either an application needs a fixed uid/gid for some particular reason > > or it just can allocate an uid/gid dynamically. > > Most daemons are candidates for fixed uid/gid; unfortunately, there is > only a small range (0-100) available. 'fedora-usermgmt' *allows* the > administrator to use a free range of uids for service users. No, most daemons are not, I am sorry, there is no technical reason for them to have a fixed uid/gid. After this discussion for example I am going to release one of the uid/gid I reserved for the samba packages, because it simply make no sense to reserve it, I can add 2 lines in the spec file to detect the user if it already exist or useradd one on the fly. > 'fedora-usermgmt' is completely transparent transparent: either you know > about it and use it, or it behaves like a plain 'useradd'. Do you realize this phrase means exactly that: fedora-usermgmt == useradd for all practical purposes ? I think it is even a danger for who is aware of it. What happen to your scheme if you reserve 5000-6000 and then it happens that adding normal users you end up going over that space? Any application that rely on fedore-usermgmt at that point will break as it will try to use normal user's uid/gids ... Simo. From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 15:47:59 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 16:47:59 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173540694.3403.6.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 10:31:34 -0500") References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <1173540694.3403.6.camel@localhost.localdomain> Message-ID: <87tzwtcd74.fsf@kosh.bigo.ensc.de> Simo Sorce writes: > I think that's a packaging error. From my point of view, once a user > is created it should never be deleted. Happens automatically e.g. during a reinstallation. E.g. have /srv/data with TiB of data owned by service user A with dynamic uid 234. Something foobars your system (disk error in system partition, somebody deleted /lib, perhaps intrusion) and after reinstallation the user A has suddenly an uid of 198. > Besides, there are countries (Italy for example, but I think > Sarbanes-Oaxley in the US may say something similar) where there > are laws that dictate how to manage users and declare that users > should never deleted but disabled. Without being sure, I think this is about accounts of natural persons but not of service users. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ssorce at redhat.com Sat Mar 10 15:53:39 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:53:39 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87wt1pe2zj.fsf@kosh.bigo.ensc.de> References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> Message-ID: <1173542019.3403.30.camel@localhost.localdomain> On Sat, 2007-03-10 at 12:45 +0100, Enrico Scholz wrote: > Axel Thimm writes: > > "a package/daemon writes files and/or reads files which are protected > > by file permissions" does not do so by default from machine A to > > machine B, right? > > Perhaps not "by default"; but this package might be used in a setup > which shares network resources betwen A and B. sharing resource between machines using protocls like NFSv3 requires planning _from scratch_. You cannot share resources otherwise in any case because real users and groups uid/gids will not match. So the example is simply deceiving and not real. > I do not see why you want to delete the user resp. why you are speaking > about this. Problem happens when 'httpd' has uid 100 on A, uid 101 on B > and both are using a common, NFS-shared /srv/www. > > Or, when /srv/www is on the local machine, contains an huge amount of > data, and the system must be reinstalled for some reason. If you have to reinstall you just keep around /etc/passwd anyway, you don't want to reenter all passwords, and all users and change all permissions on regular user files. Please think of realistic examples. People is willing to discuss this matter but on the ground of reasonable example and arguments. > 'fedora-usermgmt' solves this problem by allowing the adminstrator to > use a fixed window for daemon uids. With this setup, 'httpd' will have > same uid on machine A and B, and after the reinstallation. Sorry to say it, but this is just *BS*, you may have reserved different ranges on the 2 machines, and you are back from start. Your "solution" solves exactly nothing and introduces other problems (see other mails where I detailed what problems it may cause). From ssorce at redhat.com Sat Mar 10 15:56:30 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 10:56:30 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <20070310120401.GA23762@neu.nirvana> References: <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> Message-ID: <1173542190.3403.34.camel@localhost.localdomain> On Sat, 2007-03-10 at 13:04 +0100, Axel Thimm wrote: > On Sat, Mar 10, 2007 at 12:45:36PM +0100, Enrico Scholz wrote: > > Axel Thimm writes: > > > > >> >> When a package/daemon writes files and/or reads files which are protected > > >> >> by file permissions, it is a good candidate for fixed uids. > > >> > > > >> > Don't userdel the user. > > >> > > >> ??? When I install a package on machine A and machine B, I do not use > > >> 'userdel' overall. > > > > > > "a package/daemon writes files and/or reads files which are protected > > > by file permissions" does not do so by default from machine A to > > > machine B, right? > > > > Perhaps not "by default"; but this package might be used in a setup > > which shares network resources betwen A and B. > > Ok, let's bite. Please name a couple that would be candiates for doing > so. Looking at the package registry for fedora-useradd I don't see > anything but perhaps twiki that would use shared networked folders > (and I'm not even sure about twiki either). > > For example having clamav using a shared networked database for virus > signatures is out of question. Or zaptel would never mount its device > nodes from another machine. > > If there are *real* use cases for sharing data across machines the > packager should request a fixed uid/gid. No, if you want to share resources across machines you have to plan it from scratch and use a shared passwd/group database or a network file system like CIFS or NFSv4 that do not depend on local uid/gid space as it transmits a SID/user principal on the wire. Anything else is broken on premises. From ssorce at redhat.com Sat Mar 10 16:04:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 11:04:43 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87fy8ddz0f.fsf@kosh.bigo.ensc.de> References: <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> Message-ID: <1173542683.3403.40.camel@localhost.localdomain> On Sat, 2007-03-10 at 14:11 +0100, Enrico Scholz wrote: > Axel Thimm writes: > > > vservers and chroots? Is this what this is all about? I'd say whoever > > setups vservers and chroots *himself* and keeps different passwd/group > > files across them should be able to deal with this. > > I did this. And it was a pain to deal with it. 'fedora-usermgmt' solved > this once and forever. I don't want to seem willing to attack you personally, but if you didn't think of synchronizing and rationalizing the uid/gid space, _before_ installing your shared environment, then that was just bad planning and poor handling of the process on your side. fedora-usermgmt may hide some of this, but still the bad planning is out there you are basically just hacking up a nasty patch for it. > >> 'fedora-usermgmt' deals both with users who must have predictable > >> uids, who need predictable uids under some circumstances and who > >> never need predictable uids (although: say never "never"). Its flaws > >> (causes lot of discussion, is proprietary, nobody else uses it) are > >> of non-technical nature and negligible and I do not see why it should > >> not be used for all users. > > > > That's your POV. Exactly a year ago there was the same discussion > > about it draining brain power and volunteer time. > > Yes; there posted lot of people too who never took a look at > fedora-usermgmt... :( The mechanism you described says it all, no need to try it, it is very clear what it does, and to many it is the wrong way to "fix" a deployment planning problem in specific situations. > > Since we can't count it, it needs to be weighted on a case by case > > basis. > > Why not use 'fedora-usermgmt'? Cause its base mechanism is logically flawed ? Simo. From ssorce at redhat.com Sat Mar 10 16:16:03 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 11:16:03 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <873b4ddt9g.fsf@kosh.bigo.ensc.de> References: <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <20070310135130.GC26349@neu.nirvana> <87bqj1dw8o.fsf@kosh.bigo.ensc.de> <20070310142906.GA29953@neu.nirvana> <873b4ddt9g.fsf@kosh.bigo.ensc.de> Message-ID: <1173543363.3403.48.camel@localhost.localdomain> On Sat, 2007-03-10 at 16:15 +0100, Enrico Scholz wrote: > Around 500-1000; for my local system I use a policy (window for service > uids) of > > | Service (Fedora RPM-package) 63000-63999 > | Service (local RPM-package) 64000-64999 Again its a local policy, bad planning can hose this up as well and you may have 2 different spaces on 2 machines. This makes the whole mechanism simply completely useless. You do not have a real fixed uid, nor a dynamically allocated uid, just the worst of both. > > What happens if the package wants to register into the user reserved > > space? > > Should not happen resp. detected during the review (cry loudly when > hint-id is out of order) Should !? > Else, when fedora-usermgmt tries to override an existing user, it will > fail: > > | $ ssh root at athen "LANG=C fedora-useradd -62495 -r foobar" > | useradd: UID 505 is not unique Oh nice very useful, so now we trade a dynamic uid with a possibly failed package installation ... very useful!! > > Is there any check that my user Bob won't suddenly become the master > > of the web server or any other accidentally overlapping daemon? > > ok; when the assigned window is in the middle of the normal user space, > this will be a problem indeed. Solutions: > > * choose a window above UID_MAX (/etc/login.defs) resp. adapt this > value. ditto for GID_MAX The user space window is defined as anything > 500 > * teach the tool which creates the users that the window is tabooed This is exactly the same thing as increasing the reserved fixed space to 200 or 300, and that _is_ a solution! Yours is a bad hack. Simo. From ssorce at redhat.com Sat Mar 10 16:22:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 11:22:45 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87tzwtcd74.fsf@kosh.bigo.ensc.de> References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <1173540694.3403.6.camel@localhost.localdomain> <87tzwtcd74.fsf@kosh.bigo.ensc.de> Message-ID: <1173543765.3403.54.camel@localhost.localdomain> On Sat, 2007-03-10 at 16:47 +0100, Enrico Scholz wrote: > Simo Sorce writes: > > > I think that's a packaging error. From my point of view, once a user > > is created it should never be deleted. > > Happens automatically e.g. during a reinstallation. E.g. have /srv/data > with TiB of data owned by service user A with dynamic uid 234. Something > foobars your system (disk error in system partition, somebody deleted > /lib, perhaps intrusion) and after reinstallation the user A has suddenly > an uid of 198. You never heard of backups and disaster recovery did you? You can't be serious I have to think that you can't make real examples because there isn't a single real case that your method fixes. All cases you posted so far, if you go at the bottom of it, are really just poor deployment planning cases. You can't fix poor planning, and trying to fix, in some questionable way, just one of the thousands issues that poor planning causes is just silly imo. > > Besides, there are countries (Italy for example, but I think > > Sarbanes-Oaxley in the US may say something similar) where there > > are laws that dictate how to manage users and declare that users > > should never deleted but disabled. > > Without being sure, I think this is about accounts of natural persons > but not of service users. No, all users (and service users are no different from normal users) that own files must not be deleted or even if deleted uid/gids MUST not be reused. Simo. From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 16:23:46 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 17:23:46 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173541659.3403.24.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 10:47:39 -0500") References: <45EDC8F8.8060606@redhat.com> <1173211656.6561.51.camel@zod.rchland.ibm.com> <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <876499fiwj.fsf@kosh.bigo.ensc.de> <1173541659.3403.24.camel@localhost.localdomain> Message-ID: <87ps7hcbjh.fsf@kosh.bigo.ensc.de> Simo Sorce writes: >> > Why do we need fixed uids at all? is it so difficult to use >> > getpwnam() ?? >> >> Most filesystems store only the uid/gid, not the name of a user. > > Do you read what people write at all? yes > Do you know what getpwnam() do ? yes; getpwnam(3) works in userspace while permission checks in the filesystem are a kernel thing (which knows nothing about getpwnam(3)). > If I specify 2 different ranges on 2 machines Why would you do this? Just to prove that fedora-usermgmt is shit? coreutils are shit too. I can destroy my system with a simple 'rm -rf /'! >> 'fedora-usermgmt' is completely transparent transparent: either you know >> about it and use it, or it behaves like a plain 'useradd'. > > Do you realize this phrase means exactly that: > fedora-usermgmt == useradd > for all practical purposes ? No; there are existing installations with activated predictable-mode. Hence, 'all' is wrong. > I think it is even a danger for who is aware of it. What happen to > your scheme if you reserve 5000-6000 and then it happens that adding > normal users you end up going over that space? Any application that > rely on fedore-usermgmt at that point will break as it will try to use > normal user's uid/gids ... Without being the 640k guy, I think that the currently suggested window size of 500-1000 is enough for the next years. Nevertheless, when we really come over this limit an administrator can map hint-ids > 1000 into another window. Some sanity checks can be added to 'fedora-usermgmt' e.g. to abort or fallback when hint-id > 500 and there is no file /etc/fedora/hints-above-500-are-ok. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 16:27:07 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 17:27:07 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173542019.3403.30.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 10:53:39 -0500") References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <1173542019.3403.30.camel@localhost.localdomain> Message-ID: <87lki5cbdw.fsf@kosh.bigo.ensc.de> Simo Sorce writes: >> > "a package/daemon writes files and/or reads files which are protected >> > by file permissions" does not do so by default from machine A to >> > machine B, right? >> >> Perhaps not "by default"; but this package might be used in a setup >> which shares network resources betwen A and B. > > sharing resource between machines using protocls like NFSv3 requires > planning _from scratch_. Using 'fedora-usermgmt' eases this planning. >> Or, when /srv/www is on the local machine, contains an huge amount of >> data, and the system must be reinstalled for some reason. > > If you have to reinstall you just keep around /etc/passwd anyway No; normal users are in LDAP, login happens with SSH keys resp. KRB5. The root-password for console-login is set during the kickstart installation. > you may have reserved different ranges on the 2 machines, again: why would you do this? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From pertusus at free.fr Sat Mar 10 16:23:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 17:23:40 +0100 Subject: vim and /etc/alternatives In-Reply-To: <20070310131215.GC22861@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> <20070310124907.GA22861@redhat.com> <20070310125259.GE3153@free.fr> <20070310131215.GC22861@redhat.com> Message-ID: <20070310162340.GB3261@free.fr> On Sat, Mar 10, 2007 at 02:12:15PM +0100, Tomas Janousek wrote: > Zdar, > > On Sat, Mar 10, 2007 at 01:52:59PM +0100, Patrice Dumas wrote: > > Why do you want that? vim is a console app, it just needs a terminal. > > Because I love the ability to pass huge amounts of text using the X clipboard. I see. > > Why don't you want to use gvim for gvim and vim for the console vim? > > There are 2 different apps with different names, what is the problem? > > No, they are not. Indeed you are right. > They are two same apps compiled with different options. And > I _do_ want every single command that runs a vim to run the vim-X11 version. I want the reverse. After looking more seems like that when vim-minimal (with vi) and vim-enhanced (with vim) are installed an alias is done in /etc/profile.d to alias vi to vim. Why don't you alias vim to gvim? -- Pat From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 16:31:38 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 17:31:38 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173542683.3403.40.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 11:04:43 -0500") References: <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <1173542683.3403.40.camel@localhost.localdomain> Message-ID: <87hcstcb6d.fsf@kosh.bigo.ensc.de> Simo Sorce writes: >> I did this. And it was a pain to deal with it. 'fedora-usermgmt' >> solved this once and forever. > > I don't want to seem willing to attack you personally, but if you didn't > think of synchronizing and rationalizing the uid/gid space, _before_ > installing your shared environment, Keeping the shared environment alive is a process. Nightly 'yum upgrade' operations can create previously unknown users which are messing up your shared /etc/passwd. I do not have the resources to review every package-upgrade to see whether new users will be added. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Mar 10 16:32:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Mar 2007 17:32:03 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173540810.3403.9.camel@localhost.localdomain> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> Message-ID: <1173544323.4143.8.camel@rousalka.dyndns.org> Please can we kill the "fixed UID are useless", "you can get by with local planning", "I don't need it there" arguments once and for all? 1. If you really think so, are you ready to empty the current 0-100 range and deal with the the user backlash? 2. We don't aim at "local planning mitigation", we aim at "just works" systems 3. Fixed uids are useful enough they got a range reserved within Fedora & Linux standards. 4. People care enough today we'll get regular flamewars till the problem is fixed The *only* problem is this range is full, not that it should or should not exist. Any other argument is not worth the bytes expended on it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 16:48:36 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 17:48:36 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173543363.3403.48.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 11:16:03 -0500") References: <20070310110610.GD20977@neu.nirvana> <871wjxfis3.fsf@kosh.bigo.ensc.de> <20070310112715.GF20977@neu.nirvana> <87wt1pe2zj.fsf@kosh.bigo.ensc.de> <20070310120401.GA23762@neu.nirvana> <87odn1e0qm.fsf@kosh.bigo.ensc.de> <20070310130302.GA26349@neu.nirvana> <87fy8ddz0f.fsf@kosh.bigo.ensc.de> <20070310135130.GC26349@neu.nirvana> <87bqj1dw8o.fsf@kosh.bigo.ensc.de> <20070310142906.GA29953@neu.nirvana> <873b4ddt9g.fsf@kosh.bigo.ensc.de> <1173543363.3403.48.camel@localhost.localdomain> Message-ID: <87d53hcae3.fsf@kosh.bigo.ensc.de> Simo Sorce writes: > you may have 2 different spaces on 2 machines. again: why should I have this? >> Should not happen resp. detected during the review (cry loudly when >> hint-id is out of order) > > Should !? yes, "should" like in: "scriptlets *should* not contain 'rm -rf /'" >> | $ ssh root at athen "LANG=C fedora-useradd -62495 -r foobar" >> | useradd: UID 505 is not unique > > Oh nice very useful, so now we trade a dynamic uid with a possibly > failed package installation ... very useful!! As I wrote in another posting: I do not expect that UIDs are exceeding the 500-1000 range in the next years. When this happens, the hint-translator can be configured to map ids > 1000 into a second window. >> ok; when the assigned window is in the middle of the normal user space, >> this will be a problem indeed. Solutions: >> >> * choose a window above UID_MAX (/etc/login.defs) resp. adapt this >> value. ditto for GID_MAX > > The user space window is defined as anything > 500 wrong. It is 500-60000 by default. >> * teach the tool which creates the users that the window is tabooed > > This is exactly the same thing as increasing the reserved fixed space > to 200 or 300, and that _is_ a solution! No; there *are* existing systems which have already (system) users in the 100-300 range. Mentioned tool is something written by the same administrator(group) who defined the window for the service users. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 16:53:39 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 17:53:39 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173543765.3403.54.camel@localhost.localdomain> (Simo Sorce's message of "Sat, 10 Mar 2007 11:22:45 -0500") References: <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <1173540694.3403.6.camel@localhost.localdomain> <87tzwtcd74.fsf@kosh.bigo.ensc.de> <1173543765.3403.54.camel@localhost.localdomain> Message-ID: <878xe5ca5o.fsf@kosh.bigo.ensc.de> Simo Sorce writes: >> > I think that's a packaging error. From my point of view, once a >> > user is created it should never be deleted. >> >> Happens automatically e.g. during a reinstallation. E.g. have /srv/data >> with TiB of data owned by service user A with dynamic uid 234. Something >> foobars your system (disk error in system partition, somebody deleted >> /lib, perhaps intrusion) and after reinstallation the user A has suddenly >> an uid of 198. > > You never heard of backups and disaster recovery did you? System does not contain anything which can not be recovered by kickstart and a cfagent run. Why should I create a backup of potentially corrupted/rootkitted libraries/binaries? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ssorce at redhat.com Sat Mar 10 17:02:36 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Mar 2007 12:02:36 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173544323.4143.8.camel@rousalka.dyndns.org> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> <1173544323.4143.8.camel@rousalka.dyndns.org> Message-ID: <1173546156.3403.61.camel@localhost.localdomain> On Sat, 2007-03-10 at 17:32 +0100, Nicolas Mailhot wrote: > Please can we kill the "fixed UID are useless", "you can get by with > local planning", "I don't need it there" arguments once and for all? We are not saying all fixed UIDs are useless. We are discussing the fact that the solution for fixed UIDs space needs is to increase the space beyond 100 not invent some semi-predictable method to assign ranges of uid/gids special meanings. I know very well what are the limits of "special ranges" as we had to use them in samba (see idmap ranges for winbindd). > 1. If you really think so, are you ready to empty the current 0-100 > range and deal with the the user backlash? I am not saying we should empty that space at all, what I am saying is that A) fedora-usermgmt is not a good solution, B) not all daemons need fixed uid/gids and some got one when they probably should have not. > 2. We don't aim at "local planning mitigation", we aim at "just works" > systems If you plan at "just works" systems then there so many things to do, that we should just enlarge the existing space ask package maintainers to think if this may affect their packages and fix them eventually, and move on. > 3. Fixed uids are useful enough they got a range reserved within Fedora > & Linux standards. See above > 4. People care enough today we'll get regular flamewars till the problem > is fixed > > The *only* problem is this range is full, not that it should or should > not exist. Any other argument is not worth the bytes expended on it. We are saying exactly the same thing here. Violent agreement! Simo. From ville.skytta at iki.fi Sat Mar 10 17:02:45 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 10 Mar 2007 19:02:45 +0200 Subject: virtualbox - automatically loaded kernel module In-Reply-To: <200703101331.00320.opensource@till.name> References: <200703101331.00320.opensource@till.name> Message-ID: <200703101902.45822.ville.skytta@iki.fi> On Saturday 10 March 2007, Till Maas wrote: > is it somehow possible to configure which modules should be loaded at > bootime? fgrep -A 2 -B 2 sysconfig/modules /etc/rc.sysinit From tjanouse at redhat.com Sat Mar 10 17:28:51 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 18:28:51 +0100 Subject: vim and /etc/alternatives In-Reply-To: <20070310162340.GB3261@free.fr> References: <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> <20070310124907.GA22861@redhat.com> <20070310125259.GE3153@free.fr> <20070310131215.GC22861@redhat.com> <20070310162340.GB3261@free.fr> Message-ID: <20070310172851.GA5843@redhat.com> Hi, On Sat, Mar 10, 2007 at 05:23:40PM +0100, Patrice Dumas wrote: > I want the reverse. /etc/alternatives is a solution for both of us, isn't it? :) > After looking more seems like that when vim-minimal (with vi) and > vim-enhanced (with vim) are installed an alias is done in /etc/profile.d > to alias vi to vim. Uh, that's evil :) -- e.g. view still runs /bin/vi. > Why don't you alias vim to gvim? Because that would run the gui automatically. We'd need an alias that preserves argv[0]. -- TJ., BaseOS, Brno, CZ From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 18:14:19 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 19:14:19 +0100 Subject: An alternative to fedora-usermgmt Message-ID: <874potc6f8.fsf@kosh.bigo.ensc.de> Hello, I just submitted some thoughts how fedora-usermgmt can be replaced http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups Most important is point | 1. Before submitting the package for review, add the user to PackageUserRegistry, ... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From a.badger at gmail.com Sat Mar 10 19:46:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 10 Mar 2007 11:46:31 -0800 Subject: vim and /etc/alternatives In-Reply-To: <20070310130959.GB22861@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173460086.3329.168.camel@localhost.localdomain> <20070310130959.GB22861@redhat.com> Message-ID: <1173555991.3329.254.camel@localhost.localdomain> On Sat, 2007-03-10 at 14:09 +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 09, 2007 at 09:08:06AM -0800, Toshio Kuratomi wrote: > > The vim split has another purpose: To keep the X, perl, and python > > libraries off of /. > > > > We need /bin/vi to run if /usr is not mounted. So we have to compile a > > version of vim that doesn't drag in the kitchen sink. > > http://people.redhat.com/tjanouse/tmp/launchvim.c > > Probably something like this may do the job? > > (yeah, I see a huge flame on this, but if they don't want /etc/alternatives, > they asked for this!) > Uhm. No. 1) alternatives isn't an issue with vim as is because we have three distinct programs with three distinct names: /bin/vi /usr/bin/vim /usr/bin/gvim 2) Something like launchvim has no bearing on whether we are going to split out /bin/vi from vim/gvim as it does nothing to address the issue of /bin/vi needing /usr to be mounted in order to run. > > Uhm. No it doesn't. I hate how gvim moves the cursor when I click in > > it with a mouse (I just want to select the text to paste into evolution > > or firefox, not move my editing cursor) and I have three buttons for a > > reason :-) (Unlike the vim-minimal split, I understand that vim's > > interaction with the mouse is a matter of personal taste.) > > That's the way how mouse works in vim GUI, that's not my problem. In terminal, > you can always just use the shift key. > I'm certain I'm not understanding what you want now. I don't know what you're referring to with the "just use the shift key". However, I've found a solution for the issue that's prompting you to request this:: alias vim='gvim -v' The man page for this option is a little confusing:: -v Start Vim in Vi mode, just like the executable was called "vi". This only has effect when the executable is called "ex". What you have to realize is that although this sounds as though it's going to run vim in vi-compatibility mode there's already a switch for that: "-C". What "-v" really does is run vim as a console mode screen editor in contrast to "-e" which runs vim as the line editor and "-g" as the GUI editor. I've confirmed that this gives you access to "*p -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tjanouse at redhat.com Sat Mar 10 20:57:36 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 21:57:36 +0100 Subject: vim and /etc/alternatives In-Reply-To: <1173555991.3329.254.camel@localhost.localdomain> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173460086.3329.168.camel@localhost.localdomain> <20070310130959.GB22861@redhat.com> <1173555991.3329.254.camel@localhost.localdomain> Message-ID: <20070310205736.GA16842@redhat.com> Hi, On Sat, Mar 10, 2007 at 11:46:31AM -0800, Toshio Kuratomi wrote: > 2) Something like launchvim has no bearing on whether we are going to > split out /bin/vi from vim/gvim as it does nothing to address the issue > of /bin/vi needing /usr to be mounted in order to run. I believe it addresses. /bin/vi will not require /usr to be mounted. Say we have something like /bin/vi.minimal, /usr/bin/vim.enhanced and /usr/bin/vim.x11. And /bin/launchvim with all those vis, vims, vimdiffs and whatever symlinked to it. Then it would launch the most featureful version available at the moment. Seems like noone is flaming me, so I'll flame myself. It is a nonsense. This is certainly not how things should be done. It's better than alternatives because of that /usr issue. But otherwise it's just an ugly bullshit. It is better than the current approach, though (imho). > I'm certain I'm not understanding what you want now. I don't know what > you're referring to with the "just use the shift key". Fire up 'gvim -v' in an xterm. Try to select something. Ouch, it moves the cursor. Fine, do the same while holding the Shift key. Works like normal xterm selection. Cool. > alias vim='gvim -v' Ok, you win, I lose. So I guess the vim-X11 package needs this: for cmd in ex rvi rview vi view rvim vim vimdiff; do echo "alias $cmd = gvim -whatever" >>/etc/profile.d/vim-X11.sh done (i know this is never gonna happen, just like i'll never set these aliases and will use those symlinks and/or debian instead :/) -- TJ., BaseOS, Brno, CZ From Axel.Thimm at ATrpms.net Sun Mar 11 00:12:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Mar 2007 01:12:01 +0100 Subject: Fixed uid space only half full? (was: Fedora User Management (revisited)) In-Reply-To: <1173544323.4143.8.camel@rousalka.dyndns.org> References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> <1173544323.4143.8.camel@rousalka.dyndns.org> Message-ID: <20070311001201.GD5550@neu.nirvana> On Sat, Mar 10, 2007 at 05:32:03PM +0100, Nicolas Mailhot wrote: > Please can we kill the "fixed UID are useless", [...] > The *only* problem is this range is full, not that it should or should > not exist. Any other argument is not worth the bytes expended on it. Just as a datapoint: My rather full install of FC6/x86_64 yields: $ getent passwd | sort -t: -k3,3n|cat -n|grep -B5 :99:99: 53 distcache:x:94:94:Distcache:/:/sbin/nologin 54 radiusd:x:95:95:radiusd user:/:/bin/false 55 hsqldb:x:96:96::/var/lib/hsqldb:/sbin/nologin 56 dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin 57 ident:x:98:98::/home/ident:/sbin/nologin 58 nobody:x:99:99:Nobody:/:/sbin/nologin So it looks like there are only 58 of 100 fixed uid really in use. Maybe some quick review will give us 42 *fixed* uids, and I'm sure that's more than enough for the next 1-2 years (e.g. until F9/10/RHEL6. And until then we can talk with the LSB to change the system fixed/non-fixed uid ranges and prepare a sensitive and compliant setup to last for the next decade. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Mar 11 01:33:36 2007 From: opensource at till.name (Till Maas) Date: Sun, 11 Mar 2007 02:33:36 +0100 Subject: virtualbox - automatically loaded kernel module In-Reply-To: <200703101902.45822.ville.skytta@iki.fi> References: <200703101331.00320.opensource@till.name> <200703101902.45822.ville.skytta@iki.fi> Message-ID: <200703110233.36351.opensource@till.name> On Sa M?rz 10 2007, Ville Skytt? wrote: > fgrep -A 2 -B 2 sysconfig/modules /etc/rc.sysinit Thank you very much, I only looked for a file in /etc/sysconfig/ not for a directory... Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guthrie at counterexample.org Sun Mar 11 04:50:08 2007 From: guthrie at counterexample.org (John T. Guthrie) Date: Sat, 10 Mar 2007 23:50:08 -0500 Subject: %bcond macros in Fedora spec files Message-ID: <1173588608.16485.29.camel@euler.counterexample.org> Hello all, I was wondering if there were any guidelines about the use of %bcond_* macros in Fedora spec files? I checked the wiki, and there are three pages that contain the string bcond in their text, but those are only in passing. Of course, the %bcond_* macros can give people flexibility in the features of the package should they need to use the src.rpm. (For example, needing to back-port a package to FC-4, say.) However, fwiw, my general observation of Fedora has been a tendency to include as many features as possible in packages. (Some people will probably think that this is a bad thing. Personally, I like this trend in general. But that's a discussion for an entirely different thread...) The main reason that I could see these macros being used in Fedora would be to allow people to exclude a feature that they weren't able to build with. For example, in some distant future, a package gets released for FC-8, and someone wants to backport that package to their FC-4 machine. However, the FC-8 package requires some devel packages that aren't available for FC-4. A %bcond_* macro would let that person just drop that feature from that package that they built using --without flags instead of going in, editing the spec file, and re-creating a new package. In this sense, %bcond_* macros could be a type of courtesy for legacy systems. On the other hand, however, the %bcond_* macros do lead to a certain lack of reproduceability in RPM builds. Of course, the exact command "rpmbuild --rebuild blah.src.rpm" will always produce the same package, even with %bcond_* macros. However, the general set of rebuild commands for blah.src.rpm would now include "rpmbuild --rebuild blah.src.rpm" and "rpmbuild --rebuild --with foo blah.src.rpm" which would probably *not* be the same package. So that we could conceivably end up having to ask people who have problems with such a package, "Did you build with the flag '--with foo'?" So is there some kind of policy (or more appropriately a guideline) regarding this kind of macro in spec files? Should even be there be such a guideline or not? (That is, do we even care?) -- John Guthrie guthrie at counterexample.org From cweyl at alumni.drew.edu Sun Mar 11 05:37:01 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 10 Mar 2007 21:37:01 -0800 Subject: Review with flags documentation on the wiki? Message-ID: <7dd7ab490703102137v1510c1e2l4e92db074afeb59@mail.gmail.com> Soo.... While the FESCo-sanctioned new review policy using flags has been posted to this list, it doesn't look like Packaging/ReviewGuidelines has been updated to it. Worse off, the only documentation of it in the wiki is seriously outdated. Given the level of confusion in the past, could we at least nix the outdated procedure section in Packaging/ReviewGuidelines and point to the review with flags v6 procedure email? And remove/update WarrenTogami/ReviewWithFlags, as appropriate? Thanks :) -Chris -- Chris Weyl Ex astris, scientia From nicolas.mailhot at laposte.net Sun Mar 11 08:45:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Mar 2007 09:45:57 +0100 Subject: Fixed uid space only half full? (was: Fedora User Management (revisited)) In-Reply-To: <20070311001201.GD5550@neu.nirvana> References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> <1173544323.4143.8.camel@rousalka.dyndns.org> <20070311001201.GD5550@neu.nirvana> Message-ID: <1173602757.13302.8.camel@rousalka.dyndns.org> Le dimanche 11 mars 2007 ? 01:12 +0100, Axel Thimm a ?crit : > On Sat, Mar 10, 2007 at 05:32:03PM +0100, Nicolas Mailhot wrote: > > Please can we kill the "fixed UID are useless", [...] > > > The *only* problem is this range is full, not that it should or should > > not exist. Any other argument is not worth the bytes expended on it. > Maybe some quick review will give us 42 *fixed* uids, and I'm > sure that's more than enough for the next 1-2 years (e.g. until > F9/10/RHEL6. And until then we can talk with the LSB to change the > system fixed/non-fixed uid ranges and prepare a sensitive and > compliant setup to last for the next decade. IMHO trying to be smarter at fixed UID attribution is a dead end. We've been hitting the limit for some years now, and getting smart just didn't happen. It won't now ? it's just too much work to evaluate the threshold between fixed/dynamic (taking into account past of future versions of a package, build and configure options, local site usages, etc) A KISS policy "every rpm-created system ID has a fixed uid referenced in this table" is the only sane approach. Except for the problem of short-sighted range limit, UIDs are cheap and not worth spending hours over. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Sun Mar 11 10:24:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Mar 2007 11:24:08 +0100 Subject: Fixed uid space only half full? (was: Fedora User Management (revisited)) In-Reply-To: <1173602757.13302.8.camel@rousalka.dyndns.org> References: <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> <1173544323.4143.8.camel@rousalka.dyndns.org> <20070311001201.GD5550@neu.nirvana> <1173602757.13302.8.camel@rousalka.dyndns.org> Message-ID: <20070311102408.GA507@neu.nirvana> On Sun, Mar 11, 2007 at 09:45:57AM +0100, Nicolas Mailhot wrote: > Le dimanche 11 mars 2007 ? 01:12 +0100, Axel Thimm a ?crit : > > On Sat, Mar 10, 2007 at 05:32:03PM +0100, Nicolas Mailhot wrote: > > > Please can we kill the "fixed UID are useless", [...] > > > > > The *only* problem is this range is full, not that it should or should > > > not exist. Any other argument is not worth the bytes expended on it. > > > Maybe some quick review will give us 42 *fixed* uids, and I'm > > sure that's more than enough for the next 1-2 years (e.g. until > > F9/10/RHEL6. And until then we can talk with the LSB to change the > > system fixed/non-fixed uid ranges and prepare a sensitive and > > compliant setup to last for the next decade. > > IMHO trying to be smarter at fixed UID attribution is a dead end. We've > been hitting the limit for some years now, and getting smart just didn't > happen. I don't think we tried to get smarter. Whenever this came up the legitimate question was posed whether the package in question really needed a fixed uid or would also work with non-fixed ones, and it always turned out that it didn't really need fixed uids (last one was gkrellm IIRC). > It won't now ? it's just too much work to evaluate the threshold > between fixed/dynamic (taking into account past of future versions of a > package, build and configure options, local site usages, etc) The 42 uid mentioned above *are* free.Even if I missed a few, I'm quite sure that we have about 30 uids immediately for disposal. > A KISS policy "every rpm-created system ID has a fixed uid referenced in > this table" is the only sane approach. Except for the problem of > short-sighted range limit, UIDs are cheap and not worth spending hours > over. As long as we have the limitation (imposed by LSB and long year practices) and lifting it means planing in years, uids aren't really that cheap. OTOH they are cheaper then anticipated if everyone thinks they are full, while there's 1/3 or more free. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Sun Mar 11 11:44:00 2007 From: alan at redhat.com (Alan Cox) Date: Sun, 11 Mar 2007 07:44:00 -0400 Subject: Fedora User Management (revisited) In-Reply-To: <1173544323.4143.8.camel@rousalka.dyndns.org> References: <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173540810.3403.9.camel@localhost.localdomain> <1173544323.4143.8.camel@rousalka.dyndns.org> Message-ID: <20070311114400.GA7865@devserv.devel.redhat.com> On Sat, Mar 10, 2007 at 05:32:03PM +0100, Nicolas Mailhot wrote: > 3. Fixed uids are useful enough they got a range reserved within Fedora > & Linux standards. And beyond Fedora across the whole of Unix and Linux and BSD. That also matters the moment you have NFS or any kind of shared uid system. From Christian.Iseli at licr.org Sun Mar 11 11:47:39 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sun, 11 Mar 2007 12:47:39 +0100 Subject: FE Package Status of Mar 9, 2007 In-Reply-To: <20070309175930.3dcbbba4@ghistelwchlohm.scrye.com> References: <20070309142834.7ea3f83c@ludwig-alpha.unil.ch> <20070309175930.3dcbbba4@ghistelwchlohm.scrye.com> Message-ID: <20070311124739.6ab71421@ludwig-alpha.unil.ch> On Fri, 9 Mar 2007 17:59:30 -0700, Kevin Fenzi wrote: > You mean "Packages not present in the development repo" ? Yup > Many of these look like merge requests that are not yet imported over > to the formerly extras CVS I think... But the strange thing is that they are not available in Core devel either... C From tcallawa at redhat.com Sun Mar 11 13:16:10 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 11 Mar 2007 08:16:10 -0500 Subject: Review with flags documentation on the wiki? In-Reply-To: <7dd7ab490703102137v1510c1e2l4e92db074afeb59@mail.gmail.com> References: <7dd7ab490703102137v1510c1e2l4e92db074afeb59@mail.gmail.com> Message-ID: <1173618970.31843.30.camel@localhost.localdomain> On Sat, 2007-03-10 at 21:37 -0800, Chris Weyl wrote: > Soo.... While the FESCo-sanctioned new review policy using flags has > been posted to this list, it doesn't look like > Packaging/ReviewGuidelines has been updated to it. Worse off, the > only documentation of it in the wiki is seriously outdated. > > Given the level of confusion in the past, could we at least nix the > outdated procedure section in Packaging/ReviewGuidelines and point to > the review with flags v6 procedure email? And remove/update > WarrenTogami/ReviewWithFlags, as appropriate? I'd be happy to clean up Packaging/ReviewGuidelines to point to the proper methodology for a review when such a document exists somewhere in the wiki. ~spot From buildsys at fedoraproject.org Sun Mar 11 14:17:47 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 11 Mar 2007 10:17:47 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-11 Message-ID: <20070311141747.B53B6152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) eclipse FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) ekiga FC6-updates > FC7 (0:2.0.5-3.fc6 > 0:2.0.5-2.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) foolish AT guezz.net: gtk-recordmydesktop FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) lxtnow AT gmail.com: ntfs-config FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) meme AT daughtersoftiresias.org: nethack-vultures FE5 > FE6 (0:2.1.0-9.fc5 > 0:2.1.0-8.fc6) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rc040203 AT freenet.de: perl-DBIx-SearchBuilder FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) ekiga: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.0.5-3.fc6 > 0:2.0.5-2.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) gtk-recordmydesktop: foolish AT guezz.net FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) nethack-vultures: meme AT daughtersoftiresias.org FE5 > FE6 (0:2.1.0-9.fc5 > 0:2.1.0-8.fc6) ntfs-config: lxtnow AT gmail.com FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) perl-DBIx-SearchBuilder: rc040203 AT freenet.de FE5 > FE7 (0:1.46-1.fc5 > 0:1.45-1.fc6) FE6 > FE7 (0:1.46-1.fc6 > 0:1.45-1.fc6) perl-File-Copy-Recursive: rc040203 AT freenet.de FE5 > FE7 (0:0.31-1.fc5 > 0:0.30-2.fc7) FE6 > FE7 (0:0.31-1.fc6 > 0:0.30-2.fc7) perl-Params-Util: rc040203 AT freenet.de FE5 > FE7 (0:0.23-1.fc5 > 0:0.22-1.fc7) FE6 > FE7 (0:0.23-1.fc6 > 0:0.22-1.fc7) perl-Text-Quoted: rc040203 AT freenet.de FE5 > FE7 (0:2.02-1.fc5 > 0:1.10-1.fc7) FE6 > FE7 (0:2.02-1.fc6 > 0:1.10-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From wtogami at redhat.com Sun Mar 11 17:14:56 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 11 Mar 2007 13:14:56 -0400 Subject: Review with flags documentation on the wiki? In-Reply-To: <7dd7ab490703102137v1510c1e2l4e92db074afeb59@mail.gmail.com> References: <7dd7ab490703102137v1510c1e2l4e92db074afeb59@mail.gmail.com> Message-ID: <45F43910.7070607@redhat.com> Chris Weyl wrote: > Soo.... While the FESCo-sanctioned new review policy using flags has > been posted to this list, it doesn't look like > Packaging/ReviewGuidelines has been updated to it. Worse off, the > only documentation of it in the wiki is seriously outdated. > > Given the level of confusion in the past, could we at least nix the > outdated procedure section in Packaging/ReviewGuidelines and point to > the review with flags v6 procedure email? And remove/update > WarrenTogami/ReviewWithFlags, as appropriate? > > Thanks :) > -Chris Thanks for mentioning this. I updated other places on the Wiki, but missed here. Are there any others? A few places still point at the FE-REVIEW FE-NEW FE-ACCEPTED trackers, but only in the capacity of statistics, because we didn't auto-migrate all of that to match the new flags. Warren TOgami wtogami at redhat.com From seg at haxxed.com Sun Mar 11 18:42:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 13:42:32 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <873b4er7m2.fsf@fc5.bigo.ensc.de> References: <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> Message-ID: <1173638552.18771.117.camel@localhost.localdomain> On Fri, 2007-03-09 at 12:15 +0100, Enrico Scholz wrote: > you and notting are wanting to break the LSB by using an area which must > not be used for fixed uids. I outlined an alternative which breaks LSB > too but is much less painless on most systems. Fuck the LSB. Last I checked, blind adherence to "standards" wasn't in Fedora policy. The LSB fails to accommodate our needs in this situation. The LSB's job is to accommodate *us*, the global collective of distribution vendors, not the other way around. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Mar 11 18:48:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 13:48:52 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87ejnxflo0.fsf@kosh.bigo.ensc.de> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> Message-ID: <1173638932.18771.123.camel@localhost.localdomain> On Sat, 2007-03-10 at 11:16 +0100, Enrico Scholz wrote: > Axel Thimm writes: > > > Indeed, most of the packages we're talking about (if not all) don't > > need a fixed uid/gid at all. > > When a package/daemon writes files and/or reads files which are protected > by file permissions, it is a good candidate for fixed uids. Okay this whole line of thought is total crackrock. Why do we need to make value judgements over what packages deserve a fixed ID, and what doesn't? If we're going to do fixed IDs at all, there's *no* reason we can't do it for all packages. We run out of space in the 0-499 range once there's 500 system users either way. This might be better as Wiki discussion so that it can be properly structured. There's way too many different issues being mixed up here. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Mar 11 19:03:34 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 14:03:34 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <1173638932.18771.123.camel@localhost.localdomain> References: <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173638932.18771.123.camel@localhost.localdomain> Message-ID: <1173639814.18771.129.camel@localhost.localdomain> On Sun, 2007-03-11 at 13:48 -0500, Callum Lerwick wrote: > Okay this whole line of thought is total crackrock. Why do we need to > make value judgements over what packages deserve a fixed ID, and what > doesn't? If we're going to do fixed IDs at all, there's *no* reason we > can't do it for all packages. We run out of space in the 0-499 range > once there's 500 system users either way. Oh, also mixing static and fixed ID only causes problems with dynamic and static IDs colliding. Which only results in *less* efficient use of the number space. Dynamic UIDs only cause us more problems, and solve nothing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Sun Mar 11 19:14:13 2007 From: alan at redhat.com (Alan Cox) Date: Sun, 11 Mar 2007 15:14:13 -0400 Subject: Fedora User Management (revisited) In-Reply-To: <1173638552.18771.117.camel@localhost.localdomain> References: <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <1173638552.18771.117.camel@localhost.localdomain> Message-ID: <20070311191413.GA24288@devserv.devel.redhat.com> On Sun, Mar 11, 2007 at 01:42:32PM -0500, Callum Lerwick wrote: > Fuck the LSB. Last I checked, blind adherence to "standards" wasn't in > Fedora policy. The LSB fails to accommodate our needs in this situation. > The LSB's job is to accommodate *us*, the global collective of > distribution vendors, not the other way around. Actually the LSB's role is primarily simply to document existing standard behaviour so that you don't get fragmentation and chaos (which is exactly what some folks in this discussion appear intent upon). It documents cross vendor, cross distribution common and relied upon behaviour with more than a non at long standing unix tradition that uid < 100 is magic. From seg at haxxed.com Sun Mar 11 19:22:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 14:22:16 -0500 Subject: Review guidelines and rpmlint In-Reply-To: References: <1173374864.1641.312.camel@finch.boston.redhat.com> <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> Message-ID: <1173640936.18771.144.camel@localhost.localdomain> On Fri, 2007-03-09 at 11:50 -0500, Chip Coldwell wrote: > Yes. In order to meet the merge review requirements for Fedora 7 I must > silence rpmlint. I keep seeing this over and over and over and over and over and over and over and over and over and over and over and over and over again. If you look closely, rpmlint output is separated into warnings (W:) and errors (E:). Just like a C compiler. IMHO we should do this: Errors MUST be fixed to pass review. (Or to pass the upcoming rpmlint-after-build test) Warnings can be ignored IF (BIG IF) there is reasonable justification. For example, the common "no documentation" warning with sub-packages such as -devel. Often all documentation goes into the main package, and there's nothing suited to go in the -devel package. And if rpmlint flags something as an error that shouldn't be, file a bug against rpmlint. The test can be revised, or downgraded to a warning. ... Is this an agreeable revision to the review guidelines? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Sun Mar 11 19:24:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 11 Mar 2007 20:24:35 +0100 Subject: Review guidelines and rpmlint In-Reply-To: <1173640936.18771.144.camel@localhost.localdomain> References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> <1173640936.18771.144.camel@localhost.localdomain> Message-ID: <20070311192435.GA3960@free.fr> On Sun, Mar 11, 2007 at 02:22:16PM -0500, Callum Lerwick wrote: > > If you look closely, rpmlint output is separated into warnings (W:) and > errors (E:). Just like a C compiler. If I remember well Ville said that the difference between W and E was quite arbitrary. > Errors MUST be fixed to pass review. (Or to pass the upcoming > rpmlint-after-build test) Some errors have to be ignored (from the top of my head, errors about setuid binaries, for example). > Warnings can be ignored IF (BIG IF) there is reasonable justification. > For example, the common "no documentation" warning with sub-packages > such as -devel. Often all documentation goes into the main package, and > there's nothing suited to go in the -devel package. In my opinion it should be like that for W and E rpmlint messages indistinctly. Maybe E may be scrutated more, but it isn't obvious either. -- Pat From j.w.r.degoede at hhs.nl Sun Mar 11 20:05:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 11 Mar 2007 21:05:48 +0100 Subject: Review guidelines and rpmlint In-Reply-To: <20070311192435.GA3960@free.fr> References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> <1173640936.18771.144.camel@localhost.localdomain> <20070311192435.GA3960@free.fr> Message-ID: <45F4611C.2070207@hhs.nl> Patrice Dumas wrote: > On Sun, Mar 11, 2007 at 02:22:16PM -0500, Callum Lerwick wrote: >> If you look closely, rpmlint output is separated into warnings (W:) and >> errors (E:). Just like a C compiler. > > If I remember well Ville said that the difference between W and E was > quite arbitrary. > >> Errors MUST be fixed to pass review. (Or to pass the upcoming >> rpmlint-after-build test) > > Some errors have to be ignored (from the top of my head, errors about > setuid binaries, for example). > >> Warnings can be ignored IF (BIG IF) there is reasonable justification. >> For example, the common "no documentation" warning with sub-packages >> such as -devel. Often all documentation goes into the main package, and >> there's nothing suited to go in the -devel package. > > In my opinion it should be like that for W and E rpmlint messages > indistinctly. Maybe E may be scrutated more, but it isn't obvious either. > Agreed, as a loyal rpmlint user and someone with quite a few packages and reviews on his name, I must say this is the only way. Many rpmlint errors are errors in most cases but not always, some should / could be changed to warnings. But there will never be a rpmlint without false positives on the error front. This is also why my suggestion for adding rpmlint to the buildsys and makefile.common test builds, contains a whitelist. Regards, Hans From enrico.scholz at informatik.tu-chemnitz.de Sun Mar 11 21:01:18 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 11 Mar 2007 22:01:18 +0100 Subject: Fedora User Management (revisited) In-Reply-To: <1173638552.18771.117.camel@localhost.localdomain> (Callum Lerwick's message of "Sun, 11 Mar 2007 13:42:32 -0500") References: <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <1173638552.18771.117.camel@localhost.localdomain> Message-ID: <87mz2jbild.fsf@kosh.bigo.ensc.de> Callum Lerwick writes: >> you and notting are wanting to break the LSB by using an area which >> must not be used for fixed uids. I outlined an alternative which >> breaks LSB too but is much less painless on most systems. > > Fuck the LSB. Last I checked, blind adherence to "standards" > wasn't in Fedora policy. It is not a "blind adherence" but an adherence that existing systems should not be broken. You can not use range 100-499 for static uids because existing systems are having already uids in this range. > The LSB fails to accommodate our needs in this situation. The LSB's > job is to accommodate *us*, It was a wrong/shortsighted decision to reserve only 0-100 for static uids. But this decision can not be corrected anymore because there is no other room for static uids. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Sun Mar 11 23:23:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 11 Mar 2007 19:23:03 -0400 Subject: Fedora User Management (revisited) In-Reply-To: <1173638932.18771.123.camel@localhost.localdomain> References: <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173638932.18771.123.camel@localhost.localdomain> Message-ID: <20070311232303.GA13621@jadzia.bu.edu> On Sun, Mar 11, 2007 at 01:48:52PM -0500, Callum Lerwick wrote: > Okay this whole line of thought is total crackrock. Why do we need to > make value judgements over what packages deserve a fixed ID, and what > doesn't? If we're going to do fixed IDs at all, there's *no* reason we Because there's no important reason to have a fixed UID if no files are owned. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From petersen at redhat.com Mon Mar 12 04:11:13 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 12 Mar 2007 14:11:13 +1000 Subject: [rpmlint] obsolete-not-provided and versioned obsoletes Message-ID: <45F4D2E1.5060606@redhat.com> Hi, rpmlint currently marks obsoletes without provides as errors in its output. However some obsoletes are really just a convenience for upgrades, etc. For example scim obsoletes some old iiimf packages but it surely does not provide iiimf. The scim package has versioned obsoletes, and I do not think that it should provide the obsoleted iiimf packages. Should rpmlint be updated to only warn about versioned obsoletes without provides? Jens From aph at redhat.com Mon Mar 12 11:45:25 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Mar 2007 11:45:25 +0000 Subject: New gcj in rawhide Message-ID: <17909.15701.46734.24668@zebedee.pink> The new gcj package with version 5 libraries and compiler has been available in rawhide for a couple of weeks now. This package is available from the yum development repo as gcc-java.*.4.1.2-3. If you are a maintainer of a package that has a dependency on libgcj please make sure that your package builds. I don't expect there to be many problems, but it's worth checking. Thanks, Andrew. From mattdm at mattdm.org Mon Mar 12 12:09:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Mar 2007 08:09:33 -0400 Subject: [rpmlint] obsolete-not-provided and versioned obsoletes In-Reply-To: <45F4D2E1.5060606@redhat.com> References: <45F4D2E1.5060606@redhat.com> Message-ID: <20070312120933.GA7809@jadzia.bu.edu> On Mon, Mar 12, 2007 at 02:11:13PM +1000, Jens Petersen wrote: > rpmlint currently marks obsoletes without provides as errors in its > output. However some obsoletes are really just a convenience for > upgrades, etc. For example scim obsoletes some old iiimf packages but > it surely does not provide iiimf. > The scim package has versioned obsoletes, and I do not think that it > should provide the obsoleted iiimf packages. > Should rpmlint be updated to only warn about versioned obsoletes without > provides? I think it's a reasonable warning -- not all warnings are errors. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ajackson at redhat.com Mon Mar 12 14:21:08 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Mar 2007 10:21:08 -0400 Subject: vim and /etc/alternatives In-Reply-To: <20070310124907.GA22861@redhat.com> References: <200703081655.01890.jkeating@redhat.com> <200703081816.23690.jkeating@redhat.com> <20974.1173413147@sss.pgh.pa.us> <20070309091910.GC2866@free.fr> <20070309094022.GA8331@redhat.com> <1173455877.20555.3.camel@localhost.localdomain> <20070310124907.GA22861@redhat.com> Message-ID: <1173709268.1242.4.camel@localhost.localdomain> On Sat, 2007-03-10 at 13:49 +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 09, 2007 at 10:57:57AM -0500, Adam Jackson wrote: > > The one major reason to not want X support in your editor is so you > > don't block on the XOpenDisplay, which can take much longer than you > > want when using ssh with a forwarded display. But I'd assert that the > > right way to fix that is to teach vim about xcb so the open can fail > > asynchronously. > > I want vim to open an X connection over forwarded X. And it does not fail. I want this, when it works. I want vim to have a connection to the X server when it's available, because "*y is awesome. I want it to maybe give me a warning when I forgot to set $DISPLAY before launching ssh -Y, whatever, not a big deal. But most importantly, I don't want to have to wait for vim to connect to the X server, because I _could_ start editing immediately, instead of waiting for five seconds of round-trips. Hence, XCB. vim should try to do an asynchronous connect. - ajax From fedora at leemhuis.info Mon Mar 12 18:00:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Mar 2007 19:00:24 +0100 Subject: RFC: Package maintenance and update policy for EPEL Message-ID: <45F59538.3050800@leemhuis.info> Hi, find below my take for a "Package maintenance and update policy for EPEL". You an find it in the wiki at: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates It has been discussed on the epel-devel-list already last week (received some comments, but only a few), but I thought it might be best to actually bring it up one this list once here, too. Did I miss anything? Do people like the general direction? CU thl P.S.: If you spot typos (there are probably still some...) please fix them in the wiki directly -- that's why the document is there ;-) ---- = Package maintenance and update policy = EPEL wants to provide a common "look and feel" to the users of our repository. Thus the EPEL SIG wrote this policy that describes the regulations for package maintenance and updates in EPEL, that are a bit more strictly regulated then they are in Fedora now. [[TableOfContents]] == Digest == ## INCLUDEPOLICYFRONTSTART The goal is to have packages in EPEL that enhances the Enterprise Linux distributions the packages were build against without disturbing or replacing packages from that distribution. The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against. In other words: have a mostly stable set of packages that normally to not change at all and only changes if there are good reasons for it -- so no "hey, there is a new version, it builds, let's ship it" mentality. ## INCLUDEPOLICYFRONTEND [[Anchor(afterinclude)]] == Policy == EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were build for. Thus packages from EPEL should never replace packages from the target base distribution; kernel-modules further are not allowed, as they can disturb the base kernel easily. The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against. In other words: have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for changes. This is the spirit of a stable enterprise environment. The changes that cant be avoided get routed into different release trees. Only updates that fix important bugs (say: data-corruption, security problems, really annoying bugs) go to a testing branch for a short time period and then build a second time for the stable branch; those people that sign and push the EPEL packages to the public repo will skim over the list of updated packages for the stable repo to make sure that sure the goal "only important updates for the stable branch" is fulfilled. Other updates get queued up in a testing repository over time. That repository becomes the new stable branch in parallel with the quarterly update that get released by the Linux Distributor that creates the Enterprise Linux the packages gets build against. There will be a short freeze time period before the quarterly update happens to make sure the repo and its packages are in a good shape -- packages in this phase still can be removed if thats is needed. But even this updates should be limited to fixes only as far as possible and should be tested in Fedora beforehand if possible. Updated Packages that change the ABI or require config file adjustments must be avoided if somehow possible. Compat- Packages that provide the old ABI need to be provided in the repo if there is no way around a package update that changes the ABI. == Guidelines and Backgrounds for this policy == === Some examples of what package updates that are fine or not === Examples hopefully help to outline how to actually apply above policy in practise. ==== Minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.0.2 * build for the stable branch only if it fixes serious bugs * build for the testing branch (which will be 5.1 later) is acceptable if the upstream release is mostly a bugfix release without new features and the package got run-time testing ==== A little bit bigger minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and the existing config files continue to work * build for the stable branch only if it fixes a really serious bug * build for the testing branch (which will be 5.1 later) is acceptable if it fixes serious bugs ==== A yet again little bit bigger minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but the config files need manual adjustments * build for the stable branch is normally not acceptable; a backport should be strongly considered if there are any serious bugs that must be fixed * build for the testing branch (which will be 5.1 later) is also disliked; but it is acceptable if there is no other easy way out to solve serious bugs; but the update and the config file adjustments need to be announced to the users properly -- say in form of release notes that get published together with the quarterly announcement. ==== A major version update ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 2.0.0; the ABI changes or the config files need manual adjustments * this update should be avoided if possible at all. If there really is no other way out to fix a serious bug then it rare cases it might be acceptable to build the new version for the testing branch and mention the update and the needed adjustments in the release notes for the next update. An additional compat- packages with the old libs is necessary if the ABI changed. ==== Add more examples as they show up ==== If to many show up put them into a separate document. === Still unsure if a package is fine for EPEL? === Just ask on [http://www.redhat.com/archives/epel-devel-list/ EPEL developers mailing list] or #epel on freenode.org for opinions from EPEL SIG members. === Why not a rolling release with up2date packages like Extras? === Why should we? That would be what Fedora (Extras) did and worked and works well for it -- but that's mainly because Fedora (Core) has lots of updates and a nearly rolling-release scheme/quick release cycle, too. But the Enterprise Linux we build against is much more careful with updates and has longer life-cycle; thus we should do the same for EPEL, as most users will properly prefer it that way, as they chose a stable distro for some reasons -- if they want the latest packages they might have chosen Fedora. Sure, there are lots of areas where having a mix of a stable base and a set of quite new packages on top of it is wanted. *Maybe* the EPEL project will provide a solution (in parallel to the carefully updated repository!) for those cases in the long term, but not for the start. BTW, there are already repositories out there that provide something in this direction, so users might be served by them already. Further: A rolling release scheme like Fedora (Extras) did/does is not possible for many EPEL packages for another reason, new packages often require new versions of certain core libraries. This will cause problems in EPEL because we won't be able to provide updated libs as it would replace libraries in the core OS. Example: This document was written round about when RHEL5 got released; many packages that get build for RHEL5 can't be build for RHEL4 at this point of time already, as the RHEL4-gtk2-Package is two years old and is to old for many current applications, as they depend on a newer gtk2. So if even if we would try to have a rolling scheme with with quite new package we'd fail, as we can't build a bunch of package due to this dependencies on libs; in the end we would have a repo with some quite new packages while others are still quite old. That mix wouldn't make either of the "latest versions" or "careful updates only" sides happy; so we try to target the "careful updates only" sides. Remember, EPEL's support cycle is much longer then Fedora's. === How will the repo actually look like === Similar to what [ http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/ layout] CentOS uses. Rough example: {{{ * epel/ # topdir * 4/ # topdir for EPEL4 * 4 -> 4.5 # symbolic link to latest version * 4.1/ # this tree of course will never exists, as this is history, and is here just to show the example .... # 4.2, 4.3, 4.4; those won't ever exists, too * 4.5/ # 4.5, latest version, build target: fedora-epel-4-stable * 4.6 # not yet * .... # time will come * testing/ # testing repo, that together with the old packages that didn't get update becomes 4.6 when RHEL 4.6 # releases; build target: fedora-epel-5; gets frozen for a week or two before the quarterly update is # issued; new packages land here for a while, too * 5/ # topdir for EPEL4 * 5 -> 5.0 # symbolic link to latest version * 5.0/ # 5.0, latest version, build target: fedora-epel-5-stable * 5.1 # not yet * .... # time will come * testing/ # testing repo, that together with the old packages that didn't get update becomes 4.6 when RHEL 4.6 # releases; build target: fedora-epel-5; gets frozen for a week or two before the quarterly update is # issued; new packages land here for a while, too }}} This layout may looks complicated, but has one major benefit: Users can stick to a EPEL repo for a not up2date EL release while a newer EL quarterly update is already out (some users do that on purpose, others have no chance as for example the CentOS update gets normally released up to four weeks after RHEL released a quarterly update). The above layout can makes it possible to prevent that users run into dependency issues that might arise otherwise if packages in the new EPEL release depend on new packages in the new EL release. The EPEL quarterly update further isn't forced on users before they switch to the quarterly update. Each repo always has all the packages in it; hardlinks will be used to keep the space requirements on the server-side limited, as most packages won't change. === What about EPEL4 === We start EPEL two years after RHEL4 started getting shipped. Pushing out packages today that were up2date two years ago might look a bit odd and will be hard to realize -- what version to choose exactly? So we simply take a slightly different route for EPEL4 and suggest our maintainers to consider using the stuff from http://centos.karan.org/ (which are based on Fedora Extras 3) as base for packages in EPEL4 -- that stuff is known to work and tested, so is a good base for the EPEL4 branch. Sure, the outcome would have looked a bit different than where we might have landed if we would have started EPEL two years ago, but well, we start now. ;-) From wtogami at redhat.com Mon Mar 12 18:28:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Mar 2007 14:28:25 -0400 Subject: RFC: Signed JAR Packaging Policy Message-ID: <45F59BC9.6030405@redhat.com> https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.html Red Hat's Directory Server team wants to add JSS to Fedora. But this is currently blocked, because the JSS JAR must be signed by an upstream key. This is currently not permissible under Fedora Packaging Guidelines for a few reasons: - The binary signed by an external source is not built by us. - We cannot build an exact duplicate in Fedora from sources (because of the binary signature.) - Distribution of a signed binary could be in violation of the spirit, if not the letter of FOSS licenses or Free Software Guidelines. This may also become automatically incompatible with the GPLv3. I am not a legal expert so I don't fully understand the implications of this. How do we handle this situation? --------------------------------------------------------------- 1) Build and Compare to At Least Prove Reproducible Equivalence --------------------------------------------------------------- https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html I theorized that it might be OK if we build the binary in Fedora, and compare it to the signed binary. If they match fully (except for the signature) then equivalence is proven. Throw away the built binary and use the signed binary in the payload RPM. https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00313.html But this method is most likely not technically feasible. It is also doubtful that this would qualify as Free Software. --------------------------------------------------------------- 2) Do Not Sign the Jar? --------------------------------------------------------------- - Only local applications would use JSS. - Those local applications (or the Java stack under it) could somehow choose to ignore the JAR's signature. - We shouldn't worry about this, because JSS (and those local apps) would be distributed themselves in signed RPMS. Only apps controlled by Red Hat may be able to use an unsigned JSS, by using JSS directly instead of going through JCA. This makes it fine for Fedora, RHEL and other flexible FOSS software, but 3rd party apps might not be compatible. Theoretically, 3rd party apps could use a second copy of the JSS JAR that is the upstream signed binary. Red Hat could even provide that somewhere on the side so users have something consistent. It just wont ship in Fedora proper. So, two JSS JAR's are possible for parallel install. - FOSS JSS (unsigned) - JSS (signed, but not in Fedora) Discuss feasibility? Warren Togami wtogami at redhat.com From jkeating at redhat.com Mon Mar 12 18:46:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 14:46:09 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F59BC9.6030405@redhat.com> References: <45F59BC9.6030405@redhat.com> Message-ID: <200703121446.10486.jkeating@redhat.com> On Monday 12 March 2007 14:28:25 Warren Togami wrote: > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.h >tml Red Hat's Directory Server team wants to add JSS to Fedora. ?But this is > currently blocked, because the JSS JAR must be signed by an upstream key. How does this work for pure end users that want to build / deploy? Are they completely unable to sign the jar themselves? Could we ship an unsigned jar, allow the end user to sign the jar using whatever method they need to? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Mar 12 18:52:48 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 12 Mar 2007 13:52:48 -0500 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121446.10486.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> Message-ID: <200703121352.48644.dennis@ausil.us> On Monday 12 March 2007 01:46:09 pm Jesse Keating wrote: > On Monday 12 March 2007 14:28:25 Warren Togami wrote: > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166 > >.h tml Red Hat's Directory Server team wants to add JSS to Fedora. ?But > > this is currently blocked, because the JSS JAR must be signed by an > > upstream key. > > How does this work for pure end users that want to build / deploy? Are > they completely unable to sign the jar themselves? Could we ship an > unsigned jar, allow the end user to sign the jar using whatever method they > need to? The only people that can sign the jar's are sun. No one else. -- Dennis Gilmore, RHCE From jkeating at redhat.com Mon Mar 12 18:57:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 14:57:41 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121352.48644.dennis@ausil.us> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> Message-ID: <200703121457.45678.jkeating@redhat.com> On Monday 12 March 2007 14:52:48 Dennis Gilmore wrote: > The only people that can sign the jar's are sun. ?No one else. Hrm, that doesn't match what I was asked internally, it sounded like we would be able to get it signed after we built it, but we wouldn't be able to expose that step that does the signing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Mar 12 18:56:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 19:56:33 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121446.10486.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> Message-ID: <1173725793.2488.10.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 14:46 -0400, Jesse Keating a ?crit : > On Monday 12 March 2007 14:28:25 Warren Togami wrote: > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.h > >tml Red Hat's Directory Server team wants to add JSS to Fedora. But this is > > currently blocked, because the JSS JAR must be signed by an upstream key. > > How does this work for pure end users that want to build / deploy? Are they > completely unable to sign the jar themselves? Could we ship an unsigned jar, > allow the end user to sign the jar using whatever method they need to? The problem is SUN controls the default certificate list in jvms, and it's reinitialised every time you update a vendor jvm, so in practical terms only SUN-approved keys "just work" Even if a user could authorise his own or Fedora's certificate (not sure he can) remembering to do it after every update is just too much hassle gcj could of course ignore this but knowing one can switch to a proprietary jvm any time goes a long way to reassure users. -- Nicolas Mailhot From rcritten at redhat.com Mon Mar 12 18:56:46 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2007 14:56:46 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F59BC9.6030405@redhat.com> References: <45F59BC9.6030405@redhat.com> Message-ID: <45F5A26E.40000@redhat.com> Warren Togami wrote: > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.html > > Red Hat's Directory Server team wants to add JSS to Fedora. But this is > currently blocked, because the JSS JAR must be signed by an upstream > key. This is currently not permissible under Fedora Packaging > Guidelines for a few reasons: > > - The binary signed by an external source is not built by us. > - We cannot build an exact duplicate in Fedora from sources (because of > the binary signature.) > - Distribution of a signed binary could be in violation of the spirit, > if not the letter of FOSS licenses or Free Software Guidelines. This > may also become automatically incompatible with the GPLv3. I am not a > legal expert so I don't fully understand the implications of this. > Here is a bit more information on this. JSS is, among other things, a Java Cryptography Extension (JCE) provider. This means that it provides cryptographic algorithms (block ciphers, etc). Sun requires all JCE providers to be signed by a Sun-issued X.509 certificate. This is partly for export reasons as well as to provide a level of confidence that the implemented provider you are using to perform your crypto operation is trusted. For more information on JCE/JCA see http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html One can request a signing cert from Sun at: http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CertForm.txt Fedora could likely get one of these certificates but then we'd have to find a way to protect the key material and still allow the JAR to be signed. The bottom line is that if the jar isn't signed and someoone tries to use the JCE classes in JSS they will fail with a nasty error message like: java.security.NoSuchProviderException: JCE cannot authenticate the provider Mozilla-JSS at javax.crypto.SunJCE_b.a(DashoA6275) at javax.crypto.SunJCE_b.a(DashoA6275) at javax.crypto.SecretKeyFactory.getInstance(DashoA6275) at org.mozilla.jss.tests.HMACTest.main(HMACTest.java:140) Caused by: java.util.jar.JarException: file:/usr/share/java/jss4-4.2.4.jar has unsigned entries - org/mozilla/jss/CRLImportException.class at javax.crypto.SunJCE_d.b(DashoA6275) at javax.crypto.SunJCE_d.a(DashoA6275) at javax.crypto.SunJCE_d.a(DashoA6275) at javax.crypto.SunJCE_b.b(DashoA6275) ... 4 more > How do we handle this situation? > > --------------------------------------------------------------- > 1) Build and Compare to At Least Prove Reproducible Equivalence > --------------------------------------------------------------- > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html > > I theorized that it might be OK if we build the binary in Fedora, and > compare it to the signed binary. If they match fully (except for the > signature) then equivalence is proven. Throw away the built binary and > use the signed binary in the payload RPM. > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00313.html > > But this method is most likely not technically feasible. > > It is also doubtful that this would qualify as Free Software. > > --------------------------------------------------------------- > 2) Do Not Sign the Jar? > --------------------------------------------------------------- > - Only local applications would use JSS. > - Those local applications (or the Java stack under it) could somehow > choose to ignore the JAR's signature. > - We shouldn't worry about this, because JSS (and those local apps) > would be distributed themselves in signed RPMS. > > Only apps controlled by Red Hat may be able to use an unsigned JSS, by > using JSS directly instead of going through JCA. This makes it fine for > Fedora, RHEL and other flexible FOSS software, but 3rd party apps might > not be compatible. > > Theoretically, 3rd party apps could use a second copy of the JSS JAR > that is the upstream signed binary. Red Hat could even provide that > somewhere on the side so users have something consistent. It just wont > ship in Fedora proper. > > So, two JSS JAR's are possible for parallel install. > - FOSS JSS (unsigned) > - JSS (signed, but not in Fedora) > > Discuss feasibility? > > Warren Togami > wtogami at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Mon Mar 12 18:59:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 19:59:40 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121457.45678.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> <200703121457.45678.jkeating@redhat.com> Message-ID: <1173725980.2488.14.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 14:57 -0400, Jesse Keating a ?crit : > On Monday 12 March 2007 14:52:48 Dennis Gilmore wrote: > > The only people that can sign the jar's are sun. No one else. > > Hrm, that doesn't match what I was asked internally, it sounded like we would > be able to get it signed after we built it, but we wouldn't be able to expose > that step that does the signing. SUN has been known to bless third-party signing certificates provided their use was restricted to a well-defined entity. So a Red Hat certificate is a possibility. A Fedora one would conflict with the project charter. -- Nicolas Mailhot From jkeating at redhat.com Mon Mar 12 19:06:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 15:06:24 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173725980.2488.14.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <200703121457.45678.jkeating@redhat.com> <1173725980.2488.14.camel@rousalka.dyndns.org> Message-ID: <200703121506.24559.jkeating@redhat.com> On Monday 12 March 2007 14:59:40 Nicolas Mailhot wrote: > SUN has been known to bless third-party signing certificates provided > their use was restricted to a well-defined entity. So a Red Hat > certificate is a possibility. A Fedora one would conflict with the > project charter. Indeed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 12 19:20:32 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2007 15:20:32 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173725980.2488.14.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> <200703121457.45678.jkeating@redhat.com> <1173725980.2488.14.camel@rousalka.dyndns.org> Message-ID: <45F5A800.5080008@redhat.com> Nicolas Mailhot wrote: > Le lundi 12 mars 2007 ? 14:57 -0400, Jesse Keating a ?crit : >> On Monday 12 March 2007 14:52:48 Dennis Gilmore wrote: >>> The only people that can sign the jar's are sun. No one else. >> Hrm, that doesn't match what I was asked internally, it sounded like we would >> be able to get it signed after we built it, but we wouldn't be able to expose >> that step that does the signing. > > SUN has been known to bless third-party signing certificates provided > their use was restricted to a well-defined entity. So a Red Hat > certificate is a possibility. A Fedora one would conflict with the > project charter. > Right. A signing certificate can be requested by filling this out and faxing it to Sun: http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CertForm.txt What their policies are for issuing certificates I don't know. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From wtogami at redhat.com Mon Mar 12 20:33:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Mar 2007 16:33:22 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173725793.2488.10.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <1173725793.2488.10.camel@rousalka.dyndns.org> Message-ID: <45F5B912.8020004@redhat.com> Nicolas Mailhot wrote: > > The problem is SUN controls the default certificate list in jvms, and > it's reinitialised every time you update a vendor jvm, so in practical > terms only SUN-approved keys "just work" > This might have interesting consequences for Sun's plans to GPLv3 their Java. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Mon Mar 12 20:36:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Mar 2007 16:36:22 -0400 Subject: festival 1.96 packages in the works.... Message-ID: <20070312203622.GA18906@jadzia.bu.edu> I'm working on updating Festival to 1.96. (I did the basic work for the upgrade from 1.4, and added the hts voices.) I'm also doing quite a bit of cleanup, and intend to split out the voices so a much smaller minimal configuration can be installed. Will post soon. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Mon Mar 12 20:42:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 21:42:11 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5B912.8020004@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <1173725793.2488.10.camel@rousalka.dyndns.org> <45F5B912.8020004@redhat.com> Message-ID: <1173732131.4032.1.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 16:33 -0400, Warren Togami a ?crit : > Nicolas Mailhot wrote: > > > > The problem is SUN controls the default certificate list in jvms, and > > it's reinitialised every time you update a vendor jvm, so in practical > > terms only SUN-approved keys "just work" > > > > This might have interesting consequences for Sun's plans to GPLv3 their > Java. I hope they dump their stupid signing requirement. They already managed to "forget" to update one of their root certificates in the past -- Nicolas Mailhot From wtogami at redhat.com Mon Mar 12 20:57:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Mar 2007 16:57:45 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5A800.5080008@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> <200703121457.45678.jkeating@redhat.com> <1173725980.2488.14.camel@rousalka.dyndns.org> <45F5A800.5080008@redhat.com> Message-ID: <45F5BEC9.6090408@redhat.com> Rob Crittenden wrote: >> >> SUN has been known to bless third-party signing certificates provided >> their use was restricted to a well-defined entity. So a Red Hat >> certificate is a possibility. A Fedora one would conflict with the >> project charter. >> > > Right. A signing certificate can be requested by filling this out and > faxing it to Sun: > > http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CertForm.txt > > > What their policies are for issuing certificates I don't know. > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html This plan might work then, with slight modification. 1) Fedora spec file builds the JAR from sources, intermediate binary output (using a boolean in the spec or something). 2) Red Hat has a Sun blessed signing key, signing that intermediate binary. 3) In the actual package build: Fedora SRPM contains both the original source and the signed binary from step #2. Build again. 4) Compare the signed JAR to the new JAR, to be sure that they match in all ways except the signature. 5) IF THEY MATCH, throw away the built copy and ship the signed JAR. Why this is good? The shipping binary is confirmed to be reproducible from source. Red Hat is clearly not holding anything back, no secrets. Why this is bad? It still is not fully reproducible in a sense that other people can't take our source, modify it slightly, and make a Sun-blessed JSS JAR. The key question: Is this acceptable to the Fedora Project? How do we draw *our* line between acts that promote and hurt freedom? In my personal opinion, we should just allow very narrowly defined cases like this. Why? - Fedora already disagrees with the FSF's position against independent, closed firmware. (Fedora *is* firmly against closed drivers or GPL flaunting like ipw3945). We are already "impure" by their arguably extreme standards. They are free to have their own opinion, we are free to have our own differing opinion. - This violates nobody's copyrights (except maybe later with GPLv3...) - This promotes the spirit of FOSS's ideals without compromising on those ideals. Thoughts? Warren Togami wtogami at redhat.com From mattdm at mattdm.org Mon Mar 12 21:02:06 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Mar 2007 17:02:06 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5BEC9.6090408@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> <200703121457.45678.jkeating@redhat.com> <1173725980.2488.14.camel@rousalka.dyndns.org> <45F5A800.5080008@redhat.com> <45F5BEC9.6090408@redhat.com> Message-ID: <20070312210206.GA21097@jadzia.bu.edu> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: > Why this is bad? > It still is not fully reproducible in a sense that other people can't > take our source, modify it slightly, and make a Sun-blessed JSS JAR. I'm really against it. At the very least, it screws over CentOS. This a bad path to be going down. I'd much prefer gcj and the future Fedora-shipped implementation of the Sun JVM to make it easy to use self-generated certificates. If someone wants to install a proprietary JVM, let's make _that_ the hard case. > - This promotes the spirit of FOSS's ideals without compromising on > those ideals. Except it doesn't, and it doesn't. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Mar 12 21:10:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 17:10:24 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <20070312210206.GA21097@jadzia.bu.edu> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> Message-ID: <200703121710.28253.jkeating@redhat.com> On Monday 12 March 2007 17:02:06 Matthew Miller wrote: > On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: > > Why this is bad? > > It still is not fully reproducible in a sense that other people can't > > take our source, modify it slightly, and make a Sun-blessed JSS JAR. > > I'm really against it. At the very least, it screws over CentOS. This a bad > path to be going down. > > I'd much prefer gcj and the future Fedora-shipped implementation of the Sun > JVM to make it easy to use self-generated certificates. If someone wants to > install a proprietary JVM, let's make _that_ the hard case. I agree. How much fun would it be if apache suddenly decided to not function with self signed certs and any cert you used had to come from verasign ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cweyl at alumni.drew.edu Mon Mar 12 21:12:19 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 12 Mar 2007 14:12:19 -0700 Subject: setting a flag via bugzilla's xlmrpc interface? Message-ID: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> Hey all-- RH's bugzilla has a (poorly documented) xmlrpc interface. Does anyone know either: * how to get/set flags using it? * where it's documented? (Assuming I just can't find it; I might just be looking in the wrong places) * or, best of all, where a copy of xmlrpc.cgi is kicking around, that I can take a peek at? Thanks :) -Chris -- Chris Weyl Ex astris, scientia From wtogami at redhat.com Mon Mar 12 21:13:44 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Mar 2007 17:13:44 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121710.28253.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> Message-ID: <45F5C288.5090507@redhat.com> Jesse Keating wrote: >> >> I'd much prefer gcj and the future Fedora-shipped implementation of the Sun >> JVM to make it easy to use self-generated certificates. If someone wants to >> install a proprietary JVM, let's make _that_ the hard case. > > I agree. How much fun would it be if apache suddenly decided to not function > with self signed certs and any cert you used had to come from verasign ? > Hmm, CentOS is a good counter argument. I guess, we don't have any way of shipping a signed JAR in Fedora. The best we can do is to ship an unsigned JAR and make all FOSS software not require the signature (because we relied on the RPM sig instead). If others want to provide a parallel install signed JAR RPM for arbitrary 3rd party software to use, that is their decision. Warren Togami wtogami at redhat.com From rmeggins at redhat.com Mon Mar 12 21:16:58 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Mar 2007 15:16:58 -0600 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121710.28253.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> Message-ID: <45F5C34A.4040405@redhat.com> Jesse Keating wrote: > On Monday 12 March 2007 17:02:06 Matthew Miller wrote: > >> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: >> >>> Why this is bad? >>> It still is not fully reproducible in a sense that other people can't >>> take our source, modify it slightly, and make a Sun-blessed JSS JAR. >>> >> I'm really against it. At the very least, it screws over CentOS. This a bad >> path to be going down. >> >> I'd much prefer gcj and the future Fedora-shipped implementation of the Sun >> JVM to make it easy to use self-generated certificates. If someone wants to >> install a proprietary JVM, let's make _that_ the hard case. >> > > I agree. How much fun would it be if apache suddenly decided to not function > with self signed certs and any cert you used had to come from verasign ? > A radical way to do this would be for Fedora to acquire a signing cert from Sun, and redistribute the key and cert with the JSS package. Plus: Anyone would be able to build and redistribute JSS, and it would load into any Java JCE implementation which required a signed jar. Minus: Anyone would be able to build and sign _any_ jar and claim that it was from Fedora, which would completely defeat the purpose of JCE, as well as any other application which required jar signing. For example, I download a random Java applet into my browser, and the dialog box pops up which says "This jar file was signed by the Fedora Completely Untrustworthy Key. Do you Accept or Decline to run this jar?" I don't exactly know what Sun would do if such a thing were to be unleashed into the wild . . . > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 12 21:29:32 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 12 Mar 2007 17:29:32 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5B912.8020004@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <1173725793.2488.10.camel@rousalka.dyndns.org> <45F5B912.8020004@redhat.com> Message-ID: <1173734972.7569.20.camel@localhost.localdomain> On Mon, 2007-03-12 at 16:33 -0400, Warren Togami wrote: > Nicolas Mailhot wrote: > > > > The problem is SUN controls the default certificate list in jvms, and > > it's reinitialised every time you update a vendor jvm, so in practical > > terms only SUN-approved keys "just work" > > > > This might have interesting consequences for Sun's plans to GPLv3 their > Java. Why? Is their own signature required for the package to work, and nothing else will work even if rebuilt from scratch? Simo. From tcallawa at redhat.com Mon Mar 12 21:34:28 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Mar 2007 16:34:28 -0500 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5C34A.4040405@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <45F5C34A.4040405@redhat.com> Message-ID: <1173735268.25122.33.camel@localhost.localdomain> On Mon, 2007-03-12 at 15:16 -0600, Richard Megginson wrote: > Jesse Keating wrote: > > On Monday 12 March 2007 17:02:06 Matthew Miller wrote: > > > >> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: > >> > >>> Why this is bad? > >>> It still is not fully reproducible in a sense that other people can't > >>> take our source, modify it slightly, and make a Sun-blessed JSS JAR. > >>> > >> I'm really against it. At the very least, it screws over CentOS. This a bad > >> path to be going down. > >> > >> I'd much prefer gcj and the future Fedora-shipped implementation of the Sun > >> JVM to make it easy to use self-generated certificates. If someone wants to > >> install a proprietary JVM, let's make _that_ the hard case. > >> > > > > I agree. How much fun would it be if apache suddenly decided to not function > > with self signed certs and any cert you used had to come from verasign ? > > > A radical way to do this would be for Fedora to acquire a signing cert > from Sun, and redistribute the key and cert with the JSS package. Clarification: Fedora can't acquire a signing cert from Sun. Only Red Hat, Inc can. I doubt Red Hat is willing to get a cert/key, then freely distribute them with the packages. I can hear lawyers screaming at the thought. IMHO, either we ship them unsigned, or we don't ship them. When Sun GPLs the Java bits, we can fix this properly. ~spot From fitzsim at redhat.com Mon Mar 12 21:55:34 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 12 Mar 2007 17:55:34 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173735268.25122.33.camel@localhost.localdomain> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <45F5C34A.4040405@redhat.com> <1173735268.25122.33.camel@localhost.localdomain> Message-ID: <45F5CC56.5080907@redhat.com> Tom 'spot' Callaway wrote: > On Mon, 2007-03-12 at 15:16 -0600, Richard Megginson wrote: >> Jesse Keating wrote: >>> On Monday 12 March 2007 17:02:06 Matthew Miller wrote: >>> >>>> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: >>>> >>>>> Why this is bad? >>>>> It still is not fully reproducible in a sense that other people can't >>>>> take our source, modify it slightly, and make a Sun-blessed JSS JAR. >>>>> >>>> I'm really against it. At the very least, it screws over CentOS. This a bad >>>> path to be going down. >>>> >>>> I'd much prefer gcj and the future Fedora-shipped implementation of the Sun >>>> JVM to make it easy to use self-generated certificates. If someone wants to >>>> install a proprietary JVM, let's make _that_ the hard case. >>>> >>> I agree. How much fun would it be if apache suddenly decided to not function >>> with self signed certs and any cert you used had to come from verasign ? >>> >> A radical way to do this would be for Fedora to acquire a signing cert >> from Sun, and redistribute the key and cert with the JSS package. > > Clarification: Fedora can't acquire a signing cert from Sun. Only Red > Hat, Inc can. > > I doubt Red Hat is willing to get a cert/key, then freely distribute > them with the packages. I can hear lawyers screaming at the thought. > > IMHO, either we ship them unsigned, or we don't ship them. Agreed, except there's no reason not to ship them. So I say ship them unsigned for use on gcj now, and then... > When Sun GPLs the Java bits, we can fix this properly. Tom From nicolas.mailhot at laposte.net Mon Mar 12 22:13:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 23:13:25 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173734972.7569.20.camel@localhost.localdomain> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <1173725793.2488.10.camel@rousalka.dyndns.org> <45F5B912.8020004@redhat.com> <1173734972.7569.20.camel@localhost.localdomain> Message-ID: <1173737605.4793.0.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 17:29 -0400, Simo Sorce a ?crit : > On Mon, 2007-03-12 at 16:33 -0400, Warren Togami wrote: > > Nicolas Mailhot wrote: > > > > > > The problem is SUN controls the default certificate list in jvms, and > > > it's reinitialised every time you update a vendor jvm, so in practical > > > terms only SUN-approved keys "just work" > > > > > > > This might have interesting consequences for Sun's plans to GPLv3 their > > Java. > > Why? > Is their own signature required for the package to work, and nothing > else will work even if rebuilt from scratch? commercial jvms will barf if a crypto package is not signed with a SUN-approved certificate -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 12 22:19:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 23:19:45 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173735268.25122.33.camel@localhost.localdomain> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <45F5C34A.4040405@redhat.com> <1173735268.25122.33.camel@localhost.localdomain> Message-ID: <1173737985.4793.7.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 16:34 -0500, Tom 'spot' Callaway a ?crit : > Clarification: Fedora can't acquire a signing cert from Sun. Only Red > Hat, Inc can. Fedora sure can, OSS projects like bouncycastle did in the past. Now even assuming SUN is stupid enough not to require a legally binding agreement not to redistribute those signing certs, it still has the "revoke at will" card. -- Nicolas Mailhot From tcallawa at redhat.com Mon Mar 12 22:31:15 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Mar 2007 17:31:15 -0500 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173737985.4793.7.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <45F5C34A.4040405@redhat.com> <1173735268.25122.33.camel@localhost.localdomain> <1173737985.4793.7.camel@rousalka.dyndns.org> Message-ID: <1173738675.25122.35.camel@localhost.localdomain> On Mon, 2007-03-12 at 23:19 +0100, Nicolas Mailhot wrote: > Le lundi 12 mars 2007 ? 16:34 -0500, Tom 'spot' Callaway a ?crit : > > > Clarification: Fedora can't acquire a signing cert from Sun. Only Red > > Hat, Inc can. > > Fedora sure can, OSS projects like bouncycastle did in the past. > > Now even assuming SUN is stupid enough not to require a legally binding > agreement not to redistribute those signing certs, it still has the > "revoke at will" card. The legal document that SUN wants groups to sign to get a cert point blank asks for "Company". Fedora is not a Company. :/ ~spot From tcallawa at redhat.com Mon Mar 12 22:36:21 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Mar 2007 17:36:21 -0500 Subject: PackageReviewProcess Message-ID: <1173738981.25122.41.camel@localhost.localdomain> I've created a new page: http://fedoraproject.org/wiki/PackageReviewProcess This page documents the process of reviewing a Fedora package, from both the contributor and reviewer perspective. Much of this content was taken from the ReviewGuidelines page, but the following changes have been applied: - Packaging/ReviewGuidelines is now just for Packaging MUSTs and SHOULDs. (It does have a link back to PackageReviewProcess, for people looking for that content) - PackageReviewProcess reflects the current CVS branching mechanism, and the new fedora-review flag process. It also no longer distinguishes between Core and Extras (when Extras goes away, there will need to be some minor changes, mostly in bugzilla URLs) I made this change so that the Review Process document could be kept current by motivated Fedora participants, and not restricted to the Packaging Committee. The list of "MUSTs and SHOULDs" for review is still controlled by the Fedora Packaging Committee. As always, any and all feedback is welcomed. Thanks, ~spot From jeff at ocjtech.us Tue Mar 13 01:13:41 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 12 Mar 2007 20:13:41 -0500 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173737605.4793.0.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <1173725793.2488.10.camel@rousalka.dyndns.org> <45F5B912.8020004@redhat.com> <1173734972.7569.20.camel@localhost.localdomain> <1173737605.4793.0.camel@rousalka.dyndns.org> Message-ID: <1173748421.3806.3.camel@lt21223.campus.dmacc.edu> On Mon, 2007-03-12 at 23:13 +0100, Nicolas Mailhot wrote: > Le lundi 12 mars 2007 ? 17:29 -0400, Simo Sorce a ?crit : > > On Mon, 2007-03-12 at 16:33 -0400, Warren Togami wrote: > > > Nicolas Mailhot wrote: > > > > > > > > The problem is SUN controls the default certificate list in jvms, and > > > > it's reinitialised every time you update a vendor jvm, so in practical > > > > terms only SUN-approved keys "just work" > > > > > > > > > > This might have interesting consequences for Sun's plans to GPLv3 their > > > Java. > > > > Why? > > Is their own signature required for the package to work, and nothing > > else will work even if rebuilt from scratch? > > commercial jvms will barf if a crypto package is not signed with a > SUN-approved certificate Won't commercial JVMs ship with their own signed binary crypto package? Or alternatively, if you're willing to run a commercial JVM, you're probably willing to go download the signed binary crypto package. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From petersen at redhat.com Tue Mar 13 02:14:59 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 13 Mar 2007 12:14:59 +1000 Subject: [rpmlint] obsolete-not-provided and versioned obsoletes In-Reply-To: <20070312120933.GA7809@jadzia.bu.edu> References: <45F4D2E1.5060606@redhat.com> <20070312120933.GA7809@jadzia.bu.edu> Message-ID: <45F60923.9000804@redhat.com> Matthew Miller wrote: > On Mon, Mar 12, 2007 at 02:11:13PM +1000, Jens Petersen wrote: >> Should rpmlint be updated to only warn about versioned obsoletes without >> provides? > > I think it's a reasonable warning -- not all warnings are errors. Yup, but rpmlint is marking it as a error AFAICT. Jens From alan at redhat.com Tue Mar 13 02:33:09 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Mar 2007 22:33:09 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F5BEC9.6090408@redhat.com> References: <45F59BC9.6030405@redhat.com> <200703121446.10486.jkeating@redhat.com> <200703121352.48644.dennis@ausil.us> <200703121457.45678.jkeating@redhat.com> <1173725980.2488.14.camel@rousalka.dyndns.org> <45F5A800.5080008@redhat.com> <45F5BEC9.6090408@redhat.com> Message-ID: <20070313023309.GB11946@devserv.devel.redhat.com> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: > Why this is bad? > It still is not fully reproducible in a sense that other people can't > take our source, modify it slightly, and make a Sun-blessed JSS JAR. And can't be used for GPL projects according to some interpretations of GPL v2. "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." Preferred form for making a work might well be held to include keys. Or you could argue its an interface definition, or perhaps an install script or .. Best not to go there Alan From bugs.michael at gmx.net Tue Mar 13 07:01:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 13 Mar 2007 08:01:37 +0100 Subject: Paul F. Johnson Message-ID: <20070313080137.a5154000.bugs.michael@gmx.net> Trying to get another reply from "Paul F. Johnson" in bugzilla has failed since 2007-02-16, 2007-02-26, and 2007-03-02: https://bugzilla.redhat.com/220187 Upstream has been very quick in merging my patches, and thanks to his new release, multiple issues are fixed in a convienent way. Please let's get this easy-fix closed. From ville.skytta at iki.fi Tue Mar 13 07:48:11 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 13 Mar 2007 09:48:11 +0200 Subject: [rpmlint] obsolete-not-provided and versioned obsoletes In-Reply-To: <45F60923.9000804@redhat.com> References: <45F4D2E1.5060606@redhat.com> <20070312120933.GA7809@jadzia.bu.edu> <45F60923.9000804@redhat.com> Message-ID: <200703130948.11686.ville.skytta@iki.fi> On Tuesday 13 March 2007, Jens Petersen wrote: > Matthew Miller wrote: > > On Mon, Mar 12, 2007 at 02:11:13PM +1000, Jens Petersen wrote: > >> Should rpmlint be updated to only warn about versioned obsoletes without > >> provides? > > > > I think it's a reasonable warning -- not all warnings are errors. > > Yup, but rpmlint is marking it as a error AFAICT. Fixed upstream: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1325 From Christian.Iseli at licr.org Tue Mar 13 08:48:53 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 13 Mar 2007 09:48:53 +0100 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> Message-ID: <20070313094853.0163428e@ludwig-alpha.unil.ch> On Mon, 12 Mar 2007 14:12:19 -0700, Chris Weyl wrote: > * how to get/set flags using it? For getting a flag, I'm not sure. Examples to detect if a flag has a given value can be found in my scripts in CVS: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/getReviewByFlags?root=fedora&rev=1.1&view=auto http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/pyGetReviewByFlags?root=fedora&rev=1.1&view=auto Setting a flag can apparently be done thusly (not tested): #!/usr/bin/perl -w use XMLRPC::Lite; use Data::Dumper; my $bugid = shift; my $username = shift; my $password = shift; my $data = { 'devel_ack' => 'X', 'pm_ack' => 'X', 'qa_ack' => 'X', }; my $rpc = new XMLRPC::Lite(proxy=>'https://bugzilla.redhat.com/bugzilla/xmlrpc.cgi'); my $call = $rpc->call('bugzilla.updateFlags', $bugid, $data, $username, $password); my $result = ""; if ($call->faultstring) { print $call->faultstring . "\n"; exit; } else { $result = $call->result; } print Dumper($result); HTH, C From aph at redhat.com Tue Mar 13 10:06:13 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Mar 2007 10:06:13 +0000 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F59BC9.6030405@redhat.com> References: <45F59BC9.6030405@redhat.com> Message-ID: <17910.30613.294621.496179@zebedee.pink> Warren Togami writes: > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.html > Red Hat's Directory Server team wants to add JSS to Fedora. But this is > currently blocked, because the JSS JAR must be signed by an upstream > key. What problem, exactly, are we trying to solve here? Is it to do with compatibility with unfree Java VMs? If people wish to install unfree VMs, then they can also install a suitably signed copy of the Mozilla-JSS JCA Provider. Andrew. From gbenson at redhat.com Tue Mar 13 11:57:43 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 13 Mar 2007 11:57:43 +0000 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <200703121710.28253.jkeating@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> Message-ID: <20070313115743.GC4136@redhat.com> Jesse Keating wrote: > On Monday 12 March 2007 17:02:06 Matthew Miller wrote: > > On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: > > > Why this is bad? > > > It still is not fully reproducible in a sense that other > > > people can't take our source, modify it slightly, and make > > > a Sun-blessed JSS JAR. > > > > I'm really against it. At the very least, it screws over > > CentOS. This a bad path to be going down. > > > > I'd much prefer gcj and the future Fedora-shipped implementation > > of the Sun JVM to make it easy to use self-generated certificates. > > If someone wants to install a proprietary JVM, let's make _that_ > > the hard case. > > I agree. How much fun would it be if apache suddenly decided to not > function with self signed certs and any cert you used had to come > from verasign ? It's not the same thing. With httpd each user generates their own certificate. With signed jarfiles it'd be one key for all of Fedora. And signing with a key you then distribute provides no security at all. I'd argue that Warren's two-step build doesn't screw over CentOS, or anyone else for that matter. Anyone wanting to rebuild could simply rebuild (steps 3-5). Anyone wanting to modify would get their own key from Sun and do the full two-step thing (steps 1-5). There's even a refinement in that jarfile signatures are not rigidly bound to their jars, so rather than shipping an entire jar in the source rpm we could simply bundle the signature information and insert that into the jar we built. Of course, this is only required to support users running proprietary JVMs. GCJ doesn't check signatures, and we can disable checks in any other JVM we ship in Fedora. It doesn't even have to be a complete disablement either. It's not so much that the code must be signed as that the code must be loaded from a trusted source. Currently there's no distinction between the two, but there's nothing stopping us from introducing other trusted sources. There is already the endorsed standards override mechanism that basically states that code loaded from specific system- and user-defined directories is considered to be "endorsed" and therefore allowed to override core system classes. We could mirror this and have it that code loaded from specific directories be considered to be trusted. Cheers, Gary From jkeating at redhat.com Tue Mar 13 14:48:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Mar 2007 10:48:21 -0400 Subject: Seeking co-maintainer Message-ID: <200703131048.21975.jkeating@redhat.com> For: libburn libisofs Mostly it has been just rolling in new upstream releases, but there is one open bug around multilib. The docs are generated at buildtime and thus conflict when multilib. The build time generated docs should probably be moved to a -docs package which wouldn't be multilib. Any takers? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Tue Mar 13 15:04:42 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 13 Mar 2007 16:04:42 +0100 Subject: Seeking co-maintainer In-Reply-To: <200703131048.21975.jkeating@redhat.com> References: <200703131048.21975.jkeating@redhat.com> Message-ID: <45F6BD8A.8050405@poolshark.org> Jesse Keating wrote: > For: > > libburn > libisofs > > Mostly it has been just rolling in new upstream releases, but there is one > open bug around multilib. The docs are generated at buildtime and thus > conflict when multilib. The build time generated docs should probably be > moved to a -docs package which wouldn't be multilib. > > Any takers? Sure! -d From rcritten at redhat.com Tue Mar 13 17:54:56 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Mar 2007 13:54:56 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <20070313115743.GC4136@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> Message-ID: <45F6E570.6040807@redhat.com> Gary Benson wrote: > Jesse Keating wrote: >> On Monday 12 March 2007 17:02:06 Matthew Miller wrote: >>> On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote: >>>> Why this is bad? >>>> It still is not fully reproducible in a sense that other >>>> people can't take our source, modify it slightly, and make >>>> a Sun-blessed JSS JAR. >>> I'm really against it. At the very least, it screws over >>> CentOS. This a bad path to be going down. >>> >>> I'd much prefer gcj and the future Fedora-shipped implementation >>> of the Sun JVM to make it easy to use self-generated certificates. >>> If someone wants to install a proprietary JVM, let's make _that_ >>> the hard case. >> I agree. How much fun would it be if apache suddenly decided to not >> function with self signed certs and any cert you used had to come >> from verasign ? > > It's not the same thing. With httpd each user generates their own > certificate. With signed jarfiles it'd be one key for all of Fedora. > And signing with a key you then distribute provides no security at > all. > > I'd argue that Warren's two-step build doesn't screw over CentOS, or > anyone else for that matter. Anyone wanting to rebuild could simply > rebuild (steps 3-5). Anyone wanting to modify would get their own key > from Sun and do the full two-step thing (steps 1-5). There's even a > refinement in that jarfile signatures are not rigidly bound to their > jars, so rather than shipping an entire jar in the source rpm we could > simply bundle the signature information and insert that into the jar > we built. This is assuming that the jar we build is identical to the Mozilla jar without the signature, right? How would we want to go about implementing Warren's idea? I assume we'd check in the Mozilla-signed jar as a source? Would this cause anyone major heartburn? > Of course, this is only required to support users running proprietary > JVMs. GCJ doesn't check signatures, and we can disable checks in any > other JVM we ship in Fedora. It doesn't even have to be a complete > disablement either. It's not so much that the code must be signed as > that the code must be loaded from a trusted source. Currently there's > no distinction between the two, but there's nothing stopping us from > introducing other trusted sources. There is already the endorsed > standards override mechanism that basically states that code loaded > from specific system- and user-defined directories is considered to > be "endorsed" and therefore allowed to override core system classes. > We could mirror this and have it that code loaded from specific > directories be considered to be trusted. But any random JVM that a user downloads from Sun or IBM directly wouldn't know about this extra endorsement, right? So any non-rpm-installed JVMs would still not work? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mattdm at mattdm.org Tue Mar 13 18:01:23 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Mar 2007 14:01:23 -0400 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F6E570.6040807@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> <45F6E570.6040807@redhat.com> Message-ID: <20070313180123.GA25603@jadzia.bu.edu> On Tue, Mar 13, 2007 at 01:54:56PM -0400, Rob Crittenden wrote: > But any random JVM that a user downloads from Sun or IBM directly > wouldn't know about this extra endorsement, right? So any > non-rpm-installed JVMs would still not work? They would work fine for whatever they were installed for. They just wouldn't work for this. Presuming that "this" can be made to work just fine with gcj and/or future-free-java, then it should just stay that way. Am I not getting something? I mean, do we consider "the kernel doesn't build with Microsoft C" a problem? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Tue Mar 13 18:13:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Mar 2007 19:13:08 +0100 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <20070313180123.GA25603@jadzia.bu.edu> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> <45F6E570.6040807@redhat.com> <20070313180123.GA25603@jadzia.bu.edu> Message-ID: <1173809588.6853.4.camel@rousalka.dyndns.org> Le mardi 13 mars 2007 ? 14:01 -0400, Matthew Miller a ?crit : > On Tue, Mar 13, 2007 at 01:54:56PM -0400, Rob Crittenden wrote: > > But any random JVM that a user downloads from Sun or IBM directly > > wouldn't know about this extra endorsement, right? So any > > non-rpm-installed JVMs would still not work? > > They would work fine for whatever they were installed for. They just > wouldn't work for this. Presuming that "this" can be made to work just fine > with gcj and/or future-free-java, then it should just stay that way. Am I > not getting something? > > I mean, do we consider "the kernel doesn't build with Microsoft C" a > problem? The kernel is mature and the main implementation. If fedora-packaged java apps fail when people try to use them with proprietary jvms that's a bigger problem. Till gcj is mature, efficient and recognized in the marketplace being able to mix and replace components (including the jvm) is a huge plus. (now on this particular point, I don't see how we can accommodate SUN & Fedora requirements, and Fedora goals come first) -- Nicolas Mailhot From aph at redhat.com Tue Mar 13 18:21:56 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Mar 2007 18:21:56 +0000 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173809588.6853.4.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> <45F6E570.6040807@redhat.com> <20070313180123.GA25603@jadzia.bu.edu> <1173809588.6853.4.camel@rousalka.dyndns.org> Message-ID: <17910.60356.871645.559593@zebedee.pink> Nicolas Mailhot writes: > Le mardi 13 mars 2007 ? 14:01 -0400, Matthew Miller a ?crit : > > On Tue, Mar 13, 2007 at 01:54:56PM -0400, Rob Crittenden wrote: > > > But any random JVM that a user downloads from Sun or IBM directly > > > wouldn't know about this extra endorsement, right? So any > > > non-rpm-installed JVMs would still not work? > > > > They would work fine for whatever they were installed for. They just > > wouldn't work for this. Presuming that "this" can be made to work just fine > > with gcj and/or future-free-java, then it should just stay that way. Am I > > not getting something? > > > > I mean, do we consider "the kernel doesn't build with Microsoft C" a > > problem? > > The kernel is mature and the main implementation. If > fedora-packaged java apps fail when people try to use them with > proprietary jvms that's a bigger problem. Till gcj is mature, > efficient and recognized in the marketplace being able to mix and > replace components (including the jvm) is a huge plus. > > (now on this particular point, I don't see how we can accommodate > SUN & Fedora requirements, and Fedora goals come first) It's just a dependency, no different from any other package dependency. A proprietary Java runtime environment that needs signed crypto JARs has a dependency on such JARs. When such a proprietary JRE is installed, the signed crypto JARs it needs should be installed with it. Andrew. From gbenson at redhat.com Tue Mar 13 18:51:13 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 13 Mar 2007 18:51:13 +0000 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <45F6E570.6040807@redhat.com> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> <45F6E570.6040807@redhat.com> Message-ID: <20070313185113.GA5657@redhat.com> Rob Crittenden wrote: > Gary Benson wrote: > > I'd argue that Warren's two-step build doesn't screw over CentOS, > > or anyone else for that matter. Anyone wanting to rebuild could > > simply rebuild (steps 3-5). Anyone wanting to modify would get > > their own key from Sun and do the full two-step thing (steps 1-5). > > There's even a refinement in that jarfile signatures are not > > rigidly bound to their jars, so rather than shipping an entire jar > > in the source rpm we could simply bundle the signature information > > and insert that into the jar we built. > > This is assuming that the jar we build is identical to the Mozilla > jar without the signature, right? No. Warren's idea was this one: https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00446.html Cheers, Gary From gbenson at redhat.com Tue Mar 13 18:53:01 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 13 Mar 2007 18:53:01 +0000 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <1173809588.6853.4.camel@rousalka.dyndns.org> References: <45F59BC9.6030405@redhat.com> <45F5BEC9.6090408@redhat.com> <20070312210206.GA21097@jadzia.bu.edu> <200703121710.28253.jkeating@redhat.com> <20070313115743.GC4136@redhat.com> <45F6E570.6040807@redhat.com> <20070313180123.GA25603@jadzia.bu.edu> <1173809588.6853.4.camel@rousalka.dyndns.org> Message-ID: <20070313185301.GB5657@redhat.com> Nicolas Mailhot wrote: > Le mardi 13 mars 2007 ? 14:01 -0400, Matthew Miller a ?crit : > > On Tue, Mar 13, 2007 at 01:54:56PM -0400, Rob Crittenden wrote: > > > But any random JVM that a user downloads from Sun or IBM > > > directly wouldn't know about this extra endorsement, right? > > > So any non-rpm-installed JVMs would still not work? > > > > They would work fine for whatever they were installed for. They > > just wouldn't work for this. Presuming that "this" can be made to > > work just fine with gcj and/or future-free-java, then it should > > just stay that way. Am I not getting something? > > > > I mean, do we consider "the kernel doesn't build with Microsoft C" > > a problem? > > The kernel is mature and the main implementation. If fedora-packaged > java apps fail when people try to use them with proprietary jvms > that's a bigger problem. Till gcj is mature, efficient and > recognized in the marketplace being able to mix and replace > components (including the jvm) is a huge plus. I was thinking with a view that post-F7 we will likely be able to ship a modified Sun JVM. Cheers, Gary From cweyl at alumni.drew.edu Tue Mar 13 21:05:33 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 13 Mar 2007 14:05:33 -0700 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <20070313094853.0163428e@ludwig-alpha.unil.ch> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> Message-ID: <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> On 3/13/07, Christian Iseli wrote: > On Mon, 12 Mar 2007 14:12:19 -0700, Chris Weyl wrote: > > * how to get/set flags using it? > > For getting a flag, I'm not sure. Examples to detect if a flag has a > given value can be found in my scripts in CVS: > http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/getReviewByFlags?root=fedora&rev=1.1&view=auto > http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/pyGetReviewByFlags?root=fedora&rev=1.1&view=auto Yes! And it looked painful :) But it was good to know that additional fields could be specified along those lines. For getting a flag, playing around a bit more revealed that a bug's flag info is returned buried in the data returned via getBug(). > Setting a flag can apparently be done thusly (not tested): > #!/usr/bin/perl -w [...perl snipped...] I'm actually trying to update my post-to-review script to deal with the owners.list/branch requests by adding a comment in the format requested and setting the flag. I know Warren has said that these two things should be done "preferably" at the same time (so the "flag set!" message carries the comment as well, I take it), so I'm trying to do both actions as the same time. (Though it would be easy to do a addComment() then an updateFlags().) Do you know if there's a more generic bug update function that would allow me to do both actions in the same update? Thanks :) -Chris -- Chris Weyl Ex astris, scientia From mmcgrath at redhat.com Tue Mar 13 21:20:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 13 Mar 2007 16:20:29 -0500 Subject: Orphan: Moodle Message-ID: <45F7159D.9020806@redhat.com> I'm orphaning moodle, I took it up after ignacio left because we used it where I work, that was two jobs ago :-D I don't use it now and shouldn't be maintaining it. Anyone interested? -Mike From mattdm at mattdm.org Tue Mar 13 21:25:17 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Mar 2007 17:25:17 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <20070312203622.GA18906@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> Message-ID: <20070313212517.GA9946@jadzia.bu.edu> As mentioned the other day, I'm working on new Festival packages, which among other things splits the voices out so we can take up less room on the livecd. See for details (and get packages from , as mentioned there). I'm not done yet and there's some cleanup to be done, but at this point I'd really appreciate comments and feedback. Also, I note that the package is a mashup of licenses. I think they're all various BSD-style, but someone should look at that. Preferably not me. :) Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Christian.Iseli at licr.org Tue Mar 13 21:30:29 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 13 Mar 2007 22:30:29 +0100 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> Message-ID: <20070313223029.75a7a04b@ludwig-alpha.unil.ch> On Tue, 13 Mar 2007 14:05:33 -0700, Chris Weyl wrote: > Do you know if there's a more generic bug update function that would > allow me to do both actions in the same update? Maybe multicall, along the lines of: # Data to be passed in is in the form of an array of hashes my @data = ( { 'methodName' => 'bugzilla.getBug', 'params' => ['966', $username, $password], }, { 'methodName' => 'bugzilla.getBugActivity', 'params' => ['966', $username, $password], }, ); my $call = $rpc->call('system.multicall', \@data, $username, $password); Maybe worth a try... C From mclasen at redhat.com Tue Mar 13 21:47:18 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Mar 2007 17:47:18 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <20070313212517.GA9946@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> Message-ID: <1173822439.4057.7.camel@localhost.localdomain> On Tue, 2007-03-13 at 17:25 -0400, Matthew Miller wrote: > As mentioned the other day, I'm working on new Festival packages, which > among other things splits the voices out so we can take up less room on the > livecd. > > See for > details (and get packages from , as > mentioned there). > > I'm not done yet and there's some cleanup to be done, but at this point I'd > really appreciate comments and feedback. > Some comments from looking over the spec file: - Might be nicer to give the subpackages containing voices slightly less cryptic names, e.g festival-voice-clb instead of festival-festvox-nitech-us-clb-artic-hts - There is a copy-and-paste error, the description for the package containing the JMK voice refers to AWB From mattdm at mattdm.org Tue Mar 13 23:07:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Mar 2007 19:07:24 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <1173822439.4057.7.camel@localhost.localdomain> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> <1173822439.4057.7.camel@localhost.localdomain> Message-ID: <20070313230724.GA17636@jadzia.bu.edu> On Tue, Mar 13, 2007 at 05:47:18PM -0400, Matthias Clasen wrote: > - Might be nicer to give the subpackages containing voices slightly less > cryptic names, e.g festival-voice-clb instead of > festival-festvox-nitech-us-clb-artic-hts I know, they're super-long. But I'm afraid that the three-letter names (initials of the speakers, I assume) aren't necessarily unique enough. That's pretty theoretical, though -- all the existing free voices certainly are. Maybe "festvox-hts-clb" or "festival-voice-hts-clb". > - There is a copy-and-paste error, the description for the package > containing the JMK voice refers to AWB Man, I read over that like six times to make sure that didn't happen. Thanks. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Wed Mar 14 00:30:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Mar 2007 19:30:09 -0500 Subject: Summary of 2007-03-13 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging meeting which occurred on 2007-03-13 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070313 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Firmware Packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html * Disallowing %config files under /usr: http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs They should be written into the guidelines soon, if that hasn't already been done. Issues pending FESCO ratification: * Codifying when it is safe for the various phases of the RPM build process to write to various directories (8 yea, 1 nay): http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs * Prepping BuildRoot for %install (8 yea, 1 nay): http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling Misc business: * Guidelines for packaging Ruby Gems: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems Please provide insight on this; there are a number of packages queued up awaiting guidelines, including Rails. * Modifying the Perl specfile template to include BuildRequires: perl(ExtUtils::MakeMaker) to cope with the perl-devel split. Please see the minutes and IRC log for complete information. Note that I have combined the minutes and IRC log together to see how it looks, but I don't think I will use it in the future because it wiki interface just makes it too annoying to edit. (It takes 30 seconds to load the preview, for example.) This message contains official notice of changes to the guidelines, but I'm concerned that it's not sufficiently prominent (and doesn't include the actual text of changes). I have considered sending separate announcements for each change which is written into the guidelines (or asking the driver of each change to do so). Would it be better to do that, or is this message sufficient? - J< From bpepple at fedoraproject.org Wed Mar 14 02:17:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 13 Mar 2007 22:17:38 -0400 Subject: FESCo Meeting Summary for 2007-03-08 Message-ID: <1173838658.17867.4.camel@Chuck> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Warren Togami (warren) * Tom Callaway (spot) === Absent === * Josh Boyer (jwb) * Bill Nottingham (notting) * Jeremy Katz (jeremy) == Summary == Closing fedora-extras mailing list * FESCo approved the closing of the f-e-l. thl will will work on this. Sponsor Nominations * Jarod Wilson was nominated and accepted as new sponsors. Packaging Committee Report * FESCo approved the Packaging Committee's guidelines regarding: * Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html * http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs fedora-usermgmt * FESCo had a long discussion on this. RedHat BaseOS folks need to be involved. It is to late to have a solution for this by Fedora 7, will target Fedora 8. Tracker Bugs * The main blockers FE-NEW, FE-REVIEW, FE-ACCEPTED will be changed to flags. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070308 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Mar 14 03:26:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Mar 2007 20:26:27 -0700 Subject: UTF-8 and filenames Message-ID: <1173842787.3329.4933.camel@localhost.localdomain> Hi all, I'm thinking of writing a draft guideline for the packaging committee to mandate all filenames be in utf-8. Theoretically, I think this is the right thing to do as : 1) UTF8 is the native encoding of our filesystems 2) UTF8 is what the distro as a whole has migrated to 3) There's no encoding information stored with the filename so having filenames in arbitrary encodings is a recipe for disaster. Since I am not an expert in i18n issues I'm posting for some feedback here first. What do people think? Is this the right thing to do? Are there some prominent examples of where this is wrong? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Wed Mar 14 03:35:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Mar 2007 23:35:38 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173842787.3329.4933.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <1173843338.4057.11.camel@localhost.localdomain> On Tue, 2007-03-13 at 20:26 -0700, Toshio Kuratomi wrote: > Hi all, > > I'm thinking of writing a draft guideline for the packaging committee to > mandate all filenames be in utf-8. Theoretically, I think this is the > right thing to do as : > > 1) UTF8 is the native encoding of our filesystems > 2) UTF8 is what the distro as a whole has migrated to > 3) There's no encoding information stored with the filename so having > filenames in arbitrary encodings is a recipe for disaster. > > Since I am not an expert in i18n issues I'm posting for some feedback > here first. What do people think? Is this the right thing to do? Are > there some prominent examples of where this is wrong? > It is certainly the right thing to do, but I have to wonder how relevant this is. Apart from the newly introduced translated directory names in xdg-user-dirs, I can't think of any examples of non-ASCII filenames in packages... Matthias From a.badger at gmail.com Wed Mar 14 05:57:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Mar 2007 22:57:44 -0700 Subject: UTF-8 and filenames In-Reply-To: <1173843338.4057.11.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> Message-ID: <1173851865.3329.4943.camel@localhost.localdomain> On Tue, 2007-03-13 at 23:35 -0400, Matthias Clasen wrote: > On Tue, 2007-03-13 at 20:26 -0700, Toshio Kuratomi wrote: > > Hi all, > > > > I'm thinking of writing a draft guideline for the packaging committee to > > mandate all filenames be in utf-8. Theoretically, I think this is the > > right thing to do as : > > > > 1) UTF8 is the native encoding of our filesystems > > 2) UTF8 is what the distro as a whole has migrated to > > 3) There's no encoding information stored with the filename so having > > filenames in arbitrary encodings is a recipe for disaster. > > > > Since I am not an expert in i18n issues I'm posting for some feedback > > here first. What do people think? Is this the right thing to do? Are > > there some prominent examples of where this is wrong? > > > > It is certainly the right thing to do, but I have to wonder how relevant > this is. Apart from the newly introduced translated directory names in > xdg-user-dirs, I can't think of any examples of non-ASCII filenames in > packages... The tools that we're building (package database, koji, etc) currently assume that we'll only encounter UTF-8 filenames. We've found at least one package (aspell-is) which currently has a non-UTF-8 filename so we want to decide if these cases should be considered packaging bugs or if we need to build some sort of support for this into our tools. Does this need to be a packaging guideline? Perhaps not but where else does it fit? We could tuck it in as one of the things rpmlint reports and not list it explicitly but it is something that we are going to always want fixed (whereas we allow people to dispute many of the other errors and warnings reported by rpmlint.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Wed Mar 14 06:07:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Mar 2007 02:07:03 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173851865.3329.4943.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> Message-ID: <1173852423.4057.30.camel@localhost.localdomain> On Tue, 2007-03-13 at 22:57 -0700, Toshio Kuratomi wrote: > > The tools that we're building (package database, koji, etc) currently > assume that we'll only encounter UTF-8 filenames. We've found at least > one package (aspell-is) which currently has a non-UTF-8 filename so we > want to decide if these cases should be considered packaging bugs or if > we need to build some sort of support for this into our tools. Does > this need to be a packaging guideline? Perhaps not but where else does > it fit? We could tuck it in as one of the things rpmlint reports and > not list it explicitly but it is something that we are going to always > want fixed (whereas we allow people to dispute many of the other errors > and warnings reported by rpmlint.) > While in practise 99.9% of all filenames will be UTF-8 or even ASCII, it seems misguided to let tools make assumptions about that. The only assumption that can be safely made is that '/' and '\0' don't occur inside the byte sequence that makes up a filename... From aoliva at redhat.com Wed Mar 14 06:08:43 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 14 Mar 2007 03:08:43 -0300 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: <1173429334.25839.421.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri\, 09 Mar 2007 09\:35\:33 +0100") References: <1173248024.3932.12.camel@tuxhugs> <1173429334.25839.421.camel@mccallum.corsepiu.local> Message-ID: On Mar 9, 2007, Ralf Corsepius wrote: > On Fri, 2007-03-09 at 05:27 -0300, Alexandre Oliva wrote: >> On Mar 7, 2007, Peter Gordon wrote: >> >> > However, it contains no full license text, and the headers in the >> > source files only contain author/version informations. The only >> > reference to a license aside from what's on the website is that the >> > README file (which I include as %doc) contains the following line: >> >> > License: GPL >> >> > Is this reference enough, >> >> IANAL. It's enough for you to tell that you can use any version of >> the GPL, but it's not enough for you to be allowed to distribute the >> program without a copy of the GPL, because the GPL itself requires it >> to be included. > IANAL, IMO, this is an upstream-issue, because it's legally > irrelevant/legally not bind to _upstream_ whether a packager adds a copy > of the GPL or not. IANAL, but AFAIK the terms established by the GPL for licensees don't apply to a sole copyright holder. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rc040203 at freenet.de Wed Mar 14 06:43:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Mar 2007 07:43:57 +0100 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: References: <1173248024.3932.12.camel@tuxhugs> <1173429334.25839.421.camel@mccallum.corsepiu.local> Message-ID: <1173854637.4680.29.camel@mccallum.corsepiu.local> On Wed, 2007-03-14 at 03:08 -0300, Alexandre Oliva wrote: > On Mar 9, 2007, Ralf Corsepius wrote: > > > On Fri, 2007-03-09 at 05:27 -0300, Alexandre Oliva wrote: > >> On Mar 7, 2007, Peter Gordon wrote: > >> > >> > However, it contains no full license text, and the headers in the > >> > source files only contain author/version informations. The only > >> > reference to a license aside from what's on the website is that the > >> > README file (which I include as %doc) contains the following line: > >> > >> > License: GPL > >> > >> > Is this reference enough, > >> > >> IANAL. It's enough for you to tell that you can use any version of > >> the GPL, but it's not enough for you to be allowed to distribute the > >> program without a copy of the GPL, because the GPL itself requires it > >> to be included. > > > IANAL, IMO, this is an upstream-issue, because it's legally > > irrelevant/legally not bind to _upstream_ whether a packager adds a copy > > of the GPL or not. > > IANAL, but AFAIK the terms established by the GPL for licensees don't > apply to a sole copyright holder. Well, yes, but ... the real question is: What are legal implications on rpm packagers when they add legal files? Does it strengthen the rpm packager's legal position or weaken it in case a package is being legally fought? Ralf From a.badger at gmail.com Wed Mar 14 07:01:18 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Mar 2007 00:01:18 -0700 Subject: UTF-8 and filenames In-Reply-To: <1173852423.4057.30.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> Message-ID: <1173855678.3329.4948.camel@localhost.localdomain> On Wed, 2007-03-14 at 02:07 -0400, Matthias Clasen wrote: > On Tue, 2007-03-13 at 22:57 -0700, Toshio Kuratomi wrote: > > > > > The tools that we're building (package database, koji, etc) currently > > assume that we'll only encounter UTF-8 filenames. We've found at least > > one package (aspell-is) which currently has a non-UTF-8 filename so we > > want to decide if these cases should be considered packaging bugs or if > > we need to build some sort of support for this into our tools. Does > > this need to be a packaging guideline? Perhaps not but where else does > > it fit? We could tuck it in as one of the things rpmlint reports and > > not list it explicitly but it is something that we are going to always > > want fixed (whereas we allow people to dispute many of the other errors > > and warnings reported by rpmlint.) > > > > While in practise 99.9% of all filenames will be UTF-8 or even ASCII, > it seems misguided to let tools make assumptions about that. The only > assumption that can be safely made is that '/' and '\0' don't occur > inside the byte sequence that makes up a filename... The thing is we control the filenames to some extent. If we decide that every filename in one of our packages has to be utf-8 then we'll never have a filename enter the database that isn't utf-8. If we decide that it's okay for fedora packages to contain files whose names are not encoded in utf-8 then the tools will have to cope with it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Wed Mar 14 07:20:59 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 14 Mar 2007 08:20:59 +0100 Subject: Summary of 2007-03-13 Packaging Committee meeting In-Reply-To: References: Message-ID: <20070314082059.aa8bb2f3.bugs.michael@gmx.net> On 13 Mar 2007 19:30:09 -0500, Jason L Tibbitts III wrote: > Issues pending FESCO ratification: > * Codifying when it is safe for the various phases of the RPM build > process to write to various directories (8 yea, 1 nay): > http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs As a side-note here, and because it has come up several times during reviews that packagers try to clean up in %clean what is cleaned up automatically: rpmbuild --clean -bb ... [...] --clean Remove the build tree after the packages are made. [...] From buildsys at fedoraproject.org Wed Mar 14 08:23:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Mar 2007 04:23:37 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-14 Message-ID: <20070314082337.D471E152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) eclipse FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) foolish AT guezz.net: gtk-recordmydesktop FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) lxtnow AT gmail.com: ntfs-config FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rdieter AT math.unl.edu: kmymoney2 FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:3.2.2-1.fc6 > 1:3.2.1-37.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) gtk-recordmydesktop: foolish AT guezz.net FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kmymoney2: rdieter AT math.unl.edu FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) ntfs-config: lxtnow AT gmail.com FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From nicolas.mailhot at laposte.net Wed Mar 14 08:59:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Mar 2007 09:59:11 +0100 (CET) Subject: UTF-8 and filenames In-Reply-To: <1173855678.3329.4948.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> Message-ID: <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> The tools may have to be parano?d but I'm surprised people question the fact we should use our default encoding in our own filename. Seems a no-brainer to me. -- Nicolas Mailhot From triad at df.lth.se Wed Mar 14 10:09:27 2007 From: triad at df.lth.se (Linus Walleij) Date: Wed, 14 Mar 2007 11:09:27 +0100 (CET) Subject: UTF-8 and filenames In-Reply-To: <1173842787.3329.4933.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: On Tue, 13 Mar 2007, Toshio Kuratomi wrote: > I'm thinking of writing a draft guideline for the packaging committee to > mandate all filenames be in utf-8. As a side note: many users (including yours truly) really want to migrate their $HOME recursively from ISO8859-1 etc to UTF-8. Has anyone seen a good tool for this? I've written small scripts myself but never seen a program to do it. The problem grows worse when you keep legacy files on NFS shares and the like. (I guess all the Swedes, German, French and Spanish with a legacy of files in $HOME have the same problem as me...) Linus From fedora at camperquake.de Wed Mar 14 10:31:49 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 14 Mar 2007 11:31:49 +0100 Subject: UTF-8 and filenames In-Reply-To: References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <20070314113149.40d5149e@banea.int.addix.net> Hi. On Wed, 14 Mar 2007 11:09:27 +0100 (CET), Linus Walleij wrote: > As a side note: many users (including yours truly) really want to > migrate their $HOME recursively from ISO8859-1 etc to UTF-8. Has > anyone seen a good tool for this? I've written small scripts myself > but never seen a program to do it. The problem grows worse when you > keep legacy files on NFS shares and the like. > > (I guess all the Swedes, German, French and Spanish with a legacy of > files in $HOME have the same problem as me...) I have to admit that there were not many files in my $HOME that were not US-ASCII to begin with (and thus valid UTF-8 as well). The few that were left I renamed when I came across them. From fedora at camperquake.de Wed Mar 14 10:37:25 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 14 Mar 2007 11:37:25 +0100 Subject: UTF-8 and filenames In-Reply-To: <1173842787.3329.4933.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <20070314113725.0274bc7e@banea.int.addix.net> Hi. On Tue, 13 Mar 2007 20:26:27 -0700, Toshio Kuratomi wrote: > 1) UTF8 is the native encoding of our filesystems Just a little technical nitpicking: most filesystems do not have a notion of charsets or encodings, they treat a filename as a string of bytes, the interpretation of which is entirely left to userspace. From P at draigBrady.com Wed Mar 14 10:42:27 2007 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 14 Mar 2007 10:42:27 +0000 Subject: UTF-8 and filenames In-Reply-To: References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <45F7D193.9000500@draigBrady.com> Linus Walleij wrote: > On Tue, 13 Mar 2007, Toshio Kuratomi wrote: > >> I'm thinking of writing a draft guideline for the packaging committee to >> mandate all filenames be in utf-8. > > As a side note: many users (including yours truly) really want to > migrate their $HOME recursively from ISO8859-1 etc to UTF-8. Has anyone > seen a good tool for this? I've written small scripts myself but never > seen a program to do it. The problem grows worse when you keep legacy > files on NFS shares and the like. > > (I guess all the Swedes, German, French and Spanish with a legacy of > files in $HOME have the same problem as me...) If you want to report non UTF8 files then have a look at the "bad names" functionality in FSlint which is in extras. I might get round to implementing a fix up function in the next version where the user would specify the encoding to convert from. Also have a look at convmv P?draig. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 14 10:45:46 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 14 Mar 2007 19:45:46 +0900 Subject: UTF-8 and filenames In-Reply-To: <1173842787.3329.4933.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <45F7D25A.50105@ioa.s.u-tokyo.ac.jp> Toshio Kuratomi wrote: > Hi all, > > I'm thinking of writing a draft guideline for the packaging committee to > mandate all filenames be in utf-8. This may be difficult when filename contains multibyte characters (such as Japanese Kanji characters), although I am not familiar with handling filenames with multibyte characters. Mamoru Tasaka From ssorce at redhat.com Wed Mar 14 12:44:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 08:44:52 -0400 Subject: UTF-8 and filenames In-Reply-To: References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <1173876292.3705.0.camel@willson> On Wed, 2007-03-14 at 11:09 +0100, Linus Walleij wrote: > On Tue, 13 Mar 2007, Toshio Kuratomi wrote: > > > I'm thinking of writing a draft guideline for the packaging committee to > > mandate all filenames be in utf-8. > > As a side note: many users (including yours truly) really want to migrate > their $HOME recursively from ISO8859-1 etc to UTF-8. Has anyone seen a > good tool for this? I've written small scripts myself but never seen a > program to do it. The problem grows worse when you keep legacy files on > NFS shares and the like. > > (I guess all the Swedes, German, French and Spanish with a legacy of > files in $HOME have the same problem as me...) Install convmv Simo. From ssorce at redhat.com Wed Mar 14 12:48:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 08:48:22 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173842787.3329.4933.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> Message-ID: <1173876502.3705.5.camel@willson> On Tue, 2007-03-13 at 20:26 -0700, Toshio Kuratomi wrote: > Hi all, > > I'm thinking of writing a draft guideline for the packaging committee to > mandate all filenames be in utf-8. Theoretically, I think this is the > right thing to do as : > > 1) UTF8 is the native encoding of our filesystems > 2) UTF8 is what the distro as a whole has migrated to > 3) There's no encoding information stored with the filename so having > filenames in arbitrary encodings is a recipe for disaster. > > Since I am not an expert in i18n issues I'm posting for some feedback > here first. What do people think? Is this the right thing to do? Are > there some prominent examples of where this is wrong? Absolutely, we MUST be consistent. >From a Samba POV for example we can certainly cope with different charsets, but 1 at a time, there is NO way for samba to successfully present files to other hosts if there are files with mixed chrasets. And consistency in a distro is what everybody expects, I think it make absolutely no sense to permit anything but utf8 in today packages.\ Simo. From mclasen at redhat.com Wed Mar 14 13:25:00 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Mar 2007 09:25:00 -0400 Subject: UTF-8 and filenames In-Reply-To: <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> Message-ID: <1173878700.4057.33.camel@localhost.localdomain> On Wed, 2007-03-14 at 09:59 +0100, Nicolas Mailhot wrote: > The tools may have to be parano?d but I'm surprised people question the > fact we should use our default encoding in our own filename. Seems a > no-brainer to me. > I don't question that, and it is a very sane thing to put this as a recommendation somewhere in the packaging guidelines. Still, it would be bad if the tools fell over in the presence of a non-utf8 filename. There is just no good reason for that limitation. From jkeating at redhat.com Wed Mar 14 14:05:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Mar 2007 10:05:10 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173878700.4057.33.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> Message-ID: <200703141005.13634.jkeating@redhat.com> On Wednesday 14 March 2007 09:25:00 Matthias Clasen wrote: > I don't question that, and it is a very sane thing to put this as a > recommendation somewhere in the packaging guidelines. Still, it would be > bad if the tools fell over in the presence of a non-utf8 filename. There > is just no good reason for that limitation. From the koji dev: [why utf8?] because otherwise you can't really do anything sane with the data. If it's a mix of utf-8, iso-8859-1, WIN-1259, etc. you have no way of knowing how to display it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Wed Mar 14 14:05:29 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 10:05:29 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173878700.4057.33.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> Message-ID: <1173881129.3705.10.camel@willson> On Wed, 2007-03-14 at 09:25 -0400, Matthias Clasen wrote: > On Wed, 2007-03-14 at 09:59 +0100, Nicolas Mailhot wrote: > > The tools may have to be parano?d but I'm surprised people question the > > fact we should use our default encoding in our own filename. Seems a > > no-brainer to me. > > > > I don't question that, and it is a very sane thing to put this as a > recommendation somewhere in the packaging guidelines. Still, it would be > bad if the tools fell over in the presence of a non-utf8 filename. There > is just no good reason for that limitation. What do you propose the tool to do? If you don't known the encoding, and knowing it is fundamental for the tool to function, there is not much you can do except avoid wrong file names by policy. It should probably report a graceful error, and obviously not crash, but beyond this? Simo. From laurent.rineau__fedora_extras at normalesup.org Wed Mar 14 14:58:58 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 14 Mar 2007 15:58:58 +0100 Subject: UTF-8 and filenames In-Reply-To: <1173878700.4057.33.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> Message-ID: <200703141558.59074@rineau.tsetse> On Wednesday 14 March 2007 14:25:00 Matthias Clasen wrote: > I don't question that, and it is a very sane thing to put this as a > recommendation somewhere in the packaging guidelines. Still, it would be > bad if the tools fell over in the presence of a non-utf8 filename. There > is just no good reason for that limitation. I can imagine a tool that fills a XML file with filenames. If the encoding of the XML file is UTF-8, that (hypothetical) tool would have to know the encoding of the file names to create a correct XML file. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From mclasen at redhat.com Wed Mar 14 15:27:25 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Mar 2007 11:27:25 -0400 Subject: UTF-8 and filenames In-Reply-To: <200703141005.13634.jkeating@redhat.com> References: <1173842787.3329.4933.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> <200703141005.13634.jkeating@redhat.com> Message-ID: <1173886045.4057.47.camel@localhost.localdomain> On Wed, 2007-03-14 at 10:05 -0400, Jesse Keating wrote: > On Wednesday 14 March 2007 09:25:00 Matthias Clasen wrote: > > I don't question that, and it is a very sane thing to put this as a > > recommendation somewhere in the packaging guidelines. Still, it would be > > bad if the tools fell over in the presence of a non-utf8 filename. There > > is just no good reason for that limitation. > > From the koji dev: > > [why utf8?] because otherwise you can't really do anything sane with the data. > If it's a mix of utf-8, iso-8859-1, WIN-1259, etc. you have no way of knowing > how to display it. > g_filename_display_name() or equivalent From fche at redhat.com Wed Mar 14 16:16:06 2007 From: fche at redhat.com (Frank Ch. Eigler) Date: 14 Mar 2007 12:16:06 -0400 Subject: UTF-8 and filenames In-Reply-To: <200703141005.13634.jkeating@redhat.com> References: <1173842787.3329.4933.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> <200703141005.13634.jkeating@redhat.com> Message-ID: jkeating wrote: > From the koji dev: > > [why utf8?] because otherwise you can't really do anything sane with > the data. If it's a mix of utf-8, iso-8859-1, WIN-1259, etc. you > have no way of knowing how to display it. At worst, a tool can do what "ls -b" does: quoting. At best, it can allow a user to specify the character set/encoding for directories/file names. - FChE From a.badger at gmail.com Wed Mar 14 16:34:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Mar 2007 09:34:12 -0700 Subject: UTF-8 and filenames In-Reply-To: References: <1173842787.3329.4933.camel@localhost.localdomain> <42033.192.54.193.51.1173862751.squirrel@rousalka.dyndns.org> <1173878700.4057.33.camel@localhost.localdomain> <200703141005.13634.jkeating@redhat.com> Message-ID: <1173890052.3329.4956.camel@localhost.localdomain> On Wed, 2007-03-14 at 12:16 -0400, Frank Ch. Eigler wrote: > jkeating wrote: > > > From the koji dev: > > > > [why utf8?] because otherwise you can't really do anything sane with > > the data. If it's a mix of utf-8, iso-8859-1, WIN-1259, etc. you > > have no way of knowing how to display it. > > At worst, a tool can do what "ls -b" does: quoting. At best, it can > allow a user to specify the character set/encoding for > directories/file names. > Quoting is a possibility. Displaying my ignorance, will there ever be a time when an encoding maps a character to a value that is valid UTF-8? If so, then we'll end up with garbage filenames rather than quoting for those encodings which seems suboptimal. For specifying the character set, I'd argue that the spec file is the correct level for that to occur. If so, why not have the packager change the filename to UTF-8 instead? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Mar 14 17:11:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Mar 2007 10:11:31 -0700 Subject: UTF-8 and filenames In-Reply-To: <45F7D25A.50105@ioa.s.u-tokyo.ac.jp> References: <1173842787.3329.4933.camel@localhost.localdomain> <45F7D25A.50105@ioa.s.u-tokyo.ac.jp> Message-ID: <1173892291.3329.4971.camel@localhost.localdomain> On Wed, 2007-03-14 at 19:45 +0900, Mamoru Tasaka wrote: > Toshio Kuratomi wrote: > > Hi all, > > > > I'm thinking of writing a draft guideline for the packaging committee to > > mandate all filenames be in utf-8. > > This may be difficult when filename contains multibyte > characters (such as Japanese Kanji characters), although > I am not familiar with handling filenames with multibyte > characters. > I was under the impression that utf-8 was capable of storing Kanji, just not as efficiently as utf-16 or another encoding. (AIUI utf-8 uses three bytes instead of two.) Am I missing something important here? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Mar 14 17:43:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Mar 2007 18:43:12 +0100 Subject: UTF-8 and filenames In-Reply-To: <1173892291.3329.4971.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <45F7D25A.50105@ioa.s.u-tokyo.ac.jp> <1173892291.3329.4971.camel@localhost.localdomain> Message-ID: <1173894192.22102.2.camel@rousalka.dyndns.org> Le mercredi 14 mars 2007 ? 10:11 -0700, Toshio Kuratomi a ?crit : > On Wed, 2007-03-14 at 19:45 +0900, Mamoru Tasaka wrote: > > Toshio Kuratomi wrote: > > > Hi all, > > > > > > I'm thinking of writing a draft guideline for the packaging committee to > > > mandate all filenames be in utf-8. > > > > This may be difficult when filename contains multibyte > > characters (such as Japanese Kanji characters), although > > I am not familiar with handling filenames with multibyte > > characters. > > > I was under the impression that utf-8 was capable of storing Kanji, > just not as efficiently as utf-16 or another encoding. (AIUI utf-8 uses > three bytes instead of two.) Am I missing something important here? IIRC JIS was slow to get on the unicode bandwagon, that's all -- Nicolas Mailhot From jkeating at redhat.com Wed Mar 14 19:30:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Mar 2007 15:30:15 -0400 Subject: The road to the merge Message-ID: <200703141530.15683.jkeating@redhat.com> As you've probably heard, we're trying to get a new buildsystem ( http://hosted.fedoraproject.org/projects/koji ) in place before merging the source control. This is to give us more functionality and better resources to manage our entire distribution in the buildsystem. We're making progress with koji and are nearly there. However, I don't feel that we can swap over to Koji before the Test 3 freeze next week. To move we need to solve a few different things. A) ssl cert auth for the koji client. Work is progressing with this, but just not done yet. B) current package builds imported into the db that koji uses so that they are available for building with. This is a fairly straight forward process, but it takes time to rsync things to the new buildsystem location, import them into the db, and tag them for the correct collections. This requires a build stoppage for a period of time. C) A tool to dump the latest packages of a given collection into a repo (and potentially make it multilib) for things like pungi, extras push (for FC6), the update tool. The multilib is the hard part. Bill Nottingham has been beating on the logic around this for a bit. The other parts are fairly straight forward, the koji API is pretty easy to use. D) Makefile.common changes. I've done this before for other things, so I'll be taking this on again probably. Not too difficult, just need proper timing. Like, during the outage. E) CVS to pull packages from for build requests. We have to actually merge the content so that koji can build it. This also requires an outage and can happen during the outage that we're syncing up the latest builds and creating the tags. F) everybody to have a Fedora Account System account, the proper ACLs on their packages, and the koji client installed and properly configured. G) Storage in the colo to toss all the builds. Mike McGrath is working on this as we speak I do believe. H) Bodhi ( http://hosted.fedoraproject.org/projects/bodhi ) up and running to deliver updates for FC6 (since development inherits from the FC6 updates) I'm sure I'm forgetting some things along the way, but I think it is pretty clear that there is not a small amount of work to be done, and I'd really rather not interrupt the mad dash to get things in before the Test3 freeze, since that is the Feature Freeze as well. However after Test3 goes gold, or shortly there after, we should be able to accomplish most of the above if not all. Disadvantage is that the feature of a merged world will happen after the feature freeze, and it only gives us one more test release before the final. However with all things external, I plan to start doing more frequent public composes of things that could be downloadable. I'm doing composes almost every day anyway to test pungi code, it is just painful to sync those up to somewhere for public consumption. We could also delay Test3, and do the outage before the freeze or even during the freeze and just extend the freeze, but we'll most likely need to fix up a bunch of stuff along the way and that cuts into the time I use to get the tree in shape for release. Or we do a test5 and.... well, I don't like that idea either (: Basically I want to give people a status update on where things are going, and what work still needs to be done, and what our expectations are. I welcome input around when and how to flip the switch and whether or not dropping this "feature" in after the feature freeze is acceptable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Wed Mar 14 19:54:40 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 15:54:40 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173892291.3329.4971.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <45F7D25A.50105@ioa.s.u-tokyo.ac.jp> <1173892291.3329.4971.camel@localhost.localdomain> Message-ID: <1173902080.3705.25.camel@willson> On Wed, 2007-03-14 at 10:11 -0700, Toshio Kuratomi wrote: > On Wed, 2007-03-14 at 19:45 +0900, Mamoru Tasaka wrote: > > Toshio Kuratomi wrote: > > > Hi all, > > > > > > I'm thinking of writing a draft guideline for the packaging committee to > > > mandate all filenames be in utf-8. > > > > This may be difficult when filename contains multibyte > > characters (such as Japanese Kanji characters), although > > I am not familiar with handling filenames with multibyte > > characters. > > > I was under the impression that utf-8 was capable of storing Kanji, > just not as efficiently as utf-16 or another encoding. (AIUI utf-8 uses > three bytes instead of two.) Am I missing something important here? UTF8 is a multipyte charset with a 1 byte base unit, IIRC it can go up to 4 or 6 bytes for a single character in some rare conditions, but IIRC. UTF8 is ASCII-7 compatible and null terminated. UTF16 is a multibyte charset but the base unit is 2 bytes long, it is not ASCII-7 compatible and is not null"byte" terminated (ascii chars translates into \00\XX with XX the actual ASCII code). Also UTF16 should be further divided in LE and BE (little Endian and Big Endian) depending on the byte order of the 2 byte base unit. Both, utf8 and utf16 are just representations of the Unicode standard, and in theory you should be able to translate from utf8 to utf16 and vice-versa with no loss of information. Then MS started using UCS2/UTF16 and ... well you can guess ... Simo. From Axel.Thimm at ATrpms.net Wed Mar 14 20:40:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 21:40:55 +0100 Subject: The road to the merge In-Reply-To: <200703141530.15683.jkeating@redhat.com> References: <200703141530.15683.jkeating@redhat.com> Message-ID: <20070314204055.GD10100@neu.nirvana> On Wed, Mar 14, 2007 at 03:30:15PM -0400, Jesse Keating wrote: > [...] it is pretty clear that there is not a small amount of work to > be done, and I'd really rather not interrupt the mad dash to get > things in before the Test3 freeze, since that is the Feature Freeze > as well. [...] > Basically I want to give people a status update on where things are going, and > what work still needs to be done, and what our expectations are. I welcome > input around when and how to flip the switch and whether or not dropping > this "feature" in after the feature freeze is acceptable. I'd argue that this feature is a meta-feature (e.g. it should not really be observable when someone grabs the final product what kind of buildsystem was used), so perhaps the feature-freeze does not really apply to this part. So, I think it's acceptable to add it after test3. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Wed Mar 14 22:03:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 17:03:13 -0500 Subject: UTF-8 and filenames In-Reply-To: <1173855678.3329.4948.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> Message-ID: <1173909793.14325.14.camel@localhost.localdomain> On Wed, 2007-03-14 at 00:01 -0700, Toshio Kuratomi wrote: > The thing is we control the filenames to some extent. If we decide that > every filename in one of our packages has to be utf-8 then we'll never > have a filename enter the database that isn't utf-8. If we decide that > it's okay for fedora packages to contain files whose names are not > encoded in utf-8 then the tools will have to cope with it. I'm seeing two issues here. Unix systems have supported arbitrary bitstreams for filenames (well, except for '/'...) since the beginning of time. Any low level tool that falls over because the filename contains whitespace or high-ascii or utf-8 or whatever is broken. Period. Now interpreting the meaning of these bitstreams is a higher level display problem. The great thing about having a "case sensitive" filesystem is the kernel doesn't have to care about encodings. That bloat is pushed to userspace. Its just a bunch of bits as far as the kernel and low-level libc are concerned. (Except the kernel DOES have to know about encodings in order to implement vfat, SMB, ntfs and whatnot, because microsoft sux...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 22:10:59 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 17:10:59 -0500 Subject: RFC: Signed JAR Packaging Policy In-Reply-To: <17910.30613.294621.496179@zebedee.pink> References: <45F59BC9.6030405@redhat.com> <17910.30613.294621.496179@zebedee.pink> Message-ID: <1173910259.14325.16.camel@localhost.localdomain> On Tue, 2007-03-13 at 10:06 +0000, Andrew Haley wrote: > What problem, exactly, are we trying to solve here? Is it to do with > compatibility with unfree Java VMs? If people wish to install unfree > VMs, then they can also install a suitably signed copy of the > Mozilla-JSS JCA Provider. +1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 22:18:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 17:18:16 -0500 Subject: Review guidelines and rpmlint In-Reply-To: <20070311192435.GA3960@free.fr> References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> <1173640936.18771.144.camel@localhost.localdomain> <20070311192435.GA3960@free.fr> Message-ID: <1173910696.14325.22.camel@localhost.localdomain> On Sun, 2007-03-11 at 20:24 +0100, Patrice Dumas wrote: > On Sun, Mar 11, 2007 at 02:22:16PM -0500, Callum Lerwick wrote: > > > > If you look closely, rpmlint output is separated into warnings (W:) and > > errors (E:). Just like a C compiler. > > If I remember well Ville said that the difference between W and E was > quite arbitrary. And we can always make them less arbitrary. Its not set in stone. rpmlint is *our* tool. > > Errors MUST be fixed to pass review. (Or to pass the upcoming > > rpmlint-after-build test) > > Some errors have to be ignored (from the top of my head, errors about > setuid binaries, for example). You didn't quote the part where I said: > > And if rpmlint flags something as an error that shouldn't be, file a > > bug against rpmlint. The test can be revised, or downgraded to a > > warning. If there's any justification at all to ignore an error, ever, then it should be downgraded to a warning. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Wed Mar 14 22:22:26 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 18:22:26 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173909793.14325.14.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> Message-ID: <1173910946.3705.36.camel@willson> On Wed, 2007-03-14 at 17:03 -0500, Callum Lerwick wrote: > On Wed, 2007-03-14 at 00:01 -0700, Toshio Kuratomi wrote: > > The thing is we control the filenames to some extent. If we decide that > > every filename in one of our packages has to be utf-8 then we'll never > > have a filename enter the database that isn't utf-8. If we decide that > > it's okay for fedora packages to contain files whose names are not > > encoded in utf-8 then the tools will have to cope with it. > > I'm seeing two issues here. > > Unix systems have supported arbitrary bitstreams for filenames (well, > except for '/'...) since the beginning of time. Any low level tool that > falls over because the filename contains whitespace or high-ascii or > utf-8 or whatever is broken. Period. This is not a black and white, thing, you can't say that _any_ tool that falls is broken. Example: convmv is a lower level tool, and it can't translate unknown charsets, but it is not broken. > Now interpreting the meaning of these bitstreams is a higher level > display problem. The great thing about having a "case sensitive" > filesystem is the kernel doesn't have to care about encodings. That > bloat is pushed to userspace. Its just a bunch of bits as far as the > kernel and low-level libc are concerned. (Except the kernel DOES have to > know about encodings in order to implement vfat, SMB, ntfs and whatnot, > because microsoft sux...) The fact that the Linux kernel can ignore the content of the file name does not mean that nothing have to. Managing char sets is not only a display problem, and it is not certainly Microsoft fault that someone invented a broken standard like ASCII from start. There are historical reasons why some protocols (and no just file sharing protocols, think of http/html) have standardized on some char set, and no matter what you say, any network protocol have to deal with that, cause machines used to speak in different ways. And you can't force everybody to have the same encoding. Actually the fact that the kernel accept everything worsen the problem, as it allows mixed char set file names to exists. But this is a different problem. Now if we could standardize everything on utf8 we would have no problem, and this is why, at least internally, we should standardize on it, and not propagate the plague of mixed incompatible char sets. We can and we should standardize at least at the user space level. People expect consistency from a distribution and the tools it ships. Simo. From nicolas.mailhot at laposte.net Wed Mar 14 22:24:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Mar 2007 23:24:18 +0100 Subject: UTF-8 and filenames In-Reply-To: <1173909793.14325.14.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> Message-ID: <1173911058.22102.47.camel@rousalka.dyndns.org> Le mercredi 14 mars 2007 ? 17:03 -0500, Callum Lerwick a ?crit : > Now interpreting the meaning of these bitstreams is a higher level > display problem. The great thing about having a "case sensitive" > filesystem is the kernel doesn't have to care about encodings. That > bloat is pushed to userspace. Except userspace has no way to guess the filename encoding: filename itself is too short to use any sort of euristic, and Linux filesystems won't provide any other hint. The only sane thing userspace can do is postulate a system-wide encoding and display garbage for filenames encoded otherwise (hoping that will force users to use the default encoding), even if that will fail spectacularly with removable medias or legacy partitions that use another convention. Also little help to apps that do something else with filenames than displaying them. Casing, sorting is quite another problem. If the encoding is fixed, it only requires locale knowledge, which is already exported to userspace reliably. Also don't forget UTF-8 coverage comes at the price of forbidding some valid ASCII sequences. So anyone blindly injecting data using legacy 8-bit encoding in an UTF-8 system is asking for trouble (and Linus refused to enforce UTF-8 safety kernel-side) -- Nicolas Mailhot From ssorce at redhat.com Wed Mar 14 22:36:31 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 18:36:31 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173911058.22102.47.camel@rousalka.dyndns.org> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173911058.22102.47.camel@rousalka.dyndns.org> Message-ID: <1173911791.3705.43.camel@willson> On Wed, 2007-03-14 at 23:24 +0100, Nicolas Mailhot wrote: > Le mercredi 14 mars 2007 ? 17:03 -0500, Callum Lerwick a ?crit : > > > Now interpreting the meaning of these bitstreams is a higher level > > display problem. The great thing about having a "case sensitive" > > filesystem is the kernel doesn't have to care about encodings. That > > bloat is pushed to userspace. > > Except userspace has no way to guess the filename encoding: filename > itself is too short to use any sort of euristic, and Linux filesystems > won't provide any other hint. > > The only sane thing userspace can do is postulate a system-wide encoding > and display garbage for filenames encoded otherwise (hoping that will > force users to use the default encoding), even if that will fail > spectacularly with removable medias or legacy partitions that use > another convention. Also little help to apps that do something else with > filenames than displaying them. > > Casing, sorting is quite another problem. If the encoding is fixed, it > only requires locale knowledge, which is already exported to userspace > reliably. +1 up to this point > Also don't forget UTF-8 coverage comes at the price of forbidding some > valid ASCII sequences. So anyone blindly injecting data using legacy > 8-bit encoding in an UTF-8 system is asking for trouble (and Linus > refused to enforce UTF-8 safety kernel-side) To be pedant, UTF-8 and ASCII* are perfectly compatible, but encodings that use the upper 127 values, like iso8859-*, are not compatible with UTF-8. Simo. * http://en.wikipedia.org/wiki/ASCII From pertusus at free.fr Wed Mar 14 22:35:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Mar 2007 23:35:01 +0100 Subject: Review guidelines and rpmlint In-Reply-To: <1173910696.14325.22.camel@localhost.localdomain> References: <45F08403.3090302@redhat.com> <45F085A1.9040001@redhat.com> <20070308220453.GA2305@jadzia.bu.edu> <17905.17260.372000.126744@zebedee.pink> <1173640936.18771.144.camel@localhost.localdomain> <20070311192435.GA3960@free.fr> <1173910696.14325.22.camel@localhost.localdomain> Message-ID: <20070314223501.GA2916@free.fr> On Wed, Mar 14, 2007 at 05:18:16PM -0500, Callum Lerwick wrote: > > > > If I remember well Ville said that the difference between W and E was > > quite arbitrary. > > And we can always make them less arbitrary. Its not set in stone. > rpmlint is *our* tool. Not really. It has an upstream too. > If there's any justification at all to ignore an error, ever, then it > should be downgraded to a warning. Maybe. I won't fill that bug myself, though. -- Pat From bpepple at fedoraproject.org Wed Mar 14 22:43:40 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 14 Mar 2007 18:43:40 -0400 Subject: Plan for tomorrows (20070315) FESCO meeting Message-ID: <1173912220.24590.4.camel@Chuck> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC (1:00 ET) in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- Core Package Review Process -- warren /topic FESCO-Meeting -- new sponsor nominations anyone? /topic FESCO-meeting -- MISC -- garbage-collector rpm -- https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html /topic FESCO-Meeting -- MISC -- cvs-import changes - c4chris /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- EPEL -- dgilmore /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 22:44:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 17:44:11 -0500 Subject: UTF-8 and filenames In-Reply-To: <1173910946.3705.36.camel@willson> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173910946.3705.36.camel@willson> Message-ID: <1173912251.14325.33.camel@localhost.localdomain> Okay, so people missed my point. The point is, if its a tool that doesn't *have* to care about encodings, then it should not care about encodings. If its not something that performs stuff like alphabetical sorting or case insensitive comparison, then it should just accept and pass on the filename as a bag of bits, not caring what they mean. For example, for a long time rsync wouldn't allow you to specify files and directories with spaces in the name on the command line, no matter how hard you tried to escape or quote it. It would interpret the space as a filename seperator. This finally got fixed at some point though. :) This also applies to people not properly quoting variables in shell scripts... :( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 22:49:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 17:49:39 -0500 Subject: UTF-8 and filenames In-Reply-To: <1173910946.3705.36.camel@willson> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173910946.3705.36.camel@willson> Message-ID: <1173912579.14325.39.camel@localhost.localdomain> On Wed, 2007-03-14 at 18:22 -0400, Simo Sorce wrote: > We can and we should standardize at least at the user space level. > People expect consistency from a distribution and the tools it ships. We've already standardized. UTF-8 is what Nautilus and Gnome/gtk file selectors and every other GUI app expects and uses. At least they do on my system. Its probably based on locale and if the user changes that and it breaks stuff it's kind of their fault. We always default to utf-8 in all locales, right? Right? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Wed Mar 14 22:51:51 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 18:51:51 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173912251.14325.33.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173910946.3705.36.camel@willson> <1173912251.14325.33.camel@localhost.localdomain> Message-ID: <1173912711.3705.47.camel@willson> On Wed, 2007-03-14 at 17:44 -0500, Callum Lerwick wrote: > Okay, so people missed my point. > > The point is, if its a tool that doesn't *have* to care about encodings, > then it should not care about encodings. If its not something that > performs stuff like alphabetical sorting or case insensitive comparison, > then it should just accept and pass on the filename as a bag of bits, > not caring what they mean. > > For example, for a long time rsync wouldn't allow you to specify files > and directories with spaces in the name on the command line, no matter > how hard you tried to escape or quote it. It would interpret the space > as a filename seperator. This finally got fixed at some point though. :) > > This also applies to people not properly quoting variables in shell > scripts... :( This is much more clearer and I agree 101% Simo. From ssorce at redhat.com Wed Mar 14 22:55:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2007 18:55:58 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173912711.3705.47.camel@willson> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173910946.3705.36.camel@willson> <1173912251.14325.33.camel@localhost.localdomain> <1173912711.3705.47.camel@willson> Message-ID: <1173912958.3705.52.camel@willson> Replying to myself :( On Wed, 2007-03-14 at 18:51 -0400, Simo Sorce wrote: > On Wed, 2007-03-14 at 17:44 -0500, Callum Lerwick wrote: > > Okay, so people missed my point. > > > > The point is, if its a tool that doesn't *have* to care about encodings, > > then it should not care about encodings. If its not something that > > performs stuff like alphabetical sorting or case insensitive comparison, > > then it should just accept and pass on the filename as a bag of bits, > > not caring what they mean. > > > > For example, for a long time rsync wouldn't allow you to specify files > > and directories with spaces in the name on the command line, no matter > > how hard you tried to escape or quote it. It would interpret the space > > as a filename seperator. This finally got fixed at some point though. :) Except that rsync may run on windows or mac OS X as well, and this reintroduce the need for rsync to be able to understand what are the bits so that it can translate names to UTF-16 ... > > This also applies to people not properly quoting variables in shell > > scripts... :( > > This is much more clearer and I agree 101% I still agree, it is just that the number of apps that can really avoid caring are less than what most people may think without careful consideration. Simo. From seg at haxxed.com Wed Mar 14 23:10:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 18:10:20 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <20070311232303.GA13621@jadzia.bu.edu> References: <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <1173496082.3466.17.camel@localhost.localdomain> <20070310031242.GA10735@jadzia.bu.edu> <1173497232.3466.22.camel@localhost.localdomain> <9234.1173515434@sss.pgh.pa.us> <20070310095400.GB17717@neu.nirvana> <87ejnxflo0.fsf@kosh.bigo.ensc.de> <1173638932.18771.123.camel@localhost.localdomain> <20070311232303.GA13621@jadzia.bu.edu> Message-ID: <1173913820.14325.50.camel@localhost.localdomain> On Sun, 2007-03-11 at 19:23 -0400, Matthew Miller wrote: > On Sun, Mar 11, 2007 at 01:48:52PM -0500, Callum Lerwick wrote: > > Okay this whole line of thought is total crackrock. Why do we need to > > make value judgements over what packages deserve a fixed ID, and what > > doesn't? If we're going to do fixed IDs at all, there's *no* reason we > > Because there's no important reason to have a fixed UID if no files are > owned. Other than reducing the number of dynamically assigned IDs out in the wild that can bite us in the ass in the future. We can't eliminate dynamic IDs, but I believe minimizing their usage is in our best interests. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 23:25:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 18:25:51 -0500 Subject: Fedora User Management (revisited) In-Reply-To: <87mz2jbild.fsf@kosh.bigo.ensc.de> References: <45EDCBD9.6080102@redhat.com> <87hcsydrsy.fsf@kosh.bigo.ensc.de> <45EDD7FB.5020406@redhat.com> <1173216064.3698.1.camel@rousalka.dyndns.org> <20070308220911.GE5337@nostromo.devel.redhat.com> <45F09BEE.7090909@redhat.com> <20070309084325.GD19382@neu.nirvana> <87fy8erci3.fsf@fc5.bigo.ensc.de> <20070309100101.GA5557@neu.nirvana> <877itqraco.fsf@fc5.bigo.ensc.de> <20070309110339.GB5557@neu.nirvana> <873b4er7m2.fsf@fc5.bigo.ensc.de> <1173638552.18771.117.camel@localhost.localdomain> <87mz2jbild.fsf@kosh.bigo.ensc.de> Message-ID: <1173914751.14325.63.camel@localhost.localdomain> On Sun, 2007-03-11 at 22:01 +0100, Enrico Scholz wrote: > It is not a "blind adherence" but an adherence that existing systems > should not be broken. You can not use range 100-499 for static uids > because existing systems are having already uids in this range. I always had in mind that if the assigned userid was already taken when a package is installed, useradd would fall back on allocating a dynamic ID. Statically assigned IDs are going to have to be on a "best effort" basis. (I could have sworn it had a flag for this...) On a clean, freshly installed Fedora system all packages will get their assigned IDs. If an assigned ID is taken, just fall back on a dynamic ID in the dynamic range, which will leave these systems no worse off then they were already. Best effort. Best effort. Best effort. If its not self evident by now, yes, this situation sucks. There's not going to be a perfect solution. (Actually, moving to using 128 bit UUIDs, would solve a lot of problems... (And create a bunch of others, like interoperability...)) No matter what we do, its still going to suck for someone. It is just a matter of who. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 14 23:44:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 14 Mar 2007 18:44:24 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E5DD2E.3090305@redhat.com> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E5DD2E.3090305@redhat.com> Message-ID: <1173915864.14325.66.camel@localhost.localdomain> On Wed, 2007-02-28 at 14:51 -0500, Havoc Pennington wrote: > ACLs are fine as a broad thing to keep total strangers from putting a > virus in a package - but getting too fine-grained with security > clearances and policies within a community of people who are supposed to > be working together is just overhead that sucks energy - implementation, > administration, and endless policy debates. +1000000000 Oh thank god its not just me. This is what I've been trying to say. Maybe it will carry more weight coming from Havoc. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Thu Mar 15 00:03:08 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 14 Mar 2007 20:03:08 -0400 Subject: The road to the merge In-Reply-To: <20070314204055.GD10100@neu.nirvana> References: <200703141530.15683.jkeating@redhat.com> <20070314204055.GD10100@neu.nirvana> Message-ID: <1173916988.17584.10.camel@localhost.localdomain> On Wed, 2007-03-14 at 21:40 +0100, Axel Thimm wrote: > On Wed, Mar 14, 2007 at 03:30:15PM -0400, Jesse Keating wrote: > > [...] it is pretty clear that there is not a small amount of work to > > be done, and I'd really rather not interrupt the mad dash to get > > things in before the Test3 freeze, since that is the Feature Freeze > > as well. [...] > > > Basically I want to give people a status update on where things are going, and > > what work still needs to be done, and what our expectations are. I welcome > > input around when and how to flip the switch and whether or not dropping > > this "feature" in after the feature freeze is acceptable. > > I'd argue that this feature is a meta-feature (e.g. it should not > really be observable when someone grabs the final product what kind of > buildsystem was used), so perhaps the feature-freeze does not really > apply to this part. So, I think it's acceptable to add it after test3. I just want to make sure that we don't get into a situation where we've waited until after Test3 and then it's too late to make the change. --Chris From jwboyer at jdub.homelinux.org Thu Mar 15 01:31:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 14 Mar 2007 20:31:51 -0500 Subject: The road to the merge In-Reply-To: <20070314204055.GD10100@neu.nirvana> References: <200703141530.15683.jkeating@redhat.com> <20070314204055.GD10100@neu.nirvana> Message-ID: <1173922312.2977.1.camel@vader.jdub.homelinux.org> On Wed, 2007-03-14 at 21:40 +0100, Axel Thimm wrote: > On Wed, Mar 14, 2007 at 03:30:15PM -0400, Jesse Keating wrote: > > [...] it is pretty clear that there is not a small amount of work to > > be done, and I'd really rather not interrupt the mad dash to get > > things in before the Test3 freeze, since that is the Feature Freeze > > as well. [...] > > > Basically I want to give people a status update on where things are going, and > > what work still needs to be done, and what our expectations are. I welcome > > input around when and how to flip the switch and whether or not dropping > > this "feature" in after the feature freeze is acceptable. > > I'd argue that this feature is a meta-feature (e.g. it should not > really be observable when someone grabs the final product what kind of > buildsystem was used), so perhaps the feature-freeze does not really > apply to this part. So, I think it's acceptable to add it after test3. Yes and no. With a merged collection of packages (which can't happen before koji is in place), you could potentially start enabling some features in what were Core packages that previously couldn't be done because the libs (or whatever) resided in what was Extras. josh From Axel.Thimm at ATrpms.net Thu Mar 15 01:38:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 02:38:46 +0100 Subject: The road to the merge In-Reply-To: <1173922312.2977.1.camel@vader.jdub.homelinux.org> References: <200703141530.15683.jkeating@redhat.com> <20070314204055.GD10100@neu.nirvana> <1173922312.2977.1.camel@vader.jdub.homelinux.org> Message-ID: <20070315013846.GC22805@neu.nirvana> On Wed, Mar 14, 2007 at 08:31:51PM -0500, Josh Boyer wrote: > On Wed, 2007-03-14 at 21:40 +0100, Axel Thimm wrote: > > On Wed, Mar 14, 2007 at 03:30:15PM -0400, Jesse Keating wrote: > > > [...] it is pretty clear that there is not a small amount of work to > > > be done, and I'd really rather not interrupt the mad dash to get > > > things in before the Test3 freeze, since that is the Feature Freeze > > > as well. [...] > > > > > Basically I want to give people a status update on where things are going, and > > > what work still needs to be done, and what our expectations are. I welcome > > > input around when and how to flip the switch and whether or not dropping > > > this "feature" in after the feature freeze is acceptable. > > > > I'd argue that this feature is a meta-feature (e.g. it should not > > really be observable when someone grabs the final product what kind of > > buildsystem was used), so perhaps the feature-freeze does not really > > apply to this part. So, I think it's acceptable to add it after test3. > > Yes and no. With a merged collection of packages (which can't happen > before koji is in place), Why not? (Just curious, no disbelieve :) > you could potentially start enabling some features in what were Core > packages that previously couldn't be done because the libs (or > whatever) resided in what was Extras. It would probably mean that no BR from premerge-extras to premerge-core will be allowed until then, which would be sad, but probably bearable. What would you suggest otherwise as an alternative? Slip test3? No feature freeze until test4? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aoliva at redhat.com Thu Mar 15 03:29:49 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 15 Mar 2007 00:29:49 -0300 Subject: Is referencing the GPL in the package's README enough of a "license"? In-Reply-To: <1173854637.4680.29.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed\, 14 Mar 2007 07\:43\:57 +0100") References: <1173248024.3932.12.camel@tuxhugs> <1173429334.25839.421.camel@mccallum.corsepiu.local> <1173854637.4680.29.camel@mccallum.corsepiu.local> Message-ID: On Mar 14, 2007, Ralf Corsepius wrote: > On Wed, 2007-03-14 at 03:08 -0300, Alexandre Oliva wrote: >> On Mar 9, 2007, Ralf Corsepius wrote: >> > On Fri, 2007-03-09 at 05:27 -0300, Alexandre Oliva wrote: >> >> it's not enough for you to be allowed to distribute the program >> >> without a copy of the GPL, because the GPL itself requires it to >> >> be included. > What are legal implications on rpm packagers when they add legal > files? If it adds something that the copyright holder demanded everyone who distributes the program to add, you can't get it wrong as far as the copyright holder is concerned, methinks. But IANAL ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dennis at ausil.us Thu Mar 15 03:31:51 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Mar 2007 22:31:51 -0500 Subject: ppc64 builds Message-ID: <200703142231.51890.dennis@ausil.us> Hey All, With the merge of core and extras we need to enable ppc64 builds for what was formally know as extras. So this weekend I am going to turn on ppc64 builds in plague for extras packages on devel only. We need to enable this so that we can continue to support G5 macs and other 64 bit ppc platforms. Everything will need to be built for ppc64. Dennis From mattdm at mattdm.org Thu Mar 15 04:25:01 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 00:25:01 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <20070313212517.GA9946@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> Message-ID: <20070315042501.GA29582@jadzia.bu.edu> On Tue, Mar 13, 2007 at 05:25:17PM -0400, Matthew Miller wrote: > See for > details (and get packages from , as > mentioned there). There's a new version now. Anyone else interested in having a look? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dcbw at redhat.com Thu Mar 15 05:21:13 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Mar 2007 01:21:13 -0400 Subject: ppc64 builds In-Reply-To: <200703142231.51890.dennis@ausil.us> References: <200703142231.51890.dennis@ausil.us> Message-ID: <1173936073.28468.9.camel@localhost.localdomain> On Wed, 2007-03-14 at 22:31 -0500, Dennis Gilmore wrote: > Hey All, > > With the merge of core and extras we need to enable ppc64 builds for what was > formally know as extras. So this weekend I am going to turn on ppc64 builds > in plague for extras packages on devel only. > > We need to enable this so that we can continue to support G5 macs and other 64 > bit ppc platforms. > > Everything will need to be built for ppc64. I thought we were only doing kernels and such for ppc64, because ppc64 normally runs a 32-bit userland just like sparc64? Dan From alan at redhat.com Thu Mar 15 10:34:25 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Mar 2007 06:34:25 -0400 Subject: UTF-8 and filenames In-Reply-To: <1173911058.22102.47.camel@rousalka.dyndns.org> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173911058.22102.47.camel@rousalka.dyndns.org> Message-ID: <20070315103425.GA19361@devserv.devel.redhat.com> On Wed, Mar 14, 2007 at 11:24:18PM +0100, Nicolas Mailhot wrote: > Except userspace has no way to guess the filename encoding: filename > itself is too short to use any sort of euristic, and Linux filesystems > won't provide any other hint. Filenames should be in UTF-8 format. That has been what we've said since forever > 8-bit encoding in an UTF-8 system is asking for trouble (and Linus > refused to enforce UTF-8 safety kernel-side) And Unix behaviour pretty much says you can't and shouldn't do UTF8 filters kernel side if you don't want to break stuff From alexl at redhat.com Thu Mar 15 10:51:23 2007 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Mar 2007 11:51:23 +0100 Subject: UTF-8 and filenames In-Reply-To: <1173912579.14325.39.camel@localhost.localdomain> References: <1173842787.3329.4933.camel@localhost.localdomain> <1173843338.4057.11.camel@localhost.localdomain> <1173851865.3329.4943.camel@localhost.localdomain> <1173852423.4057.30.camel@localhost.localdomain> <1173855678.3329.4948.camel@localhost.localdomain> <1173909793.14325.14.camel@localhost.localdomain> <1173910946.3705.36.camel@willson> <1173912579.14325.39.camel@localhost.localdomain> Message-ID: <1173955883.10024.161.camel@greebo> On Wed, 2007-03-14 at 17:49 -0500, Callum Lerwick wrote: > On Wed, 2007-03-14 at 18:22 -0400, Simo Sorce wrote: > > We can and we should standardize at least at the user space level. > > People expect consistency from a distribution and the tools it ships. > > We've already standardized. UTF-8 is what Nautilus and Gnome/gtk file > selectors and every other GUI app expects and uses. Gnome user can change this with the G_FILENAME_ENCODING env var. Set it to a comma separated list of encodings, with @locale meaning the encoding of the current locale. Gnome/Gtk apps wanting to display filenames should use g_filename_to/from_utf8() so that they properly handle this. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick dishevelled Green Beret with a robot buddy named Sparky. She's a radical gold-digging widow with a flame-thrower. They fight crime! From dennis at ausil.us Thu Mar 15 11:45:25 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Mar 2007 06:45:25 -0500 Subject: ppc64 builds In-Reply-To: <1173936073.28468.9.camel@localhost.localdomain> References: <200703142231.51890.dennis@ausil.us> <1173936073.28468.9.camel@localhost.localdomain> Message-ID: <200703150645.25841.dennis@ausil.us> Once upon a time Thursday 15 March 2007, Dan Williams wrote: > On Wed, 2007-03-14 at 22:31 -0500, Dennis Gilmore wrote: > > Hey All, > > > > With the merge of core and extras we need to enable ppc64 builds for what > > was formally know as extras. So this weekend I am going to turn on ppc64 > > builds in plague for extras packages on devel only. > > > > We need to enable this so that we can continue to support G5 macs and > > other 64 bit ppc platforms. > > > > Everything will need to be built for ppc64. > > I thought we were only doing kernels and such for ppc64, because ppc64 > normally runs a 32-bit userland just like sparc64? > > Dan development tree is all ppc64 and ppc itself has all *-devel packages and the deps in it so someone can if they want build a ppc64 binary. Dennis From jwboyer at jdub.homelinux.org Thu Mar 15 12:11:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 15 Mar 2007 07:11:20 -0500 Subject: The road to the merge In-Reply-To: <20070315013846.GC22805@neu.nirvana> References: <200703141530.15683.jkeating@redhat.com> <20070314204055.GD10100@neu.nirvana> <1173922312.2977.1.camel@vader.jdub.homelinux.org> <20070315013846.GC22805@neu.nirvana> Message-ID: <1173960680.3413.2.camel@zod.rchland.ibm.com> On Thu, 2007-03-15 at 02:38 +0100, Axel Thimm wrote: > On Wed, Mar 14, 2007 at 08:31:51PM -0500, Josh Boyer wrote: > > On Wed, 2007-03-14 at 21:40 +0100, Axel Thimm wrote: > > > On Wed, Mar 14, 2007 at 03:30:15PM -0400, Jesse Keating wrote: > > > > [...] it is pretty clear that there is not a small amount of work to > > > > be done, and I'd really rather not interrupt the mad dash to get > > > > things in before the Test3 freeze, since that is the Feature Freeze > > > > as well. [...] > > > > > > > Basically I want to give people a status update on where things are going, and > > > > what work still needs to be done, and what our expectations are. I welcome > > > > input around when and how to flip the switch and whether or not dropping > > > > this "feature" in after the feature freeze is acceptable. > > > > > > I'd argue that this feature is a meta-feature (e.g. it should not > > > really be observable when someone grabs the final product what kind of > > > buildsystem was used), so perhaps the feature-freeze does not really > > > apply to this part. So, I think it's acceptable to add it after test3. > > > > Yes and no. With a merged collection of packages (which can't happen > > before koji is in place), > > Why not? (Just curious, no disbelieve :) Technically it probably could happen before koji was in place if everything was just moved to Extras CVS and plague was used. But I believe koji provides some additional function that Jesse and Rel-Eng need to actually do freezes and composes. Particularly, tagging of packages to a collection. > > > you could potentially start enabling some features in what were Core > > packages that previously couldn't be done because the libs (or > > whatever) resided in what was Extras. > > It would probably mean that no BR from premerge-extras to > premerge-core will be allowed until then, which would be sad, but > probably bearable. Sure. > > What would you suggest otherwise as an alternative? Slip test3? No > feature freeze until test4? I don't have another suggestion and I think Jesse's and your's seem fine. I was just saying it wasn't exactly a meta-feature :). josh From ville.skytta at iki.fi Thu Mar 15 12:46:59 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 15 Mar 2007 14:46:59 +0200 Subject: Review guidelines and rpmlint In-Reply-To: <20070314223501.GA2916@free.fr> References: <45F08403.3090302@redhat.com> <1173910696.14325.22.camel@localhost.localdomain> <20070314223501.GA2916@free.fr> Message-ID: <200703151446.59882.ville.skytta@iki.fi> On Thursday 15 March 2007, Patrice Dumas wrote: > On Wed, Mar 14, 2007 at 05:18:16PM -0500, Callum Lerwick wrote: > > > If I remember well Ville said that the difference between W and E was > > > quite arbitrary. > > > > And we can always make them less arbitrary. Its not set in stone. > > rpmlint is *our* tool. > > Not really. It has an upstream too. That's right. But the vast majority of features/changes that satisfy our needs are acceptable upstream too. And in the rare cases where they aren't, the Fedora rpmlint package can be patched. Just go ahead and file bugs and RFE's and I'll have a look. From tibbs at math.uh.edu Thu Mar 15 14:42:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Mar 2007 09:42:33 -0500 Subject: ppc64 builds In-Reply-To: <200703142231.51890.dennis@ausil.us> References: <200703142231.51890.dennis@ausil.us> Message-ID: >>>>> "DG" == Dennis Gilmore writes: DG> Everything will need to be built for ppc64. Isn't it a bit late in the game to essentially add another level 1 platform? What do we do if things don't build? Will packages which currently Excludearch: ppc automatically not build for ppc64? If not, who will fix them? And so we need to queue rebuilds for all of our packages? Will this need a release bump as well? I guess six questions exceeds my quota for the day. - J< From jkeating at redhat.com Thu Mar 15 14:57:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 10:57:39 -0400 Subject: ppc64 builds In-Reply-To: References: <200703142231.51890.dennis@ausil.us> Message-ID: <200703151057.39795.jkeating@redhat.com> On Thursday 15 March 2007 10:42:33 Jason L Tibbitts III wrote: > Isn't it a bit late in the game to essentially add another level 1 > platform? All the core packages currently build for ppc64, and they have to continue building for ppc64 if we want to continue supporting 64bit ppc installs. > What do we do if things don't build? ? Unfortunately you'll have to fix them. David Woodhouse is very good at fixing ppc arch specific issues, and will be the PPC maintainer once we can downgrade ppc(64) to a secondary arch. > Will packages which > currently Excludearch: ppc automatically not build for ppc64? No, they are separate arches. > If not, > who will fix them? The maintainer of the package? > And so we need to queue rebuilds for all of our packages? I'm not sure on that one. If we can manage to build what we have already built just for ppc64 without any bumps, that would be nice. > Will this > need a release bump as well? See above. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mlichvar at redhat.com Thu Mar 15 18:31:51 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 15 Mar 2007 19:31:51 +0100 Subject: Orphaning compat-readline43 and compat-slang Message-ID: <20070315183151.GD3308@localhost> I'm orphaning compat-slang and compat-readline43 packages. The packages will be blocked from F7. Nothing depends on them now, so it shouldn't cause any problems and will just save some space. -- Miroslav Lichvar From mattdm at mattdm.org Thu Mar 15 21:16:11 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 17:16:11 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <20070315042501.GA29582@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> <20070315042501.GA29582@jadzia.bu.edu> Message-ID: <20070315211611.GA11129@jadzia.bu.edu> On Thu, Mar 15, 2007 at 12:25:01AM -0400, Matthew Miller wrote: > > See for > > details (and get packages from , as > > mentioned there). > There's a new version now. Anyone else interested in having a look? And now a new, new version. This should be a significant improvement for FC7. And correspondingly, could really stand to be significantly tested. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Mar 15 22:27:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 18:27:06 -0400 Subject: "Core" multilib is broken right now Message-ID: <200703151827.06937.jkeating@redhat.com> It may be due to some of the changes I made to the internal compose tool to do away with the RPMS/ dir, but it seems we're getting all packages as multilib (minus explicit blacklist) rather than the ones that are -devel + deps. I'll be working on fixing this tomorrow. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 16 04:40:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 00:40:16 -0400 Subject: "Core" multilib is broken right now In-Reply-To: <200703151827.06937.jkeating@redhat.com> References: <200703151827.06937.jkeating@redhat.com> Message-ID: <200703160040.19317.jkeating@redhat.com> On Thursday 15 March 2007 18:27:06 Jesse Keating wrote: > It may be due to some of the changes I made to the internal compose tool to > do away with the RPMS/ dir, but it seems we're getting all packages as > multilib (minus explicit blacklist) rather than the ones that are -devel + > deps. I'll be working on fixing this tomorrow. I do believe I've fixed this. We'll see what happens for tomorrow's rawhide (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Fri Mar 16 15:22:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 16 Mar 2007 11:22:49 -0400 Subject: Fedora Developer Ranking System v1 In-Reply-To: <1173915864.14325.66.camel@localhost.localdomain> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E5DD2E.3090305@redhat.com> <1173915864.14325.66.camel@localhost.localdomain> Message-ID: <45FAB649.3010408@redhat.com> Callum Lerwick wrote: > On Wed, 2007-02-28 at 14:51 -0500, Havoc Pennington wrote: >> ACLs are fine as a broad thing to keep total strangers from putting a >> virus in a package - but getting too fine-grained with security >> clearances and policies within a community of people who are supposed to >> be working together is just overhead that sucks energy - implementation, >> administration, and endless policy debates. > > +1000000000 > > Oh thank god its not just me. This is what I've been trying to say. > Maybe it will carry more weight coming from Havoc. ;) OMG, it is Havoc Pennington! I believe we concluded that hp was talking about something different. This resulted from a misunderstanding of what the Ranking system is about (not necessarily fine-grained security levels). Ideas like ranking and Bugzilla scores (or other scores) are just ideas that we can think about for shiny future land (after Fedora 7). Warren Togami wtogami at redhat.com From sundaram at fedoraproject.org Fri Mar 16 15:29:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Mar 2007 20:59:20 +0530 Subject: Request for review: festival 1.96 update In-Reply-To: <20070315042501.GA29582@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> <20070315042501.GA29582@jadzia.bu.edu> Message-ID: <45FAB7D0.3020102@fedoraproject.org> Matthew Miller wrote: > On Tue, Mar 13, 2007 at 05:25:17PM -0400, Matthew Miller wrote: >> See for >> details (and get packages from , as >> mentioned there). > > There's a new version now. Anyone else interested in having a look? I guess asking in fedora-devel list is better. Rahul From mattdm at mattdm.org Fri Mar 16 15:52:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Mar 2007 11:52:54 -0400 Subject: Request for review: festival 1.96 update In-Reply-To: <45FAB7D0.3020102@fedoraproject.org> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> <20070315042501.GA29582@jadzia.bu.edu> <45FAB7D0.3020102@fedoraproject.org> Message-ID: <20070316155254.GA1256@jadzia.bu.edu> On Fri, Mar 16, 2007 at 08:59:20PM +0530, Rahul Sundaram wrote: > >>See for > >>details (and get packages from , as > >>mentioned there). > >There's a new version now. Anyone else interested in having a look? > I guess asking in fedora-devel list is better. Probably. I figured I'd start here since it's a core package. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cweyl at alumni.drew.edu Fri Mar 16 17:34:44 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 16 Mar 2007 10:34:44 -0700 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <20070313223029.75a7a04b@ludwig-alpha.unil.ch> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> <20070313223029.75a7a04b@ludwig-alpha.unil.ch> Message-ID: <7dd7ab490703161034w10737497k727a27f92ee1e452@mail.gmail.com> On 3/13/07, Christian Iseli wrote: > On Tue, 13 Mar 2007 14:05:33 -0700, Chris Weyl wrote: > > Do you know if there's a more generic bug update function that would > > allow me to do both actions in the same update? > > Maybe multicall, along the lines of: Well, after a little testing, multicall works but is still executed as two separate calls. The results returned indicate this (as do the two emails to the review list). ### $res: [ ### { ### excluded => [ ### 'cweyl at alumni.drew.edu' ### ], ### sent => [ ### 'panemade at gmail.com', ### 'cluebot at fedorafaq.org', ### 'fedora-package-review at redhat.com' ### ] ### }, ### { ### excluded => [ ### 'cweyl at alumni.drew.edu' ### ], ### sent => [ ### 'panemade at gmail.com', ### 'cluebot at fedorafaq.org', ### 'fedora-package-review at redhat.com' ### ] ### } ### ] Soo... From what I see it's not possible over XML-RPC. *sigh* Where did you discover updateFlags()? Is this information available generally? -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Fri Mar 16 17:45:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 13:45:39 -0400 Subject: Freeze for Test3 (and string/feature freeze) Message-ID: <200703161345.39275.jkeating@redhat.com> Currently the schedule has Monday the 19th of March as a freeze for Test3. I've completely failed at reminding people about this :/ I've also failed at following up my post about changing the freeze setup so that we freeze on a Tuesday for a following Thursday release. I'd like this to go into effect for Test3, freeze Tuesday the 20th for a Thursday 29th release. Any objections? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Fri Mar 16 18:38:48 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 16 Mar 2007 14:38:48 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <200703161345.39275.jkeating@redhat.com> References: <200703161345.39275.jkeating@redhat.com> Message-ID: <20070316183848.GA31964@devserv.devel.redhat.com> On Fri, Mar 16, 2007 at 01:45:39PM -0400, Jesse Keating wrote: > I'd like this to go into effect for Test3, freeze Tuesday the 20th for a > Thursday 29th release. > > Any objections? For the kernel we have two features that are must haves - the HPA support which I'm working on at the moment, and the correct drive shutdown sequence which is a stop-ship level feature. From fitzsim at redhat.com Fri Mar 16 20:29:34 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 16 Mar 2007 16:29:34 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc Message-ID: <45FAFE2E.8040304@redhat.com> Hi, I'd like to propose the following packages for exclusion from Fedora 7: java-1.4.2-gcj-compat - provided by java-1.5.0-gcj in Rawhide - these packages have BuildRequires for java-1.4.2-gcj-compat*: R-0:2.4.1-3.fc7 db4-0:4.5.20-4.fc7 erlang-0:R11B-2.3.fc7 compat-erlang-0:R10B-10.4.fc6 cairo-java-0:1.0.5-6.fc7 db4-0:4.5.20-4.fc7 openoffice.org-1:2.2.0-12.1 libgconf-java-0:2.12.4-7.fc7 bigloo-0:2.9a-1.fc7 - these packages have Requires for java-1.4.2-gcj-compat*: bouncycastle-0:1.34-2.fc7 lucene-0:1.4.3-1jpp.14 csound-java-0:5.03.0-9.fc7 openoffice.org-sdk-1:2.2.0-11.2 These build and runtime requirements should be satisfied by the new java-1.5.0-gcj packages' compatibility Provides. jessie - provided by libgcj in Rawhide - no packages have BuildRequires for jessie - no packages have Requires for jessie gnu-crypto - provided by libgcj in Rawhide - these packages have BuildRequires for gnu-crypto*: jessie-0:1.0.1-7 azureus-0:2.5.0.0-11.fc7 classpathx-mail-0:1.1.1-4jpp.2 jtidy-2:1.0-0.1.r7dev.1jpp.1.fc7 - these packages have Requires for gnu-crypto*: azureus-0:2.5.0.0-11.fc7 jessie-0:1.0.1-7 Matt Wringe is currently investigating if these requirements can be removed. I think that in all cases it will be as simple as removing the BuildRequires and Requires for gnu-crypto, since gnu-crypto has been merged into libgcj which is already a build and runtime requirement for these packages. gjdoc - provided by sinjdoc in Rawhide - these packages have BuildRequires for gjdoc: java-1.5.0-gcj-0:1.5.0.0-2.fc7 eclipse-1:3.2.2-4.fc7 java-1.4.2-gcj-compat-0:1.4.2.0-40jpp.111 - these packages have Requires for gjdoc: java-1.4.2-gcj-compat-0:1.4.2.0-40jpp.111 Can the eclipse package's build requirement be changed to sinjdoc? The java-1.5.0-gcj build requirement is temporary, pending new gcc rpms. Tom From Christian.Iseli at licr.org Fri Mar 16 21:09:31 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 16 Mar 2007 22:09:31 +0100 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <7dd7ab490703161034w10737497k727a27f92ee1e452@mail.gmail.com> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> <20070313223029.75a7a04b@ludwig-alpha.unil.ch> <7dd7ab490703161034w10737497k727a27f92ee1e452@mail.gmail.com> Message-ID: <20070316220931.6642ff16@ludwig-alpha.unil.ch> On Fri, 16 Mar 2007 10:34:44 -0700, Chris Weyl wrote: > Where did you discover updateFlags()? In a bunch of example scripts warren sent me > Is this information available generally? Not that I know of. I think someone from RH should make a good pass through those scripts to make sure nothing sensitive (e.g. passwords) is forgotten in there and post them somewhere on the wiki... Cheers, C From cweyl at alumni.drew.edu Fri Mar 16 21:14:25 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 16 Mar 2007 14:14:25 -0700 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <20070316220931.6642ff16@ludwig-alpha.unil.ch> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> <20070313223029.75a7a04b@ludwig-alpha.unil.ch> <7dd7ab490703161034w10737497k727a27f92ee1e452@mail.gmail.com> <20070316220931.6642ff16@ludwig-alpha.unil.ch> Message-ID: <7dd7ab490703161414q37f6c8a0sae935bea0d0a857@mail.gmail.com> On 3/16/07, Christian Iseli wrote: > On Fri, 16 Mar 2007 10:34:44 -0700, Chris Weyl wrote: > > Where did you discover updateFlags()? > > In a bunch of example scripts warren sent me > > > Is this information available generally? I figured it was something like that. > Not that I know of. I think someone from RH should make a good pass > through those scripts to make sure nothing sensitive (e.g. passwords) > is forgotten in there and post them somewhere on the wiki... Seconded. I'd even be willing to take the "declassified" scripts and create a documentation page on the wiki. -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Fri Mar 16 21:38:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 17:38:30 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <20070316183848.GA31964@devserv.devel.redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> Message-ID: <200703161738.30476.jkeating@redhat.com> On Friday 16 March 2007 14:38:48 Alan Cox wrote: > For the kernel we have two features that are must haves - the HPA support > which I'm working on at the moment, and the correct drive shutdown sequence > which is a stop-ship level feature. ETA? And what's the fallback option if you can't get these done in a reasonable amount of time? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mwringe at redhat.com Fri Mar 16 21:39:16 2007 From: mwringe at redhat.com (Matt Wringe) Date: Fri, 16 Mar 2007 17:39:16 -0400 Subject: Proposal for Split of xml-commons Message-ID: <1174081156.27403.54.camel@toque.toronto.redhat.com> Hi, I would like to propose the exclusion of xml-commons from Fedora 7, to be replaced by xml-commons-apis and xml-commons-which. The current xml-commons srpm produces the apis and which packages, but each is built from a separate source and it not building in a sane manner. I have split each of these projects into their own srpms: xml-commons-which and xml-commons-apis. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232555 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232557 (these packages have already passed fedora extras review) Inclusion of these packages will mean that the xml-commons package will no longer be needed in Fedora 7. This will also mean the removal of the xml-commons binary rpm. This rpm didn't contain any code, only a couple of license files, and was only used by the subpackages. The new xml-commons-apis virtual provides xml-commons so there shouldn't be any issue with its removal. Thanks, Matt Wringe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Sat Mar 17 00:28:16 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 16 Mar 2007 20:28:16 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <200703161738.30476.jkeating@redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> <200703161738.30476.jkeating@redhat.com> Message-ID: <20070317002816.GB11909@devserv.devel.redhat.com> On Fri, Mar 16, 2007 at 05:38:30PM -0400, Jesse Keating wrote: > On Friday 16 March 2007 14:38:48 Alan Cox wrote: > > For the kernel we have two features that are must haves - the HPA support > > which I'm working on at the moment, and the correct drive shutdown sequence > > which is a stop-ship level feature. > > ETA? And what's the fallback option if you can't get these done in a > reasonable amount of time? HPA testing is going on at the moment so hopefully goes upstream to Jeff in a testable form Monday. The Ubuntu guys had the same need and have done pretty much all the work here. The drive shutdown sequence one I don't know - ask Jeff but since it will shorten drive life its definitely not something we can ship a production production until it is fixed. Alan From alan at redhat.com Sat Mar 17 00:30:41 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 16 Mar 2007 20:30:41 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <200703161738.30476.jkeating@redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> <200703161738.30476.jkeating@redhat.com> Message-ID: <20070317003041.GC11909@devserv.devel.redhat.com> On Fri, Mar 16, 2007 at 05:38:30PM -0400, Jesse Keating wrote: > ETA? And what's the fallback option if you can't get these done in a > reasonable amount of time? Fallback - I don't have one. That is why its currently top of my problem list. With no HPA support we get folk who cannot upgrade or whose upgrade blows up part way (more likely) and they need to reinstall. From sundaram at fedoraproject.org Sat Mar 17 02:43:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 17 Mar 2007 08:13:11 +0530 Subject: Repo merge wiki content and links reorganization Message-ID: <45FB55BF.1020908@fedoraproject.org> Hi Throughout the day I have made several changes to core and extras pages related to the merge. All the pages originally under the /Core hierarchy have been redirected as appropriate. Since pages under the /Packaging hierarchy have ACL's limiting access to the packaging committee, the pages originally under /Extras hierarchy have been moved to http://fedoraproject.org/wiki/PackageMaintainers. I have redone the content of all these pages and setup redirects for all the pages I renamed to ensure that links are not orphaned. There are several pages left untouched yet. Please feel free to reorganize them as required. Rahul From tcallawa at redhat.com Sat Mar 17 17:35:32 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 17 Mar 2007 12:35:32 -0500 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <1174152932.3628.95.camel@localhost.localdomain> On Fri, 2007-03-16 at 16:29 -0400, Thomas Fitzsimmons wrote: > - these packages have BuildRequires for java-1.4.2-gcj-compat*: > > R-0:2.4.1-3.fc7 Fixed in R-2.4.1-4.fc7. ~spot From wtogami at redhat.com Sat Mar 17 19:43:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Sat, 17 Mar 2007 15:43:06 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <20070317003041.GC11909@devserv.devel.redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> <200703161738.30476.jkeating@redhat.com> <20070317003041.GC11909@devserv.devel.redhat.com> Message-ID: <45FC44CA.60609@redhat.com> Alan Cox wrote: > On Fri, Mar 16, 2007 at 05:38:30PM -0400, Jesse Keating wrote: >> ETA? And what's the fallback option if you can't get these done in a >> reasonable amount of time? > > Fallback - I don't have one. That is why its currently top of my problem > list. With no HPA support we get folk who cannot upgrade or whose upgrade > blows up part way (more likely) and they need to reinstall. Is there also risk of blowing away or corrupting whatever data is in the HPA? Warren Togami wtogami at redhat.com From alan at redhat.com Sat Mar 17 19:59:17 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 17 Mar 2007 15:59:17 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <45FC44CA.60609@redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> <200703161738.30476.jkeating@redhat.com> <20070317003041.GC11909@devserv.devel.redhat.com> <45FC44CA.60609@redhat.com> Message-ID: <20070317195917.GC21441@devserv.devel.redhat.com> On Sat, Mar 17, 2007 at 03:43:06PM -0400, Warren Togami wrote: > >Fallback - I don't have one. That is why its currently top of my problem > >list. With no HPA support we get folk who cannot upgrade or whose upgrade > >blows up part way (more likely) and they need to reinstall. > > Is there also risk of blowing away or corrupting whatever data is in the > HPA? If you have a system which is using the HPA for drive clipping to avoid BIOS bugs with old BIOSes, or is setting it but it was cleared and then repartitioned for Linux then an upgrade without HPA resetting will begin happily munching away and then blow up when it touches the first sector of an update that is in the HPA region. You can (usually) detect this because the partition table end will point outside the apparent disk size. In the other direction if you remove the HPA and don't repartition then you'll not create anything that leaks out and you can detect the HPA size and boot size by querying the drive initial id data (which unlike drivers/ide actually is the initial data). My test code requires booting with libata.ignore_hpa=1 to remove the HPA, I'm not sure what the right default is. Alan From jgarzik at redhat.com Sat Mar 17 20:16:38 2007 From: jgarzik at redhat.com (Jeff Garzik) Date: Sat, 17 Mar 2007 16:16:38 -0400 Subject: Freeze for Test3 (and string/feature freeze) In-Reply-To: <20070317195917.GC21441@devserv.devel.redhat.com> References: <200703161345.39275.jkeating@redhat.com> <20070316183848.GA31964@devserv.devel.redhat.com> <200703161738.30476.jkeating@redhat.com> <20070317003041.GC11909@devserv.devel.redhat.com> <45FC44CA.60609@redhat.com> <20070317195917.GC21441@devserv.devel.redhat.com> Message-ID: <20070317201637.GA8842@devserv.devel.redhat.com> On Sat, Mar 17, 2007 at 03:59:17PM -0400, Alan Cox wrote: > My test code requires booting with libata.ignore_hpa=1 to remove the HPA, > I'm not sure what the right default is. I don't think much of consequence blows up if the underlying disk is suddenly larger, right? I would rather default HPA to on if at all possible. My main worry is breaking SATA with this new default. Jeff From fitzsim at redhat.com Sun Mar 18 01:49:17 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sat, 17 Mar 2007 21:49:17 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <45FC9A9D.2010909@redhat.com> Thomas Fitzsimmons wrote: > - these packages have BuildRequires for gjdoc: > > java-1.5.0-gcj-0:1.5.0.0-2.fc7 Fixed in java-1.5.0-gcj-0:1.5.0.0-4.fc7. Tom From dwmw2 at infradead.org Sun Mar 18 12:05:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Mar 2007 12:05:37 +0000 Subject: ppc64 builds In-Reply-To: <200703151057.39795.jkeating@redhat.com> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> Message-ID: <1174219537.3461.610.camel@pmac.infradead.org> On Thu, 2007-03-15 at 10:57 -0400, Jesse Keating wrote: > > > And so we need to queue rebuilds for all of our packages? > > I'm not sure on that one. If we can manage to build what we have already > built just for ppc64 without any bumps, that would be nice. We've never bothered shipping 64-bit versions of Extras packages before -- unless you suddenly find an overriding reason to do so, I don't see any reason to rebuild for F7 just to add a 64-bit binary package which we don't need to ship anyway. -- dwmw2 From Axel.Thimm at ATrpms.net Sun Mar 18 13:57:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 14:57:19 +0100 Subject: ppc64 builds In-Reply-To: <1174219537.3461.610.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> Message-ID: <20070318135719.GF24404@neu.nirvana> On Sun, Mar 18, 2007 at 12:05:37PM +0000, David Woodhouse wrote: > On Thu, 2007-03-15 at 10:57 -0400, Jesse Keating wrote: > > > > > And so we need to queue rebuilds for all of our packages? > > > > I'm not sure on that one. If we can manage to build what we have already > > built just for ppc64 without any bumps, that would be nice. > > We've never bothered shipping 64-bit versions of Extras packages before > -- unless you suddenly find an overriding reason to do so, I don't see > any reason to rebuild for F7 just to add a 64-bit binary package which > we don't need to ship anyway. 36% of FC6/ppc Core are shipped as 64 bit packages, which means that there is quite often the demand/desire to do so. It is very unlikely that the demand in Extras is 0. The fact that Extras didn't build/ship 64 bits for ppc was probably more a technical one, but since the worlds unite, anything that was possible with a former Core package will be possible with a former Extras package, too. 36% also indicates that not all ppc packages make sense to build as 64 bits, but rather about a third. This looks like the packagers need to decide on a package by package basis and communicate this to the buildsystem, either by the package database or some metafile in the sources. But since this mechanism has to have been available to Core, we just need to let packagers know how to trigger this, if they want it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Mar 18 14:02:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 15:02:24 +0100 Subject: ppc64 builds In-Reply-To: <20070318135719.GF24404@neu.nirvana> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <20070318135719.GF24404@neu.nirvana> Message-ID: <20070318140224.GG24404@neu.nirvana> On Sun, Mar 18, 2007 at 02:57:19PM +0100, Axel Thimm wrote: > On Sun, Mar 18, 2007 at 12:05:37PM +0000, David Woodhouse wrote: > > On Thu, 2007-03-15 at 10:57 -0400, Jesse Keating wrote: > > > > > > > And so we need to queue rebuilds for all of our packages? > > > > > > I'm not sure on that one. If we can manage to build what we have already > > > built just for ppc64 without any bumps, that would be nice. > > > > We've never bothered shipping 64-bit versions of Extras packages before > > -- unless you suddenly find an overriding reason to do so, I don't see > > any reason to rebuild for F7 just to add a 64-bit binary package which > > we don't need to ship anyway. > > 36% of FC6/ppc Core are shipped as 64 bit packages, which means that > there is quite often the demand/desire to do so. It is very unlikely > that the demand in Extras is 0. I redid the math for F7 and the same percentage was given back. In order to get something different I also checked FC5 and there we had 14% in Core. So the stats of Core ppc packages shipped as ppc64 versions as well are: FC5: 14% FC6: 36% F7: 36% > The fact that Extras didn't build/ship 64 bits for ppc was probably > more a technical one, but since the worlds unite, anything that was > possible with a former Core package will be possible with a former > Extras package, too. > > 36% also indicates that not all ppc packages make sense to build as 64 > bits, but rather about a third. This looks like the packagers need to > decide on a package by package basis and communicate this to the > buildsystem, either by the package database or some metafile in the > sources. But since this mechanism has to have been available to Core, > we just need to let packagers know how to trigger this, if they want > it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Mar 18 15:30:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 18 Mar 2007 11:30:31 -0400 Subject: ppc64 builds In-Reply-To: <1174219537.3461.610.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> Message-ID: <200703181130.35571.jkeating@redhat.com> On Sunday 18 March 2007 08:05:37 David Woodhouse wrote: > We've never bothered shipping 64-bit versions of Extras packages before > -- unless you suddenly find an overriding reason to do so, I don't see > any reason to rebuild for F7 just to add a 64-bit binary package which > we don't need to ship anyway. By merging all the packages into one big collection we can't segregate "Extras" and "Core" anymore for decisions such as build for ppc64 or not. Every package will build for every arch unless explicitly told not to, and if told, there is supposed to be bug regarding this according to our guidelines (which you wanted IIRC). This means we need to turn on ppc64 in the new build system to keep the current "Core" packages building there, and we need to bootstrap the rest of the packages so that they can start building ppc64 without causing failures all over the place. Whether or not the builds wind up on the "ppc" compose is a different story, although I do believe we need to publish a pure ppc64 tree alongside the other trees, so that derivative folks can have something to build from. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Mar 18 15:32:42 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 18 Mar 2007 10:32:42 -0500 Subject: ppc64 builds In-Reply-To: <1174219537.3461.610.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> Message-ID: <200703181032.44173.dennis@ausil.us> Once upon a time Sunday 18 March 2007, David Woodhouse wrote: > On Thu, 2007-03-15 at 10:57 -0400, Jesse Keating wrote: > > > And so we need to queue rebuilds for all of our packages? > > > > I'm not sure on that one. If we can manage to build what we have already > > built just for ppc64 without any bumps, that would be nice. > > We've never bothered shipping 64-bit versions of Extras packages before > -- unless you suddenly find an overriding reason to do so, I don't see > any reason to rebuild for F7 just to add a 64-bit binary package which > we don't need to ship anyway. David do you still want ppc64 support? if so it needs built. we dont have any way to say build this package ppc64 and this one not. Its all or nothing. there is no more extras there is only Fedora. Im just as happy to say you get no more ppc64 kernel glibc etc which will be the outcome if we dont do this Dennis From chitlesh at fedoraproject.org Sun Mar 18 18:11:38 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Mar 2007 19:11:38 +0100 Subject: Paul F. Johnson In-Reply-To: <20070313080137.a5154000.bugs.michael@gmx.net> References: <20070313080137.a5154000.bugs.michael@gmx.net> Message-ID: <13dbfe4f0703181111x70555cafk29165935c3ed636b@mail.gmail.com> On 3/13/07, Michael Schwendt wrote: > Trying to get another reply from "Paul F. Johnson" in bugzilla has failed > since 2007-02-16, 2007-02-26, and 2007-03-02: Is Paul F. Johnson still around ? He was supposed to review one of my packages :P https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221027 Chitlesh -- http://clunixchit.blogspot.com From giallu at gmail.com Sun Mar 18 18:20:29 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 18 Mar 2007 19:20:29 +0100 Subject: Paul F. Johnson In-Reply-To: <13dbfe4f0703181111x70555cafk29165935c3ed636b@mail.gmail.com> References: <20070313080137.a5154000.bugs.michael@gmx.net> <13dbfe4f0703181111x70555cafk29165935c3ed636b@mail.gmail.com> Message-ID: On 3/18/07, Chitlesh GOORAH wrote: > On 3/13/07, Michael Schwendt wrote: > > Trying to get another reply from "Paul F. Johnson" in bugzilla has failed > > since 2007-02-16, 2007-02-26, and 2007-03-02: > > Is Paul F. Johnson still around ? > > He was supposed to review one of my packages :P > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221027 > Seems he posted today on fedora-extras (though it passed some time since his last post...) From dwmw2 at infradead.org Sun Mar 18 18:43:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Mar 2007 18:43:18 +0000 Subject: ppc64 builds In-Reply-To: <200703181130.35571.jkeating@redhat.com> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> Message-ID: <1174243398.3392.7.camel@pmac.infradead.org> On Sun, 2007-03-18 at 11:30 -0400, Jesse Keating wrote: > On Sunday 18 March 2007 08:05:37 David Woodhouse wrote: > > We've never bothered shipping 64-bit versions of Extras packages before > > -- unless you suddenly find an overriding reason to do so, I don't see > > any reason to rebuild for F7 just to add a 64-bit binary package which > > we don't need to ship anyway. > > By merging all the packages into one big collection we can't > segregate "Extras" and "Core" anymore for decisions such as build for ppc64 > or not. Every package will build for every arch unless explicitly told not > to, and if told, there is supposed to be bug regarding this according to our > guidelines (which you wanted IIRC). This means we need to turn on ppc64 in > the new build system to keep the current "Core" packages building there, and > we need to bootstrap the rest of the packages so that they can start building > ppc64 without causing failures all over the place. This is true. I was just suggesting that we don't necessarily need to rush out and do a mass rebuild of all Extras packages before F7 just to create ppc64 versions of them, since those _wouldn't_ be likely to end up in the "ppc" compose; they'd only be in the pure ppc64 tree which isn't a product we release; it's just the same as the unshipped ia64, s390 rawhide trees. -- dwmw2 From dwmw2 at infradead.org Sun Mar 18 18:50:06 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Mar 2007 18:50:06 +0000 Subject: ppc64 builds In-Reply-To: <20070318135719.GF24404@neu.nirvana> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <20070318135719.GF24404@neu.nirvana> Message-ID: <1174243806.3392.16.camel@pmac.infradead.org> On Sun, 2007-03-18 at 14:57 +0100, Axel Thimm wrote: > 36% of FC6/ppc Core are shipped as 64 bit packages, which means that > there is quite often the demand/desire to do so. It is very unlikely > that the demand in Extras is 0. > > The fact that Extras didn't build/ship 64 bits for ppc was probably > more a technical one, but since the worlds unite, anything that was > possible with a former Core package will be possible with a former > Extras package, too. > > 36% also indicates that not all ppc packages make sense to build as 64 > bits, but rather about a third. This looks like the packagers need to > decide on a package by package basis and communicate this to the > buildsystem, either by the package database or some metafile in the > sources. But since this mechanism has to have been available to Core, > we just need to let packagers know how to trigger this, if they want > it. Currently it's just a rather crappy heuristic -- "does it have a -devel subpackage?". That worked well enough as a first attempt, but it's not really good enough. Ideally, I think we want a new RPM tag for it, and it can be specified in the specfile. The package author can then specify whether the package should be shipped for the secondary arch (i386 on x86_64, or ppc64 on ppc64), and even whether the secondary version should be _favoured_ (64-bit gdb on ppc64). There are those who make coherent arguments that we should prevent RPM from allowing multilib installations of packages with 'conflicting' executable files in /usr/bin. Instead of just 'foo' and 'foo-devel', we should have 'foo', 'foo-libs', and 'foo-devel' packages. The stuff in /usr/bin should be in 'foo' and you should have _one_ version installed, not two. Firefox is a prime example of where we got this wrong, shipping it in ppc64 form because it had a -devel subpackage, and shipping both executables _and_ libraries in the 'firefox' package instead of splitting into 'firefox' and 'firefox-libs' packages. We're fixing that when we switch to xulrunner. After a clean install on ppc64, I really shouldn't have _any_ 64-bit binaries in /usr/bin other than gdb and maybe one or two similar tools which actually need to be 64-bit, like strace. This is obviously something to be addressed after the F7 release. -- dwmw2 From bugs.michael at gmx.net Sun Mar 18 19:13:05 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Mar 2007 20:13:05 +0100 Subject: ppc64 builds In-Reply-To: <1174243398.3392.7.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> <1174243398.3392.7.camel@pmac.infradead.org> Message-ID: <20070318201305.a4e16f21.bugs.michael@gmx.net> On Sun, 18 Mar 2007 18:43:18 +0000, David Woodhouse wrote: > On Sun, 2007-03-18 at 11:30 -0400, Jesse Keating wrote: > > On Sunday 18 March 2007 08:05:37 David Woodhouse wrote: > > > We've never bothered shipping 64-bit versions of Extras packages before > > > -- unless you suddenly find an overriding reason to do so, I don't see > > > any reason to rebuild for F7 just to add a 64-bit binary package which > > > we don't need to ship anyway. > > > > By merging all the packages into one big collection we can't > > segregate "Extras" and "Core" anymore for decisions such as build for ppc64 > > or not. Every package will build for every arch unless explicitly told not > > to, and if told, there is supposed to be bug regarding this according to our > > guidelines (which you wanted IIRC). This means we need to turn on ppc64 in > > the new build system to keep the current "Core" packages building there, and > > we need to bootstrap the rest of the packages so that they can start building > > ppc64 without causing failures all over the place. > > This is true. I was just suggesting that we don't necessarily need to > rush out and do a mass rebuild of all Extras packages before F7 just to > create ppc64 versions of them, since those _wouldn't_ be likely to end > up in the "ppc" compose; they'd only be in the pure ppc64 tree which > isn't a product we release; it's just the same as the unshipped ia64, > s390 rawhide trees. From Push.py: # rpmUtils.arch.getBaseArch(a) elif a in ['i386', 'i486', 'i586', 'i686', 'athlon']: basearch = 'i386' elif a in ['x86_64', 'ia32e', 'amd64']: basearch = 'x86_64' elif a in ['ppc', 'ppc64', 'ppc32']: basearch = 'ppc' else: print 'Unknown arch %s' % a continue # with next package From Axel.Thimm at ATrpms.net Sun Mar 18 19:12:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 20:12:11 +0100 Subject: ppc64 builds In-Reply-To: <1174243398.3392.7.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> <1174243398.3392.7.camel@pmac.infradead.org> Message-ID: <20070318191211.GA4773@neu.nirvana> On Sun, Mar 18, 2007 at 06:43:18PM +0000, David Woodhouse wrote: > On Sun, 2007-03-18 at 11:30 -0400, Jesse Keating wrote: > > On Sunday 18 March 2007 08:05:37 David Woodhouse wrote: > > > We've never bothered shipping 64-bit versions of Extras packages before > > > -- unless you suddenly find an overriding reason to do so, I don't see > > > any reason to rebuild for F7 just to add a 64-bit binary package which > > > we don't need to ship anyway. > > > > By merging all the packages into one big collection we can't > > segregate "Extras" and "Core" anymore for decisions such as build for ppc64 > > or not. Every package will build for every arch unless explicitly told not > > to, and if told, there is supposed to be bug regarding this according to our > > guidelines (which you wanted IIRC). This means we need to turn on ppc64 in > > the new build system to keep the current "Core" packages building there, and > > we need to bootstrap the rest of the packages so that they can start building > > ppc64 without causing failures all over the place. > > This is true. I was just suggesting that we don't necessarily need to > rush out and do a mass rebuild of all Extras packages before F7 just to > create ppc64 versions of them, since those _wouldn't_ be likely to end > up in the "ppc" compose; they'd only be in the pure ppc64 tree which > isn't a product we release; it's just the same as the unshipped ia64, > s390 rawhide trees. You mean anything that doesn't get on one of the spins will get banned off the ftp servers? ;=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tgl at redhat.com Mon Mar 19 06:51:24 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 19 Mar 2007 02:51:24 -0400 Subject: ppc64 builds In-Reply-To: <200703181130.35571.jkeating@redhat.com> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> Message-ID: <22335.1174287084@sss.pgh.pa.us> Jesse Keating writes: > By merging all the packages into one big collection we can't > segregate "Extras" and "Core" anymore for decisions such as build for ppc64 > or not. Every package will build for every arch unless explicitly told not > to, and if told, there is supposed to be bug regarding this according to our > guidelines (which you wanted IIRC). AFAIK, not building a ppc64 version should not be a "bug", indeed it likely should be the default. 32-bit code runs faster than 64-bit code on that arch, and so the only reason to build 64-bit is if you really need access to more than 4Gb of address space. There are apps that need that, but not all that many. So my position is that libraries should generally be built in both flavors (since they can't predict which flavor of executable might want them) but applications should be built as 32-bit unless there's a good reason why they need a 64-bit address space. (If you ask me, the interesting question here is why the other arches don't behave the same way. Any reasonably competent hardware design should have the property that doubling the bit-volume of traffic to main memory has a penalty...) regards, tom lane From dwmw2 at infradead.org Mon Mar 19 06:59:57 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Mar 2007 06:59:57 +0000 Subject: ppc64 builds In-Reply-To: <22335.1174287084@sss.pgh.pa.us> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> <22335.1174287084@sss.pgh.pa.us> Message-ID: <1174287597.3392.47.camel@pmac.infradead.org> On Mon, 2007-03-19 at 02:51 -0400, Tom Lane wrote: > AFAIK, not building a ppc64 version should not be a "bug", indeed it > likely should be the default. 32-bit code runs faster than 64-bit code > on that arch, and so the only reason to build 64-bit is if you really > need access to more than 4Gb of address space. There are apps that need > that, but not all that many. > > So my position is that libraries should generally be built in both > flavors (since they can't predict which flavor of executable might want > them) but applications should be built as 32-bit unless there's a good > reason why they need a 64-bit address space. Certainly I agree that we should _ship_ no executables in 64-bit mode other than the ones which actually need it, like perhaps gdb. However, we currently need a pure 64-bit buildroot for building the 64-bit stuff, so in practice we'll need to build _some_ 64-bit packages that don't get shipped. It might well be easier just to build them all. > (If you ask me, the interesting question here is why the other arches > don't behave the same way. Any reasonably competent hardware design > should have the property that doubling the bit-volume of traffic to > main memory has a penalty...) We do it the other way round on i386 because i386 _isn't_ something we could consider a "reasonably competent" design these days. It has too few registers, and the benefit of switching to x86_64 mode and actually having a sensible number of registers is more than sufficient to offset the bloat of 64-bit code. -- dwmw2 From jakub at redhat.com Mon Mar 19 07:45:19 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 19 Mar 2007 02:45:19 -0500 Subject: ppc64 builds In-Reply-To: <22335.1174287084@sss.pgh.pa.us> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181130.35571.jkeating@redhat.com> <22335.1174287084@sss.pgh.pa.us> Message-ID: <20070319074519.GI355@devserv.devel.redhat.com> On Mon, Mar 19, 2007 at 02:51:24AM -0400, Tom Lane wrote: > AFAIK, not building a ppc64 version should not be a "bug", indeed it > likely should be the default. 32-bit code runs faster than 64-bit code > on that arch, and so the only reason to build 64-bit is if you really > need access to more than 4Gb of address space. There are apps that need > that, but not all that many. > > So my position is that libraries should generally be built in both > flavors (since they can't predict which flavor of executable might want > them) but applications should be built as 32-bit unless there's a good > reason why they need a 64-bit address space. On ppc/sparc yes, plus rpm should prefer there 32-bit packages over 64-bit ones (currently it prefers 64-bit), but there should be a way to override this on a per-package basis (things like gdb and a few others that prefer to be 64-bit if possible). > (If you ask me, the interesting question here is why the other arches > don't behave the same way. Any reasonably competent hardware design > should have the property that doubling the bit-volume of traffic to > main memory has a penalty...) On x86_64 the thing that makes 64-bit code more desirable is doubling the number of general purpose registers and a better addressing mode for PIC code (%rip addressing). So for most apps on x86_64 using 64-bit programs is an overall win. On s390x 64-bit code can use direct calls rather than always loading a function address from literal pool and calling indirectly and a few other improvements, so I believe running 64-bit code on s390x is as slow/fast as 31-bit code. Jakub From jkeating at redhat.com Mon Mar 19 12:15:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 08:15:05 -0400 Subject: ppc64 builds In-Reply-To: <1174243398.3392.7.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703181130.35571.jkeating@redhat.com> <1174243398.3392.7.camel@pmac.infradead.org> Message-ID: <200703190815.08560.jkeating@redhat.com> On Sunday 18 March 2007 14:43:18 David Woodhouse wrote: > This is true. I was just suggesting that we don't necessarily need to > rush out and do a mass rebuild of all Extras packages before F7 just to > create ppc64 versions of them, since those _wouldn't_ be likely to end > up in the "ppc" compose; they'd only be in the pure ppc64 tree which > isn't a product we release; it's just the same as the unshipped ia64, > s390 rawhide trees. Except that we need them to be able to build for ppc64. Every single build from the merge point on will build for our primary arches, which at this time is i386, x86_64, ppc, and ppc64. We can't selectively build things, that arch has to be one for every package unless the package decides to not build for that arch. That is part of being a primary arch. If a ppc64 build fails, the entire build fails, and will have to be fixed. Also, we've (the Fedora Board and I) have talked about actually "shipping" the full tree for each arch. We accomplish this for i386, x86_64, and ppc by nature of those composes, but we don't for ppc64. Just because we (Fedora) made one decision about what to or not to ship ppc64 doesn't mean that should be the same decision for anybody basing a distribution off of Fedora. They should have equal access to the binary packages that fall out of our buildsystem as we do, and that generally means shipping them in a directory. During rawhide we continue doing the ppc64 directory of just 64bit packages, at release time we ship a directory of them, and we continue to populate an updates directory for it. This feels like the responsible thing to do, and it only takes up a bit more space since we'd be building them anyway due to ppc(64) being a primary arch. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 19 12:20:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 08:20:20 -0400 Subject: ppc64 builds In-Reply-To: <1174243806.3392.16.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> Message-ID: <200703190820.20739.jkeating@redhat.com> On Sunday 18 March 2007 14:50:06 David Woodhouse wrote: > Ideally, I think we want a new RPM tag for it, and it can be specified > in the specfile. The package author can then specify whether the package > should be shipped for the secondary arch (i386 on x86_64, or ppc64 on > ppc64), and even whether the secondary version should be _favoured_ > (64-bit gdb on ppc64). Unfortunately multilib isn't well understood by a large majority of our maintainers, both inside RH and without. Leaving it up to the maintainer is pretty much going to result in the vast majority of packages not being multilib, especially the first time a multilib problem is found, boom, multilib off rather than fixing the problem. Add to that the confusion of "Hey, I set my package to not be multilib, why is it landing in the tree as multilib" when we bring things in due to deps of some other package that was marked as multilib. These are just a couple of problems I see with leaving it up to the maintainer. Not that there aren't problems with the way it is done now, but at least there we can typically blacklist something (if it isn't brought in by deps) or re-adjust the packaging to make it more sane. Firefox was a rather unique situation and an unfortunate outcome, but I don't think it is fair to base the entire multilib experience on Firefox ppc64, something which extremely few of our users would have seen/experienced. But I do appreciate you thinking about how to better manage this! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 19 12:26:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 08:26:51 -0400 Subject: ppc64 builds In-Reply-To: <22335.1174287084@sss.pgh.pa.us> References: <200703142231.51890.dennis@ausil.us> <200703181130.35571.jkeating@redhat.com> <22335.1174287084@sss.pgh.pa.us> Message-ID: <200703190826.51120.jkeating@redhat.com> On Monday 19 March 2007 02:51:24 Tom Lane wrote: > AFAIK, not building a ppc64 version should not be a "bug", indeed it > likely should be the default. Any arch that you have to exclude should be for a really good reason (like grub doesn't function on non x86 arches), or there should be a bug filed as to why that software doesn't compile for a particular arch. This is orthogonal as to whether or not it would be "useful" to have it for that arch. > 32-bit code runs faster than 64-bit code > on that arch, and so the only reason to build 64-bit is if you really > need access to more than 4Gb of address space. ?There are apps that need > that, but not all that many. > > So my position is that libraries should generally be built in both > flavors (since they can't predict which flavor of executable might want > them) but applications should be built as 32-bit unless there's a good > reason why they need a 64-bit address space. But most "applications" ship a set of "libraries" for use with that app and potentially other apps. So we have to build that "application" package for the other arch. Now if we did have that tag to prefer specific 64bit things over 3[21]bit a lot of this problem would go away for ppc/sparc. The same packages would be multilib but you'd get the right runtime and both libs. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Mon Mar 19 15:26:03 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 19 Mar 2007 11:26:03 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <20070319152603.GA3053@redhat.com> * Thomas Fitzsimmons [2007-03-16 16:29]: > Can the eclipse package's build requirement be changed to sinjdoc? The > java-1.5.0-gcj build requirement is temporary, pending new gcc rpms. Yeah, it can be removed. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 19 15:47:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 11:47:15 -0400 Subject: Freeze for Test 3 (and adjusted schedule) Message-ID: <200703191147.15481.jkeating@redhat.com> I went ahead and shifted the freeze/release schedule for Test3 (and 4). We now freeze on a Tuesday for a release the following Thursday. Hopefully this will cut down on the slips we have to do. This is also a reminder that Tuesday the 20th of March is now the freeze for Test 3. I plan on "freezing" later in the afternoon Eastern US time. I'll announce once frozen. http://fedoraproject.org/wiki/Releases/Schedule has been updated. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fitzsim at redhat.com Mon Mar 19 16:11:42 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 19 Mar 2007 12:11:42 -0400 Subject: moving java-1.5.0-gcj and sinjdoc from Extras to Core Message-ID: <45FEB63E.6020809@redhat.com> Hi, I introduced java-1.5.0-gcj and sinjdoc into Extras, thinking that the Core/Extras merge would happen sooner than it has. This is a problem because Brew can't pull build requirements from Extras. I'm working with releng to move java-1.5.0-gcj and sinjdoc into Core. In the meantime, you may have problems building Java packages in Brew. I'll post an update when the move has happened. Tom From ville.skytta at iki.fi Mon Mar 19 18:23:04 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 19 Mar 2007 20:23:04 +0200 Subject: ppc64 builds In-Reply-To: <1174287597.3392.47.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <22335.1174287084@sss.pgh.pa.us> <1174287597.3392.47.camel@pmac.infradead.org> Message-ID: <200703192023.05368.ville.skytta@iki.fi> (Sorry for replying to a wrong message in this thread, but I don't have the original available any more.) ppc64 is now listed in the archs of the ppc1 builder. However, the buildsys did not try to build a new em8300-kmod revision in which I added ppc64 to ExclusiveArch for ppc64. Configuration bug somewhere? http://buildsys.fedoraproject.org/build-status/job.psp?uid=29667 From dennis at ausil.us Mon Mar 19 18:44:42 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Mar 2007 13:44:42 -0500 Subject: ppc64 builds In-Reply-To: <200703192023.05368.ville.skytta@iki.fi> References: <200703142231.51890.dennis@ausil.us> <1174287597.3392.47.camel@pmac.infradead.org> <200703192023.05368.ville.skytta@iki.fi> Message-ID: <200703191344.43063.dennis@ausil.us> On Monday 19 March 2007 01:23:04 pm Ville Skytt? wrote: > (Sorry for replying to a wrong message in this thread, but I don't have the > original available any more.) > > ppc64 is now listed in the archs of the ppc1 builder. However, the > buildsys did not try to build a new em8300-kmod revision in which I added > ppc64 to ExclusiveArch for ppc64. Configuration bug somewhere? > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=29667 right now ppc64 is a separate target. to build for ppc64 you need a line like plague-client build em8300-kmod em8300-kmod-0_16_1-7_2_6_20_1_2997_fc7 fc7ppc64 which will build the ppc64 build. I was thinking it would be best to get things built ppc64 before breaking the world by enabling ppc64 by default. But if people disagree wit me on this yell at me and ill make ppc64 builds enabled by default. -- Dennis Gilmore, RHCE From jwboyer at jdub.homelinux.org Mon Mar 19 18:59:29 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 13:59:29 -0500 Subject: ppc64 builds In-Reply-To: <200703191344.43063.dennis@ausil.us> References: <200703142231.51890.dennis@ausil.us> <1174287597.3392.47.camel@pmac.infradead.org> <200703192023.05368.ville.skytta@iki.fi> <200703191344.43063.dennis@ausil.us> Message-ID: <1174330769.30079.57.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 13:44 -0500, Dennis Gilmore wrote: > On Monday 19 March 2007 01:23:04 pm Ville Skytt? wrote: > > (Sorry for replying to a wrong message in this thread, but I don't have the > > original available any more.) > > > > ppc64 is now listed in the archs of the ppc1 builder. However, the > > buildsys did not try to build a new em8300-kmod revision in which I added > > ppc64 to ExclusiveArch for ppc64. Configuration bug somewhere? > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=29667 > > right now ppc64 is a separate target. to build for ppc64 you need a line like > plague-client build em8300-kmod em8300-kmod-0_16_1-7_2_6_20_1_2997_fc7 > fc7ppc64 > which will build the ppc64 build. I was thinking it would be best to get > things built ppc64 before breaking the world by enabling ppc64 by default. > But if people disagree wit me on this yell at me and ill make ppc64 builds > enabled by default. Can anyone queue up a build manually like that? If so, I'd like to have a small task group do the rebuilds manually and see how it goes. josh From wtogami at redhat.com Mon Mar 19 19:01:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Mar 2007 15:01:06 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions Message-ID: <45FEDDF2.1050208@redhat.com> fedora-maintainers is our by-invite-only distribution development discussion list. We keep it this way in an attempt to improve the signal to noise ratio. Problem ======= fedora-maintainers does not automatically grow as new, potentially useful maintainers join the project. Currently new members are invited only if someone does it manually, or if someone approves a subscription request. Proposal ======== If cvsextras access is sponsored, FAS runs a script that logs into the mailman admin page and sends an Invite to the e-mail address on the FAS account. This script could be relatively simple to implement, using curl or some other command-line tool. Any objections? Any volunteers to write this script? Warren Togami wtogami at redhat.com From dennis at ausil.us Mon Mar 19 19:07:22 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Mar 2007 14:07:22 -0500 Subject: ppc64 builds In-Reply-To: <1174330769.30079.57.camel@zod.rchland.ibm.com> References: <200703142231.51890.dennis@ausil.us> <200703191344.43063.dennis@ausil.us> <1174330769.30079.57.camel@zod.rchland.ibm.com> Message-ID: <200703191407.23173.dennis@ausil.us> On Monday 19 March 2007 01:59:29 pm Josh Boyer wrote: > On Mon, 2007-03-19 at 13:44 -0500, Dennis Gilmore wrote: > > On Monday 19 March 2007 01:23:04 pm Ville Skytt? wrote: > > > (Sorry for replying to a wrong message in this thread, but I don't have > > > the original available any more.) > > > > > > ppc64 is now listed in the archs of the ppc1 builder. However, the > > > buildsys did not try to build a new em8300-kmod revision in which I > > > added ppc64 to ExclusiveArch for ppc64. Configuration bug somewhere? > > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=29667 > > > > right now ppc64 is a separate target. to build for ppc64 you need a line > > like plague-client build em8300-kmod > > em8300-kmod-0_16_1-7_2_6_20_1_2997_fc7 fc7ppc64 > > which will build the ppc64 build. I was thinking it would be best to get > > things built ppc64 before breaking the world by enabling ppc64 by > > default. But if people disagree wit me on this yell at me and ill make > > ppc64 builds enabled by default. > > Can anyone queue up a build manually like that? If so, I'd like to have > a small task group do the rebuilds manually and see how it goes. > > josh anyone can queue a build manually that way the format is plague-client build fc7ppc64 -- Dennis Gilmore, RHCE From jkeating at redhat.com Mon Mar 19 19:09:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 15:09:35 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FEDDF2.1050208@redhat.com> References: <45FEDDF2.1050208@redhat.com> Message-ID: <200703191509.35517.jkeating@redhat.com> On Monday 19 March 2007 15:01:06 Warren Togami wrote: > Any objections? None from me. Of course it'll check to see if said person is already invited right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Mon Mar 19 19:14:59 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 19 Mar 2007 15:14:59 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FEDDF2.1050208@redhat.com> References: <45FEDDF2.1050208@redhat.com> Message-ID: <1174331699.16159.30.camel@localhost.localdomain> On Mon, 2007-03-19 at 15:01 -0400, Warren Togami wrote: > fedora-maintainers is our by-invite-only distribution development > discussion list. We keep it this way in an attempt to improve the > signal to noise ratio. > > Problem > ======= > fedora-maintainers does not automatically grow as new, potentially > useful maintainers join the project. Currently new members are invited > only if someone does it manually, or if someone approves a subscription > request. > > Proposal > ======== > If cvsextras access is sponsored, FAS runs a script that logs into the > mailman admin page and sends an Invite to the e-mail address on the FAS > account. > > This script could be relatively simple to implement, using curl or some > other command-line tool. > > Any objections? Sounds good to me. --Chris From mattdm at mattdm.org Mon Mar 19 19:17:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 19 Mar 2007 15:17:40 -0400 Subject: festival 1.96 -- want to get this in for test 3. In-Reply-To: <20070313212517.GA9946@jadzia.bu.edu> References: <20070312203622.GA18906@jadzia.bu.edu> <20070313212517.GA9946@jadzia.bu.edu> Message-ID: <20070319191740.GA8888@jadzia.bu.edu> > See for > details (and get packages from , as > mentioned there). please! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bpepple at fedoraproject.org Mon Mar 19 19:20:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 19 Mar 2007 15:20:14 -0400 Subject: FESCo Meeting Summary for 2007-03-15 Message-ID: <1174332014.15923.3.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Warren Togami (warren) * Tom Callaway (spot) * Josh Boyer (jwb) * Bill Nottingham (notting) === Absent === * Jeremy Katz (jeremy) == Summary == === Core Review Process === * The Merge Review is only a cleanup sweep, and the cleanup changes need to end at Test4. The merge will happens whether or not they are approved in a Merge Review. The cleanup will continue after F7. === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs * http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070315 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Mon Mar 19 20:22:08 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Mar 2007 16:22:08 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-19 Message-ID: <20070319202208.6527A152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) foolish AT guezz.net: gtk-recordmydesktop FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) lxtnow AT gmail.com: ntfs-config FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rdieter AT math.unl.edu: kmymoney2 FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) gtk-recordmydesktop: foolish AT guezz.net FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kmymoney2: rdieter AT math.unl.edu FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) ntfs-config: lxtnow AT gmail.com FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From fitzsim at redhat.com Mon Mar 19 22:59:10 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 19 Mar 2007 18:59:10 -0400 Subject: moving java-1.5.0-gcj and sinjdoc from Extras to Core In-Reply-To: <45FEB63E.6020809@redhat.com> References: <45FEB63E.6020809@redhat.com> Message-ID: <45FF15BE.4020604@redhat.com> Thomas Fitzsimmons wrote: > Hi, > > I introduced java-1.5.0-gcj and sinjdoc into Extras, thinking that the > Core/Extras merge would happen sooner than it has. This is a problem > because Brew can't pull build requirements from Extras. I'm working > with releng to move java-1.5.0-gcj and sinjdoc into Core. In the > meantime, you may have problems building Java packages in Brew. I'll > post an update when the move has happened. java-1.5.0-gcj and sinjdoc are now available in the Brew buildroots. Java packages should now build in Brew as they did with java-1.4.2-gcj-compat. Tom From fitzsim at redhat.com Tue Mar 20 00:04:18 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 19 Mar 2007 20:04:18 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <45FF2502.2070401@redhat.com> Thomas Fitzsimmons wrote: > - these packages have BuildRequires for gnu-crypto*: > > classpathx-mail-0:1.1.1-4jpp.2 > jtidy-2:1.0-0.1.r7dev.1jpp.1.fc7 These are both fixed in Rawhide. Tom From buildsys at fedoraproject.org Tue Mar 20 02:12:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Mar 2007 22:12:07 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-19 Message-ID: <20070320021207.CCBDD152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) alex AT dalloz.de: pan FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) foolish AT guezz.net: gtk-recordmydesktop FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) lxtnow AT gmail.com: ntfs-config FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) matt AT truch.net: gpsd FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rdieter AT math.unl.edu: kmymoney2 FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) gpsd: matt AT truch.net FE5 > FE6 (0:2.34-3.fc5 > 0:2.34-1.fc6) FE5 > FE7 (0:2.34-3.fc5 > 0:2.34-2.fc7) gtk-recordmydesktop: foolish AT guezz.net FE6 > FE7 (0:0.3.3.1-4.fc6 > 0:0.3.3.1-3.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kmymoney2: rdieter AT math.unl.edu FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) ntfs-config: lxtnow AT gmail.com FE6 > FE7 (0:0.5.5-2 > 0:0.5.5-1.fc7) pan: alex AT dalloz.de FE6 > FE7 (1:0.125-2.fc6 > 1:0.125-1.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From fedora at leemhuis.info Tue Mar 20 05:58:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 06:58:56 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FEDDF2.1050208@redhat.com> References: <45FEDDF2.1050208@redhat.com> Message-ID: <45FF7820.6090809@leemhuis.info> On 19.03.2007 20:01, Warren Togami wrote: > [...] > Any objections? Is it wise to do that now, even if there are rough plans that fedora-maintainers might vanish with the mailing list reorganization (that is waiting for new hardware atm that afaics should get installed in one month from now)?. I'd say a definite "no" and propose to revisit this during or after the mailing list reorganization. > Any volunteers to write this script? Anyway, such a script might be helpful for other mailing list after the mailing list reorg. But is this worth the trouble? Why not put a simple "hey, you are a member of cvsextras now, so you are now allowed to join mailing list foo and bar; it's strongly suggested to be on at least list foo" in the message you get from the accounts system when you join a group? CU thl From Axel.Thimm at ATrpms.net Tue Mar 20 09:06:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 10:06:26 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FEDDF2.1050208@redhat.com> References: <45FEDDF2.1050208@redhat.com> Message-ID: <20070320090626.GB14567@neu.nirvana> Hi, On Mon, Mar 19, 2007 at 03:01:06PM -0400, Warren Togami wrote: > fedora-maintainers is our by-invite-only distribution development > discussion list. We keep it this way in an attempt to improve the > signal to noise ratio. > > Problem > ======= > fedora-maintainers does not automatically grow as new, potentially > useful maintainers join the project. Currently new members are invited > only if someone does it manually, or if someone approves a subscription > request. > > Proposal > ======== > If cvsextras access is sponsored, FAS runs a script that logs into the > mailman admin page and sends an Invite to the e-mail address on the FAS > account. Isn't subscription to fedora-maintainers at redhat.com even required for contributors? So maybe the script could go ahead and subscribe instead of invite to shorten the procedure? Also if there are no security issues between the accounts managing machine and the mailing list server, maybe an echo mail at somewhere.tld | ssh listserver ~mailman/bin/add_members -r - fedora-maintainers at redhat.com is already enough? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Mar 20 09:06:50 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 09:06:50 +0000 Subject: ppc64 builds In-Reply-To: <200703181032.44173.dennis@ausil.us> References: <200703142231.51890.dennis@ausil.us> <200703151057.39795.jkeating@redhat.com> <1174219537.3461.610.camel@pmac.infradead.org> <200703181032.44173.dennis@ausil.us> Message-ID: <1174381610.3392.227.camel@pmac.infradead.org> On Sun, 2007-03-18 at 10:32 -0500, Dennis Gilmore wrote: > Once upon a time Sunday 18 March 2007, David Woodhouse wrote: > > On Thu, 2007-03-15 at 10:57 -0400, Jesse Keating wrote: > > > > And so we need to queue rebuilds for all of our packages? > > > > > > I'm not sure on that one. If we can manage to build what we have already > > > built just for ppc64 without any bumps, that would be nice. > > > > We've never bothered shipping 64-bit versions of Extras packages before > > -- unless you suddenly find an overriding reason to do so, I don't see > > any reason to rebuild for F7 just to add a 64-bit binary package which > > we don't need to ship anyway. > > David do you still want ppc64 support? if so it needs built. we dont have > any way to say build this package ppc64 and this one not. Its all or > nothing. I wasn't talking about the configuration of the build system -- I was responding to the question of whether we need to queue rebuilds for all packages just to make ppc64 versions of them. > there is no more extras there is only Fedora. Im just as happy to say you get > no more ppc64 kernel glibc etc which will be the outcome if we dont do this The kernel and glibc are already built for ppc64. There is no need to queue a rebuild just to get ppc64 versions of those. Everything we want to ship for ppc64 is already built, surely? Except perhaps blt :) -- dwmw2 From dwmw2 at infradead.org Tue Mar 20 09:17:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 09:17:33 +0000 Subject: Handling multilib In-Reply-To: <200703190820.20739.jkeating@redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> Message-ID: <1174382253.3392.238.camel@pmac.infradead.org> On Mon, 2007-03-19 at 08:20 -0400, Jesse Keating wrote: > On Sunday 18 March 2007 14:50:06 David Woodhouse wrote: > > Ideally, I think we want a new RPM tag for it, and it can be specified > > in the specfile. The package author can then specify whether the package > > should be shipped for the secondary arch (i386 on x86_64, or ppc64 on > > ppc64), and even whether the secondary version should be _favoured_ > > (64-bit gdb on ppc64). > > Unfortunately multilib isn't well understood by a large majority of our > maintainers, both inside RH and without. Leaving it up to the maintainer is > pretty much going to result in the vast majority of packages not being > multilib, especially the first time a multilib problem is found, boom, > multilib off rather than fixing the problem. I agree that if we give more control to the package maintainer, there is a risk of them taking the easy and wrong way out of any situation -- just like the abuse of ExcludeArch when a packagemonkey can't be bothered to fix a problem. In practice, our maintainers aren't _so_ bad, and it's relatively simple to keep the use of ExcludeArch in check. I don't think it would be impossible to keep multilib stuff in check too. I'm not entirely sure how "multilib off" would work; we always end up building for both architectures; the question is what happens when you need both versions installed. The packagemonkey can't just turn that _off_, surely? In fact there are a number of questions related to multilib... 1. Do we build this package on both architectures? I think the answer for this wants to continue to be "yes" in all cases, as you said. 2. Do we ship both versions of this package in the default install? For gdb, kernel, glibc "yes". For just about everything else, probably not. Only if you ask for development packages should you get the mess of -devel packages in both versions. And possibly only then if you specifically ask for development packages for the secondary architecture. 3. Do we _install_ both versions of this package by default, either during installation or upon 'yum install foo'? Or do we install the primary architecture version alone? The secondary architecture alone? The 64-bit version alone? The 32-bit version alone? For gdb on 64-bit machines we always want the 64-bit version. For kernel we want the one which matches the hardware -- kernel is a special case, really. For most things we want _just_ the primary architecture (ppc/x86_64). For glibc we want both simultaneously. Development packages probably also just primary, although you can make an argument for installing both versions in parallel. 4. When we install both versions in parallel and there are conflicting files, what do we do? Refuse to install it? Let files for primary arch override secondary? Let files for 64-bit override 32-bit? Currently, RPM is has hardcoded exceptions so that it can install packages with conflicting files. When there are different executables it'll choose the 64-bit one, even on ppc64 where the 32-bit one is the "primary arch" and would usually be the better choice. So we end up with a mix of 32-bit and 64-bit executables in /usr/bin. There are those who would argue that we should allow "conflicting" files only when they're identical -- not for executables. Thus we should split executables and libraries into separate packages, so that the libs can be installed in both flavours while the executables may only be installed in one version at a time. That makes sense to me -- the alternative is to just screw around a little more with RPM's hardcoded behaviour, which seems wrong. > Add to that the confusion of "Hey, I set my package to not be multilib, why is > it landing in the tree as multilib" when we bring things in due to deps of > some other package that was marked as multilib. Er, did we fix the deps so that we actually pull in foo.ppc64 when bar.ppc64 requires 'foo'? Or do we still let foo.ppc "satisfy" that dependency? :) > These are just a couple of problems I see with leaving it up to the > maintainer. Both of which involve the simple "multilib off" option, and the assumption that the packagemonkey would be permitted to abuse it. I do understand and share those concerns to a certain extent, but based on my experience with chasing up usage of ExcludeArch I think we can keep it in check quite happily. > Not that there aren't problems with the way it is done now, but > at least there we can typically blacklist something (if it isn't brought in > by deps) or re-adjust the packaging to make it more sane. Firefox was a > rather unique situation and an unfortunate outcome, but I don't think it is > fair to base the entire multilib experience on Firefox ppc64, something which > extremely few of our users would have seen/experienced. I spoke of firefox as a recent example, but it certainly wasn't the majority influence in my thinking. How we handle tagging multilib in the package itself depends on what we do with RPM -- do we make it stop silently resolving conflicts on executables? That seemed to be the consensus when it was discussed briefly on IRC; nobody really spoke up for the status quo. So I'll work on that assumption; we can backtrack if necessary. That means we have to have a separate subpackage for libraries vs. executables in the case where we want the libraries to be available multilib. We could add a 'Multilib' tag to each binary RPM, with four possible values: "primary", "secondary", "64bit", "32bit", "parallel". OK, five values. The first four options would mean that the package should be installed only for one architecture depending on the hardware. Packages marked '64bit' or 'secondary' would be shipped in both forms in the ppc compose, and packages marked '32bit' or 'secondary' would be shipped in both forms in the x86_64 compose. Packages marked 'parallel' should be shipped in both forms -- and that would cover most of the libraries and -devel packages. It should be relatively simple to do a pass over package CVS adding those tags according to our current heuristic, in fact. Whether the installer or yum actually _installs_ both versions of a package marked as 'parallel' is a different question -- I suspect it should be optional. Some users might want it; most won't. This means that in the normal case a 'foo' package would be marked 'primary', while 'foo-libs' and 'foo-devel' are marked 'parallel'. I wonder if there's some way we can make that work by default without making the user explicitly tag it? Perhaps we can default to 'parallel' but switch to 'primary' if there are any files in %_bindir? Or something? -- dwmw2 From fedora at leemhuis.info Tue Mar 20 09:25:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 10:25:30 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <20070320090626.GB14567@neu.nirvana> References: <45FEDDF2.1050208@redhat.com> <20070320090626.GB14567@neu.nirvana> Message-ID: <45FFA88A.1020308@leemhuis.info> On 20.03.2007 10:06, Axel Thimm wrote: > On Mon, Mar 19, 2007 at 03:01:06PM -0400, Warren Togami wrote: >> fedora-maintainers is our by-invite-only distribution development >> discussion list. We keep it this way in an attempt to improve the >> signal to noise ratio. >> >> Problem >> ======= >> fedora-maintainers does not automatically grow as new, potentially >> useful maintainers join the project. Currently new members are invited >> only if someone does it manually, or if someone approves a subscription >> request. >> >> Proposal >> ======== >> If cvsextras access is sponsored, FAS runs a script that logs into the >> mailman admin page and sends an Invite to the e-mail address on the FAS >> account. > > Isn't subscription to fedora-maintainers at redhat.com even required for > contributors? Strongly suggested, but not required afaik. The plan is still to use a low-traffic, moderated, non-discussion-just-announcements fedora-maintainers-announce where people get auto-subscribed. But I see no point in starting this now before the mailing list reorg. > So maybe the script could go ahead and subscribe instead > of invite to shorten the procedure? I suppose all those people that use a different addresses for mailing lists and the accounts system would be happy about such a move, as they might be subscribed two times to this list afterwards :-) > [...] CU thl From jakub at redhat.com Tue Mar 20 09:31:17 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 20 Mar 2007 04:31:17 -0500 Subject: Handling multilib In-Reply-To: <1174382253.3392.238.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> Message-ID: <20070320093117.GS355@devserv.devel.redhat.com> On Tue, Mar 20, 2007 at 09:17:33AM +0000, David Woodhouse wrote: > 4. When we install both versions in parallel and there are conflicting > files, what do we do? Refuse to install it? Let files for primary arch > override secondary? Let files for 64-bit override 32-bit? > > Currently, RPM is has hardcoded exceptions so that it can install > packages with conflicting files. When there are different executables > it'll choose the 64-bit one, even on ppc64 where the 32-bit one is > the "primary arch" and would usually be the better choice. So we end > up with a mix of 32-bit and 64-bit executables in /usr/bin. > > There are those who would argue that we should allow "conflicting" > files only when they're identical -- not for executables. Thus we > should split executables and libraries into separate packages, so > that the libs can be installed in both flavours while the executables > may only be installed in one version at a time. > > That makes sense to me -- the alternative is to just screw around a > little more with RPM's hardcoded behaviour, which seems wrong. It is not that hardcoded. Files with non-zero %FILECOLORS can be installed from either package (and just rpm decides which one wins, here IMHO should be a per-package and system default configurable preference), files with zero %FILECOLORS can't conflict between different arches. Try: rpm -q --qf '[%{FILECOLORS} %{FILENAMES}\n]' glibc I'm not arguing that it is sometimes desirable to split off a library package when you want libraries to be multilib, but they occupy only very small part of the whole package. But forcing splitting of every second package is IMHO an overkill and rpms %FILECOLORS can do its work there. For packages where you have a bunch of libraries and one or two small binaries and a few small data files lib subpackages would just clutter the package universe. Jakub From dwmw2 at infradead.org Tue Mar 20 09:41:55 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 09:41:55 +0000 Subject: Handling multilib In-Reply-To: <20070320093117.GS355@devserv.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> Message-ID: <1174383715.3392.246.camel@pmac.infradead.org> On Tue, 2007-03-20 at 04:31 -0500, Jakub Jelinek wrote: > It is not that hardcoded. Files with non-zero %FILECOLORS can be installed > from either package (and just rpm decides which one wins, here IMHO should > be a per-package and system default configurable preference), > files with zero %FILECOLORS can't conflict between different arches. > Try: > rpm -q --qf '[%{FILECOLORS} %{FILENAMES}\n]' glibc > > I'm not arguing that it is sometimes desirable to split off a library > package when you want libraries to be multilib, but they occupy only very > small part of the whole package. But forcing splitting of every second > package is IMHO an overkill and rpms %FILECOLORS can do its work there. > For packages where you have a bunch of libraries and one or two small > binaries and a few small data files lib subpackages would just clutter > the package universe. OK. As long as we change the default to use the _primary_ architecture (i.e. ppc32 on ppc64) and allow the package to override that in special cases (gdb), it could also make sense to just continue to use what RPM already has. Actually, I'm not sure gdb _would_ need to override the %FILECOLORS behaviour, if it's marked as something that should be installed for the 64-bit architecture only. Perhaps we just need a system-wide default, and the other per-package tagging I've already proposed is sufficient to cover the rest of what we need? -- dwmw2 From Axel.Thimm at ATrpms.net Tue Mar 20 09:42:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 10:42:21 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FFA88A.1020308@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <20070320090626.GB14567@neu.nirvana> <45FFA88A.1020308@leemhuis.info> Message-ID: <20070320094221.GD14567@neu.nirvana> On Tue, Mar 20, 2007 at 10:25:30AM +0100, Thorsten Leemhuis wrote: > On 20.03.2007 10:06, Axel Thimm wrote: > > On Mon, Mar 19, 2007 at 03:01:06PM -0400, Warren Togami wrote: > >> fedora-maintainers is our by-invite-only distribution development > >> discussion list. We keep it this way in an attempt to improve the > >> signal to noise ratio. > >> > >> Problem > >> ======= > >> fedora-maintainers does not automatically grow as new, potentially > >> useful maintainers join the project. Currently new members are invited > >> only if someone does it manually, or if someone approves a subscription > >> request. > >> > >> Proposal > >> ======== > >> If cvsextras access is sponsored, FAS runs a script that logs into the > >> mailman admin page and sends an Invite to the e-mail address on the FAS > >> account. > > > > Isn't subscription to fedora-maintainers at redhat.com even required for > > contributors? > > Strongly suggested, but not required afaik. I thought fedora-maintainers was mandatory like the commits list. I was always told so and http://fedoraproject.org/wiki/PackageMaintainers/Join#head-84e3ccb7c5b1f47aab9c6cee5439ae12010c8678 lists subscribing to these two list (and also still the readonly list by cut&paste error I suppose) as part of the joining procedure. > > So maybe the script could go ahead and subscribe instead of invite > > to shorten the procedure? > > I suppose all those people that use a different addresses for mailing > lists and the accounts system would be happy about such a move, as they > might be subscribed two times to this list afterwards :-) The invite would go to the same email address, anyway, and by definition these people cannot have been on the list previously. If having different email addresses for FAS, bugzilla, mailing lists is really needed, then the FAS needs to carry these, too. I think it already caters for the bugzilla address because 8 people didn't want to set them equal to the FAS account ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Tue Mar 20 09:52:02 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 20 Mar 2007 04:52:02 -0500 Subject: Handling multilib In-Reply-To: <1174383715.3392.246.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> <1174383715.3392.246.camel@pmac.infradead.org> Message-ID: <20070320095201.GT355@devserv.devel.redhat.com> On Tue, Mar 20, 2007 at 09:41:55AM +0000, David Woodhouse wrote: > OK. As long as we change the default to use the _primary_ architecture > (i.e. ppc32 on ppc64) and allow the package to override that in special > cases (gdb), it could also make sense to just continue to use what RPM > already has. > > Actually, I'm not sure gdb _would_ need to override the %FILECOLORS > behaviour, if it's marked as something that should be installed for the > 64-bit architecture only. Perhaps we just need a system-wide default, > and the other per-package tagging I've already proposed is sufficient to > cover the rest of what we need? We certainly need to include 32-bit gdb, so that people with 32-bit PPC CPUs can debug things. But I agree it is better on ppc64 kernel to install just 64-bit gdb, 64-bit frysk, 64-bit strace and whatever else falls into this category of packages that handle both 32-bit and 64-bit processes in 64-bit incarnation, but 32-bit incarnation handles solely 32-bit ones. Some tools tightly coupled with the kernel for which sufficient ioctl 32-bit wrappers don't exist would fall here as well. Jakub From dwmw2 at infradead.org Tue Mar 20 10:08:27 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 10:08:27 +0000 Subject: Handling multilib In-Reply-To: <20070320095201.GT355@devserv.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> <1174383715.3392.246.camel@pmac.infradead.org> <20070320095201.GT355@devserv.devel.redhat.com> Message-ID: <1174385307.3392.249.camel@pmac.infradead.org> On Tue, 2007-03-20 at 04:52 -0500, Jakub Jelinek wrote: > We certainly need to include 32-bit gdb, so that people with 32-bit PPC > CPUs can debug things. Yes -- the whole multilib thing is basically ignored on 32-bit hardware. When I say "install for 64-bit only" that's only relevant on 64-bit hardware. > But I agree it is better on ppc64 kernel to install > just 64-bit gdb, 64-bit frysk, 64-bit strace and whatever else falls into > this category of packages that handle both 32-bit and 64-bit processes > in 64-bit incarnation, but 32-bit incarnation handles solely 32-bit ones. Well, strace doesn't actually manage that yet -- but it _should_ :) > Some tools tightly coupled with the kernel for which sufficient ioctl 32-bit > wrappers don't exist would fall here as well. Yes, if we can't fix the wrappers. -- dwmw2 From jkeating at redhat.com Tue Mar 20 12:59:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 08:59:51 -0400 Subject: ppc64 builds In-Reply-To: <1174381610.3392.227.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <200703181032.44173.dennis@ausil.us> <1174381610.3392.227.camel@pmac.infradead.org> Message-ID: <200703200859.51146.jkeating@redhat.com> On Tuesday 20 March 2007 05:06:50 David Woodhouse wrote: > The kernel and glibc are already built for ppc64. There is no need to > queue a rebuild just to get ppc64 versions of those. > > Everything we want to ship for ppc64 is already built, surely? Except > perhaps blt And when we want to _rebuild_ them after we merge core and extras? ppc64 has to be turned on if you want that rebuild to succeed. To be turned on, it has to be turned on for every package, and unless somebody goes through and bootstraps Extras into ppc64, builds will be failing left and right because there are no packages to build against. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Mar 20 13:16:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 14:16:31 +0100 Subject: ppc64 builds In-Reply-To: <200703200859.51146.jkeating@redhat.com> References: <200703142231.51890.dennis@ausil.us> <200703181032.44173.dennis@ausil.us> <1174381610.3392.227.camel@pmac.infradead.org> <200703200859.51146.jkeating@redhat.com> Message-ID: <45FFDEAF.2000207@leemhuis.info> On 20.03.2007 13:59, Jesse Keating wrote: > On Tuesday 20 March 2007 05:06:50 David Woodhouse wrote: >> The kernel and glibc are already built for ppc64. There is no need to >> queue a rebuild just to get ppc64 versions of those. >> Everything we want to ship for ppc64 is already built, surely? Except >> perhaps blt > And when we want to _rebuild_ them after we merge core and extras? ppc64 has > to be turned on if you want that rebuild to succeed. To be turned on, it has > to be turned on for every package, and unless somebody goes through and > bootstraps Extras into ppc64, builds will be failing left and right because > there are no packages to build against. Maybe we can handle PPC64 as our first "secondary arch testbed"? E.g. enable ppc64 everywhere, but having a package that fails to build on ppc64 would not block the rebuild package to enter the i386, x86_64 and ppc repos. Or does support for this not exists yet in Koji? Then this might be a bad idea... CU thl From jkeating at redhat.com Tue Mar 20 14:27:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 10:27:06 -0400 Subject: ppc64 builds In-Reply-To: <45FFDEAF.2000207@leemhuis.info> References: <200703142231.51890.dennis@ausil.us> <200703200859.51146.jkeating@redhat.com> <45FFDEAF.2000207@leemhuis.info> Message-ID: <200703201027.06817.jkeating@redhat.com> On Tuesday 20 March 2007 09:16:31 Thorsten Leemhuis wrote: > Maybe we can handle PPC64 as our first "secondary arch testbed"? E.g. > enable ppc64 everywhere, but having a package that fails to build on > ppc64 would not block the rebuild package to enter the i386, x86_64 and > ppc repos. Or does support for this not exists yet in Koji? Then this > might be a bad idea... Doesn't exist quite yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Mar 20 15:02:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 11:02:51 -0400 Subject: Handling multilib In-Reply-To: <1174382253.3392.238.camel@pmac.infradead.org> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> Message-ID: <20070320150251.GA11089@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > 2. Do we ship both versions of this package in the default install? ... > 3. Do we _install_ both versions of this package by default, either > during installation or upon 'yum install foo'? Or do we install the > primary architecture version alone? The secondary architecture alone? > The 64-bit version alone? The 32-bit version alone? So, the idea I had is that for things like this: - you subscribe your multi-arch system to both channels - the decision for what is installed is done via yum plugins/configurable yum behavior You could say 'multlib=devel', to get development packages and their dependencies. Or 'runtime', to get runtime libraries. Or 'none', to get, well, nothing. This isn't something that can be done for F7, though. Bill From notting at redhat.com Tue Mar 20 15:04:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 11:04:47 -0400 Subject: Handling multilib In-Reply-To: <20070320095201.GT355@devserv.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> <1174383715.3392.246.camel@pmac.infradead.org> <20070320095201.GT355@devserv.devel.redhat.com> Message-ID: <20070320150447.GB11089@nostromo.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > We certainly need to include 32-bit gdb, so that people with 32-bit PPC > CPUs can debug things. But I agree it is better on ppc64 kernel to install > just 64-bit gdb, 64-bit frysk, 64-bit strace and whatever else falls into > this category of packages that handle both 32-bit and 64-bit processes > in 64-bit incarnation, but 32-bit incarnation handles solely 32-bit ones. > Some tools tightly coupled with the kernel for which sufficient ioctl 32-bit > wrappers don't exist would fall here as well. So, is your algorithm 'packages XYZ need to be installed as the largest wordsize ABI supported', or 'packages XYZ need to be installed as an architecture that matches the kernel installed'? Bill From bugs.michael at gmx.net Tue Mar 20 15:21:15 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Mar 2007 16:21:15 +0100 Subject: gnubg powerpc build fails <-> gnuplot In-Reply-To: <20070320021207.CCBDD152130@buildsys.fedoraproject.org> References: <20070320021207.CCBDD152130@buildsys.fedoraproject.org> Message-ID: <20070320162115.6d3cceba.bugs.michael@gmx.net> On Mon, 19 Mar 2007 22:12:07 -0400 (EDT), buildsys wrote: > limb AT jcomserv.net: > gnubg > FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) fc7 build fails on ppc https://bugzilla.redhat.com/233113 could also be a problem in gnuplot: tr -d '\f' < anneal.txt > ./annealing.txt; fi /bin/sh: line 2: 400 Segmentation fault gnuplot annealing.gp make[2]: *** [annealing.eps] Error 139 From limb at jcomserv.net Tue Mar 20 15:19:06 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 20 Mar 2007 10:19:06 -0500 (CDT) Subject: gnubg powerpc build fails <-> gnuplot In-Reply-To: <20070320162115.6d3cceba.bugs.michael@gmx.net> References: <20070320021207.CCBDD152130@buildsys.fedoraproject.org> <20070320162115.6d3cceba.bugs.michael@gmx.net> Message-ID: <64568.65.192.24.190.1174403946.squirrel@mail.jcomserv.net> Working on a fresh test build on an updated i386 machine. I don't have access to PPC, but this should help narrow it down. . . > On Mon, 19 Mar 2007 22:12:07 -0400 (EDT), buildsys wrote: > >> limb AT jcomserv.net: >> gnubg >> FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) >> FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > fc7 build fails on ppc > https://bugzilla.redhat.com/233113 > > could also be a problem in gnuplot: > > tr -d '\f' < anneal.txt > ./annealing.txt; fi > /bin/sh: line 2: 400 Segmentation fault gnuplot annealing.gp > make[2]: *** [annealing.eps] Error 139 > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From jakub at redhat.com Tue Mar 20 15:23:26 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 20 Mar 2007 10:23:26 -0500 Subject: Handling multilib In-Reply-To: <20070320150447.GB11089@nostromo.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> <1174383715.3392.246.camel@pmac.infradead.org> <20070320095201.GT355@devserv.devel.redhat.com> <20070320150447.GB11089@nostromo.devel.redhat.com> Message-ID: <20070320152326.GW355@devserv.devel.redhat.com> On Tue, Mar 20, 2007 at 11:04:47AM -0400, Bill Nottingham wrote: > Jakub Jelinek (jakub at redhat.com) said: > > We certainly need to include 32-bit gdb, so that people with 32-bit PPC > > CPUs can debug things. But I agree it is better on ppc64 kernel to install > > just 64-bit gdb, 64-bit frysk, 64-bit strace and whatever else falls into > > this category of packages that handle both 32-bit and 64-bit processes > > in 64-bit incarnation, but 32-bit incarnation handles solely 32-bit ones. > > Some tools tightly coupled with the kernel for which sufficient ioctl 32-bit > > wrappers don't exist would fall here as well. > > So, is your algorithm 'packages XYZ need to be installed as the largest > wordsize ABI supported', or 'packages XYZ need to be installed as an > architecture that matches the kernel installed'? The former (which is equivalent to 'as an architecture that matches the running kernel'). You can have several kernels instaled and not all of them need to be the same arch. Jakub From dwmw2 at infradead.org Tue Mar 20 15:25:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 15:25:11 +0000 Subject: Handling multilib In-Reply-To: <20070320150447.GB11089@nostromo.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320093117.GS355@devserv.devel.redhat.com> <1174383715.3392.246.camel@pmac.infradead.org> <20070320095201.GT355@devserv.devel.redhat.com> <20070320150447.GB11089@nostromo.devel.redhat.com> Message-ID: <1174404311.3603.26.camel@hades.cambridge.redhat.com> On Tue, 2007-03-20 at 11:04 -0400, Bill Nottingham wrote: > So, is your algorithm 'packages XYZ need to be installed as the largest > wordsize ABI supported', or 'packages XYZ need to be installed as an > architecture that matches the kernel installed'? Not as I stated it, no. -- dwmw2 From dwmw2 at infradead.org Tue Mar 20 15:33:30 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 15:33:30 +0000 Subject: Handling multilib In-Reply-To: <20070320150251.GA11089@nostromo.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320150251.GA11089@nostromo.devel.redhat.com> Message-ID: <1174404810.3603.29.camel@hades.cambridge.redhat.com> On Tue, 2007-03-20 at 11:02 -0400, Bill Nottingham wrote: > So, the idea I had is that for things like this: > > - you subscribe your multi-arch system to both channels > > - the decision for what is installed is done via yum > plugins/configurable > yum behavior > > You could say 'multlib=devel', to get development packages and their > dependencies. Or 'runtime', to get runtime libraries. Or 'none', to > get, well, nothing. That makes a certain amount of sense. Although I don't really think we need to offer the "runtime" option -- what's the point in a bunch of libraries which never get used? Just pull them in if they're required, surely -- either by a -devel package or by an executable? Let the default be 'none', which gives you nothing but the special cases like gdb and strace. -- dwmw2 From wtogami at redhat.com Tue Mar 20 16:36:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 12:36:28 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <45FF7820.6090809@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> Message-ID: <46000D8C.4000404@redhat.com> Thorsten Leemhuis wrote: > On 19.03.2007 20:01, Warren Togami wrote: >> [...] >> Any objections? > > Is it wise to do that now, even if there are rough plans that > fedora-maintainers might vanish with the mailing list reorganization > (that is waiting for new hardware atm that afaics should get installed > in one month from now)?. I'd say a definite "no" and propose to revisit > this during or after the mailing list reorganization. Where is the latest version of the reorg proposal? I am not sure if it is wise to get rid of fedora-maintainers list. > >> Any volunteers to write this script? > > Anyway, such a script might be helpful for other mailing list after the > mailing list reorg. But is this worth the trouble? Why not put a simple > "hey, you are a member of cvsextras now, so you are now allowed to join > mailing list foo and bar; it's strongly suggested to be on at least list > foo" in the message you get from the accounts system when you join a group? > Because it requires somebody to manually approve their registration request, which is a big loss when this step could be automated. Warren Togami wtogami at redhat.com From notting at redhat.com Tue Mar 20 16:34:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 12:34:07 -0400 Subject: Handling multilib In-Reply-To: <1174404810.3603.29.camel@hades.cambridge.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320150251.GA11089@nostromo.devel.redhat.com> <1174404810.3603.29.camel@hades.cambridge.redhat.com> Message-ID: <20070320163407.GA15145@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > That makes a certain amount of sense. Although I don't really think we > need to offer the "runtime" option -- what's the point in a bunch of > libraries which never get used? Just pull them in if they're required, > surely -- either by a -devel package or by an executable? Let the > default be 'none', which gives you nothing but the special cases like > gdb and strace. Well, there *is* non-RPM software that you may want to support as well (moreso on x86_64 than ppc64). Also, I suspect things like PAM and NSS modules would be in the same bucket as gdb, strace. Bill From fedora at leemhuis.info Tue Mar 20 17:17:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 18:17:08 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46000D8C.4000404@redhat.com> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> Message-ID: <46001714.4070603@leemhuis.info> Warren Togami schrieb: > Thorsten Leemhuis wrote: >> On 19.03.2007 20:01, Warren Togami wrote: >>> [...] >>> Any objections? >> Is it wise to do that now, even if there are rough plans that >> fedora-maintainers might vanish with the mailing list reorganization >> (that is waiting for new hardware atm that afaics should get installed >> in one month from now)?. I'd say a definite "no" and propose to revisit >> this during or after the mailing list reorganization. > Where is the latest version of the reorg proposal? http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization But I think it doesn't make to much sense to discuss that now -- I'd say we should discuss this again in detail when we are getting closer to actually realizing it (e.g. maybe four weeks from now; or after F7 is out). > I am not sure if it > is wise to get rid of fedora-maintainers list. I think it is (?) and the proposal received only very few flames when it got discussed on fedora-devel -- hey, it even received some "I like that" ;-) >>> Any volunteers to write this script? >> Anyway, such a script might be helpful for other mailing list after the >> mailing list reorg. But is this worth the trouble? Why not put a simple >> "hey, you are a member of cvsextras now, so you are now allowed to join >> mailing list foo and bar; it's strongly suggested to be on at least list >> foo" in the message you get from the accounts system when you join a group? > Because it requires somebody to manually approve their registration > request, which is a big loss when this step could be automated. Agreed (hey, I did this for this list for nearly one year ;-) ). Nevertheless I would not invest work into it at this point of time with the mailing list reorg on the horizon. But I won't stop you ;-) CU thl (?) -- especially as the difference between fedora-maintainers and fedora-devel seems to be not that obvious these days. Just look at the last topics from this list. From chris.stone at gmail.com Tue Mar 20 17:26:57 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 10:26:57 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46001714.4070603@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> Message-ID: On 3/20/07, Thorsten Leemhuis wrote: > http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization -1 on removal of fedora-games-list From wtogami at redhat.com Tue Mar 20 17:35:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 13:35:53 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46001714.4070603@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> Message-ID: <46001B79.9030704@redhat.com> Thorsten Leemhuis wrote: > http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization > > But I think it doesn't make to much sense to discuss that now -- I'd say > we should discuss this again in detail when we are getting closer to > actually realizing it (e.g. maybe four weeks from now; or after F7 is out). > I agree it is not a high priority to discuss this now, but please do not assume there is widespread agreement to make these changes happen. I believe this has been a case where silence != agreement. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Mar 20 17:38:17 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 13:38:17 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46001714.4070603@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> Message-ID: <46001C09.4020703@redhat.com> Thorsten Leemhuis wrote: > > (?) -- especially as the difference between fedora-maintainers and > fedora-devel seems to be not that obvious these days. Just look at the > last topics from this list. List consolidation is not going to solve our problems. More lists are not going to solve our problems. Automation is the only way to solve our problems. Only exactly how is currently unclear. Auto-invite to fedora-maintainers seems like an obvious simple thing we can do in the short term. Further automation ideas we will have to figure out later. Warren Togami wtogami at redhat.com From fedora at leemhuis.info Tue Mar 20 17:59:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 18:59:13 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46001C09.4020703@redhat.com> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001C09.4020703@redhat.com> Message-ID: <460020F1.1020601@leemhuis.info> Warren Togami schrieb: > Thorsten Leemhuis wrote: >> (?) -- especially as the difference between fedora-maintainers and >> fedora-devel seems to be not that obvious these days. Just look at the >> last topics from this list. > List consolidation is not going to solve our problems. Agreed, world hunger won't end. But list consolidation might help to make some things easier and hopefully everyone a bit more happy. I suppose that's the reasons why the Board asked me to drive this. And sure, I won't make everyone happy, but I'm trying to make most happy. > More lists are not going to solve our problems. Exactly, that's why after this reorganization there are less lists then before (and not more). > Automation is the only way to solve our problems. Depends on the definition of "our problems" -- that could mean a whole lot of things ;-) But sure, automation often helps. > [...] CU thl From dwmw2 at infradead.org Tue Mar 20 18:02:08 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Mar 2007 18:02:08 +0000 Subject: Handling multilib In-Reply-To: <20070320163407.GA15145@nostromo.devel.redhat.com> References: <200703142231.51890.dennis@ausil.us> <20070318135719.GF24404@neu.nirvana> <1174243806.3392.16.camel@pmac.infradead.org> <200703190820.20739.jkeating@redhat.com> <1174382253.3392.238.camel@pmac.infradead.org> <20070320150251.GA11089@nostromo.devel.redhat.com> <1174404810.3603.29.camel@hades.cambridge.redhat.com> <20070320163407.GA15145@nostromo.devel.redhat.com> Message-ID: <1174413728.1410.4.camel@hades.cambridge.redhat.com> On Tue, 2007-03-20 at 12:34 -0400, Bill Nottingham wrote: > Well, there *is* non-RPM software that you may want to support as > well (moreso on x86_64 than ppc64). Also, I suspect things like > PAM and NSS modules would be in the same bucket as gdb, strace. Same bucket as glibc, I think you mean -- in that we want _both_ versions of them, because they're core libraries. For gdb and strace (once it's fixed) we want _only_ the 64-bit versions, which is a special case. -- dwmw2 From fedora at leemhuis.info Tue Mar 20 18:05:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 19:05:53 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46001B79.9030704@redhat.com> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> Message-ID: <46002281.3030706@leemhuis.info> Warren Togami schrieb: > Thorsten Leemhuis wrote: >> http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization >> But I think it doesn't make to much sense to discuss that now -- I'd say >> we should discuss this again in detail when we are getting closer to >> actually realizing it (e.g. maybe four weeks from now; or after F7 is out). > I agree it is not a high priority to discuss this now, but please do not > assume there is widespread agreement to make these changes happen. > I believe this has been a case where silence != agreement. https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00104.html https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00230.html https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00104.html https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00732.html That are probably about 100 mails about the topic. And, as I wrote, I even got a "Looks very sane to me." https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00735.html -- I marked that day in my calendar ;-) But seems your don't like the plan that got worked out so far. That's fine. Feel free to work out something else. CU thl From chris.stone at gmail.com Tue Mar 20 18:18:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 11:18:02 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46002281.3030706@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> Message-ID: On 3/20/07, Thorsten Leemhuis wrote: > Warren Togami schrieb: > > Thorsten Leemhuis wrote: > >> http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization > >> But I think it doesn't make to much sense to discuss that now -- I'd say > >> we should discuss this again in detail when we are getting closer to > >> actually realizing it (e.g. maybe four weeks from now; or after F7 is out). > > I agree it is not a high priority to discuss this now, but please do not > > assume there is widespread agreement to make these changes happen. > > I believe this has been a case where silence != agreement. > > https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00104.html > https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00230.html > https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00104.html > https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00732.html > > That are probably about 100 mails about the topic. And, as I wrote, I > even got a "Looks very sane to me." > https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00735.html > -- I marked that day in my calendar ;-) > > But seems your don't like the plan that got worked out so far. That's > fine. Feel free to work out something else. I can speak on the behalf of the games SIG and hereby declare that the fedora-games-list should stay. Please take all references of fedora-games-list off your mailing list reorg doc. Thanks, Christopher Stone (on behalf of entire games SIG) From sundaram at fedoraproject.org Tue Mar 20 18:22:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 Mar 2007 23:52:23 +0530 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> Message-ID: <4600265F.9070308@fedoraproject.org> Christopher Stone wrote: > On 3/20/07, Thorsten Leemhuis wrote: >> Warren Togami schrieb: >> > Thorsten Leemhuis wrote: >> >> >> http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization >> >> But I think it doesn't make to much sense to discuss that now -- >> I'd say >> >> we should discuss this again in detail when we are getting closer to >> >> actually realizing it (e.g. maybe four weeks from now; or after F7 >> is out). >> > I agree it is not a high priority to discuss this now, but please do >> not >> > assume there is widespread agreement to make these changes happen. >> > I believe this has been a case where silence != agreement. >> >> https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00104.html >> >> https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00230.html >> >> https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00104.html >> >> https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00732.html >> >> >> That are probably about 100 mails about the topic. And, as I wrote, I >> even got a "Looks very sane to me." >> https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00735.html >> >> -- I marked that day in my calendar ;-) >> >> But seems your don't like the plan that got worked out so far. That's >> fine. Feel free to work out something else. > > I can speak on the behalf of the games SIG and hereby declare that the > fedora-games-list should stay. Please take all references of > fedora-games-list off your mailing list reorg doc. Why does games SIG require a separate mailing list? Rahul From chris.stone at gmail.com Tue Mar 20 18:26:27 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 11:26:27 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <4600265F.9070308@fedoraproject.org> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> Message-ID: On 3/20/07, Rahul Sundaram wrote: > Why does games SIG require a separate mailing list? For the same reason any SIG should have their own list. Rename the lists fedora-SIG-foo for all I care, but these lists should exist. Using something like [games] in message headers on fedora-maintainers or something is just going to get lost in all the noise. Infact, while we are on the discussion, can we please add a fedora-SIG-PHP mailing list. Thanks! From sundaram at fedoraproject.org Tue Mar 20 18:31:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 00:01:37 +0530 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> Message-ID: <46002889.6010204@fedoraproject.org> Christopher Stone wrote: > On 3/20/07, Rahul Sundaram wrote: >> Why does games SIG require a separate mailing list? > > For the same reason any SIG should have their own list. That is not a good reason consider no SIG except games has its own mailing list. Rename the > lists fedora-SIG-foo for all I care, but these lists should exist. > Using something like [games] in message headers on fedora-maintainers > or something is just going to get lost in all the noise. > > Infact, while we are on the discussion, can we please add a > fedora-SIG-PHP mailing list. If it is packaging details it should be in fedora-packaging list. Other details could be in fedora-devel list. In other words what do you discuss in fedora-games list that doesnt fit into any existing other Fedora lists? Every SIG creating their own lists would essentially reduce the visibility and participation of contributors and users. Rahul From fedora at leemhuis.info Tue Mar 20 18:34:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 19:34:31 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> Message-ID: <46002937.2070505@leemhuis.info> Christopher Stone schrieb: > On 3/20/07, Thorsten Leemhuis wrote: > > I can speak on the behalf of the games SIG and hereby declare that the > fedora-games-list should stay. Please take all references of > fedora-games-list off your mailing list reorg doc. Did you actually look at the document closely? It doesn't request that this list is going to be removed. The reference to it is in a "Not sure" section, under a section that starts with "Some people questioned the needs for these lists." and ends with "Ask the list-maintainers if separate lists really make sense for these topics. fedora-games-list for example" I noticed you'd like to keep this list and highly respect your opinion as SIG member. Nevertheless I think this issue still needs to be discussed. Cu thl From Axel.Thimm at ATrpms.net Tue Mar 20 18:39:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 19:39:13 +0100 Subject: fedora-maintainers vs fedora-devel Message-ID: <20070320183913.GB20185@neu.nirvana> Hi, since it comes up every now and then, I'd like to get the differences clarified, especially since there are ideas to get them united, which if the contents and target groups are too different would be wrong. The way I see it it is like the following: o fedora-devel - concentrates on rawhide and its way to a release - has in-house upstream development discussion - more in-depth Linux mechanics - manages release cycle o fedora-maintainers - concentrates on the packaging community as a whole - More issues about packaging than on upstream development, if any - cares more about current and past releases There is some (IMHO) healthy overlap, but I do think that they differ enough to keep them separated to have each group enjoy a better SNR level. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Mar 20 18:40:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 14:40:42 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <4600265F.9070308@fedoraproject.org> References: <45FEDDF2.1050208@redhat.com> <4600265F.9070308@fedoraproject.org> Message-ID: <200703201440.42769.jkeating@redhat.com> On Tuesday 20 March 2007 14:22:23 Rahul Sundaram wrote: > Why does games SIG require a separate mailing list? For the same reason that other subjects need their own list. Finding subject material in a one-for-all list is extremely hard. When 200+ new messages arrive daily finding the 2 or 3 you might want to read is very difficult. This is a no-win situation. Either A) you have separate lists for topics and run the risk of discussions happening in different places, or B) you shove everything into a few lists and the traffic (even if it is all signal) is so great, nobody reads it and topics they care about are missed. This is the part where you suggest an announce list, and then we argue about what is a suitable 'announcement'. Policy change? soname bumps? New packages? Removed packages? Meeting times/notes? At what point does the noise of a single announce list become so great that it gets ignored too? I don't have solutions, I only have experience and insight. I get most the mail anyway, so I don't necessarily care if it comes from one list of 5, but I do like subjects to be split out so I can set priority on what list to read. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Gateway at redhat.com Tue Mar 20 18:39:59 2007 From: Gateway at redhat.com (Gateway at redhat.com) Date: Tue, 20 Mar 2007 19:39:59 +0100 Subject: NDN: fedora-maintainers vs fedora-devel Message-ID: Sorry. Your message could not be delivered to: christian paratschek,reflex.at (The name was not found at the remote site. Check that the name has been entered correctly.) From fedora at leemhuis.info Tue Mar 20 18:41:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 19:41:28 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> Message-ID: <46002AD8.2050501@leemhuis.info> Christopher Stone schrieb: > On 3/20/07, Rahul Sundaram wrote: >> Why does games SIG require a separate mailing list? > For the same reason any SIG should have their own list. And that reason is? CU thl P.S..:In case it matters: my current opinion is that this list is fine to stay, but seems some people think different about it and I agree that it's worth to be discussed P.P.S.:I just want to make sure we have a healthy information flow in the project as a whole. Having separate communication channels sometimes can improve the "information flow" but sometimes disturb it. It's a trade off. From jkeating at redhat.com Tue Mar 20 18:45:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 14:45:06 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <200703201445.06284.jkeating@redhat.com> On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > The way I see it it is like the following: > > o fedora-devel > ? - concentrates on rawhide and its way to a release > ? - has in-house upstream development discussion > ? - more in-depth Linux mechanics > ? - manages release cycle > > o fedora-maintainers > ? - concentrates on the packaging community as a whole > ? - More issues about packaging than on upstream development, if any > ? - cares more about current and past releases Actually I do all the freeze and collection announcements to fedora-maintainers. They're the people that need to know, and it's largely just noise for fedora-devel. To me, fedora-maintainers are the people doing the work, and a communication place for that. fedora-devel is a combo of people doing work and a larger community consuming the work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Mar 20 18:48:49 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 14:48:49 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <20070320184849.GA18323@jadzia.bu.edu> On Tue, Mar 20, 2007 at 07:39:13PM +0100, Axel Thimm wrote: > since it comes up every now and then, I'd like to get the differences > clarified, especially since there are ideas to get them united, which > if the contents and target groups are too different would be wrong. [...] > o fedora-devel > - concentrates on rawhide and its way to a release > - has in-house upstream development discussion > - more in-depth Linux mechanics > - manages release cycle > o fedora-maintainers > - concentrates on the packaging community as a whole > - More issues about packaging than on upstream development, if any > - cares more about current and past releases I'd kind of like it like this: extended discussion goes on fedora-devel. If you get behind and have to delete it all to catch up, you'll be okay. Things on fedora-maintainers should at least have the subjects skimmed through. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chris.stone at gmail.com Tue Mar 20 18:50:59 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 11:50:59 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46002889.6010204@fedoraproject.org> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> Message-ID: On 3/20/07, Rahul Sundaram wrote: > Christopher Stone wrote: > > On 3/20/07, Rahul Sundaram wrote: > >> Why does games SIG require a separate mailing list? > > > > For the same reason any SIG should have their own list. > > That is not a good reason consider no SIG except games has its own > mailing list. I wouldn't say that. Fedora-perl-devel-list -> perl SIG Fedora-music-list -> music and media production SIG Fedora-security-list -> security SIG There are probably others which you could consider SIGs like mentors, fr, women etc. I think if we just relabeled these as fedora-SIG-foo it would make finding special interest topics easier. > > Rename the > > lists fedora-SIG-foo for all I care, but these lists should exist. > > Using something like [games] in message headers on fedora-maintainers > > or something is just going to get lost in all the noise. > > > > Infact, while we are on the discussion, can we please add a > > fedora-SIG-PHP mailing list. > > If it is packaging details it should be in fedora-packaging list. Other > details could be in fedora-devel list. In other words what do you > discuss in fedora-games list that doesnt fit into any existing other > Fedora lists? Stuff that only interests people who are interested in games. Game specific questions, making a games spin, etc. Basically people who are interested in games can peruse our archives and easily find discussions related to games. > > Every SIG creating their own lists would essentially reduce the > visibility and participation of contributors and users. No, there are main lists which everyone subscribes to such as packaging and maintainers, and then there are the SIG lists you can subscribe to if you have an interested in a particular topic. For example, let people interested in PHP discuss some packaging issue related to PHP amongst themselves and when they are satisfied they can then bring the discussion over to a main list like packaging for inclusion in the standards. Creating SIG lists does not reduce visibility as long as such lists are named as SIG lists, that is why I propose to rename all lists that have a special interest to fedora-SIG-*. From jspaleta at gmail.com Tue Mar 20 18:51:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Mar 2007 10:51:31 -0800 Subject: A modest proposal: Have SIGS manage day-to-day comps additions with feedback from release-eng Message-ID: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> Here's my proposal. We make it the responsibility of each SIG to take ownership of at least one comps group definition and to keep it pruned, with feedback from release-eng. The real question is how do we do that functionally. There is one comps file right now. Do we give a lot of people the authority to poke around inside that file. I'm not sure I like that approach, I'd be afraid of inexperienced people accidentally breaking the comps syntax, unless we can find a way to toolize a syntax verifier as part of the check in process, like what Jesse has suggested to me in irc. This way we could be reasonable sure that we can get updated comps definitions for development as well as the current fedora release(s) by harnessing the specialized knowledge of active SIGs as packages roll into the tree. I want to encourage SIGs to do the comps janitorial work, but I don't want to risk compromising the comps file integrity with a lot of daily edits. Tboughts? -jef From fedora at leemhuis.info Tue Mar 20 18:55:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 19:55:52 +0100 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <46002E38.5020907@leemhuis.info> Axel Thimm schrieb: > > The way I see it it is like the following: > [...] The way it was meant was the following afaics and iirc: * fedora-maintainers -- important discussions between maintainers where we exclude the world (remember: it's a closed list!), no endless flamewars, not that much traffic, so people can easily follow it * fedora-devel -- all the other devel stuff I'd say we failed with what fedora-maintainers was meant for. We have quite some flamewars on fedora-maintainers, we discussed stuff here that we should have discussed in the open on fedora-devel-list, where non-contributors can participate, it's high traffic and we scared people away with it. CU thl From sundaram at fedoraproject.org Tue Mar 20 19:06:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 00:36:06 +0530 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> Message-ID: <4600309E.8060202@fedoraproject.org> Christopher Stone wrote: > On 3/20/07, Rahul Sundaram wrote: >> Christopher Stone wrote: >> > On 3/20/07, Rahul Sundaram wrote: >> >> Why does games SIG require a separate mailing list? >> > >> > For the same reason any SIG should have their own list. >> >> That is not a good reason consider no SIG except games has its own >> mailing list. > > I wouldn't say that. > > Fedora-perl-devel-list -> perl SIG > Fedora-music-list -> music and media production SIG > Fedora-security-list -> security SIG This is incorrect. Fedora-perl-devel list was formed before the concept of SIG's were in place. Fedora music list is not related to the music SIG but was originally created to coordinate on the merge of Planet CCRMA into Fedora Extras. Fedora-security list is not a Extras SIG list either. It deals with security issues not packaging. > There are probably others which you could consider SIGs like mentors, > fr, women etc. I think if we just relabeled these as fedora-SIG-foo > it would make finding special interest topics easier. SIG's were originally created to coordinate on packaging. Mentors,fr or Women dont fit into that description at all. > Stuff that only interests people who are interested in games. Game > specific questions, making a games spin, etc. Basically people who > are interested in games can peruse our archives and easily find > discussions related to games I periodically watch discussions at the fedora-games list and my opinions is that those topics would benefit from being discussed in fedora-devel or fedora-maintainers list with more of the community participating. Menu organization of games for example is a topic of interest to not just people packaging games but also folks who care about usability or those who want to make sure that menus follow the relevant specs. Rahul From Gateway at redhat.com Tue Mar 20 19:06:55 2007 From: Gateway at redhat.com (Gateway at redhat.com) Date: Tue, 20 Mar 2007 20:06:55 +0100 Subject: NDN: Re: fedora-maintainers vs fedora-devel Message-ID: Sorry. Your message could not be delivered to: christian paratschek,reflex.at (The name was not found at the remote site. Check that the name has been entered correctly.) From chris.stone at gmail.com Tue Mar 20 19:08:41 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 12:08:41 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46002AD8.2050501@leemhuis.info> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002AD8.2050501@leemhuis.info> Message-ID: On 3/20/07, Thorsten Leemhuis wrote: > Christopher Stone schrieb: > > On 3/20/07, Rahul Sundaram wrote: > >> Why does games SIG require a separate mailing list? > > For the same reason any SIG should have their own list. > > And that reason is? Okay, well if we are going to remove special interest topics, we may as well remove 99% of the mailing lists listed here: https://redhat.com/mailman/listinfo Clearly there in the past was a need for special interest topics, I havn't actually counted, but it looks like somewhere between 95%-99% of all those mailing lists could be considered special interest. > P.S..:In case it matters: my current opinion is that this list is fine > to stay, but seems some people think different about it and I agree that > it's worth to be discussed I looked through those threads that you posted and did not see anyone but you questioning the need for the games list. > P.P.S.:I just want to make sure we have a healthy information flow in > the project as a whole. Having separate communication channels sometimes > can improve the "information flow" but sometimes disturb it. It's a > trade off. I think clearly labeling special interest lists with a format like: fedora-SIG-* would clearly differentiate special interest list against general interest lists. If the list is named fedora-foo, you know it is a general interest list. If it is named fedora-SIG-foo, then it is a special interest list. From mattdm at mattdm.org Tue Mar 20 19:08:55 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 15:08:55 -0400 Subject: fedora 7 comps change request (for festival) Message-ID: <20070320190855.GA20971@jadzia.bu.edu> Not sure how to do this properly during the merge-in-transition phase. The updated Festival text-to-speech package breaks out the voices, requiring only one. The rest should be in comps somewhere. Currently, festival is an optional package in "System Tools", and pulled in as default in "Gnome Desktop Environment" by orca. I think we should default to also installing at least the non-accented HTS voices (giving two male and two female choices by default): festvox-bdl-arctic-hts festvox-clb-arctic-hts festvox-rms-arctic-hts plus I'd suggest making the other voices visible somewhere in comps as optional. (festvox-awb-arctic-hts, festvox-jmk-arctic-hts, festvox-kal-diphone, festvox-ked-diphone.) Probably somewhere better than "System Tools" -- "Sound and Video", maybe? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Mar 20 19:13:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 15:13:46 -0400 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <4600309E.8060202@fedoraproject.org> References: <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> <4600309E.8060202@fedoraproject.org> Message-ID: <20070320191346.GA18364@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >Fedora-perl-devel-list -> perl SIG > >Fedora-music-list -> music and media production SIG > >Fedora-security-list -> security SIG > > This is incorrect. Fedora-perl-devel list was formed before the concept > of SIG's were in place. That's just nomenclature stuff. If it looks like a SIG, and acts like a SIG... Bill From nicolas.mailhot at laposte.net Tue Mar 20 19:20:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 20:20:52 +0100 Subject: A modest proposal: Have SIGS manage day-to-day comps additions with feedback from release-eng In-Reply-To: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> References: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> Message-ID: <1174418452.19100.6.camel@rousalka.dyndns.org> Le mardi 20 mars 2007 ? 10:51 -0800, Jeff Spaleta a ?crit : > The real question is how do we do that functionally. There is one > comps file right now. Do we > give a lot of people the authority to poke around inside that file. > I'm not sure I like that approach, I'd be afraid of inexperienced > people accidentally breaking the comps syntax, unless we can find a > way to toolize a syntax verifier as part of the check in process, like > what Jesse has suggested to me in irc. We already have a syntax verifier http://cvs.fedora.redhat.com/viewcvs/comps/comps-cleanup.xsl?root=extras (written because people kept breaking FE comps) And we could easily do more if the people responsible for the various upstreams (rpm, anaconda, yum) could bother looking at the existing proposals : - actual comps XML schema https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00426.html https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00443.html - more radical stuff http://fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements > Thoughts? Will only happen if comps-using upstreams participate Regards, -- Nicolas Mailhot From wtogami at redhat.com Tue Mar 20 19:24:20 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 15:24:20 -0400 Subject: NDN: Re: fedora-maintainers vs fedora-devel In-Reply-To: References: Message-ID: <460034E4.2000802@redhat.com> Gateway at redhat.com wrote: > Sorry. Your message could not be delivered to: > > christian paratschek,reflex.at (The name was not found at the remote site. > Check that the name has been entered correctly.) > I'm attempting to figure out how to get rid of these strange bounces. *something* is misbehaving somewhere... Warren From notting at redhat.com Tue Mar 20 19:23:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 15:23:13 -0400 Subject: A modest proposal: Have SIGS manage day-to-day comps additions with feedback from release-eng In-Reply-To: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> References: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> Message-ID: <20070320192313.GC18364@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > We make it the responsibility of each SIG to take ownership of at > least one comps group definition and to keep it pruned, with feedback > from release-eng. Well, I'm not sure the Security SIG needs to own a group, nor are there enough SIGS for all the groups. But it's a good idea for things like KDE, GNOME, Games, etc. > The real question is how do we do that functionally. There is one > comps file right now. Do we > give a lot of people the authority to poke around inside that file. > I'm not sure I like that approach, I'd be afraid of inexperienced > people accidentally breaking the comps syntax, unless we can find a > way to toolize a syntax verifier as part of the check in process, like > what Jesse has suggested to me in irc. I'd just edit the file. Bill From jspaleta at gmail.com Tue Mar 20 19:30:21 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Mar 2007 11:30:21 -0800 Subject: A modest proposal: Have SIGS manage day-to-day comps additions with feedback from release-eng In-Reply-To: <1174418452.19100.6.camel@rousalka.dyndns.org> References: <604aa7910703201151j2b751406nd67c6aefacc6c20@mail.gmail.com> <1174418452.19100.6.camel@rousalka.dyndns.org> Message-ID: <604aa7910703201230p5fc2cff0kfe3c44e0dc196e63@mail.gmail.com> On 3/20/07, Nicolas Mailhot wrote: > And we could easily do more if the people responsible for the various > upstreams (rpm, anaconda, yum) could bother looking at the existing > proposals : > - actual comps XML schema > https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00426.html > https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00443.html > > - more radical stuff > http://fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements > > > Thoughts? > > Will only happen if comps-using upstreams participate Sound like a job for my baseball bat. I need to get some batting practise in before the summer software season anyways. I'll see how many upstream kneecaps want to play ball. -jef From notting at redhat.com Tue Mar 20 19:25:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 15:25:11 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320190855.GA20971@jadzia.bu.edu> References: <20070320190855.GA20971@jadzia.bu.edu> Message-ID: <20070320192511.GD18364@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Not sure how to do this properly during the merge-in-transition phase. The > updated Festival text-to-speech package breaks out the voices, requiring > only one. The rest should be in comps somewhere. > > Currently, festival is an optional package in "System Tools", and pulled in > as default in "Gnome Desktop Environment" by orca. > > I think we should default to also installing at least the non-accented HTS > voices (giving two male and two female choices by default): > > festvox-bdl-arctic-hts > festvox-clb-arctic-hts > festvox-rms-arctic-hts The problem is pulling in any one particular voice - does festival pull in any voices by default? > Probably somewhere better than "System Tools" -- "Sound and Video", maybe? Text-to-speech doesn't sound right for sound and video. Bill From sundaram at fedoraproject.org Tue Mar 20 19:40:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 01:10:24 +0530 Subject: Role of SIG's Message-ID: <460038A8.8010706@fedoraproject.org> Hi I had previously left the SIG pages during the move to /PackageMaintainers in the wiki since I wasn't sure the SIG's were limited to coordination of packaging anymore. What would be a appropriate place? Do folks prefer the /PackageMaintainers/SIGs or just /SIG/? Rahul From mattdm at mattdm.org Tue Mar 20 19:44:53 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 15:44:53 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320192511.GD18364@nostromo.devel.redhat.com> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> Message-ID: <20070320194453.GA23884@jadzia.bu.edu> On Tue, Mar 20, 2007 at 03:25:11PM -0400, Bill Nottingham wrote: > > Currently, festival is an optional package in "System Tools", and pulled in > > as default in "Gnome Desktop Environment" by orca. > > I think we should default to also installing at least the non-accented HTS > > voices (giving two male and two female choices by default): > > festvox-bdl-arctic-hts > > festvox-clb-arctic-hts > > festvox-rms-arctic-hts > The problem is pulling in any one particular voice - does festival > pull in any voices by default? Yes, I made it pull in festvox-sdl-arctic-hts as a hard requirement. That way that's guaranteed. (Maybe in the future this could use "Recommends:" instead of "Requires".) The package actually will work as long as any one of the voices is installed. Well, it'll work to some degree with no voices at all, if you just want to use it as a Scheme interpreter. > > Probably somewhere better than "System Tools" -- "Sound and Video", > > maybe? > Text-to-speech doesn't sound right for sound and video. I suppose it depends if you're thinking of it as accessibility technology or as "cool, my computer can talk". Got a better suggestion? I don't think I'd look under System Tools at all. And it is "sound", after all. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Mar 20 19:58:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 15:58:08 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320194453.GA23884@jadzia.bu.edu> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> Message-ID: <20070320195808.GE18364@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Well, it'll work to some degree with no voices at > all, if you just want to use it as a Scheme interpreter. I really didn't need to know that. > > > Probably somewhere better than "System Tools" -- "Sound and Video", > > > maybe? > > Text-to-speech doesn't sound right for sound and video. > > I suppose it depends if you're thinking of it as accessibility technology or > as "cool, my computer can talk". > > Got a better suggestion? I don't think I'd look under System Tools at all. > And it is "sound", after all. Not sure. We also have espeak which isn't in comps. Bill From chris.stone at gmail.com Tue Mar 20 20:05:13 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Mar 2007 13:05:13 -0700 Subject: Role of SIG's In-Reply-To: <460038A8.8010706@fedoraproject.org> References: <460038A8.8010706@fedoraproject.org> Message-ID: On 3/20/07, Rahul Sundaram wrote: > Hi > > I had previously left the SIG pages during the move to > /PackageMaintainers in the wiki since I wasn't sure the SIG's were > limited to coordination of packaging anymore. What would be a > appropriate place? > > Do folks prefer the /PackageMaintainers/SIGs or just /SIG/? You should not have to be a packager to join a special interest group. The path of least resistance is that people first join a SIG and then become a packager, not the other way around. Getting people to sign up for special interest groups is a good way to recruit new packagers. I would actually consider PackageMaintainers as a SIG in itself. It makes more sense to me to have /SIG/PackageMaintainers rather than /PackageMaintainers/SIGs From overholt at redhat.com Tue Mar 20 20:07:32 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 20 Mar 2007 16:07:32 -0400 Subject: Freeze extension for eclipse-sdk-nls Message-ID: <20070320200732.GE14800@redhat.com> Hi, For Fedora 7, we are really hoping to deliver translations for the Eclipse SDK. Kyu Lee wrote a tool to repackage upstream's translation drops into a form suitable for Fedora. This tool made it into rawhide today as eclipse-nlspackager. The actual translations for the Eclipse SDK -- eclipse-sdk-nls -- are huge and are taking a very long time to upload with cvs-import.sh. As such -- and especially when combined with the crazy load of the build system today -- I'd like to ask for an extension of the feature freeze for this package. Once it is uploaded, it shouldn't take more than a few hours to build and be ready for inclusion. I'm sorry if this isn't the right place to request this. Thanks, Andrew From wtogami at redhat.com Tue Mar 20 20:12:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 16:12:28 -0400 Subject: Role of SIG's In-Reply-To: <460038A8.8010706@fedoraproject.org> References: <460038A8.8010706@fedoraproject.org> Message-ID: <4600402C.8090301@redhat.com> Rahul Sundaram wrote: > Hi > > I had previously left the SIG pages during the move to > /PackageMaintainers in the wiki since I wasn't sure the SIG's were > limited to coordination of packaging anymore. What would be a > appropriate place? > > Do folks prefer the /PackageMaintainers/SIGs or just /SIG/? > /SIG/ makes more sense, it contains focused content. /PackageMaintainers/ please remain separate. Warren From rdieter at math.unl.edu Tue Mar 20 20:19:54 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Mar 2007 15:19:54 -0500 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320195808.GE18364@nostromo.devel.redhat.com> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> Message-ID: <460041EA.80000@math.unl.edu> Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: >> Well, it'll work to some degree with no voices at >> all, if you just want to use it as a Scheme interpreter. > > I really didn't need to know that. > >>>> Probably somewhere better than "System Tools" -- "Sound and Video", >>>> maybe? >>> Text-to-speech doesn't sound right for sound and video. >> I suppose it depends if you're thinking of it as accessibility technology or >> as "cool, my computer can talk". >> >> Got a better suggestion? I don't think I'd look under System Tools at all. >> And it is "sound", after all. > > Not sure. We also have espeak which isn't in comps. Maybe a group for accessibility utils? -- Rex From mattdm at mattdm.org Tue Mar 20 20:23:26 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 16:23:26 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <460041EA.80000@math.unl.edu> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> <460041EA.80000@math.unl.edu> Message-ID: <20070320202326.GA29234@jadzia.bu.edu> On Tue, Mar 20, 2007 at 03:19:54PM -0500, Rex Dieter wrote: > >Not sure. We also have espeak which isn't in comps. > Maybe a group for accessibility utils? It's so tempting to keep adding groups to solve all problems. But this one might actually deserve it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Mar 20 20:27:37 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 16:27:37 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320190855.GA20971@jadzia.bu.edu> References: <20070320190855.GA20971@jadzia.bu.edu> Message-ID: <20070320202737.GA29738@jadzia.bu.edu> On Tue, Mar 20, 2007 at 03:08:55PM -0400, Matthew Miller wrote: > Currently, festival is an optional package in "System Tools", and pulled in > as default in "Gnome Desktop Environment" by orca. Oh, note that the later part of this is currently only true on i386, for no good reason (anymore). See bug #232517. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Tue Mar 20 20:32:30 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 20 Mar 2007 13:32:30 -0700 Subject: Role of SIG's In-Reply-To: References: <460038A8.8010706@fedoraproject.org> Message-ID: <1174422750.3390.0.camel@tuxhugs> On Tue, 2007-03-20 at 13:05 -0700, Christopher Stone wrote: > I would actually consider PackageMaintainers as a SIG in itself. It > makes more sense to me to have /SIG/PackageMaintainers rather than > /PackageMaintainers/SIGs +1 from me. This makes more sense to me and continues along the already in-place lines of having a bug-triaging squad, a documentation group, translation group, etc. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kmacmill at redhat.com Tue Mar 20 20:33:55 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 20 Mar 2007 16:33:55 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <200703201445.06284.jkeating@redhat.com> References: <20070320183913.GB20185@neu.nirvana> <200703201445.06284.jkeating@redhat.com> Message-ID: <1174422835.31342.11.camel@localhost.localdomain> On Tue, 2007-03-20 at 14:45 -0400, Jesse Keating wrote: > On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > > The way I see it it is like the following: > > > > o fedora-devel > > - concentrates on rawhide and its way to a release > > - has in-house upstream development discussion > > - more in-depth Linux mechanics > > - manages release cycle > > > > o fedora-maintainers > > - concentrates on the packaging community as a whole > > - More issues about packaging than on upstream development, if any > > - cares more about current and past releases > > Actually I do all the freeze and collection announcements to > fedora-maintainers. They're the people that need to know, and it's largely > just noise for fedora-devel. I may not be typical as I don't maintain any packages, but I do upstream work that often specifically targets Fedora releases. So seeing freeze announcements and similar on fedora-devel would be helpful. Not a big deal as I usually hear this from package maintainers indirectly, but more direct information would sometimes help. Karl From sundaram at fedoraproject.org Tue Mar 20 20:39:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 02:09:15 +0530 Subject: Role of SIG's In-Reply-To: References: <460038A8.8010706@fedoraproject.org> Message-ID: <46004673.8040603@fedoraproject.org> Christopher Stone wrote: > On 3/20/07, Rahul Sundaram wrote: >> Hi >> >> I had previously left the SIG pages during the move to >> /PackageMaintainers in the wiki since I wasn't sure the SIG's were >> limited to coordination of packaging anymore. What would be a >> appropriate place? >> >> Do folks prefer the /PackageMaintainers/SIGs or just /SIG/? > > You should not have to be a packager to join a special interest group. > The path of least resistance is that people first join a SIG and then > become a packager, not the other way around. > > Getting people to sign up for special interest groups is a good way to > recruit new packagers. Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. > I would actually consider PackageMaintainers as a SIG in itself. It > makes more sense to me to have /SIG/PackageMaintainers rather than > /PackageMaintainers/SIGs I spend a lot of time renaming and reorganizing the pages and content from /Extras to /PackageMaintainers recently so I would just keep them separate since Extras was a project I would consider Packaging Maintainers as part of the packaging project in the merged world. Rahul From denis at poolshark.org Tue Mar 20 20:57:02 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 20 Mar 2007 21:57:02 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46002889.6010204@fedoraproject.org> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> Message-ID: <46004A9E.9080604@poolshark.org> Rahul Sundaram wrote: > Christopher Stone wrote: >> On 3/20/07, Rahul Sundaram wrote: >>> Why does games SIG require a separate mailing list? >> >> For the same reason any SIG should have their own list. > > That is not a good reason consider no SIG except games has its own > mailing list. > > If it is packaging details it should be in fedora-packaging list. Other > details could be in fedora-devel list. In other words what do you > discuss in fedora-games list that doesnt fit into any existing other > Fedora lists? To me the Games SIG is a fantastic example of a "SIG done right": a very dynamic and active group that essentially created their own sub-community. The smaller size makes it easier to define games-specific packaging standard, contributes to faster package reviews, and so on. I don't know about "should", but it seems to me if SIG members feel they need their own list, why not. From nicolas.mailhot at laposte.net Tue Mar 20 21:09:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 22:09:53 +0100 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320202326.GA29234@jadzia.bu.edu> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> <460041EA.80000@math.unl.edu> <20070320202326.GA29234@jadzia.bu.edu> Message-ID: <1174424994.5362.0.camel@rousalka.dyndns.org> Le mardi 20 mars 2007 ? 16:23 -0400, Matthew Miller a ?crit : > On Tue, Mar 20, 2007 at 03:19:54PM -0500, Rex Dieter wrote: > > >Not sure. We also have espeak which isn't in comps. > > Maybe a group for accessibility utils? > > It's so tempting to keep adding groups to solve all problems. But this one > might actually deserve it. Right now we're leaning more towards giant useless groups -- Nicolas Mailhot From wtogami at redhat.com Tue Mar 20 21:09:57 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 17:09:57 -0400 Subject: No Freeze Yet, Extras New Packages Message-ID: <46004DA5.6070803@redhat.com> http://fedoraproject.org/wiki/Releases/Schedule Today is the "Feature Freeze" for Fedora 7. This in the past has meant that (the distro on media) no longer accepts new features. The reason for the freeze is primarily for the stabilization of the install process. I just spoke with Jeremy Katz. He said: - Feature freeze is in effect for the content of the standard spins. - Extras is not frozen yet. Keep going with package additions in Extras devel for now. Moving forward we will have to freeze Extras devel for new additions at some point, in order to stabilize the tree. We don't know for sure when yet (likely Test4). We have to see about the progress of Koji and other merge infrastructure currently underway before we can figure out the schedule. Warren Togami wtogami at redhat.com From a.badger at gmail.com Tue Mar 20 21:27:32 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 Mar 2007 14:27:32 -0700 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <46004A9E.9080604@poolshark.org> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> <46004A9E.9080604@poolshark.org> Message-ID: <1174426052.24014.46.camel@localhost.localdomain> On Tue, 2007-03-20 at 21:57 +0100, Denis Leroy wrote: > Rahul Sundaram wrote: > > Christopher Stone wrote: > >> On 3/20/07, Rahul Sundaram wrote: > >>> Why does games SIG require a separate mailing list? > >> > >> For the same reason any SIG should have their own list. > > > > That is not a good reason consider no SIG except games has its own > > mailing list. > > > > If it is packaging details it should be in fedora-packaging list. Other > > details could be in fedora-devel list. In other words what do you > > discuss in fedora-games list that doesnt fit into any existing other > > Fedora lists? > > To me the Games SIG is a fantastic example of a "SIG done right": a very > dynamic and active group that essentially created their own > sub-community. The smaller size makes it easier to define games-specific > packaging standard, contributes to faster package reviews, and so on. I > don't know about "should", but it seems to me if SIG members feel they > need their own list, why not. > +1. A follow-on question: does the list help strengthen the feeling of community for the SIG members? It's not all about technical questions and answers, after all. Having a camaraderie with fellow packagers is also a worthwhile goal. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Mar 20 21:44:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 17:44:17 -0400 Subject: Freeze extension for eclipse-sdk-nls In-Reply-To: <20070320200732.GE14800@redhat.com> References: <20070320200732.GE14800@redhat.com> Message-ID: <200703201744.17588.jkeating@redhat.com> On Tuesday 20 March 2007 16:07:32 Andrew Overholt wrote: > For Fedora 7, we are really hoping to deliver translations for the > Eclipse SDK. ?Kyu Lee wrote a tool to repackage > upstream's translation drops into a form suitable for Fedora. ?This tool > made it into rawhide today as eclipse-nlspackager. ?The actual > translations for the Eclipse SDK -- eclipse-sdk-nls -- are huge and are > taking a very long time to upload with cvs-import.sh. ?As such -- and > especially when combined with the crazy load of the build system today > -- I'd like to ask for an extension of the feature freeze for this > package. ?Once it is uploaded, it shouldn't take more than a few hours > to build and be ready for inclusion. I'm OK with this being granted. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Mar 20 21:46:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 17:46:16 -0400 Subject: Fedora 7 frozen for Test 3 Message-ID: <200703201746.16628.jkeating@redhat.com> I've frozen the "Core" side of Fedora 7 for Test 3. Rawhide composes will happen from the 'f7-test3' collection. Builds from the devel/ branch continue to go to dist-fc7 and will be picked up after the freeze. If you have compelling reason to have your build included in Test3, please email rel-eng at fedoraproject.org State your package build and reasons why it should be included in Test3. That is all. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Tue Mar 20 21:51:07 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 17:51:07 -0400 Subject: Rename cvsextras? Message-ID: <4600574B.7010405@redhat.com> I think it is time to rename the cvsextras group. This would help us to be consistent moving forward in documentation and general understanding. Perhaps we should call it cvspackage? Thoughts? Warren Togami wtogami at redhat.com From tibbs at math.uh.edu Tue Mar 20 22:45:34 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Mar 2007 17:45:34 -0500 Subject: Rename cvsextras? In-Reply-To: <4600574B.7010405@redhat.com> References: <4600574B.7010405@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> Perhaps we should call it cvspackage? Now that we have a proper ACL system, why not merge cvsextras and cvsfedora? - J< From dennis at ausil.us Tue Mar 20 22:56:38 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 Mar 2007 17:56:38 -0500 Subject: ppc64 builds In-Reply-To: <200703142231.51890.dennis@ausil.us> References: <200703142231.51890.dennis@ausil.us> Message-ID: <200703201756.38945.dennis@ausil.us> On Wednesday 14 March 2007 10:31:51 pm Dennis Gilmore wrote: > Hey All, > > With the merge of core and extras we need to enable ppc64 builds for what > was formally know as extras. So this weekend I am going to turn on ppc64 > builds in plague for extras packages on devel only. > > We need to enable this so that we can continue to support G5 macs and other > 64 bit ppc platforms. > > Everything will need to be built for ppc64. So we have hit a rpm bug that is causing libdir to always be /usr/lib before we build to many things we need to fix that. we will then need to start over again. -- Dennis Gilmore, RHCE From jwboyer at jdub.homelinux.org Tue Mar 20 23:25:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 18:25:16 -0500 Subject: Rename cvsextras? In-Reply-To: References: <4600574B.7010405@redhat.com> Message-ID: <1174433117.2977.49.camel@vader.jdub.homelinux.org> On Tue, 2007-03-20 at 17:45 -0500, Jason L Tibbitts III wrote: > >>>>> "WT" == Warren Togami writes: > > WT> Perhaps we should call it cvspackage? > > Now that we have a proper ACL system, why not merge cvsextras and > cvsfedora? And call it what? 'cvsfedora'? I like that name. I'll even volunteer to update any wiki documentation to fix references to cvsextras once we have a name. I just hope it doesn't cause lots of pain... josh From katzj at redhat.com Tue Mar 20 23:32:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Mar 2007 19:32:06 -0400 Subject: Rename cvsextras? In-Reply-To: References: <4600574B.7010405@redhat.com> Message-ID: <1174433526.3100.3.camel@aglarond.local> On Tue, 2007-03-20 at 17:45 -0500, Jason L Tibbitts III wrote: > >>>>> "WT" == Warren Togami writes: > WT> Perhaps we should call it cvspackage? > > Now that we have a proper ACL system, why not merge cvsextras and > cvsfedora? cvsfedora is for access to /cvs/fedora which is more "software maintained in this cvsroot" and thus the acl stuff we're doing with package CVS can't really work as well.[1] Jeremy [1] I really don't want a file pkg.avail in my tagged dists of software :-) From buildsys at fedoraproject.org Wed Mar 21 00:13:44 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 20 Mar 2007 20:13:44 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-20 Message-ID: <20070321001344.15E93152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: ettercap FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) rdieter AT math.unl.edu: kmymoney2 FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) ettercap: limb AT jcomserv.net FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kmymoney2: rdieter AT math.unl.edu FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-3.fc7) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-3.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From mmcgrath at redhat.com Wed Mar 21 00:29:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Mar 2007 19:29:32 -0500 Subject: Rename cvsextras? In-Reply-To: References: <4600574B.7010405@redhat.com> Message-ID: <46007C6C.5030502@redhat.com> Jason L Tibbitts III wrote: > WT> Perhaps we should call it cvspackage? > > Now that we have a proper ACL system, why not merge cvsextras and > cvsfedora? > > - J< > cvsfedora actually has upstream (our) code, like the account system, the wiki's kindofblue theme, etc. It's different from the packages. -Mike From caillon at redhat.com Wed Mar 21 01:57:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 20 Mar 2007 21:57:57 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <46009125.4040802@redhat.com> Axel Thimm wrote: > o fedora-devel > - concentrates on rawhide and its way to a release > - has in-house upstream development discussion > - more in-depth Linux mechanics > - manages release cycle > > o fedora-maintainers > - concentrates on the packaging community as a whole > - More issues about packaging than on upstream development, if any > - cares more about current and past releases No, that's fedora-packaging AIUI. Fedora-maintainers is simply a list for issuing information for all maintainers. If there's new policy that affects maintainers, it gets sent to -maintainers. If there's a rebuild coming up that all maintainers need to notice, it gets sent to -maintainers. If someone rebuilds a library which others might depend on, -maintainers. Else, devel/rawhide stuff to -devel and packaging issues to -packaging. From tibbs at math.uh.edu Wed Mar 21 01:58:42 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Mar 2007 20:58:42 -0500 Subject: Rename cvsextras? In-Reply-To: <46007C6C.5030502@redhat.com> References: <4600574B.7010405@redhat.com> <46007C6C.5030502@redhat.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> cvsfedora actually has upstream (our) code, like the account MM> system, the wiki's kindofblue theme, etc. It's different from the MM> packages. cvsfedora is just an account group. - J< From dennis at ausil.us Wed Mar 21 02:18:17 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 Mar 2007 21:18:17 -0500 Subject: Rename cvsextras? In-Reply-To: References: <4600574B.7010405@redhat.com> <46007C6C.5030502@redhat.com> Message-ID: <200703202118.17737.dennis@ausil.us> Once upon a time Tuesday 20 March 2007, Jason L Tibbitts III wrote: > >>>>> "MM" == Mike McGrath writes: > > MM> cvsfedora actually has upstream (our) code, like the account > MM> system, the wiki's kindofblue theme, etc. It's different from the > MM> packages. > > cvsfedora is just an account group. it is more than that. cvsextras lives in /cvs/extras cvsfedora is /cvs/fedora and contains upstream things. they really need to be kept seperate i personally like cvsdist From tibbs at math.uh.edu Wed Mar 21 02:41:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Mar 2007 21:41:22 -0500 Subject: Rename cvsextras? In-Reply-To: <200703202118.17737.dennis@ausil.us> References: <4600574B.7010405@redhat.com> <46007C6C.5030502@redhat.com> <200703202118.17737.dennis@ausil.us> Message-ID: >>>>> "DG" == Dennis Gilmore writes: DG> it is more than that. I am indeed aware that there is a CVS tree which the cvsfedora group partially controls access to (and indeed I have access to it), but I have not seen it called "cvsfedora" before. I never mentioned and did not intend to imply joining the multiple CVS repositories, although at some point I suppose the repository under cvs/dist and the one under cvs/extras will merge in some way. I was only speaking of the account group named "cvsfedora" in the account system. - J< From fedora at leemhuis.info Wed Mar 21 05:53:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 06:53:46 +0100 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002AD8.2050501@leemhuis.info> Message-ID: <4600C86A.8030407@leemhuis.info> On 20.03.2007 20:08, Christopher Stone wrote: > On 3/20/07, Thorsten Leemhuis wrote: >> Christopher Stone schrieb: >>> On 3/20/07, Rahul Sundaram wrote: >>>> Why does games SIG require a separate mailing list? >>> For the same reason any SIG should have their own list. >> And that reason is? > Okay, well if we are going to remove special interest topics, we may > as well remove 99% of the mailing lists listed here: > https://redhat.com/mailman/listinfo > > Clearly there in the past was a need for special interest topics, I > havn't actually counted, but it looks like somewhere between 95%-99% > of all those mailing lists could be considered special interest. Sure; but it depends on how big this "special interest" is to be worth having a special list where large parts of the other contributors probably won't be on. So they might miss important informations that might be relevant for them, and that's what some people complained about in the past with the current mailing list. >> P.S..:In case it matters: my current opinion is that this list is fine >> to stay, but seems some people think different about it and I agree that >> it's worth to be discussed > I looked through those threads that you posted and did not see anyone > but you questioning the need for the games list. This stuff got discussed on IRC, too (I think the fedora-games example came up there there). And I received some private mails, too. /me thinks finger pointing doesn't help much >> P.P.S.:I just want to make sure we have a healthy information flow in >> the project as a whole. Having separate communication channels sometimes >> can improve the "information flow" but sometimes disturb it. It's a >> trade off. > I think clearly labeling special interest lists with a format like: > fedora-SIG-* would clearly differentiate special interest list against > general interest lists. If the list is named fedora-foo, you know it > is a general interest list. If it is named fedora-SIG-foo, then it is > a special interest list. See above. I don't have a problem with a list for a SIG, my only concern is that people not on the list need to know all the details that are relevant for them. A example for this case: there are special "suggestions" for packaging games. They are documented on the wiki, but I think such stuff and especially changes to it should get announced to the normal lists, so non-SIG members know what's the current suggestion-set in case they package or review a game; and it allows the other contributors to discuss stuff the games-SIG worked out, without being member of the SIG mailing list. CU thl From cweyl at alumni.drew.edu Wed Mar 21 06:05:28 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 20 Mar 2007 23:05:28 -0700 Subject: setting a flag via bugzilla's xlmrpc interface? In-Reply-To: <7dd7ab490703161414q37f6c8a0sae935bea0d0a857@mail.gmail.com> References: <7dd7ab490703121412u291fc94ci1c10508fb8c074ba@mail.gmail.com> <20070313094853.0163428e@ludwig-alpha.unil.ch> <7dd7ab490703131405l582f7361l4c3d8fc9b8687a67@mail.gmail.com> <20070313223029.75a7a04b@ludwig-alpha.unil.ch> <7dd7ab490703161034w10737497k727a27f92ee1e452@mail.gmail.com> <20070316220931.6642ff16@ludwig-alpha.unil.ch> <7dd7ab490703161414q37f6c8a0sae935bea0d0a857@mail.gmail.com> Message-ID: <7dd7ab490703202305i5017cac1r734477786708cbe5@mail.gmail.com> On 3/16/07, Chris Weyl wrote: > On 3/16/07, Christian Iseli wrote: > > Not that I know of. I think someone from RH should make a good pass > > through those scripts to make sure nothing sensitive (e.g. passwords) > > is forgotten in there and post them somewhere on the wiki... > > Seconded. I'd even be willing to take the "declassified" scripts and > create a documentation page on the wiki. Any luck with getting these scripts "cleaned"? :) I've put up a small page at: http://fedoraproject.org/wiki/AutomatingBugzilla. It's very basic, doesn't contain everything (clearly), and I'm too tired to edit it too much more tonight, but I wanted to get it out there so others could add/use it. -Chris -- Chris Weyl Ex astris, scientia From markmc at redhat.com Wed Mar 21 08:35:10 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 21 Mar 2007 08:35:10 +0000 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <200703201445.06284.jkeating@redhat.com> References: <20070320183913.GB20185@neu.nirvana> <200703201445.06284.jkeating@redhat.com> Message-ID: <1174466110.3328.14.camel@blaa> On Tue, 2007-03-20 at 14:45 -0400, Jesse Keating wrote: > On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > > The way I see it it is like the following: > > > > o fedora-devel > > - concentrates on rawhide and its way to a release > > - has in-house upstream development discussion > > - more in-depth Linux mechanics > > - manages release cycle > > > > o fedora-maintainers > > - concentrates on the packaging community as a whole > > - More issues about packaging than on upstream development, if any > > - cares more about current and past releases > > Actually I do all the freeze and collection announcements to > fedora-maintainers. They're the people that need to know, and it's largely > just noise for fedora-devel. To me, fedora-maintainers are the people doing > the work, and a communication place for that. fedora-devel is a combo of > people doing work and a larger community consuming the work. It seems odd to create a boundary (i.e. fedora-maintainers is a closed list) between the people currently doing the work and people which might potentially do some work. You want to make it easier for people to contribute, not harder. Also, it's a pretty artificial distinction. Not currently owning a package does not mean one is not contributing to fedora e.g. I don't currently own any packages so I was silently dropped from fedora-maintainers, but I do contribute in various ways to some packages. Looking at the archives, I'm quite surprised at the level of discussion on fedora-maintainers I'm missing out on. Cheers, Mark. From trond.danielsen at gmail.com Wed Mar 21 08:48:58 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Wed, 21 Mar 2007 09:48:58 +0100 Subject: Role of SIG's In-Reply-To: <46004673.8040603@fedoraproject.org> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> Message-ID: <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> 2007/3/20, Rahul Sundaram : > > Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. Should the members of the various Extras SIGs move the pages from /Extras/SIGs/my_sig to /SIGs/my_sig, or will that be taken care of? -- Trond Danielsen From Axel.Thimm at ATrpms.net Wed Mar 21 09:25:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Mar 2007 10:25:22 +0100 Subject: Rename cvsextras? In-Reply-To: <4600574B.7010405@redhat.com> References: <4600574B.7010405@redhat.com> Message-ID: <20070321092522.GA18252@neu.nirvana> On Tue, Mar 20, 2007 at 05:51:07PM -0400, Warren Togami wrote: > I think it is time to rename the cvsextras group. This would help us to > be consistent moving forward in documentation and general understanding. > > Perhaps we should call it cvspackage? > > Thoughts? Perhaps something w/o an explict VCS implementation in the name, as we'd like to think about CVS alternatives after F7, and if we switch away from CVS everything would need to be renamed. So perhaps just "packagers" or "contributors"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Mar 21 10:07:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 11:07:09 +0100 Subject: Rename cvsextras? In-Reply-To: <20070321092522.GA18252@neu.nirvana> References: <4600574B.7010405@redhat.com> <20070321092522.GA18252@neu.nirvana> Message-ID: <460103CD.9010404@leemhuis.info> On 21.03.2007 10:25, Axel Thimm wrote: > On Tue, Mar 20, 2007 at 05:51:07PM -0400, Warren Togami wrote: >> I think it is time to rename the cvsextras group. This would help us to >> be consistent moving forward in documentation and general understanding. >> Perhaps we should call it cvspackage? >> Thoughts? > Perhaps something w/o an explict VCS implementation in the name, as > we'd like to think about CVS alternatives after F7, and if we switch > away from CVS everything would need to be renamed. So perhaps just > "packagers" or "contributors"? Putting some more ideas into the mix: There were thoughts to have different contributors levels; e.g. some with only VCS access only, some with buildsys access, too. Maybe this will influence the naming for the Accounts system, too. CU thl From fedora at leemhuis.info Wed Mar 21 10:09:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 11:09:01 +0100 Subject: Role of SIG's In-Reply-To: <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> Message-ID: <4601043D.1070806@leemhuis.info> On 21.03.2007 09:48, Trond Danielsen wrote: > 2007/3/20, Rahul Sundaram : >> Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. I'm late in the game, but I would have prefered to differentiate Fedora SIG and Packaging SIGs a bit more. Maybe SIGs/ for Fedora Sigs PackagingSGIs/ or SIGs/Packaging/ for Packaging SIGs But well, to late now probably. CU thl From Axel.Thimm at ATrpms.net Wed Mar 21 10:17:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Mar 2007 11:17:32 +0100 Subject: Rename cvsextras? In-Reply-To: <460103CD.9010404@leemhuis.info> References: <4600574B.7010405@redhat.com> <20070321092522.GA18252@neu.nirvana> <460103CD.9010404@leemhuis.info> Message-ID: <20070321101732.GC18252@neu.nirvana> On Wed, Mar 21, 2007 at 11:07:09AM +0100, Thorsten Leemhuis wrote: > On 21.03.2007 10:25, Axel Thimm wrote: > > On Tue, Mar 20, 2007 at 05:51:07PM -0400, Warren Togami wrote: > >> I think it is time to rename the cvsextras group. This would help us to > >> be consistent moving forward in documentation and general understanding. > >> Perhaps we should call it cvspackage? > >> Thoughts? > > Perhaps something w/o an explict VCS implementation in the name, as > > we'd like to think about CVS alternatives after F7, and if we switch > > away from CVS everything would need to be renamed. So perhaps just > > "packagers" or "contributors"? > > Putting some more ideas into the mix: There were thoughts to have > different contributors levels; e.g. some with only VCS access only, some > with buildsys access, too. Maybe this will influence the naming for the > Accounts system, too. How about "packagers" and "build-admins"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Mar 21 10:33:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 11:33:04 +0100 Subject: Rename cvsextras? In-Reply-To: <20070321101732.GC18252@neu.nirvana> References: <4600574B.7010405@redhat.com> <20070321092522.GA18252@neu.nirvana> <460103CD.9010404@leemhuis.info> <20070321101732.GC18252@neu.nirvana> Message-ID: <460109E0.6050005@leemhuis.info> On 21.03.2007 11:17, Axel Thimm wrote: > On Wed, Mar 21, 2007 at 11:07:09AM +0100, Thorsten Leemhuis wrote: >> On 21.03.2007 10:25, Axel Thimm wrote: >>> On Tue, Mar 20, 2007 at 05:51:07PM -0400, Warren Togami wrote: >>>> I think it is time to rename the cvsextras group. This would help us to >>>> be consistent moving forward in documentation and general understanding. >>>> Perhaps we should call it cvspackage? >>>> Thoughts? >>> Perhaps something w/o an explict VCS implementation in the name, as >>> we'd like to think about CVS alternatives after F7, and if we switch >>> away from CVS everything would need to be renamed. So perhaps just >>> "packagers" or "contributors"? >> Putting some more ideas into the mix: There were thoughts to have >> different contributors levels; e.g. some with only VCS access only, some >> with buildsys access, too. Maybe this will influence the naming for the >> Accounts system, too. > How about "packagers" and "build-admins"? Well, there were more levels on Warrens proposal. And build-admins IMHO sounds like buildsys-admins. I'd say we'd probably need to discuss how we go forward with Warrens concept (I really liked the direction) and then rename. Or rename to "packagers" or something else now and get back to do the other stuff later. CU thl From limb at jcomserv.net Wed Mar 21 11:53:57 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 21 Mar 2007 06:53:57 -0500 (CDT) Subject: Buildsys problem? Message-ID: <35839.65.192.24.190.1174478037.squirrel@mail.jcomserv.net> I submitted a job about 30 min ago and plague told me the job was enqueued but did not receive a job number. I've been checking plague-client list status building every few minutes, and the list of jobs and their status has not changed. Does someone need to kick something? Thanks, Jon -- novus ordo absurdum From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 21 12:32:53 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 Mar 2007 21:32:53 +0900 Subject: Buildsys problem? In-Reply-To: <35839.65.192.24.190.1174478037.squirrel@mail.jcomserv.net> References: <35839.65.192.24.190.1174478037.squirrel@mail.jcomserv.net> Message-ID: <460125F5.40708@ioa.s.u-tokyo.ac.jp> Jon Ciesla wrote: > I submitted a job about 30 min ago and plague told me the job was enqueued > but did not receive a job number. I've been checking plague-client list > status building every few minutes, and the list of jobs and their status > has not changed. Does someone need to kick something? > I saw buildsys status and it seems that currently buildsys is crowded with lots of build request queues. And buildsys status is actually changing. So perhaps you just have to wait... Mamoru From limb at jcomserv.net Wed Mar 21 12:39:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 21 Mar 2007 07:39:21 -0500 (CDT) Subject: Buildsys problem? In-Reply-To: <460125F5.40708@ioa.s.u-tokyo.ac.jp> References: <35839.65.192.24.190.1174478037.squirrel@mail.jcomserv.net> <460125F5.40708@ioa.s.u-tokyo.ac.jp> Message-ID: <38542.65.192.24.190.1174480761.squirrel@mail.jcomserv.net> Thanks, I'll try requesting builds AFTER I have some caffeine, next time. :) > Jon Ciesla wrote: >> I submitted a job about 30 min ago and plague told me the job was >> enqueued >> but did not receive a job number. I've been checking plague-client list >> status building every few minutes, and the list of jobs and their status >> has not changed. Does someone need to kick something? >> > > I saw buildsys status and it seems that currently buildsys is > crowded with lots of build request queues. And buildsys status > is actually changing. So perhaps you just have to wait... > > Mamoru > -- novus ordo absurdum From overholt at redhat.com Wed Mar 21 13:19:12 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 21 Mar 2007 09:19:12 -0400 Subject: Freeze extension for eclipse-sdk-nls In-Reply-To: <200703201744.17588.jkeating@redhat.com> References: <20070320200732.GE14800@redhat.com> <200703201744.17588.jkeating@redhat.com> Message-ID: <20070321131912.GB11004@redhat.com> * Jesse Keating [2007-03-20 17:43]: > On Tuesday 20 March 2007 16:07:32 Andrew Overholt wrote: > > For Fedora 7, we are really hoping to deliver translations for the > > Eclipse SDK. ?Kyu Lee wrote a tool to repackage > > upstream's translation drops into a form suitable for Fedora. ?This tool > > made it into rawhide today as eclipse-nlspackager. ?The actual > > translations for the Eclipse SDK -- eclipse-sdk-nls -- are huge and are > > taking a very long time to upload with cvs-import.sh. ?As such -- and > > especially when combined with the crazy load of the build system today > > -- I'd like to ask for an extension of the feature freeze for this > > package. ?Once it is uploaded, it shouldn't take more than a few hours > > to build and be ready for inclusion. > > I'm OK with this being granted. Thanks. This finished building last night and I now see all of the language binary RPMs in the extras download repo. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skasal at redhat.com Wed Mar 21 14:02:18 2007 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 21 Mar 2007 15:02:18 +0100 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <20070321140218.GA10893@camelia.ucw.cz> Hello, On Fri, Mar 16, 2007 at 04:29:34PM -0400, Thomas Fitzsimmons wrote: > - these packages have BuildRequires for java-1.4.2-gcj-compat*: .. > libgconf-java-0:2.12.4-7.fc7 I have followed your advices and replaced this buildrequire by "java-devel", which brings sinjdoc. The rebuilded package is ready and will get to rawhide after Test3 is released. Stepan Kasal From mattdm at mattdm.org Wed Mar 21 14:47:28 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Mar 2007 10:47:28 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070320195808.GE18364@nostromo.devel.redhat.com> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> Message-ID: <20070321144728.GA19264@jadzia.bu.edu> On Tue, Mar 20, 2007 at 03:58:08PM -0400, Bill Nottingham wrote: > > Well, it'll work to some degree with no voices at > > all, if you just want to use it as a Scheme interpreter. > I really didn't need to know that. (yeah (times (good (it's)))) > > Got a better suggestion? I don't think I'd look under System Tools at all. > > And it is "sound", after all. > Not sure. We also have espeak which isn't in comps. So, an "Accessibility" group? Should I bugzilla this as an enhancement request against comps? Or should I be patient? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Wed Mar 21 14:58:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Mar 2007 10:58:07 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-21 Message-ID: <20070321145807.05064152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: ettercap FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) overholt AT redhat.com: eclipse-emf FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) eclipse-emf: overholt AT redhat.com FE6 > FE7 (0:2.2.2-1.fc6 > 0:2.2.1-9.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) ettercap: limb AT jcomserv.net FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From tcallawa at redhat.com Wed Mar 21 21:11:11 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 Mar 2007 16:11:11 -0500 Subject: Role of SIG's In-Reply-To: <4601043D.1070806@leemhuis.info> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> <4601043D.1070806@leemhuis.info> Message-ID: <1174511471.3288.41.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-03-21 at 11:09 +0100, Thorsten Leemhuis wrote: > On 21.03.2007 09:48, Trond Danielsen wrote: > > 2007/3/20, Rahul Sundaram : > >> Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. > > I'm late in the game, but I would have prefered to differentiate Fedora > SIG and Packaging SIGs a bit more. Maybe > > SIGs/ for Fedora Sigs > PackagingSGIs/ or SIGs/Packaging/ for Packaging SIGs > > But well, to late now probably. Packaging is not a SIG. We're extra special. :) ~spot From fedora at leemhuis.info Wed Mar 21 21:22:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 22:22:52 +0100 Subject: Role of SIG's In-Reply-To: <1174511471.3288.41.camel@dhcp67.install.boston.redhat.com> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> <4601043D.1070806@leemhuis.info> <1174511471.3288.41.camel@dhcp67.install.boston.redhat.com> Message-ID: <4601A22C.3080000@leemhuis.info> Tom "spot" Callaway schrieb: > On Wed, 2007-03-21 at 11:09 +0100, Thorsten Leemhuis wrote: >> On 21.03.2007 09:48, Trond Danielsen wrote: >>> 2007/3/20, Rahul Sundaram : >>>> Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. >> I'm late in the game, but I would have prefered to differentiate Fedora >> SIG and Packaging SIGs a bit more. Maybe >> SIGs/ for Fedora Sigs >> PackagingSGIs/ or SIGs/Packaging/ for Packaging SIGs >> But well, to late now probably. > > Packaging is not a SIG. We're extra special. :) I meant packaging the task in writing and maintaining spec files, not the Packaging Committee ;-) But well, you brought that topic up. Quoting https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html "[...]The Packaging Committee at the same time becomes a SIG. It will work as before;[...]FESCo in its meeting today agreed that this is the route it wants to take [...]Could the board please look at the proposal, discuss it in its tomorrows meeting and ACK it or if it dislikes parts give feedback if it wants to see something changed?" The Board ACKed that afaik. CU thl From tcallawa at redhat.com Wed Mar 21 21:43:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 Mar 2007 16:43:25 -0500 Subject: Role of SIG's In-Reply-To: <4601A22C.3080000@leemhuis.info> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> <4601043D.1070806@leemhuis.info> <1174511471.3288.41.camel@dhcp67.install.boston.redhat.com> <4601A22C.3080000@leemhuis.info> Message-ID: <1174513405.3288.47.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-03-21 at 22:22 +0100, Thorsten Leemhuis wrote: > But well, you brought that topic up. Quoting > https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html > > "[...]The Packaging Committee at the same time becomes a SIG. It will > work as before;[...]FESCo in its meeting today agreed that this is the > route it wants to take [...]Could the board please look at the proposal, > discuss it in its tomorrows meeting and ACK it or if it dislikes parts > give feedback if it wants to see something changed?" > > The Board ACKed that afaik. Heh, so we're a SIG, but we don't act like one, and we have special powers. I think FPC is an ESIG. ;) I don't really care what you call us, as long as you understand us. ~spot From bpepple at fedoraproject.org Thu Mar 22 01:13:53 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 21 Mar 2007 21:13:53 -0400 Subject: Plan for tomorrows (20070322) FESCO meeting Message-ID: <1174526033.4165.3.camel@Chuck> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC (1:00 ET) in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- Core Package Review Process -- warren /topic FESCO-Meeting -- new sponsor nominations anyone? /topic FESCO-Meeting -- MISC -- cvs-import changes - c4chris /topic FESCO-Meeting -- MISC -- Extras 7 preparation - nirik? /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- EPEL -- dgilmore, thl /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu Mar 22 03:51:27 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Mar 2007 22:51:27 -0500 Subject: Summary of the 2007-03-20 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging meeting which occurred on 2007-03-20 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070320 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Codifying when it is safe for scriptlets to write to various directories: http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs * Prepping BuildRoot for %install: http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling If not already done as you read this, they should soon be written into the guidelines proper. Issues pending FESCO ratification: * Guidelines for using cmake (8 yea, 0 nay, 1 abstention): http://fedoraproject.org/wiki/PackagingDrafts/cmake Misc business: * Formal rejection of any guidelines requiring ipv6 support; the committee feels this is a policy issue. (7 yea, 0 nay). * Cleanups in progress over various wiki pages under the committee's purview, starting with http://fedoraproject.org/wiki/Packaging/Committee * More discussion of Ruby Gems: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems There's some question about whether Gems should be permitted at all in Fedora, and discussion is ongoing. The committee welcomes (and indeed requests) input from everyone on this matter. Please see the minutes and IRC log for complete information. - J< From bugs.michael at gmx.net Thu Mar 22 08:20:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Mar 2007 09:20:42 +0100 Subject: Plan for tomorrows (20070322) FESCO meeting In-Reply-To: <1174526033.4165.3.camel@Chuck> References: <1174526033.4165.3.camel@Chuck> Message-ID: <20070322092042.917f7f03.bugs.michael@gmx.net> On Wed, 21 Mar 2007 21:13:53 -0400, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > (1:00 ET) in #fedora-meeting on irc.freenode.org: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. Can FESCo or the FPC perhaps come up with an official policy on retired packages which have been published before for multiple releases of the dist, but which are not obsoleted in any new package? E.g. python-libtorrent as requested for removal here: http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests A possible solution is a mandatory entry in the release notes, in a section that explains how to remove orphans/leaf-packages manually. From a.badger at gmail.com Thu Mar 22 10:41:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 22 Mar 2007 03:41:00 -0700 Subject: Plan for tomorrows (20070322) FESCO meeting In-Reply-To: <1174526033.4165.3.camel@Chuck> References: <1174526033.4165.3.camel@Chuck> Message-ID: <1174560060.2352.7.camel@localhost.localdomain> On Wed, 2007-03-21 at 21:13 -0400, Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. I'd like a brief period to talk about the Package Database. The features that I've tagged as necessary for deployment should be done in two to four weeks. I can give a summary of what it does and then maybe some brief discussion about whether anyone has any misgivings about deploying before F7. (Not planning on any final decisions at this meeting... I also have to give an update to Infrastructure and see if they have any feedback as well.) Adding it as a full topic for next week's meeting would be appreciated as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu Mar 22 12:08:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 17:38:31 +0530 Subject: Role of SIG's In-Reply-To: <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> References: <460038A8.8010706@fedoraproject.org> <46004673.8040603@fedoraproject.org> <409676c70703210148i2212c217u9c8781bd2046719d@mail.gmail.com> Message-ID: <460271BF.3010507@fedoraproject.org> Trond Danielsen wrote: > 2007/3/20, Rahul Sundaram : >> >> Ok. I am moving all of the Extras SIG's to /SIGs hierarchy. > > Should the members of the various Extras SIGs move the pages from > /Extras/SIGs/my_sig to /SIGs/my_sig, or will that be taken care of? I have taken care of all that. The content still needs to be updated to remove references to core and extras and I need to fix the wiki categorization. If you want to do that go ahead or I will eventually get to doing them myself. Rahul From opensource at till.name Thu Mar 22 13:45:03 2007 From: opensource at till.name (Till Maas) Date: Thu, 22 Mar 2007 14:45:03 +0100 Subject: Supported Fedora versions Message-ID: <200703221445.27698.opensource@till.name> Hiyas, is there some page on the wiki where it is documented which Fedora version is actually supported and when the support ended. On http://fedoraproject.org/wiki/Releases/HistoricalSchedules I only find the dates until the release, but e.g. not when FC3 was transfered to legacy or when legacy was closed. Also is there any official documentation of how long FC5 and FC6 will be supported. The last documentation of how long FC5 was supported was changed to how long FC7 will be supported: http://fedoraproject.org/wiki/LifeCycle?action=diff&rev2=16&rev1=15 Also, is there an easy way to get from http://fedoraproject.org/wiki/de_DE/FedoraHaupt to http://fedoraproject.org/wiki/FedoraMain without having to change ones default language in the preferences (which takes ages :-((() Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Thu Mar 22 14:23:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 Mar 2007 10:23:18 -0400 Subject: Plan for tomorrows (20070322) FESCO meeting In-Reply-To: <1174560060.2352.7.camel@localhost.localdomain> References: <1174526033.4165.3.camel@Chuck> <1174560060.2352.7.camel@localhost.localdomain> Message-ID: <1174573398.5961.3.camel@lincoln> On Thu, 2007-03-22 at 03:41 -0700, Toshio Kuratomi wrote: > > I'd like a brief period to talk about the Package Database. The > features that I've tagged as necessary for deployment should be done in > two to four weeks. I can give a summary of what it does and then maybe > some brief discussion about whether anyone has any misgivings about > deploying before F7. (Not planning on any final decisions at this > meeting... I also have to give an update to Infrastructure and see if > they have any feedback as well.) > > Adding it as a full topic for next week's meeting would be appreciated > as well. No problem. I'll add it to the agenda. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Thu Mar 22 14:37:23 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 Mar 2007 10:37:23 -0400 Subject: Plan for tomorrows (20070322) FESCO meeting In-Reply-To: <20070322092042.917f7f03.bugs.michael@gmx.net> References: <1174526033.4165.3.camel@Chuck> <20070322092042.917f7f03.bugs.michael@gmx.net> Message-ID: <1174574243.5961.5.camel@lincoln> On Thu, 2007-03-22 at 09:20 +0100, Michael Schwendt wrote: > Can FESCo or the FPC perhaps come up with an official policy on retired > packages which have been published before for multiple releases of the > dist, but which are not obsoleted in any new package? > > E.g. python-libtorrent as requested for removal here: > http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests > > A possible solution is a mandatory entry in the release notes, in a > section that explains how to remove orphans/leaf-packages manually. I've added this to today's agenda. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Thu Mar 22 20:05:20 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 22 Mar 2007 21:05:20 +0100 Subject: FE Package Status of Mar 22, 2007 Message-ID: <20070322210520.0324b8ad@ludwig-alpha.unil.ch> Hi folks, New update... Cheers, C ==== FE Package Status of Mar 22, 2007 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 3067 packages - 4597 binary rpms in devel - 99 orphans - 33 packages not available in devel or release aalam at redhat dot com aspell-hi allisson at gmail dot com multiget andreas at bawue dot net perl-XML-Filter-BufferText andreas at bawue dot net perl-Class-Observable andreas at bawue dot net ddrescue andreas at bawue dot net perl-XML-SAX-Writer bdpepple at ameritech dot net galago-filesystem bjohnson at symetrix dot com gscan2pdf cweyl at alumni dot drew dot edu perl-Net-CUPS dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask devrim at CommandPrompt dot com postgresql-dbi-link gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils guillaume dot thouvenin at bull dot net elsa j dot w dot r dot degoede at hhs dot nl SDLmm jhrozek at redhat dot com dwdiff jkeating at redhat dot com koji jspaleta at gmail dot com telescope-server limb at jcomserv dot net vym mcepl at redhat dot com gstreamer-plugins-pulseaudio otaylor at redhat dot com mugshot overholt at redhat dot com jython paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman peter at thecodergeek dot com blam pmachata at redhat dot com compat-flex rnorwood at redhat dot com perl-RPM2 tcallawa at redhat dot com SimGear vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp - 5 packages not available in devel but present in release andreas dot bierfert at lowlatency dot de sylpheed-claws-plugins andreas dot bierfert at lowlatency dot de sylpheed-claws jmp at safe dot ca clement lmacken at redhat dot com python-TurboMail lxtnow at gmail dot com specto - 7 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=212003,231303 mugshot otaylor at redhat.com xmlunit pcheung at redhat.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,227091,231828,231861,232548 dkms Matt_Domsch at dell.com objectweb-anttask rafaels at redhat.com bitbake trond.danielsen at gmail.com cyrus-imapd tjanouse at redhat.com gnome-yum allisson at gmail.com - 2 packages present in the development repo which have no owners entry gstreamer-plugins-pulse ws-commons-util - 2 orphaned packages, yet available in extras devel luks-tools udftools - 44 packages that moved to core FE-ACCEPT packages stats: - 2103 accepted, closed package reviews - 27 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 58 accepted, open package reviews older than 4 weeks; - 117 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 237 open tickets - 21 tickets with no activity in eight weeks - 74 tickets with no activity in four weeks - 7 closed tickets FE-NEW packages stats: - 1117 open tickets - 67 tickets with no activity in eight weeks - 855 tickets with no activity in four weeks - 31 closed tickets FE-NEEDSPONSOR packages stats: - 46 open tickets - 17 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets - 1 tickets with no activity in four weeks FE-GUIDELINES packages stats: - open tickets OPEN-BUGS packages stats: - 219 open tickets - 106 tickets with no activity in eight weeks - 68 tickets with no activity in four weeks CVS stats: - 3068 packages with a devel directory - 6 packages with no owners entry gstreamer-plugins-pulse isorelax-0-0.1.release20050331.1jpp.1.src.rpm postgis qpidpy qpidrb tdma - 3 packages in CVS devel *and* Core java-1.5.0-gcj libnl sinjdoc - 194 packages were dropped from extras Maintainers stats: - 282 maintainers - 9 inactive maintainers with open bugs - 40 inactive maintainers Dropped FC packages: - 296 packages were dropped from core since FC 1 Comps.xml files stats: - 1043 packages in comps-fe7 file - 1111 packages missing from comps-fe7 file - 11 packages in comps-fe7 but not in repo - 953 packages in comps-fe6 file - 601 packages missing from comps-fe6 file - 4 packages in comps-fe6 but not in repo From bugs.michael at gmx.net Thu Mar 22 21:15:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Mar 2007 22:15:14 +0100 Subject: Paul F. Johnson In-Reply-To: References: <20070313080137.a5154000.bugs.michael@gmx.net> <13dbfe4f0703181111x70555cafk29165935c3ed636b@mail.gmail.com> Message-ID: <20070322221514.01cd3cd9.bugs.michael@gmx.net> On Sun, 18 Mar 2007 19:20:29 +0100, Gianluca Sforna wrote: > On 3/18/07, Chitlesh GOORAH wrote: > > On 3/13/07, Michael Schwendt wrote: > > > Trying to get another reply from "Paul F. Johnson" in bugzilla has failed > > > since 2007-02-16, 2007-02-26, and 2007-03-02: > > > > Is Paul F. Johnson still around ? > > > > He was supposed to review one of my packages :P > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221027 > > > > Seems he posted today on fedora-extras (though it passed some time > since his last post...) As a final follow-up here from my side, I've fixed the bugs in gdeskcal myself. If the extras cvs syncmail feature works as expected (I know it does for other package owners), Paul should have received and seen the commit mail. Bugzilla ticket and a last privately forwarded comment remain unanswered. From wolters.liste at gmx.net Thu Mar 22 22:39:15 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Thu, 22 Mar 2007 23:39:15 +0100 Subject: Offline for several weeks Message-ID: <200703222339.20419.wolters.liste@gmx.net> Hi, I will be offline for quite some weeks - starting mid next week, ending around the 20th of April. There are three packages I currently maintain: * speedcrunch * ktorrent * rsibreak Managing the packages should be easy - just subscribe to the related entries at kde-apps.org and update the specs if there is an update. Is there someone willing to maintain these packages while I'm away? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Mar 23 00:34:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Mar 2007 20:34:02 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-22 Message-ID: <20070323003402.58EF6152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: ettercap FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) xmoto-edit FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) ettercap: limb AT jcomserv.net FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmoto-edit: limb AT jcomserv.net FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From peter at thecodergeek.com Fri Mar 23 06:09:03 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 22 Mar 2007 23:09:03 -0700 Subject: Plan for tomorrows (20070322) FESCO meeting In-Reply-To: <20070322092042.917f7f03.bugs.michael@gmx.net> References: <1174526033.4165.3.camel@Chuck> <20070322092042.917f7f03.bugs.michael@gmx.net> Message-ID: <1174630143.9528.5.camel@tuxhugs> On Thu, 2007-03-22 at 09:20 +0100, Michael Schwendt wrote: > Can FESCo or the FPC perhaps come up with an official policy on retired > packages which have been published before for multiple releases of the > dist, but which are not obsoleted in any new package? > > E.g. python-libtorrent as requested for removal here: > http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests > Sorry about that one; The Deluge developers stopped maintaining their external python bindings and integrated the functionality into upstream releases (thereby precluding the need for the external library, and in fact dropping support/maintenance for that library entirely...) Unfortunately, I'm hesitant to make Deluge obsolete it through RPM's Obsoletes/Provides functionality because the next release of rb_libtorrent is supposed to be buildable with Python bindings, which my intent is to properly Provides/Obsoletes the one by the Deluge devs. (I'm talking to the upstream rb_libtorrent devs about this via IRC.) I was hoping to get this resolved a bit quicker, but "ces't la vie" as the saying goes... :| > A possible solution is a mandatory entry in the release notes, in a > section that explains how to remove orphans/leaf-packages manually. package-cleanup (part of the yum-utils package) is very useful for this. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri Mar 23 10:23:34 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 11:23:34 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323003402.58EF6152130@buildsys.fedoraproject.org> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> Message-ID: <20070323112334.b4ea7e5d.bugs.michael@gmx.net> On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > limb AT jcomserv.net: > ettercap > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > gnubg > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > xmoto-edit > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > miker5slow AT grandecom.net: > etherape > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) The issues with "ettercap", "xmoto-edit" and "etherape" are one of the infamous problems when adding a %dist tag. In RPM Version Comparison, numbers are higher than letters. When comparing different packages with eachother, the %dist tag must be at the same position in the %release tag for all package releases, so the dist value is only compared with other dist values. etherape 4.1.fc5 > 4.fc6 because 4 = 4 but 1 > fc6 xmoto-edit 6.1.fc5 > 6.fc6 because 6 = 6 but 1 > fc6 ettercap 13.3.fc5 > 12.fc6 would need a bump to 14.fc6, since: 13.3.fc5 > 13.fc6 because 13 = 13 but 3 > fc6 You can verify your versions with fedora-rpmvercmp when you are unsure: $ rpm -qf $(which fedora-rpmvercmp) rpmdevtools-5.3-1.fc6 $ fedora-rpmvercmp Epoch1 :0 Version1 :1 Release1 :13.3.fc5 Epoch2 :0 Version2 :1 Release2 :13.fc6 0:1-13.3.fc5 is newer $ fedora-rpmvercmp 0 1 4.1.fc5 0 1 4.fc6 0:1-4.1.fc5 is newer $ fedora-rpmvercmp 0 1 4.fc5.1 0 1 4.fc6 0:1-4.fc6 is newer From wolfy at nobugconsulting.ro Fri Mar 23 10:43:28 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 23 Mar 2007 12:43:28 +0200 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323112334.b4ea7e5d.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> Message-ID: <4603AF50.4030102@nobugconsulting.ro> Michael Schwendt wrote: > > ettercap > 13.3.fc5 > 12.fc6 would need a bump to 14.fc6, since: > 13.3.fc5 > 13.fc6 because 13 = 13 but 3 > fc6 > > Will be bumped soon, Jon (the maintainer) has identified an error in the spec and we are working on a newer version. From tjanouse at redhat.com Fri Mar 23 12:02:10 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 23 Mar 2007 13:02:10 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323112334.b4ea7e5d.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> Message-ID: <20070323120210.GA15616@redhat.com> On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > In RPM Version Comparison, numbers are higher than letters. When comparing > different packages with eachother, the %dist tag must be at the same > position in the %release tag for all package releases, so the dist value > is only compared with other dist values. > > etherape > 4.1.fc5 > 4.fc6 because 4 = 4 but 1 > fc6 Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. -- TJ. (Brno, CZ), BaseOS, Red Hat From limb at jcomserv.net Fri Mar 23 12:03:22 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 23 Mar 2007 07:03:22 -0500 (CDT) Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <4603AF50.4030102@nobugconsulting.ro> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <4603AF50.4030102@nobugconsulting.ro> Message-ID: <20520.65.192.24.190.1174651402.squirrel@mail.jcomserv.net> Is it worth a rebuild to fix the others, or wait for a new release? > Michael Schwendt wrote: >> >> ettercap >> 13.3.fc5 > 12.fc6 would need a bump to 14.fc6, since: >> 13.3.fc5 > 13.fc6 because 13 = 13 but 3 > fc6 >> >> > Will be bumped soon, Jon (the maintainer) has identified an error in the > spec and we are working on a newer version. > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From bugs.michael at gmx.net Fri Mar 23 12:52:04 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 13:52:04 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323134957.d154f443.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> Message-ID: <20070323135204.41ae51f0.bugs.michael@gmx.net> On Fri, 23 Mar 2007 13:49:57 +0100, Michael Schwendt wrote: > On Fri, 23 Mar 2007 13:02:10 +0100, Tomas Janousek wrote: > > > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > > In RPM Version Comparison, numbers are higher than letters. When comparing > > > different packages with eachother, the %dist tag must be at the same > > > position in the %release tag for all package releases, so the dist value > > > is only compared with other dist values. > > > > > > etherape > > > 4.1.fc5 > 4.fc6 because 4 = 4 but 1 > fc6 > > > > Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. > > But you do understand that this makes the fc5 package newer than > the packages for fc6 and fc7? And btw, it is compared like this: 4.1 > 4.fc6 Not: 4.1 > 4 From bugs.michael at gmx.net Fri Mar 23 12:49:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 13:49:57 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323120210.GA15616@redhat.com> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> Message-ID: <20070323134957.d154f443.bugs.michael@gmx.net> On Fri, 23 Mar 2007 13:02:10 +0100, Tomas Janousek wrote: > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > In RPM Version Comparison, numbers are higher than letters. When comparing > > different packages with eachother, the %dist tag must be at the same > > position in the %release tag for all package releases, so the dist value > > is only compared with other dist values. > > > > etherape > > 4.1.fc5 > 4.fc6 because 4 = 4 but 1 > fc6 > > Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. But you do understand that this makes the fc5 package newer than the packages for fc6 and fc7? From tjanouse at redhat.com Fri Mar 23 13:05:33 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 23 Mar 2007 14:05:33 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323135204.41ae51f0.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> <20070323135204.41ae51f0.bugs.michael@gmx.net> Message-ID: <20070323130533.GA640@redhat.com> Hi, > > On Fri, 23 Mar 2007 13:02:10 +0100, Tomas Janousek wrote: > > > Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. On Fri, Mar 23, 2007 at 01:52:04PM +0100, Michael Schwendt wrote: > > But you do understand that this makes the fc5 package newer than > > the packages for fc6 and fc7? Yes, I do. I don't say it was ok this case (something like [1] should have been used), I'm arguing your statements about version comparing. [1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-378ec5e6a73d5425d55c115ff5d0fa5f5094dcba > And btw, it is compared like this: > > 4.1 > 4.fc6 > > Not: > > 4.1 > 4 And what difference does it make? I don't think your statement about the position of the dist tag is true. Since 4.1 and 4.fc6 are compared the same as 4.1 and 4, it's ok. It's common practice to add minor release numbers for spec changes etc. as long as one is sure it won't break the order of versions. -- TJ. (Brno, CZ), BaseOS, Red Hat From jkeating at redhat.com Fri Mar 23 14:05:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Mar 2007 10:05:28 -0400 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323130533.GA640@redhat.com> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323135204.41ae51f0.bugs.michael@gmx.net> <20070323130533.GA640@redhat.com> Message-ID: <200703231005.33311.jkeating@redhat.com> On Friday 23 March 2007 09:05:33 Tomas Janousek wrote: > And what difference does it make? I don't think your statement about the > position of the dist tag is true. Since 4.1 and 4.fc6 are compared the same > as 4.1 and 4, it's ok. It's common practice to add minor release numbers > for spec changes etc. as long as one is sure it won't break the order of > versions. Yes, but when the same version is shipped on multiple branches, you have to add your minor version bump after the dist-tag, not before it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wolfy at nobugconsulting.ro Fri Mar 23 14:06:47 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 23 Mar 2007 16:06:47 +0200 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323130533.GA640@redhat.com> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> <20070323135204.41ae51f0.bugs.michael@gmx.net> <20070323130533.GA640@redhat.com> Message-ID: <4603DEF7.5040206@nobugconsulting.ro> Tomas Janousek wrote: > Hi, > > >>> On Fri, 23 Mar 2007 13:02:10 +0100, Tomas Janousek wrote: >>> >>>> Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. >>>> > > On Fri, Mar 23, 2007 at 01:52:04PM +0100, Michael Schwendt wrote: > >>> But you do understand that this makes the fc5 package newer than >>> the packages for fc6 and fc7? >>> > > Yes, I do. I don't say it was ok this case (something like [1] should have > been used), I'm arguing your statements about version comparing. > > [1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-378ec5e6a73d5425d55c115ff5d0fa5f5094dcba > > >> And btw, it is compared like this: >> >> 4.1 > 4.fc6 >> >> Not: >> >> 4.1 > 4 >> > > And what difference does it make? I don't think your statement about the > position of the dist tag is true. Since 4.1 and 4.fc6 are compared the same as > 4.1 and 4, it's ok. It's common practice to add minor release numbers for spec > changes etc. as long as one is sure it won't break the order of versions. > What Michael tries to explain is that it's also needed to ensure that fc7 versions are "newer" then fc6 who should be "newer" then fc5 versions. So the 4.1.fc5 should have been 4.fc5.1 in order to keep it "older" then 4.fc6 From bugs.michael at gmx.net Fri Mar 23 13:46:21 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 14:46:21 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323130533.GA640@redhat.com> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> <20070323135204.41ae51f0.bugs.michael@gmx.net> <20070323130533.GA640@redhat.com> Message-ID: <20070323144621.6b80ad8c.bugs.michael@gmx.net> On Fri, 23 Mar 2007 14:05:33 +0100, Tomas Janousek wrote: > Hi, > > > > On Fri, 23 Mar 2007 13:02:10 +0100, Tomas Janousek wrote: > > > > Sounds pretty logical, 4.1 > 4. No need to care about dist tags at all, imho. > > On Fri, Mar 23, 2007 at 01:52:04PM +0100, Michael Schwendt wrote: > > > But you do understand that this makes the fc5 package newer than > > > the packages for fc6 and fc7? > > Yes, I do. I don't say it was ok this case (something like [1] should have > been used), I'm arguing your statements about version comparing. > > [1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-378ec5e6a73d5425d55c115ff5d0fa5f5094dcba > > > And btw, it is compared like this: > > > > 4.1 > 4.fc6 > > > > Not: > > > > 4.1 > 4 > > And what difference does it make? I don't think your statement about the > position of the dist tag is true. Since 4.1 and 4.fc6 are compared the same as > 4.1 and 4, it's ok. You compare a dist tag with a minor release number, which breaks the entire scheme. RPM doesn't see any decimal point. It compares 4 with 4 and 1 with fc6. Same applies to 4.0 > 4.fc6 4.0 > 4.Gold 4.0 > 4.a What is the relationship between minor release 0 and "fc6", "Gold", "a"? > It's common practice to add minor release numbers for spec > changes Sure. > etc. as long as one is sure it won't break the order of versions. *cough* :) From tjanouse at redhat.com Fri Mar 23 14:32:38 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 23 Mar 2007 15:32:38 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323144621.6b80ad8c.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> <20070323135204.41ae51f0.bugs.michael@gmx.net> <20070323130533.GA640@redhat.com> <20070323144621.6b80ad8c.bugs.michael@gmx.net> Message-ID: <20070323143238.GA444@redhat.com> Hi, On Fri, Mar 23, 2007 at 02:46:21PM +0100, Michael Schwendt wrote: > You compare a dist tag with a minor release number, which breaks the > entire scheme. RPM doesn't see any decimal point. It compares 4 with > 4 and 1 with fc6. Same applies to What scheme does it break? > 4.0 > 4.fc6 > 4.0 > 4.Gold > 4.0 > 4.a 4.0 > 4. That's all, it works. If I said "first compare the numbers, than the crap after them", it'd be true in these cases, even if that's not the way it's done internally. Seems like I really don't see your point. -- TJ. (Brno, CZ), BaseOS, Red Hat From bugs.michael at gmx.net Fri Mar 23 16:52:31 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 17:52:31 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323143238.GA444@redhat.com> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323120210.GA15616@redhat.com> <20070323134957.d154f443.bugs.michael@gmx.net> <20070323135204.41ae51f0.bugs.michael@gmx.net> <20070323130533.GA640@redhat.com> <20070323144621.6b80ad8c.bugs.michael@gmx.net> <20070323143238.GA444@redhat.com> Message-ID: <20070323175231.9da30dd2.bugs.michael@gmx.net> On Fri, 23 Mar 2007 15:32:38 +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 23, 2007 at 02:46:21PM +0100, Michael Schwendt wrote: > > You compare a dist tag with a minor release number, which breaks the > > entire scheme. RPM doesn't see any decimal point. It compares 4 with > > 4 and 1 with fc6. Same applies to > > What scheme does it break? The goal of the %dist tag. Using a %dist tag forces you into a specific versioning scheme that doesn't violate the upgrade path between dists. On one hand, you acknowledge that. On the other hand, you advocate your own incompatible versioning scheme. > > 4.0 > 4.fc6 > > 4.0 > 4.Gold > > 4.0 > 4.a > > 4.0 > 4. That's all, it works. If I said "first compare the numbers, 4.0 > 4 is string comparison, not comparison of numbers. > than the > crap after them", it'd be true in these cases, even if that's not the way it's > done internally. > > Seems like I really don't see your point. Then we share something, since I don't see any point in your destructive replies at all. I'm starting to regret that I've posted the original message to this list. From wtogami at redhat.com Fri Mar 23 18:05:39 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Mar 2007 14:05:39 -0400 Subject: FAS names in pkg.acl (Merge Blocker) Message-ID: <460416F3.7010801@redhat.com> Prior to the merge, owners.list will be managed by PackageDB and tracked in a database. We should change the CVS so pkg.acl contains FAS usernames instead of Bugzilla names. The combination of these changes should simplify and make it less confusing for the package maintainers. Blockers? - The ACL scripts currently have a one-off hack, mapping Bugzilla names to FAS names in cases where the e-mail addresses do not match. We would need to reverse this lookup. - (anything else? I can't remember if there were other issues.) Warren Togami wtogami at redhat.com From Axel.Thimm at ATrpms.net Fri Mar 23 18:22:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 19:22:15 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323112334.b4ea7e5d.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> Message-ID: <20070323182215.GA14988@neu.nirvana> On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > > > limb AT jcomserv.net: > > ettercap > > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > > > gnubg > > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > > > xmoto-edit > > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > > > miker5slow AT grandecom.net: > > etherape > > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) > > The issues with "ettercap", "xmoto-edit" and "etherape" are one of the > infamous problems when adding a %dist tag. Ehem. All of the above have the same inequality relation if you drop the disttag ... The disttag is not supposed to override the release tag (or the first part of it until the disttag), it is supposed to trigger as a tie break only when the rest is equal. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From limb at jcomserv.net Fri Mar 23 18:31:36 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 23 Mar 2007 13:31:36 -0500 (CDT) Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323182215.GA14988@neu.nirvana> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323182215.GA14988@neu.nirvana> Message-ID: <59845.65.192.24.190.1174674696.squirrel@mail.jcomserv.net> I've just updated ettercap and xmoto-edit to correct this. gnubg will be rebuilt once this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233143 gnuplot blocker bug is resolved, allowing it to build. > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: >> On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: >> >> > limb AT jcomserv.net: >> > ettercap >> > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) >> > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) >> > >> > gnubg >> > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) >> > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) >> > >> > xmoto-edit >> > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) >> > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) >> > >> > miker5slow AT grandecom.net: >> > etherape >> > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) >> > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) >> >> The issues with "ettercap", "xmoto-edit" and "etherape" are one of the >> infamous problems when adding a %dist tag. > > Ehem. All of the above have the same inequality relation if you drop > the disttag ... > > The disttag is not supposed to override the release tag (or the first > part of it until the disttag), it is supposed to trigger as a tie > break only when the rest is equal. > -- > Axel.Thimm at ATrpms.net > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From bugs.michael at gmx.net Fri Mar 23 18:40:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 19:40:51 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323182215.GA14988@neu.nirvana> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323182215.GA14988@neu.nirvana> Message-ID: <20070323194051.eb3beed7.bugs.michael@gmx.net> On Fri, 23 Mar 2007 19:22:15 +0100, Axel Thimm wrote: > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > > > > > limb AT jcomserv.net: > > > ettercap > > > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > > > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > > > > > gnubg > > > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > > > > > xmoto-edit > > > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > > > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > > > > > miker5slow AT grandecom.net: > > > etherape > > > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > > > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) > > > > The issues with "ettercap", "xmoto-edit" and "etherape" are one of the > > infamous problems when adding a %dist tag. > > Ehem. All of the above have the same inequality relation if you drop > the disttag ... Impossible, because then you cannot tag and build the packages in the way they have been built above. Only due to the added %disttag, it was possible to keep the rest of %release equal across multiple branches. From Axel.Thimm at ATrpms.net Fri Mar 23 18:59:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 19:59:32 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323194051.eb3beed7.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323182215.GA14988@neu.nirvana> <20070323194051.eb3beed7.bugs.michael@gmx.net> Message-ID: <20070323185932.GB14988@neu.nirvana> On Fri, Mar 23, 2007 at 07:40:51PM +0100, Michael Schwendt wrote: > On Fri, 23 Mar 2007 19:22:15 +0100, Axel Thimm wrote: > > > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > > On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > > > > > > > limb AT jcomserv.net: > > > > ettercap > > > > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > > > > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > > > > > > > gnubg > > > > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > > > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > > > > > > > xmoto-edit > > > > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > > > > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > > > > > > > miker5slow AT grandecom.net: > > > > etherape > > > > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > > > > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) > > > > > > The issues with "ettercap", "xmoto-edit" and "etherape" are one of the > > > infamous problems when adding a %dist tag. > > > > Ehem. All of the above have the same inequality relation if you drop > > the disttag ... > > Impossible, because then you cannot tag and build the packages in the way > they have been built above. Only due to the added %disttag, it was > possible to keep the rest of %release equal across multiple branches. You're setting 13.3 and 12 as well as 4.1 and 4 to be equal. OK, that must count as cheating at the very least. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Mar 23 19:06:21 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 23 Mar 2007 12:06:21 -0700 Subject: FAS names in pkg.acl (Merge Blocker) In-Reply-To: <460416F3.7010801@redhat.com> References: <460416F3.7010801@redhat.com> Message-ID: <1174676781.8986.16.camel@localhost.localdomain> On Fri, 2007-03-23 at 14:05 -0400, Warren Togami wrote: > Prior to the merge, owners.list will be managed by PackageDB and tracked > in a database. We should change the CVS so pkg.acl contains FAS > usernames instead of Bugzilla names. The combination of these changes > should simplify and make it less confusing for the package maintainers. > > Blockers? > - The ACL scripts currently have a one-off hack, mapping Bugzilla names > to FAS names in cases where the e-mail addresses do not match. We would > need to reverse this lookup. > - (anything else? I can't remember if there were other issues.) The PackageDB should replace pkg.acl files as well as owners.list. If the current interface[1]_ is missing some features that are present in pkg.acl or owners.list, let me know so I can expose them. [1]_: To try out the interface, follow these steps:: 1) Go to https://admin.fedoraproject.org/pkgdb/test/orphans 2) Click on one of these orphaned packages. 3) Login using the link in the upper right corner. The login information is your Fedora Account System user-pass. 4) If you are in the "cvsextras" group (have commit access to the "Extras" cvs repository) you should now be able to take ownership of the package, change the acls on ho can commit, get bug reports, etc. 5) If you are not in cvsextras, you should still be able to add yourself to a package and request that someone approve you for watching commit logs, bugzilla, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri Mar 23 19:26:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Mar 2007 20:26:09 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323185932.GB14988@neu.nirvana> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323182215.GA14988@neu.nirvana> <20070323194051.eb3beed7.bugs.michael@gmx.net> <20070323185932.GB14988@neu.nirvana> Message-ID: <20070323202609.e7a83a06.bugs.michael@gmx.net> On Fri, 23 Mar 2007 19:59:32 +0100, Axel Thimm wrote: > On Fri, Mar 23, 2007 at 07:40:51PM +0100, Michael Schwendt wrote: > > On Fri, 23 Mar 2007 19:22:15 +0100, Axel Thimm wrote: > > > > > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > > > On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > > > > > > > > > limb AT jcomserv.net: > > > > > ettercap > > > > > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > > > > > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > > > > > > > > > gnubg > > > > > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > > > > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > > > > > > > > > xmoto-edit > > > > > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > > > > > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > > > > > > > > > miker5slow AT grandecom.net: > > > > > etherape > > > > > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > > > > > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) > > > > > > > > The issues with "ettercap", "xmoto-edit" and "etherape" are one of the > > > > infamous problems when adding a %dist tag. > > > > > > Ehem. All of the above have the same inequality relation if you drop > > > the disttag ... > > > > Impossible, because then you cannot tag and build the packages in the way > > they have been built above. Only due to the added %disttag, it was > > possible to keep the rest of %release equal across multiple branches. > > You're setting 13.3 and 12 as well as 4.1 and 4 to be equal. OK, that > must count as cheating at the very least. ;) Haha, almost funny. So, you've taken the bait and continued with your very own way of thinking. What do you want to prove this time? ;) That Joe Packager can do the following? FE5 > FE7 (0:0.7.3-100 > 0:0.7.3-12) Yes, look closely. In a no-dist-tag scheme, packager can break versioning and upgrade paths in various ways just as when using dist tags. What is the point? Aiming at creating an endless thread once more? The key difference is, that _normally_ without a dist tag the packager is fully responsible for keeping release of the latest branch higher than for old branches. Once that is achieved, e.g. FE5 < FE7 (0:0.7.3-5 < 0:0.7.3-7) the packager can apply minor release bumps without any risk of breaking the upgrade path and without comparing release digits and dist tags: FE5 < FE7 (0:0.7.3-5.1 < 0:0.7.3-7) FE5 < FE7 (0:0.7.3-5.2 < 0:0.7.3-7) ... FE5 < FE7 (0:0.7.3-5.20 < 0:0.7.3-7) In my original post I didn't argue that a careful packager can't keep the upgrade path sane when using a dist tag, e.g. by adding something at the very right of %release. I pointed out a common mistake that is being done when using dist tags. It's just a bigger pitfall, because the visible part of %release is _equal_ for multiple branches. And please, don't point out that the guidelines cover minor release bumps with dist tags. That has been done before. This will be my last reply in this thread. From a.badger at gmail.com Fri Mar 23 20:27:07 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 23 Mar 2007 13:27:07 -0700 Subject: Packagedb Prototype 0.2.90.1 Message-ID: <1174681628.8986.38.camel@localhost.localdomain> Hi guys, As talked about in yesterday's FESCo meeting, the current prototype for the packagedb is available at https://admin.fedoraproject.org/pkgdb. The GUI to db connection is complete. I still have a little work to finish off email notifications to owners of a package when the ACLs are updated. (The changes are currently logged in the db and can send to a fedora-extras-commits style mailing list. I just need to add the logic that grabs the owner's email address to send to as well.) Here's the easiest way to try the interface out:: 1) Go to https://admin.fedoraproject.org/pkgdb/test/orphans 2) Click on one of these orphaned packages. 3) Login using the link in the upper right corner. The login information is your Fedora Account System user-pass. 4) If you are in the "cvsextras" group (have commit access to the "Extras" cvs repository) you should now be able to take ownership of the package, change the acls on who can commit, get bug reports, etc. 5) If you are not in cvsextras, you should still be able to add yourself to a package and request that someone approve you for watching commit logs, bugzilla, etc. Feel free to test this stuff out: we'll be resyncing the information in the database against what's in owners.list, pkg.acl files, and the cvs repository before we go live. Bill, I know you had a concern about orphaned packages being kept long term. I'd like to leave that as policy in the short term and address it technically after F7 by preventing builds for orphaned packages. Preventing builds is currently something we'd have to do from within koji but we'll be integrating the packagedb and koji for F8 so that's a prime time to work on it. Does that sound okay for you? PS. The packagedb now takes URLs of the form. https://admin.fedoraproject.org/pkgdb/packages/name/abiword If someone wants to code a short bit of html+javascript that lets the enduser enter a packagename and jump to the package's page, I'll add it to the sidebar for navigation. PPS. I know that navigating the packagelists using numbered pages rather than alphabetically indexed pages still sucks. If someone wants to fix that before I can get to it (probably post-F7), let me know. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Mar 23 21:12:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 22:12:49 +0100 Subject: Package EVR problems in FC+FE 2007-03-22 In-Reply-To: <20070323202609.e7a83a06.bugs.michael@gmx.net> References: <20070323003402.58EF6152130@buildsys.fedoraproject.org> <20070323112334.b4ea7e5d.bugs.michael@gmx.net> <20070323182215.GA14988@neu.nirvana> <20070323194051.eb3beed7.bugs.michael@gmx.net> <20070323185932.GB14988@neu.nirvana> <20070323202609.e7a83a06.bugs.michael@gmx.net> Message-ID: <20070323211249.GC14988@neu.nirvana> On Fri, Mar 23, 2007 at 08:26:09PM +0100, Michael Schwendt wrote: > On Fri, 23 Mar 2007 19:59:32 +0100, Axel Thimm wrote: > > > On Fri, Mar 23, 2007 at 07:40:51PM +0100, Michael Schwendt wrote: > > > On Fri, 23 Mar 2007 19:22:15 +0100, Axel Thimm wrote: > > > > > > > On Fri, Mar 23, 2007 at 11:23:34AM +0100, Michael Schwendt wrote: > > > > > On Thu, 22 Mar 2007 20:34:02 -0400 (EDT), buildsys wrote: > > > > > > > > > > > limb AT jcomserv.net: > > > > > > ettercap > > > > > > FE5 > FE6 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc6) > > > > > > FE5 > FE7 (0:0.7.3-13.3.fc5 > 0:0.7.3-12.fc7) > > > > > > > > > > > > gnubg > > > > > > FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) > > > > > > FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) > > > > > > > > > > > > xmoto-edit > > > > > > FE5 > FE6 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc6) > > > > > > FE5 > FE7 (0:0.2.4-6.1.fc5 > 0:0.2.4-6.fc7) > > > > > > > > > > > > miker5slow AT grandecom.net: > > > > > > etherape > > > > > > FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) > > > > > > FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) > > > > > > > > > > The issues with "ettercap", "xmoto-edit" and "etherape" are one of the > > > > > infamous problems when adding a %dist tag. > > > > > > > > Ehem. All of the above have the same inequality relation if you drop > > > > the disttag ... > > > > > > Impossible, because then you cannot tag and build the packages in the way > > > they have been built above. Only due to the added %disttag, it was > > > possible to keep the rest of %release equal across multiple branches. > > > > You're setting 13.3 and 12 as well as 4.1 and 4 to be equal. OK, that > > must count as cheating at the very least. ;) > > Haha, almost funny. > > So, you've taken the bait and continued with your very own way of > thinking. What do you want to prove this time? ;) Me, nothing. You're the one doing advanced mathematics no one can catch up with. > That Joe Packager can do the following? > > FE5 > FE7 (0:0.7.3-100 > 0:0.7.3-12) > > Yes, look closely. In a no-dist-tag scheme, packager can break versioning > and upgrade paths in various ways just as when using dist tags. What is > the point? Aiming at creating an endless thread once more? Sorry, you did post something controversial waiting for a reply, what exactly do you expect from the rest of the world, to remain saddened in silence? > The key difference is, that _normally_ without a dist tag the packager is > fully responsible for keeping release of the latest branch higher than for > old branches. So, let me understand, we have a fully manual way to manage upgrade paths, which is as error-prone as the packager's brain can be, or a half-automatic way that solves 90% of the problem. And your conclusion is: If we don't solve 100% of the problem let's drop to 0%. > This will be my last reply in this thread. So say we all. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Mar 23 23:02:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 23 Mar 2007 19:02:21 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-23 Message-ID: <20070323230221.284FE152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) gpm FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) tscherf AT redhat.com: Democracy FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) Democracy: tscherf AT redhat.com FE6 > FE7 (0:0.9.5.1-5.fc6 > 0:0.9.5.1-4.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) gpm: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) tzdata: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From buildsys at fedoraproject.org Sun Mar 25 16:04:44 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 25 Mar 2007 12:04:44 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-25 Message-ID: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) gpm FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) gpm: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) tzdata: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From tjanouse at redhat.com Sun Mar 25 18:43:23 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sun, 25 Mar 2007 20:43:23 +0200 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> Message-ID: <20070325184323.GA26025@redhat.com> Hi, On Sun, Mar 25, 2007 at 12:04:44PM -0400, buildsys at fedoraproject.org wrote: > gpm > FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) > FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) The fc7 package was successfully built in brew a few minutes before the fc5 and 6 ones. Anyone has an idea why it wasn't pushed yet? -- TJ. (Brno, CZ), BaseOS, Red Hat From tgl at redhat.com Sun Mar 25 19:50:51 2007 From: tgl at redhat.com (Tom Lane) Date: Sun, 25 Mar 2007 15:50:51 -0400 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <20070325184323.GA26025@redhat.com> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> <20070325184323.GA26025@redhat.com> Message-ID: <10180.1174852251@sss.pgh.pa.us> Tomas Janousek writes: > The fc7 package was successfully built in brew a few minutes before the fc5 > and 6 ones. Anyone has an idea why it wasn't pushed yet? I believe the F7 compose is still frozen for test3. If you need your update to appear in test3 rather than test4, you'll need to convince releng of that (it may well be too late by now anyway). regards, tom lane From tjanouse at redhat.com Sun Mar 25 20:08:55 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sun, 25 Mar 2007 22:08:55 +0200 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <10180.1174852251@sss.pgh.pa.us> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> <20070325184323.GA26025@redhat.com> <10180.1174852251@sss.pgh.pa.us> Message-ID: <20070325200855.GA30946@redhat.com> Hi, On Sun, Mar 25, 2007 at 03:50:51PM -0400, Tom Lane wrote: > I believe the F7 compose is still frozen for test3. If you need your > update to appear in test3 rather than test4, you'll need to convince > releng of that (it may well be too late by now anyway). I don't need that. If I understand it correctly, I'll have to wait until test3 is out and then it will be pushed, right? -- TJ. (Brno, CZ), BaseOS, Red Hat From jkeating at redhat.com Sun Mar 25 20:24:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 25 Mar 2007 16:24:38 -0400 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <20070325200855.GA30946@redhat.com> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> <10180.1174852251@sss.pgh.pa.us> <20070325200855.GA30946@redhat.com> Message-ID: <200703251624.41530.jkeating@redhat.com> On Sunday 25 March 2007 16:08:55 Tomas Janousek wrote: > I don't need that. If I understand it correctly, I'll have to wait until > test3 is out and then it will be pushed, right? Correct. It'll get pushed once rawhide starts pulling from dist-fc7 instead of the freeze tag. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjanouse at redhat.com Sun Mar 25 20:58:22 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sun, 25 Mar 2007 22:58:22 +0200 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <200703251624.41530.jkeating@redhat.com> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> <10180.1174852251@sss.pgh.pa.us> <20070325200855.GA30946@redhat.com> <200703251624.41530.jkeating@redhat.com> Message-ID: <20070325205822.GA1369@redhat.com> Hi, On Sun, Mar 25, 2007 at 04:24:38PM -0400, Jesse Keating wrote: > Correct. It'll get pushed once rawhide starts pulling from dist-fc7 instead > of the freeze tag. Ok, thanks to both of you for your replies. -- TJ. (Brno, CZ), BaseOS, Red Hat From devrim at CommandPrompt.com Mon Mar 26 00:19:01 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Mon, 26 Mar 2007 03:19:01 +0300 Subject: Looking for reviewers Message-ID: <1174868341.4352.5.camel@laptop.gunduz.org> Hi, I'm looking for reviewers for these 3 PostgreSQL related packages: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229321 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229322 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229323 These 3 packages should appear in Fedora at once, since they are part of the same team :) The first one was reviewed once. The other ones are really easy to review. I'd like to push them to Fedora and begin packaging other PostgreSQL related packages... Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Mar 26 01:05:52 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 25 Mar 2007 21:05:52 -0400 Subject: Package EVR problems in FC+FE 2007-03-25 In-Reply-To: <20070325184323.GA26025@redhat.com> References: <20070325160444.CB2ED152130@buildsys.fedoraproject.org> <20070325184323.GA26025@redhat.com> Message-ID: <1174871152.3254.4.camel@aglarond.local> On Sun, 2007-03-25 at 20:43 +0200, Tomas Janousek wrote: > On Sun, Mar 25, 2007 at 12:04:44PM -0400, buildsys at fedoraproject.org wrote: > > gpm > > FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) > > FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) > > The fc7 package was successfully built in brew a few minutes before the fc5 > and 6 ones. Anyone has an idea why it wasn't pushed yet? rawhide isn't pushing new packages except for those explicitly needed as we try to polish off test3 and get it out. Jeremy From opensource at till.name Mon Mar 26 04:28:46 2007 From: opensource at till.name (Till Maas) Date: Mon, 26 Mar 2007 06:28:46 +0200 Subject: Acceptable for inclusion: drumkits for hydrogen Message-ID: <200703260628.57644.opensource@till.name> Hiyas, according to http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac non code packages need permission from FESCo to get included, I want to ask whether hydrogen drumkits are permitted for inclusion: http://www.hydrogen-music.org/?p=drumkits These are .tar.gz files, that contain .wav files, that can be used in hydrogen (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190040) to create (drum) music. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Mon Mar 26 05:18:38 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 25 Mar 2007 22:18:38 -0700 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <200703260628.57644.opensource@till.name> References: <200703260628.57644.opensource@till.name> Message-ID: <1174886318.5937.1.camel@tuxhugs> On Mon, 2007-03-26 at 06:28 +0200, Till Maas wrote: > Hiyas, > > according to > http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac > non code packages need permission from FESCo to get included, I want to ask > whether hydrogen drumkits are permitted for inclusion: > > http://www.hydrogen-music.org/?p=drumkits > > These are .tar.gz files, that contain .wav files, that can be used in hydrogen > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190040) to create > (drum) music. So long as the content/music itself is Free (licensed under an appropriate Creative Commons deed, for example) I'd think it would be okay for inclusion, since it's not stand-alone content; but rather data to augment an already packaged (?) application. IANAL, though; and the final Yea or Nay on this is up to FESCo... -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Mon Mar 26 05:37:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Mar 2007 07:37:13 +0200 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174886318.5937.1.camel@tuxhugs> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> Message-ID: <1174887433.3596.44.camel@mccallum.corsepiu.local> On Sun, 2007-03-25 at 22:18 -0700, Peter Gordon wrote: > On Mon, 2007-03-26 at 06:28 +0200, Till Maas wrote: > > Hiyas, > > > > according to > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac > > non code packages need permission from FESCo to get included, I want to ask > > whether hydrogen drumkits are permitted for inclusion: > > > > http://www.hydrogen-music.org/?p=drumkits > > > > These are .tar.gz files, that contain .wav files, that can be used in hydrogen > > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190040) to create > > (drum) music. > > So long as the content/music itself is Free (licensed under an > appropriate Creative Commons deed, for example) I'd think it would be > okay for inclusion, since it's not stand-alone content; but rather data > to augment an already packaged (?) application. >From what I saw by sneaking into a subset of these files, - They lack any license or copyright information. - They are sound files (sound samples), being usable stand-alone with a little processing (They are plain tar.gz's of *.wav's and *.flac's) being obscured by using a nonstandard file suffix). - Question, I don't know the answer to: Do these sound samples qualify as "artwork" (and therefore have to be considered to be covered by "artistic" copyright laws)? Ralf From tcallawa at redhat.com Mon Mar 26 13:40:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 Mar 2007 08:40:32 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174887433.3596.44.camel@mccallum.corsepiu.local> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> Message-ID: <1174916432.6493.32.camel@localhost.localdomain> On Mon, 2007-03-26 at 07:37 +0200, Ralf Corsepius wrote: > >From what I saw by sneaking into a subset of these files, > - They lack any license or copyright information. > > - They are sound files (sound samples), being usable stand-alone with a > little processing (They are plain tar.gz's of *.wav's and *.flac's) > being obscured by using a nonstandard file suffix). > > - Question, I don't know the answer to: Do these sound samples qualify > as "artwork" (and therefore have to be considered to be covered by > "artistic" copyright laws)? I wouldn't go that far. I would say at least, they need some sort of license or copyright attribution. I'm slightly more concerned about whether it is legal to record the sounds that a drum machine makes and freely redistribute them without the manufacturers permission. ~spot From williams at redhat.com Mon Mar 26 15:13:05 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 26 Mar 2007 10:13:05 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174916432.6493.32.camel@localhost.localdomain> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> Message-ID: <4607E301.3070206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Mon, 2007-03-26 at 07:37 +0200, Ralf Corsepius wrote: > >> >From what I saw by sneaking into a subset of these files, >> - They lack any license or copyright information. >> >> - They are sound files (sound samples), being usable stand-alone with a >> little processing (They are plain tar.gz's of *.wav's and *.flac's) >> being obscured by using a nonstandard file suffix). >> >> - Question, I don't know the answer to: Do these sound samples qualify >> as "artwork" (and therefore have to be considered to be covered by >> "artistic" copyright laws)? > > I wouldn't go that far. I would say at least, they need some sort of > license or copyright attribution. > > I'm slightly more concerned about whether it is legal to record the > sounds that a drum machine makes and freely redistribute them without > the manufacturers permission. Hmmm. I don't think there's any restriction on the use of those sounds in a performance, but there may be restrictions on their use in a piece of software. Do we know what sort of drum brains were used to generate the samples? Alesis, Roland, Yamaha, Ddrum? Or are they samples recorded from acoustic drums? If the sounds are from an electronic source, they may be problematic, so we just need to get all the drummers on the list to setup mics and record some samples. :) Think I'll head over to the hydrogen site and see what is required... Clark "dying to setup his home studio" Williams -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGB+MBHyuj/+TTEp0RAtrjAKCy2HKPPLRAXJQy7dNx4ELBJFiEoACcCJJi uehnYl0ppHMQuFWC6xuzTrc= =AJbq -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Mar 26 15:53:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 Mar 2007 10:53:49 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <4607E301.3070206@redhat.com> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <4607E301.3070206@redhat.com> Message-ID: <1174924429.6493.46.camel@localhost.localdomain> On Mon, 2007-03-26 at 10:13 -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom "spot" Callaway wrote: > > On Mon, 2007-03-26 at 07:37 +0200, Ralf Corsepius wrote: > > > >> >From what I saw by sneaking into a subset of these files, > >> - They lack any license or copyright information. > >> > >> - They are sound files (sound samples), being usable stand-alone with a > >> little processing (They are plain tar.gz's of *.wav's and *.flac's) > >> being obscured by using a nonstandard file suffix). > >> > >> - Question, I don't know the answer to: Do these sound samples qualify > >> as "artwork" (and therefore have to be considered to be covered by > >> "artistic" copyright laws)? > > > > I wouldn't go that far. I would say at least, they need some sort of > > license or copyright attribution. > > > > I'm slightly more concerned about whether it is legal to record the > > sounds that a drum machine makes and freely redistribute them without > > the manufacturers permission. > > Hmmm. > > I don't think there's any restriction on the use of those sounds in a > performance, but there may be restrictions on their use in a piece of > software. Do we know what sort of drum brains were used to generate the > samples? Alesis, Roland, Yamaha, Ddrum? Or are they samples recorded > from acoustic drums? The website claims that they came from Roland, Yamaha, Boss, and several other units. ~spot From wolters.liste at gmx.net Mon Mar 26 16:24:23 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 26 Mar 2007 18:24:23 +0200 Subject: Temporary orphaned packages Message-ID: <200703261824.39071.wolters.liste@gmx.net> Hi, unfortunately no one seems to take over the responsibility for my three KDE packages while I'm away for at least three weeks. Does this mean I have to flag these packages as orphans? How do I do this temporarily? Roland -- "Es w?re l?cherlich, f?r auch nur einen Penny ein Wort zu schreiben. Will man eine Million Dollar verdienen, so ist der beste Weg dazu, eine eigene Religion zu gr?nden." -- Ron Hubbard, Gr?nder der Scientology-Kirche -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 26 16:26:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 11:26:22 -0500 Subject: Temporary orphaned packages In-Reply-To: <200703261824.39071.wolters.liste@gmx.net> References: <200703261824.39071.wolters.liste@gmx.net> Message-ID: <4607F42E.10009@math.unl.edu> Roland Wolters wrote: > unfortunately no one seems to take over the responsibility for my three KDE > packages while I'm away for at least three weeks. I'll help keep an eye on them. > Does this mean I have to flag these packages as orphans? No (imo). -- Rex From williams at redhat.com Mon Mar 26 16:27:25 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 26 Mar 2007 11:27:25 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174924429.6493.46.camel@localhost.localdomain> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <4607E301.3070206@redhat.com> <1174924429.6493.46.camel@localhost.localdomain> Message-ID: <4607F46D.8000105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Mon, 2007-03-26 at 10:13 -0500, Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tom "spot" Callaway wrote: >>> On Mon, 2007-03-26 at 07:37 +0200, Ralf Corsepius wrote: >>> >>>> >From what I saw by sneaking into a subset of these files, >>>> - They lack any license or copyright information. >>>> >>>> - They are sound files (sound samples), being usable stand-alone with a >>>> little processing (They are plain tar.gz's of *.wav's and *.flac's) >>>> being obscured by using a nonstandard file suffix). >>>> >>>> - Question, I don't know the answer to: Do these sound samples qualify >>>> as "artwork" (and therefore have to be considered to be covered by >>>> "artistic" copyright laws)? >>> I wouldn't go that far. I would say at least, they need some sort of >>> license or copyright attribution. >>> >>> I'm slightly more concerned about whether it is legal to record the >>> sounds that a drum machine makes and freely redistribute them without >>> the manufacturers permission. >> Hmmm. >> >> I don't think there's any restriction on the use of those sounds in a >> performance, but there may be restrictions on their use in a piece of >> software. Do we know what sort of drum brains were used to generate the >> samples? Alesis, Roland, Yamaha, Ddrum? Or are they samples recorded >> from acoustic drums? > > The website claims that they came from Roland, Yamaha, Boss, and several > other units. > I see that they have a number of drumkits available. I thought I'd download the source and some drumkits, but whenever I try, sourceforge says "your download should begin shortly" and then it just stares at me (and I stare back). the "direct link" doesn't work for me either. Anyone else having issues with sourceforge? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGB/RtHyuj/+TTEp0RAhjdAKC7QzygieeUAWLUkGpBqxGAlsIN5wCgpuii kvNHuOOSd2X8sFLZFtYYKvk= =M99o -----END PGP SIGNATURE----- From giallu at gmail.com Mon Mar 26 16:39:52 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 26 Mar 2007 18:39:52 +0200 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <4607F46D.8000105@redhat.com> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <4607E301.3070206@redhat.com> <1174924429.6493.46.camel@localhost.localdomain> <4607F46D.8000105@redhat.com> Message-ID: On 3/26/07, Clark Williams wrote: > I see that they have a number of drumkits available. I thought I'd > download the source and some drumkits, but whenever I try, sourceforge > says "your download should begin shortly" and then it just stares at me > (and I stare back). the "direct link" doesn't work for me either. > > Anyone else having issues with sourceforge? > Sometimes happened also here. Try switching mirror manually From wolters.liste at gmx.net Mon Mar 26 16:45:43 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 26 Mar 2007 18:45:43 +0200 Subject: Temporary orphaned packages In-Reply-To: <4607F42E.10009@math.unl.edu> References: <200703261824.39071.wolters.liste@gmx.net> <4607F42E.10009@math.unl.edu> Message-ID: <200703261845.52514.wolters.liste@gmx.net> Once upon a time Rex Dieter wrote: > Roland Wolters wrote: > > unfortunately no one seems to take over the responsibility for my three > > KDE packages while I'm away for at least three weeks. > > I'll help keep an eye on them. > Perfect - anything I have to do additionally? Roland -- "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr w?tend und wurde allenthalben als Schritt in die falsche Richtung angesehen." -- Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 26 17:34:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 19:34:19 +0200 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174916432.6493.32.camel@localhost.localdomain> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> Message-ID: <20070326173419.GL14911@neu.nirvana> On Mon, Mar 26, 2007 at 08:40:32AM -0500, Tom spot Callaway wrote: > I'm slightly more concerned about whether it is legal to record the > sounds that a drum machine makes and freely redistribute them without > the manufacturers permission. Isn't that what every music production does? And when someone uses their sound/music then they pay royalties to the musican's label, not to the manufacturers of their music instruments. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 26 18:24:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Mar 2007 20:24:52 +0200 Subject: Proposal for a EPEL Steering Committee Message-ID: <46080FF4.1020807@leemhuis.info> Hi all! The initial goal of the EPEL SIG was to have some kind of "work in the open, announce potential controversial topics in public before you realize them, and as long as nobody yells everything is fine and everyone glad" kind of organization. Well, seems at some EPEL-SIG members seems unhappy with that and strongly urged on the epel-devel-list to form some kind of government body. So I wrote something up, which you can find below. Start of proposal ---- == EPEL Steering Committee == An EPEL Steering Committee will be formed as government body for EPEL. It will consist of seven members. The initial committee will be filled with the first seven EPEL SIG members that are also those that invested most of the time and work for the EPEL idea until now. That includes these people: Dennis Gilmore, Mike McGrath, Michael Stahnke, Kevin Fenzi, Thorsten Leemhuis, Karsten Wade and Axel Thimm (those people can appoint different members if they don't want to be in the committee). They will take care of EPEL until 30.09.2007. Then then a new committee will be formed; FESCo and the EPEL Steering Committee until then will work out how this committee will get constituted; a mix of appointed and elected members is likely. The EPEL Steering Committee will continue to report to FESCo and will continue to be a SIG that is below FESCo in the project hierarchy. The EPEL Steering Committee will work similar how FESCo works; that means: * things normally get discusses and decided in open-to-all IRC meetings; members can send in their vote via mail/wiki if they can make the meeting. Approving something requires that either four members (e.g. the majority) agree on it or the majority of votes wins, in case all members voted, but some abstained with a vote for either side. But the goal remains to have a consensus between Committee members normally * important things get discussed on the list before they get voted upon and the goal it to find a consensus that seems to be fine for the majority of people involved * meeting summaries get send to the list, wiki and to FESCo. They will get discussed in FESCo meetings if necessary; FESCo can veto things that got decided in the FESCo-meeting that follows the public summary by at least 24 hours. That's similar to how FESCo can veto issues decide upon by the Packaging Committee; the "at least 24 hours" delay makes sure the FESCo members have enough time to look into a issue before discussing it. * each point that receives strong opposition on the list after it got decided will get revisited once in the next meeting if someone asks for it The EPEL Steering Committee won't handle issues around theoretical Packaging (e.g. everything around writing specfiles) -- the Packaging Committee will take care of this for EPEL, too. Practical packaging (for example: maintenance and update policy for EPEL) on the other hand is regulated by the EPEL Steering Committee. The goal is to let the EPEL Steering Committee work on it's own (e.g. without FESCo involvement) for all things that are specific to EPEL. Sometimes it might be necessary to solve issues hand in hand with FESCo or other SIGs. For example, when the EPEL steering committee can't agree on a issue with another committee that is on the same hierarchy level in the Fedora Project (say the Packaging Committee). Besides the general discussions that normally happens before voting's the EPEL Steering Committee will normally announce controversial or bigger voting's at least 24 hours before the voting-meeting on the list to make sure all people can send in their opinions before the meeting. Note that a lot smaller things will get decided without announcement beforehand, to make sure things are moving and to avoid to much bureaucracy; but everything of course can get revisited even after the meeting if there is a need to. The Steering Committee members will probably also use the wiki or the mailing list more often for votings than for example FESCo does. ---- End of proposal (side note: the text can be found in the wiki at http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee ) Note: This was discussed a bit on epel-devel-list already; see https://www.redhat.com/archives/epel-devel-list/2007-March/msg00360.html for details and some things that got changed in between. I'll send it to FESCo for discussions and ratifying when we agree roughly that this is the route to take. Probably for this Thursdays meeting already -- but that depends on how this discussions evolves. CU thl From Axel.Thimm at ATrpms.net Mon Mar 26 19:16:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 21:16:46 +0200 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <46080FF4.1020807@leemhuis.info> References: <46080FF4.1020807@leemhuis.info> Message-ID: <20070326191646.GJ9977@neu.nirvana> Hi, sorry I missed the following in the proof-reading: On Mon, Mar 26, 2007 at 08:24:52PM +0200, Thorsten Leemhuis wrote: > members can send in their vote via mail/wiki if they can make the ^^^ -> cannot > meeting. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Mar 26 21:07:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 Mar 2007 16:07:56 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <20070326173419.GL14911@neu.nirvana> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <20070326173419.GL14911@neu.nirvana> Message-ID: <1174943276.6493.71.camel@localhost.localdomain> On Mon, 2007-03-26 at 19:34 +0200, Axel Thimm wrote: > On Mon, Mar 26, 2007 at 08:40:32AM -0500, Tom spot Callaway wrote: > > I'm slightly more concerned about whether it is legal to record the > > sounds that a drum machine makes and freely redistribute them without > > the manufacturers permission. > > Isn't that what every music production does? And when someone uses > their sound/music then they pay royalties to the musican's label, not > to the manufacturers of their music instruments. Sortof. This is more along the lines of: - copying the sounds that drum machine A makes - so that drum machine B can make the exact same sounds - then, giving away drum machine B (and advertising it as having the exact same sounds as drum machine A) ~spot From williams at redhat.com Mon Mar 26 21:36:56 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 26 Mar 2007 16:36:56 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174943276.6493.71.camel@localhost.localdomain> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <20070326173419.GL14911@neu.nirvana> <1174943276.6493.71.camel@localhost.localdomain> Message-ID: <46083CF8.8080800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Mon, 2007-03-26 at 19:34 +0200, Axel Thimm wrote: >> On Mon, Mar 26, 2007 at 08:40:32AM -0500, Tom spot Callaway wrote: >>> I'm slightly more concerned about whether it is legal to record the >>> sounds that a drum machine makes and freely redistribute them without >>> the manufacturers permission. >> Isn't that what every music production does? And when someone uses >> their sound/music then they pay royalties to the musican's label, not >> to the manufacturers of their music instruments. > > Sortof. This is more along the lines of: > > - copying the sounds that drum machine A makes > - so that drum machine B can make the exact same sounds > - then, giving away drum machine B (and advertising it as having the > exact same sounds as drum machine A) > > ~spot Yeah, I'm not sure that Roland would like the fact that they've got TD7 sounds, despite the fact that Roland hasn't sold TD7's for oh, probably eight or ten years now. Same for the Boss stuff (owned by Roland). Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGCDz4Hyuj/+TTEp0RAoBqAJ9hoHz89GC1FHcN0gxNVZCAkhP8HwCg1104 LGcVa2uSTi7juf7mKBhM7Rs= =bRZu -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Mon Mar 26 21:45:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 23:45:19 +0200 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <46083CF8.8080800@redhat.com> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <20070326173419.GL14911@neu.nirvana> <1174943276.6493.71.camel@localhost.localdomain> <46083CF8.8080800@redhat.com> Message-ID: <20070326214519.GG16942@neu.nirvana> On Mon, Mar 26, 2007 at 04:36:56PM -0500, Clark Williams wrote: > Tom "spot" Callaway wrote: > > On Mon, 2007-03-26 at 19:34 +0200, Axel Thimm wrote: > >> On Mon, Mar 26, 2007 at 08:40:32AM -0500, Tom spot Callaway wrote: > >>> I'm slightly more concerned about whether it is legal to record the > >>> sounds that a drum machine makes and freely redistribute them without > >>> the manufacturers permission. > >> Isn't that what every music production does? And when someone uses > >> their sound/music then they pay royalties to the musican's label, not > >> to the manufacturers of their music instruments. > > > > Sortof. This is more along the lines of: > > > > - copying the sounds that drum machine A makes > > - so that drum machine B can make the exact same sounds > > - then, giving away drum machine B (and advertising it as having the > > exact same sounds as drum machine A) There isn't yet a patent for "sound formulae", is there? > Yeah, I'm not sure that Roland would like the fact that they've got TD7 > sounds, despite the fact that Roland hasn't sold TD7's for oh, probably > eight or ten years now. Same for the Boss stuff (owned by Roland). But as you write it, it is a fact, and the kit above would not do any more advertising harm than what you did by writing the above lines ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Mon Mar 26 22:15:19 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 26 Mar 2007 17:15:19 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <20070326214519.GG16942@neu.nirvana> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <20070326173419.GL14911@neu.nirvana> <1174943276.6493.71.camel@localhost.localdomain> <46083CF8.8080800@redhat.com> <20070326214519.GG16942@neu.nirvana> Message-ID: <460845F7.3060909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > On Mon, Mar 26, 2007 at 04:36:56PM -0500, Clark Williams wrote: >> Tom "spot" Callaway wrote: >>> On Mon, 2007-03-26 at 19:34 +0200, Axel Thimm wrote: >>>> On Mon, Mar 26, 2007 at 08:40:32AM -0500, Tom spot Callaway wrote: >>>>> I'm slightly more concerned about whether it is legal to record the >>>>> sounds that a drum machine makes and freely redistribute them without >>>>> the manufacturers permission. >>>> Isn't that what every music production does? And when someone uses >>>> their sound/music then they pay royalties to the musican's label, not >>>> to the manufacturers of their music instruments. >>> Sortof. This is more along the lines of: >>> >>> - copying the sounds that drum machine A makes >>> - so that drum machine B can make the exact same sounds >>> - then, giving away drum machine B (and advertising it as having the >>> exact same sounds as drum machine A) > > There isn't yet a patent for "sound formulae", is there? > We're talking about copyright here, not patents. I just happen to have a PDF of the TD-8 drum brain manual on my laptop. When I did a search for copyright, I eventually found this note: "The sounds, phrases and patterns contained in this product are sound recordings protected by copyright. Roland hereby grants to purchasers of this product the permission to utilize the sound recordings contained in this product for the creation and recording of original musical works; provided however, the sound recordings contained in this product may not be sampled, downloaded or otherwise re-recorded, in whole or in part, for any other purpose, including but not limited to the transmission of all or any part of the sound recordings via the internet or other digital or analog means of transmission, and/or the manufacture, for sale or otherwise, of any collection of sampled sounds, phrases or patterns, on CD-ROM or equivalent means. The sound recordings contained in this product are the original works of Roland Corporation. Roland is not responsible for the use of the sound recordings contained in this product, and assumes no liability for any infringement of any copyright of any third party arising out of use of the sounds, phrases and pattern" Now, they may not have copyrighted the drum sounds from the TD-7, but chances are they did. Of course it looks like hydrogen has a number of freely available drum kits available for download (at least ones that don't claim to be duplicates of copyrighted material). We could just package the source and a selection of the drum sounds that aren't going to cause us legal grief. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGCEX3Hyuj/+TTEp0RAm55AJ9MCALI/WkEOm6P8GcuEhi9/1QPsACfUhSC CxnZZzPWVkxd42TXAnqbK+M= =Ae4q -----END PGP SIGNATURE----- From tcallawa at redhat.com Tue Mar 27 01:19:03 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 Mar 2007 20:19:03 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <460845F7.3060909@redhat.com> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> <20070326173419.GL14911@neu.nirvana> <1174943276.6493.71.camel@localhost.localdomain> <46083CF8.8080800@redhat.com> <20070326214519.GG16942@neu.nirvana> <460845F7.3060909@redhat.com> Message-ID: <1174958343.6493.80.camel@localhost.localdomain> On Mon, 2007-03-26 at 17:15 -0500, Clark Williams wrote: > Of course it looks like hydrogen has a number of freely available drum > kits available for download (at least ones that don't claim to be > duplicates of copyrighted material). We could just package the source > and a selection of the drum sounds that aren't going to cause us legal > grief. This seems like the best option. ~spot From mmcgrath at redhat.com Tue Mar 27 03:22:22 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 26 Mar 2007 22:22:22 -0500 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <46080FF4.1020807@leemhuis.info> References: <46080FF4.1020807@leemhuis.info> Message-ID: <46088DEE.5080300@redhat.com> Thorsten Leemhuis wrote: > I'll send it to FESCo for discussions and ratifying when we agree > roughly that this is the route to take. Probably for this Thursdays > meeting already -- but that depends on how this discussions evolves. Looks good to me. -Mike From panemade at gmail.com Tue Mar 27 11:41:18 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 27 Mar 2007 17:11:18 +0530 Subject: fonts packages review and conffile-without-noreplace-flag warning Message-ID: Hi, While reviewing fonts-japanese package(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225765#c10), I got explanation from maintainer of this package for ignoring conffile-without-noreplace-flag warning and i think he is right to his explanation. I need some more advice on this problem. Thanks & Regards, Parag. From buildsys at fedoraproject.org Tue Mar 27 12:04:11 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 27 Mar 2007 08:04:11 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-27 Message-ID: <20070327120411.B63D2152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) gpm FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) gpm: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From tcallawa at redhat.com Tue Mar 27 14:12:41 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 09:12:41 -0500 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: References: Message-ID: <1175004761.6493.92.camel@localhost.localdomain> On Tue, 2007-03-27 at 17:11 +0530, Parag N(????) wrote: > Hi, > While reviewing fonts-japanese > package(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225765#c10), > I got explanation from maintainer of this package for ignoring > conffile-without-noreplace-flag warning and i think he is right to his > explanation. I need some more advice on this problem. Question: Is it really a configuration file? To determine this, ask, will a user be permitted to change it? If the answer is yes, then the user will be quite unhappy to have it replaced by the stock copy when they do a package update. If it is not something designed to be hand-edited (or shipped with a tool to edit), then its probably not a config file. IMHO, there are very very very few cases where %config without noreplace is acceptable. ~spot From jkeating at redhat.com Tue Mar 27 19:25:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 15:25:13 -0400 Subject: Fedora 7 frozen for Test 3 In-Reply-To: <200703201746.16628.jkeating@redhat.com> References: <200703201746.16628.jkeating@redhat.com> Message-ID: <200703271525.13956.jkeating@redhat.com> On Tuesday 20 March 2007 17:46:16 Jesse Keating wrote: > I've frozen the "Core" side of Fedora 7 for Test 3. ?Rawhide composes will > happen from the 'f7-test3' collection. ?Builds from the devel/ branch > continue to go to dist-fc7 and will be picked up after the freeze. The freeze is now over. Test3 is on its way to the mirrors. The next rawhide compose will pick up all the things that were built during the freeze, and it could be a little messy. I'm going to be flying to RDU tomorrow afternoon and if rawhide blows up bad I may not have time to fix it until tomorrow night. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Mar 27 19:26:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Mar 2007 14:26:53 -0500 Subject: Summary of the 2007-03-27 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-03-27 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070327 Executive summary: The following draft is now an official guideline, having been accepted by FESCO last week: * Guidelines for using cmake: http://fedoraproject.org/wiki/PackagingDrafts/cmake If not already done as you read this, it should soon be written into the guidelines proper. Issues pending FESCO ratification: * Modifications to the Naming Guidelines for handling non-numeric post-releases (6 yea, 0 nay): http://fedoraproject.org/wiki/PackagingDrafts/PostRelease * Additional dist-related macros (7 yea, 0 nay): http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros * Mandating that filenames in RPMs be utf8 (7 yea, 0 nay): http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames Misc business: * There was discussion about whether brp-python-bytecompile or some other rpmbuild bit could hardlink *.pyc and *.pyo files together when they don't differ. (Frequently they are the same.) This could have some reasonable space savings. Please see the minutes and IRC log for complete information. - J< From seg at haxxed.com Wed Mar 28 00:27:29 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 27 Mar 2007 19:27:29 -0500 Subject: Acceptable for inclusion: drumkits for hydrogen In-Reply-To: <1174916432.6493.32.camel@localhost.localdomain> References: <200703260628.57644.opensource@till.name> <1174886318.5937.1.camel@tuxhugs> <1174887433.3596.44.camel@mccallum.corsepiu.local> <1174916432.6493.32.camel@localhost.localdomain> Message-ID: <1175041649.6110.12.camel@localhost.localdomain> On Mon, 2007-03-26 at 08:40 -0500, Tom "spot" Callaway wrote: > I wouldn't go that far. I would say at least, they need some sort of > license or copyright attribution. They're definitely lacking in having any kind of license at all, no where on the web site or in the tarballs. They should be put under a Creative Commons license of some kind. And versioning them couldn't hurt either... > I'm slightly more concerned about whether it is legal to record the > sounds that a drum machine makes and freely redistribute them without > the manufacturers permission. The 808 kit for one, claims to have been independently synthesized, and isn't from a real TR-808. Dunno about the others. I know there's assloads of companies out there that sell CDs full of samples from various synths, so the legalities of doing such have got to be well established by now, but I haven't been able to google up anything about it so far. http://www.soundsonline.com/product.php?productid=BS-385 http://www.hollowsun.com/vintage/nostalgia.html etc etc... Also of interest: http://www.artworxinn.com/alex/history.htm The copyright on the MT-32 ROM may or may not have lapsed, Roland can't seem to find any documentation to prove it either way. :) Wonder if any other synth ROMs have fallen through the same loophole... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tagoh at redhat.com Wed Mar 28 02:25:34 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 28 Mar 2007 11:25:34 +0900 (JST) Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175004761.6493.92.camel@localhost.localdomain> References: <1175004761.6493.92.camel@localhost.localdomain> Message-ID: <20070328.112534.-1286960345.tagoh@redhat.com> >>>>> On Tue, 27 Mar 2007 09:12:41 -0500, >>>>> "TC" == "Tom \"spot\" Callaway" wrote: TC> Question: Is it really a configuration file? TC> To determine this, ask, will a user be permitted to change it? If the TC> answer is yes, then the user will be quite unhappy to have it replaced TC> by the stock copy when they do a package update. If it is not something TC> designed to be hand-edited (or shipped with a tool to edit), then its TC> probably not a config file. Yes, it's a configuration file that designed to determine the connection between PostScript fontname and the real font. someone may wants to use another one rather than the default font. those would be helpful in this case. However my question is, what happens if the default font is changed? I mean it will be not working properly after that unless people changes them manually since it doesn't reflect by noreplace flag. I just want to know what the standard way for such case, which is described somewhere explicitly. and how do we notice that change to the users to avoid the unnecessary trouble? -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Mar 28 02:32:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Mar 2007 22:32:59 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070321144728.GA19264@jadzia.bu.edu> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> <20070321144728.GA19264@jadzia.bu.edu> Message-ID: <20070328023259.GA11446@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > > Got a better suggestion? I don't think I'd look under System Tools at all. > > > And it is "sound", after all. > > Not sure. We also have espeak which isn't in comps. > > So, an "Accessibility" group? Should I bugzilla this as an enhancement > request against comps? Or should I be patient? :) Feel free to bz. Of course, it's a string change. Bill From mattdm at mattdm.org Wed Mar 28 02:50:01 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 27 Mar 2007 22:50:01 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <20070328023259.GA11446@nostromo.devel.redhat.com> References: <20070320190855.GA20971@jadzia.bu.edu> <20070320192511.GD18364@nostromo.devel.redhat.com> <20070320194453.GA23884@jadzia.bu.edu> <20070320195808.GE18364@nostromo.devel.redhat.com> <20070321144728.GA19264@jadzia.bu.edu> <20070328023259.GA11446@nostromo.devel.redhat.com> Message-ID: <20070328025001.GA13002@jadzia.bu.edu> On Tue, Mar 27, 2007 at 10:32:59PM -0400, Bill Nottingham wrote: > > > > Got a better suggestion? I don't think I'd look under System Tools at all. > > > > And it is "sound", after all. > > > Not sure. We also have espeak which isn't in comps. > > So, an "Accessibility" group? Should I bugzilla this as an enhancement > > request against comps? Or should I be patient? :) > Feel free to bz. Of course, it's a string change. Dammit. :) Can we put the mentioned voices in sound & video in the meantime? They should be somewhere. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Wed Mar 28 04:10:01 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 23:10:01 -0500 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <20070328.112534.-1286960345.tagoh@redhat.com> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> Message-ID: <1175055001.6493.179.camel@localhost.localdomain> On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote: > >>>>> On Tue, 27 Mar 2007 09:12:41 -0500, > >>>>> "TC" == "Tom \"spot\" Callaway" wrote: > > TC> Question: Is it really a configuration file? > > TC> To determine this, ask, will a user be permitted to change it? If the > TC> answer is yes, then the user will be quite unhappy to have it replaced > TC> by the stock copy when they do a package update. If it is not something > TC> designed to be hand-edited (or shipped with a tool to edit), then its > TC> probably not a config file. > > Yes, it's a configuration file that designed to determine > the connection between PostScript fontname and the real > font. someone may wants to use another one rather than the > default font. those would be helpful in this case. > > However my question is, what happens if the default font is > changed? I would say that if they changed it to use a specific font, then, they really want that specific font, whether the default changes or not. The default font should only change in a major release, and should be documented in the Release Notes. I think this is a %config(noreplace) case. ~spot From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 28 04:35:49 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 Mar 2007 13:35:49 +0900 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175055001.6493.179.camel@localhost.localdomain> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> Message-ID: <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote: > On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote: >>>>>>> On Tue, 27 Mar 2007 09:12:41 -0500, >>>>>>> "TC" == "Tom \"spot\" Callaway" wrote: >> TC> Question: Is it really a configuration file? >> >> TC> To determine this, ask, will a user be permitted to change it? If the >> TC> answer is yes, then the user will be quite unhappy to have it replaced >> TC> by the stock copy when they do a package update. If it is not something >> TC> designed to be hand-edited (or shipped with a tool to edit), then its >> TC> probably not a config file. >> >> Yes, it's a configuration file that designed to determine >> the connection between PostScript fontname and the real >> font. someone may wants to use another one rather than the >> default font. those would be helpful in this case. >> >> However my question is, what happens if the default font is >> changed? > > I would say that if they changed it to use a specific font, then, they > really want that specific font, whether the default changes or not. Here Akira says is perhaps.. what happens if the previous fonts is completely _removed_ (due to license issue or something)? In this case, user-customized config file completely gets useless. Well, this actually happened on fonts-japanese I hear some peole say, "well, actually the configuration will change in the future, so I want to leave this configuration file as not noreplace". > The default font should only change in a major release, and should be > documented in the Release Notes. I doubt every people reads release notes. And especially, this is for Japanese...... Forcing people to read release notes is not a good solution. IMO if a package has some reason not to add noreplace, then we should leave as how the packager judges. I saw another example * When I reviewed a font package and asked a configuration file to mark as noreplace, the packager said okay. * After review passed, the packager updated the package several time. After that, the packager decided, "ah, noreplace is inconvenient. removing noreplace..." Mamoru From a.badger at gmail.com Wed Mar 28 05:26:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 27 Mar 2007 22:26:05 -0700 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> Message-ID: <1175059565.16371.65.camel@localhost.localdomain> On Wed, 2007-03-28 at 13:35 +0900, Mamoru Tasaka wrote: > Tom "spot" Callaway wrote: > > On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote: > >>>>>>> On Tue, 27 Mar 2007 09:12:41 -0500, > >>>>>>> "TC" == "Tom \"spot\" Callaway" wrote: > >> TC> Question: Is it really a configuration file? > >> > >> TC> To determine this, ask, will a user be permitted to change it? If the > >> TC> answer is yes, then the user will be quite unhappy to have it replaced > >> TC> by the stock copy when they do a package update. If it is not something > >> TC> designed to be hand-edited (or shipped with a tool to edit), then its > >> TC> probably not a config file. > >> > >> Yes, it's a configuration file that designed to determine > >> the connection between PostScript fontname and the real > >> font. someone may wants to use another one rather than the > >> default font. those would be helpful in this case. > >> > >> However my question is, what happens if the default font is > >> changed? > > > > I would say that if they changed it to use a specific font, then, they > > really want that specific font, whether the default changes or not. > > Here Akira says is perhaps.. what happens if the previous fonts is > completely _removed_ (due to license issue or something)? > In this case, user-customized config file completely gets useless. > Well, this actually happened on fonts-japanese > If the font is removed, then the config file has to be updated. But the thing is that the user intiates all of these actions. We don't remove the package from the user's system. The user has to decide : 1) I want to override the default font. Make changes to /etc/configfontfile. 2) Oops. I don't like that font anymore. I'm going to rpm -e foo-font 3) Okay. I need to change the configfontfile so it points to a font that I still have installed. If the user doesn't perform actions 1 or 2 then action 3 is not necessary. > I hear some peole say, "well, actually the configuration will > change in the future, so I want to leave this configuration file > as not noreplace". > If the user doesn't change the config file and the next package iteration has a different configuration in the file, the file will be replaced despite it being %config(noreplace). %config() macros only kick in when the file has been modified on the installed system. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 28 05:51:07 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 Mar 2007 14:51:07 +0900 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175059565.16371.65.camel@localhost.localdomain> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> Message-ID: <460A024B.3090702@ioa.s.u-tokyo.ac.jp> Toshio Kuratomi wrote: > On Wed, 2007-03-28 at 13:35 +0900, Mamoru Tasaka wrote: >> Tom "spot" Callaway wrote: >>> On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote: >>>>>>>>> On Tue, 27 Mar 2007 09:12:41 -0500, >>>>>>>>> "TC" == "Tom \"spot\" Callaway" wrote: >>>> TC> Question: Is it really a configuration file? >>>> >>>> TC> To determine this, ask, will a user be permitted to change it? If the >>>> TC> answer is yes, then the user will be quite unhappy to have it replaced >>>> TC> by the stock copy when they do a package update. If it is not something >>>> TC> designed to be hand-edited (or shipped with a tool to edit), then its >>>> TC> probably not a config file. >>>> >>>> Yes, it's a configuration file that designed to determine >>>> the connection between PostScript fontname and the real >>>> font. someone may wants to use another one rather than the >>>> default font. those would be helpful in this case. >>>> >>>> However my question is, what happens if the default font is >>>> changed? >>> I would say that if they changed it to use a specific font, then, they >>> really want that specific font, whether the default changes or not. >> Here Akira says is perhaps.. what happens if the previous fonts is >> completely _removed_ (due to license issue or something)? >> In this case, user-customized config file completely gets useless. >> Well, this actually happened on fonts-japanese >> > If the font is removed, then the config file has to be updated. But the > thing is that the user intiates all of these actions. > We don't remove > the package from the user's system. No, for fonts-japanese, the package actually removed (and had to remove) one fonts. There is no font named "fonts-japanese". This is a correction of about 10? different fonts and config file points to one font by default. What happened to fonts-japanese is that this font used as default (which was very common) had to remove completely due to license issue. So simply upgrading fonts-japanese actually removed one font. At this point, user-customized config file became quite useless. And many changes happened according to this default font change, along with ghostscript change (yes, this was really many). > The user has to decide : > > 1) I want to override the default font. Make changes > to /etc/configfontfile. > 2) Oops. I don't like that font anymore. I'm going to rpm -e foo-font > 3) Okay. I need to change the configfontfile so it points to a font > that I still have installed. > > If the user doesn't perform actions 1 or 2 then action 3 is not > necessary. i.e. we *had to* do 2) despite what a user may think. Mamoru From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 28 05:54:03 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 Mar 2007 14:54:03 +0900 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <460A024B.3090702@ioa.s.u-tokyo.ac.jp> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> <460A024B.3090702@ioa.s.u-tokyo.ac.jp> Message-ID: <460A02FB.4090509@ioa.s.u-tokyo.ac.jp> > There is no font named "fonts-japanese". This is a correction > of about 10? different fonts and config file points to one > font by default. s|correction|collection| Mamoru From nicolas.mailhot at laposte.net Wed Mar 28 06:00:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Mar 2007 08:00:49 +0200 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175059565.16371.65.camel@localhost.localdomain> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> Message-ID: <1175061649.7288.7.camel@rousalka.dyndns.org> Le mardi 27 mars 2007 ? 22:26 -0700, Toshio Kuratomi a ?crit : > If the font is removed, then the config file has to be updated. But the > thing is that the user intiates all of these actions. Bzzt - when you bundle lots of different fonts in a single package the user can't control fonts at the rpm level, since the bundle will always exist but with different contents (that's a big problem with fonts-region packages) - if these things take legacy core fonts strings the string associated to a font has been known to change even though the font itself was still shipped - also some core font users (most notably X) will crash if these aliases do not resolve. So a small change a user may have forgotten about will kill his system months later if config(noreplace) is used and an old stale config file is kept on the system - core fonts need to die die die. robust config is better than perfect brittle config in core fonts case -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tagoh at redhat.com Wed Mar 28 06:25:55 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 28 Mar 2007 15:25:55 +0900 (JST) Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175059565.16371.65.camel@localhost.localdomain> References: <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> Message-ID: <20070328.152555.-818270842.tagoh@redhat.com> >>>>> On Tue, 27 Mar 2007 22:26:05 -0700, >>>>> "TK" == Toshio Kuratomi wrote: TK> On Wed, 2007-03-28 at 13:35 +0900, Mamoru Tasaka wrote: >> Tom "spot" Callaway wrote: >> > On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote: >> >>>>>>> On Tue, 27 Mar 2007 09:12:41 -0500, >> >>>>>>> "TC" == "Tom \"spot\" Callaway" wrote: >> >> TC> Question: Is it really a configuration file? >> >> >> >> TC> To determine this, ask, will a user be permitted to change it? If the >> >> TC> answer is yes, then the user will be quite unhappy to have it replaced >> >> TC> by the stock copy when they do a package update. If it is not something >> >> TC> designed to be hand-edited (or shipped with a tool to edit), then its >> >> TC> probably not a config file. >> >> >> >> Yes, it's a configuration file that designed to determine >> >> the connection between PostScript fontname and the real >> >> font. someone may wants to use another one rather than the >> >> default font. those would be helpful in this case. >> >> >> >> However my question is, what happens if the default font is >> >> changed? >> > >> > I would say that if they changed it to use a specific font, then, they >> > really want that specific font, whether the default changes or not. >> >> Here Akira says is perhaps.. what happens if the previous fonts is >> completely _removed_ (due to license issue or something)? >> In this case, user-customized config file completely gets useless. >> Well, this actually happened on fonts-japanese Yes, something like that. TK> If the font is removed, then the config file has to be updated. But the TK> thing is that the user intiates all of these actions. We don't remove TK> the package from the user's system. The user has to decide : Well, as you may know, fonts-japanese collects various Japanese fonts and I presume that the font file is removed from the package without adding/removing any packages. and it also provides configuration files for ghostscript to be able to print japanese text out correctly, which we are talking about now. TK> If the user doesn't change the config file and the next package TK> iteration has a different configuration in the file, the file will be TK> replaced despite it being %config(noreplace). %config() macros only TK> kick in when the file has been modified on the installed system. Right. I'm worrying about they may add another line to it or modify it partially etc, which is still referring to the old fonts. Another idea to solve this is, to makes it read-only file and to create the empty configuration file for users, which can overrides the sytem's. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed Mar 28 08:30:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Mar 2007 10:30:46 +0200 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <20070328.152555.-818270842.tagoh@redhat.com> References: <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> <20070328.152555.-818270842.tagoh@redhat.com> Message-ID: <20070328083046.GC2906@free.fr> On Wed, Mar 28, 2007 at 03:25:55PM +0900, Akira TAGOH wrote: > > Another idea to solve this is, to makes it read-only file > and to create the empty configuration file for users, which > can overrides the sytem's. In general this is the best solution. A 'vendor' config file below /usr/share and a sysadmin/local user config file somewhere below /etc/. An even better solution is to have a config file in /etc/ pointing at additional config files, such that it is also possible for the administrator to point to exotic location, for example a location wide config file below /usr/local. -- Pat From dennis at ausil.us Wed Mar 28 12:12:40 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Mar 2007 07:12:40 -0500 Subject: Extras Buildsys Downtime Message-ID: <200703280712.40598.dennis@ausil.us> Hi All, Sorry for the short notice. but due to some difficulties with the storage where the buildsys pulls its packages from the Extras buildsys has been turned off while we get the issues fixed. As soon as its resolved We will let you know. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From faucamp at csir.co.za Wed Mar 28 12:49:14 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Wed, 28 Mar 2007 14:49:14 +0200 Subject: fedora 7 comps change request (for festival) In-Reply-To: <460A806A0200006A000138C3@cs-emo.csir.co.za> References: <4609F4130200003A0000AD25@cs-emo.csir.co.za> <460A806A0200006A000138C3@cs-emo.csir.co.za> Message-ID: <460A806A0200006A000138C3@cs-emo.csir.co.za> On Tue, 2007-03-27 at 22:50 -0400, Matthew Miller wrote: > Can we put the mentioned voices in sound & video in the meantime? They > should be somewhere. > Works for me, as "Accessibility" isn't really why I use TTS engines (such as flite and espeak)... Actually wanted to ask about comps for these a while back, and completely forgot about it... :-/ Where should flite and espeak go? "sound & video"? (they don't have separate voice data) -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mattdm at mattdm.org Wed Mar 28 12:54:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 08:54:38 -0400 Subject: fedora 7 comps change request (for festival) In-Reply-To: <460A806A0200006A000138C3@cs-emo.csir.co.za> References: <4609F4130200003A0000AD25@cs-emo.csir.co.za> <460A806A0200006A000138C3@cs-emo.csir.co.za> <460A806A0200006A000138C3@cs-emo.csir.co.za> Message-ID: <20070328125438.GA23192@jadzia.bu.edu> On Wed, Mar 28, 2007 at 02:49:14PM +0200, Francois Aucamp wrote: > > Can we put the mentioned voices in sound & video in the meantime? They > > should be somewhere. > Works for me, as "Accessibility" isn't really why I use TTS engines > (such as flite and espeak)... > Actually wanted to ask about comps for these a while back, and > completely forgot about it... :-/ Where should flite and espeak go? > "sound & video"? (they don't have separate voice data) I think Accessibility is eventually a good option. Even if you're not using the tts engines for that, it's a place you might logically look. I want the festival voices to be put in comps somewhere right away though so we don't have a regression and make the default install less capable than it was before. Will bugzilla later today. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Wed Mar 28 13:13:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Mar 2007 09:13:53 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-28 Message-ID: <20070328131353.E4763152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) fonts-indic FC5-updates > FC7 (0:2.1.5-1.fc5 > 0:2.1.4-1.fc7) FC6-updates > FC7 (0:2.1.5-1.fc6 > 0:2.1.4-1.fc7) gpm FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) samba FC5-updates > FC6-updates (0:3.0.24-2.fc5 > 0:3.0.24-1.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) fonts-indic: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2.1.5-1.fc5 > 0:2.1.4-1.fc7) FC6-updates > FC7 (0:2.1.5-1.fc6 > 0:2.1.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) gpm: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.20.1-81.fc5 > 0:1.20.1-80.fc7) FC6-updates > FC7 (0:1.20.1-81.fc6 > 0:1.20.1-80.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) samba: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.24-2.fc5 > 0:3.0.24-1.fc6) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) tzdata: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2007d-1.fc5 > 0:2007c-1.fc7) FC6-updates > FC7 (0:2007d-1.fc6 > 0:2007c-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From dennis at ausil.us Wed Mar 28 15:36:05 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Mar 2007 10:36:05 -0500 Subject: Extras Buildsys Downtime In-Reply-To: <200703280712.40598.dennis@ausil.us> References: <200703280712.40598.dennis@ausil.us> Message-ID: <200703281036.05794.dennis@ausil.us> On Wednesday 28 March 2007 07:12:40 am Dennis Gilmore wrote: > Hi All, > > Sorry for the short notice. but due to some difficulties with the storage > where the buildsys pulls its packages from the Extras buildsys has been > turned off while we get the issues fixed. > > As soon as its resolved We will let you know. > > Dennis Buildsys is now back up. Sorry for the inconvenience. -- Dennis Gilmore, RHCE From a.badger at gmail.com Wed Mar 28 17:38:29 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 28 Mar 2007 10:38:29 -0700 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <20070328.152555.-818270842.tagoh@redhat.com> References: <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> <20070328.152555.-818270842.tagoh@redhat.com> Message-ID: <1175103510.16371.84.camel@localhost.localdomain> On Wed, 2007-03-28 at 15:25 +0900, Akira TAGOH wrote: > >>>>> On Tue, 27 Mar 2007 22:26:05 -0700, > >>>>> "TK" == Toshio Kuratomi wrote: > TK> If the font is removed, then the config file has to be updated. But the > TK> thing is that the user intiates all of these actions. We don't remove > TK> the package from the user's system. The user has to decide : > > Well, as you may know, fonts-japanese collects various Japanese > fonts and I presume that the font file is removed from the > package without adding/removing any packages. and it also > provides configuration files for ghostscript to be able to > print japanese text out correctly, which we are talking > about now. > Ah I missed that fonts-japanese is a collection of fonts. > TK> If the user doesn't change the config file and the next package > TK> iteration has a different configuration in the file, the file will be > TK> replaced despite it being %config(noreplace). %config() macros only > TK> kick in when the file has been modified on the installed system. > > Right. I'm worrying about they may add another line to it or > modify it partially etc, which is still referring to the old > fonts. > This is no different than upgrading between versions of a program where the config file format has changed in incompatible ways. What do we do then? > Another idea to solve this is, to makes it read-only file > and to create the empty configuration file for users, which > can overrides the sytem's. Sure. It sounds like it's really a per user setting preference anyway. Note that I'd either mark the system wide file %config(noreplace) if it continues to live in /etc or put it in /usr somewhere. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 28 19:50:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 28 Mar 2007 14:50:53 -0500 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175061649.7288.7.camel@rousalka.dyndns.org> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> <1175061649.7288.7.camel@rousalka.dyndns.org> Message-ID: <1175111453.6110.16.camel@localhost.localdomain> On Wed, 2007-03-28 at 08:00 +0200, Nicolas Mailhot wrote: > Le mardi 27 mars 2007 ? 22:26 -0700, Toshio Kuratomi a ?crit : > > > If the font is removed, then the config file has to be updated. But the > > thing is that the user intiates all of these actions. > > Bzzt > - when you bundle lots of different fonts in a single package the user > can't control fonts at the rpm level, since the bundle will always exist > but with different contents (that's a big problem with fonts-region > packages) Bundling multiple, not directly related items together in a single RPM is just plain wrong in any case. Each font should be split into its own package, and the "fonts-japanese" package can be a meta-package that depends on them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Mar 28 20:14:07 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 28 Mar 2007 15:14:07 -0500 Subject: Proposal: Automate fedora-maintainers subscriptions In-Reply-To: <4600309E.8060202@fedoraproject.org> References: <45FEDDF2.1050208@redhat.com> <45FF7820.6090809@leemhuis.info> <46000D8C.4000404@redhat.com> <46001714.4070603@leemhuis.info> <46001B79.9030704@redhat.com> <46002281.3030706@leemhuis.info> <4600265F.9070308@fedoraproject.org> <46002889.6010204@fedoraproject.org> <4600309E.8060202@fedoraproject.org> Message-ID: <1175112847.6110.29.camel@localhost.localdomain> On Wed, 2007-03-21 at 00:36 +0530, Rahul Sundaram wrote: > Christopher Stone wrote: > > On 3/20/07, Rahul Sundaram wrote: > >> Christopher Stone wrote: > >> > On 3/20/07, Rahul Sundaram wrote: > >> >> Why does games SIG require a separate mailing list? > >> > > >> > For the same reason any SIG should have their own list. > >> > >> That is not a good reason consider no SIG except games has its own > >> mailing list. > > > > I wouldn't say that. > > > > Fedora-perl-devel-list -> perl SIG > > Fedora-music-list -> music and media production SIG > > Fedora-security-list -> security SIG > > Fedora music list is not related to the music > SIG but was originally created to coordinate on the merge of Planet > CCRMA into Fedora Extras. Well, the media production SIG's main goal so far has been to merge as much of planet CCRMA in as possible, seeing as Fernando has already packaged damn near everything out there. :) The list was created before I attempted to name the SIG with a slightly wider scope. Admittedly, the media SIG has been a bit lacking in strong leadership. All its members seem to be rather busy people. School keeps me rather busy for one. ;P Anyway, I think its perfectly reasonable to leave the decision as to whether or not the SIG needs its own list to the SIG itself, without having to justify it to anyone else. Worst comes to worst, SIGs will just start their own lists outside the Fedora infrastructure if they aren't allowed to do it within. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Mar 28 20:22:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Mar 2007 22:22:19 +0200 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175111453.6110.16.camel@localhost.localdomain> References: <1175004761.6493.92.camel@localhost.localdomain> <20070328.112534.-1286960345.tagoh@redhat.com> <1175055001.6493.179.camel@localhost.localdomain> <4609F0A5.1010808@ioa.s.u-tokyo.ac.jp> <1175059565.16371.65.camel@localhost.localdomain> <1175061649.7288.7.camel@rousalka.dyndns.org> <1175111453.6110.16.camel@localhost.localdomain> Message-ID: <1175113339.17719.12.camel@rousalka.dyndns.org> Le mercredi 28 mars 2007 ? 14:50 -0500, Callum Lerwick a ?crit : > Each font should be split into its own > package, and the "fonts-japanese" package can be a meta-package that > depends on them. Or you can just put the various font packages in the "Japanese support" comps group, without any supplemental bundling -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mattdm at mattdm.org Wed Mar 28 20:43:58 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 16:43:58 -0400 Subject: bugzilla cleanup: old FC-test bugs Message-ID: <20070328204358.GA31569@jadzia.bu.edu> I know the bug-day folks did some triage here. I like to hit things with bigger sticks. :) Proposal: 1) Move all FC3-test and FC4-test bugs to FC3 and FC4 respectively, and mark as NEEDINFO, with the following comment: Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest this issue on a current release or on the latest development / test version, we would appreciate that. Otherwise, this bug will be marked as CANTFIX one month from now. Thanks for your help and for your patience. 2) move all FC5-test and FC6-test bugs to the corresponding final releases, and also mark as NEEDINFO, with this message: Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. 3) delete the "test" versions from bugzilla to help reduce clutter when searching and confusion when filing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwboyer at jdub.homelinux.org Wed Mar 28 21:01:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 16:01:18 -0500 Subject: bugzilla cleanup: old FC-test bugs In-Reply-To: <20070328204358.GA31569@jadzia.bu.edu> References: <20070328204358.GA31569@jadzia.bu.edu> Message-ID: <1175115678.7553.105.camel@zod.rchland.ibm.com> On Wed, 2007-03-28 at 16:43 -0400, Matthew Miller wrote: > I know the bug-day folks did some triage here. I like to hit things with > bigger sticks. :) > > Proposal: > > 1) Move all FC3-test and FC4-test bugs to FC3 and FC4 respectively, and > mark as NEEDINFO, with the following comment: > > Fedora Core 3 and Fedora Core 4 are no longer supported. If you could > retest this issue on a current release or on the latest development / > test version, we would appreciate that. Otherwise, this bug will be > marked as CANTFIX one month from now. Thanks for your help and for your > patience. > > 2) move all FC5-test and FC6-test bugs to the corresponding final > releases, and also mark as NEEDINFO, with this message: > > Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no > longer test releases. We're cleaning up the bug database and making > sure important bug reports filed against these test releases don't get > lost. It would be helpful if you could test this issue with a released > version of Fedora or with the latest development / test release. Thanks > for your help and for your patience. > > 3) delete the "test" versions from bugzilla to help reduce clutter when > searching and confusion when filing. This looks like a good idea to me. josh From jkeating at redhat.com Wed Mar 28 22:54:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 18:54:58 -0400 Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175103510.16371.84.camel@localhost.localdomain> References: <1175055001.6493.179.camel@localhost.localdomain> <20070328.152555.-818270842.tagoh@redhat.com> <1175103510.16371.84.camel@localhost.localdomain> Message-ID: <200703281854.58594.jkeating@redhat.com> On Wednesday 28 March 2007 13:38:29 Toshio Kuratomi wrote: > This is no different than upgrading between versions of a program where > the config file format has changed in incompatible ways. ?What do we do > then? release notes (: Seriously it's a hole in the process. The admin has to figure out some way that his old script is no longer compatible and will need updating to the format that is in the .rpmnew file. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nomis80 at nomis80.org Wed Mar 28 23:08:32 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Wed, 28 Mar 2007 19:08:32 -0400 Subject: Newbie question: how to update package? Message-ID: <200703281908.32426.nomis80@nomis80.org> Hello, Version 2.0.2 of quadkonsole has been released and I want to update my spec with the new tarball. How do I do that? I searched the wiki and couldn't find the answer. As payback, I'll update the wiki with the info if necessary. Thanks From mattdm at mattdm.org Wed Mar 28 23:17:39 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 19:17:39 -0400 Subject: Newbie question: how to update package? In-Reply-To: <200703281908.32426.nomis80@nomis80.org> References: <200703281908.32426.nomis80@nomis80.org> Message-ID: <20070328231739.GA11593@jadzia.bu.edu> On Wed, Mar 28, 2007 at 07:08:32PM -0400, Simon Perreault wrote: > Version 2.0.2 of quadkonsole has been released and I want to update my spec > with the new tarball. How do I do that? I searched the wiki and couldn't find > the answer. As payback, I'll update the wiki with the info if necessary. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nomis80 at nomis80.org Wed Mar 28 23:56:27 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Wed, 28 Mar 2007 19:56:27 -0400 Subject: Newbie question: how to update package? In-Reply-To: <20070328231739.GA11593@jadzia.bu.edu> References: <200703281908.32426.nomis80@nomis80.org> <20070328231739.GA11593@jadzia.bu.edu> Message-ID: <460B00AB.6070603@nomis80.org> Matthew Miller wrote: > Thanks! From buildsys at fedoraproject.org Thu Mar 29 03:04:25 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Mar 2007 23:04:25 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-28 Message-ID: <20070329030425.A8FA0152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) samba FC5-updates > FC6-updates (0:3.0.24-2.fc5 > 0:3.0.24-1.fc6) dakingun AT gmail.com: exaile FE6 > FE7 (0:0.2.9-1.fc6 > 0:0.2.8-2.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) jwboyer AT jdub.homelinux.org: gaim-meanwhile FE6 > FE7 (2:2.0.0-0.7.beta6.fc6 > 2:2.0.0-0.6.beta6.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: ettercap FE6 > FE7 (0:0.7.3-19.fc6 > 0:0.7.3-18.fc7) gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) somlo AT cmu.edu: aumix FE6 > FE7 (0:2.8-15.fc6 > 0:2.8-14.fc7) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- aumix: somlo AT cmu.edu FE6 > FE7 (0:2.8-15.fc6 > 0:2.8-14.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) ettercap: limb AT jcomserv.net FE6 > FE7 (0:0.7.3-19.fc6 > 0:0.7.3-18.fc7) exaile: dakingun AT gmail.com FE6 > FE7 (0:0.2.9-1.fc6 > 0:0.2.8-2.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gaim-meanwhile: jwboyer AT jdub.homelinux.org FE6 > FE7 (2:2.0.0-0.7.beta6.fc6 > 2:2.0.0-0.6.beta6.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) samba: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.24-2.fc5 > 0:3.0.24-1.fc6) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From bpepple at fedoraproject.org Thu Mar 29 03:32:58 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 28 Mar 2007 23:32:58 -0400 Subject: Plan for tomorrows (20070329) FESCO meeting Message-ID: <1175139178.5932.7.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 19:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- Core Package Review Process -- warren /topic FESCO-Meeting -- sponsor nominations -- David Lutterkort, nominated by Spot /topic FESCO-Meeting -- MISC -- cvs-import changes - c4chris /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Retired Package Policy - https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00700.html - bpepple, mschwent /topic FESCO-Meeting -- MISC -- Extras 7 preparation - nirik? /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- EPEL -- discuss and (if there is no disagreement) approve the proposal for the EPELSteeringCommittee https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00753.html http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... BTW: Sorry, I haven't written up a summary of last weeks meeting, but real-life intruded on my fedora time this week. I'll try to finish it up tomorrow. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Thu Mar 29 03:47:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 22:47:34 -0500 Subject: Package EVR problems in FC+FE 2007-03-28 In-Reply-To: <20070329030425.A8FA0152131@buildsys.fedoraproject.org> References: <20070329030425.A8FA0152131@buildsys.fedoraproject.org> Message-ID: <1175140054.32658.20.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 23:04 -0400, buildsys at fedoraproject.org wrote: > > jwboyer AT jdub.homelinux.org: > gaim-meanwhile > FE6 > FE7 (2:2.0.0-0.7.beta6.fc6 > 2:2.0.0-0.6.beta6.fc7) The FE7 version was actually built before the FE6 version. Only FE6 got pushed tonight because it was a bug fix. Will go away with the next Extras devel push, whenever that happens. josh From tagoh at redhat.com Thu Mar 29 04:15:55 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Thu, 29 Mar 2007 13:15:55 +0900 (JST) Subject: fonts packages review and conffile-without-noreplace-flag warning In-Reply-To: <1175103510.16371.84.camel@localhost.localdomain> References: <1175059565.16371.65.camel@localhost.localdomain> <20070328.152555.-818270842.tagoh@redhat.com> <1175103510.16371.84.camel@localhost.localdomain> Message-ID: <20070329.131555.-1707063725.tagoh@redhat.com> >>>>> On Wed, 28 Mar 2007 10:38:29 -0700, >>>>> "TK" == Toshio Kuratomi wrote: TK> This is no different than upgrading between versions of a program where TK> the config file format has changed in incompatible ways. What do we do TK> then? Exactly. I'm wondering that too. TK> Sure. It sounds like it's really a per user setting preference anyway. TK> Note that I'd either mark the system wide file %config(noreplace) if it TK> continues to live in /etc or put it in /usr somewhere. Yes, I meant to put it in /usr somewhere in this case. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Thu Mar 29 08:16:04 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 29 Mar 2007 10:16:04 +0200 Subject: bugzilla cleanup: old FC-test bugs In-Reply-To: <20070328204358.GA31569@jadzia.bu.edu> References: <20070328204358.GA31569@jadzia.bu.edu> Message-ID: <20070329101604.40bbce6a@ludwig-alpha.unil.ch> On Wed, 28 Mar 2007 16:43:58 -0400, Matthew Miller wrote: > 1) Move all FC3-test and FC4-test bugs to FC3 and FC4 respectively, and > mark as NEEDINFO, with the following comment: > > Fedora Core 3 and Fedora Core 4 are no longer supported. If you could > retest this issue on a current release or on the latest development / > test version, we would appreciate that. Otherwise, this bug will be > marked as CANTFIX one month from now. Thanks for your help and for your > patience. I went through BZ a while ago for all FC3 and FC4 tickets (including the test releases) and put them in NEEDINFO state. So I think if they are still in NEEDINFO, those can be closed... > 2) move all FC5-test and FC6-test bugs to the corresponding final > releases, and also mark as NEEDINFO, with this message: > > Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no > longer test releases. We're cleaning up the bug database and making > sure important bug reports filed against these test releases don't get > lost. It would be helpful if you could test this issue with a released > version of Fedora or with the latest development / test release. Thanks > for your help and for your patience. > > 3) delete the "test" versions from bugzilla to help reduce clutter when > searching and confusion when filing. +1 C From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 29 14:08:24 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 29 Mar 2007 16:08:24 +0200 Subject: Update to libcaca and new shared lib Message-ID: <20070329160824.3376b9d6@python3.es.egwn.lan> Hi, I've just updated libcaca in devel to 0.99.beta11, which has actually been around for a while and works fine for me. I'm posting a notice here since up to now, libcaca only provided a static library by default, but it now defaults to also providing a shared one. Basically, no rebuilds are needed, but might be in the future. Note that looking at how the library is versioned (.so.0.99.0), one might assume that binary compatibility will break if/when a final 1.0 release is made, so again, no need to rebuild anything right now if you don't want to ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 2.61 1.39 1.05 From mattdm at mattdm.org Thu Mar 29 16:13:16 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 29 Mar 2007 12:13:16 -0400 Subject: bugzilla cleanup: old FC-test bugs In-Reply-To: <20070328204358.GA31569@jadzia.bu.edu> References: <20070328204358.GA31569@jadzia.bu.edu> Message-ID: <20070329161316.GA24454@jadzia.bu.edu> On Wed, Mar 28, 2007 at 04:43:58PM -0400, Matthew Miller wrote: > Proposal: > 1) Move all FC3-test and FC4-test bugs to FC3 and FC4 respectively, and > mark as NEEDINFO, with the following comment: [...] > 2) move all FC5-test and FC6-test bugs to the corresponding final > releases, and also mark as NEEDINFO, with this message: [...] So, is anyone opposed? I'll go ahead and do this on Monday if no one steps up with a complaint. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Thu Mar 29 18:11:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Mar 2007 14:11:57 -0400 Subject: Fedora 7 Feature Frozen Message-ID: <1175191917.3034.37.camel@aglarond.local> Per the Fedora 7 release schedule[1], with the release of test3, we have entered into the feature freeze. The purpose of the feature freeze is to help ensure that changes have adequate time to be tested as well as to provide some focus on bug-fixing for the release. This means that no new features or major version bumps are allowed for packages in the Fedora collection without the approval of the release team. New packages can continue to be reviewed, approved, committed and built. For cases where you feel that a new feature or major version bump is important enough to warrant an exception, please follow the procedure at http://fedoraproject.org/wiki/Releases/FeatureFreezePolicy Jeremy [1] http://fedoraproject.org/wiki/Releases/7/Schedule From notting at redhat.com Fri Mar 30 04:30:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 Mar 2007 00:30:31 -0400 Subject: FAS names in pkg.acl (Merge Blocker) In-Reply-To: <460416F3.7010801@redhat.com> References: <460416F3.7010801@redhat.com> Message-ID: <20070330043031.GA4538@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Prior to the merge, owners.list will be managed by PackageDB and tracked > in a database. We should change the CVS so pkg.acl contains FAS > usernames instead of Bugzilla names. Um, the pkg.acl files *already* contain account names. Bill From fedora at leemhuis.info Fri Mar 30 05:02:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Mar 2007 07:02:31 +0200 Subject: Release Team (was: Re: Fedora 7 Feature Frozen) In-Reply-To: <1175191917.3034.37.camel@aglarond.local> References: <1175191917.3034.37.camel@aglarond.local> Message-ID: <460C99E7.1030801@leemhuis.info> On 29.03.2007 20:11, Jeremy Katz wrote: > > This means that no new features or major version bumps are allowed for > packages in the Fedora collection without the approval of the release > team. [...] Just wondering: Who are the members of the release team these days, how to they make decisions, how can they be reached? And how about getting in officially formed, with a proper (SIG ?) page with all the relevant informations in the wiki? A quick wiki-writeup with the most important details can probably be done in less than ten minutes. That should be sufficient for now if F7 is pressing. CU thl P.S.: Yes, I tried to search the wiki and with google, but I didn't find any details who's in the release team these days or how it works. BTW, google found http://rhold.fedoraproject.org/about/leadership.html as third hit when searching with '"release team" fedora' -- quite old and outdated :-/ From jkeating at redhat.com Fri Mar 30 05:31:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Mar 2007 01:31:47 -0400 Subject: Release Team (was: Re: Fedora 7 Feature Frozen) In-Reply-To: <460C99E7.1030801@leemhuis.info> References: <1175191917.3034.37.camel@aglarond.local> <460C99E7.1030801@leemhuis.info> Message-ID: <200703300131.47999.jkeating@redhat.com> On Friday 30 March 2007 01:02:31 Thorsten Leemhuis wrote: > Just wondering: Who are the members of the release team these days, how > to they make decisions, how can they be reached? And how about getting > in officially formed, with a proper (SIG ?) page with all the relevant > informations in the wiki? A quick wiki-writeup with the most important > details can probably be done in less than ten minutes. That should be > sufficient for now if F7 is pressing. The release team has been loosely formed around me. It is basically the people I could get on the hook for helping me make decisions for what could be "unfrozen" during freezes. It currently includes: Myself Jeremy Katz Josh Boyer Bill Nottingham I welcome more to the fray, especially once we merge the systems and the people outside of Red Hat will now have the capability of actually doing some of the rel-eng tasks instead of just saying yay or nay. However I haven't had enough time to fine tune the Fedora rel-eng manifesto or any other organizational stuff around that. I tossed together an email alias and started flying by the seat of my pants. I hope to get some time next week to toss up a SIG page like you suggested, it makes sense. Is there a SIG template to work from? I do great starting from templates, otherwise I just stare at the blank Edit Wiki window for a while and get frustrated (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 30 05:43:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Mar 2007 07:43:17 +0200 Subject: Release Team In-Reply-To: <200703300131.47999.jkeating@redhat.com> References: <1175191917.3034.37.camel@aglarond.local> <460C99E7.1030801@leemhuis.info> <200703300131.47999.jkeating@redhat.com> Message-ID: <460CA375.7020504@leemhuis.info> On 30.03.2007 07:31, Jesse Keating wrote: > On Friday 30 March 2007 01:02:31 Thorsten Leemhuis wrote: >> Just wondering: Who are the members of the release team these days, how >> to they make decisions, how can they be reached? And how about getting >> in officially formed, with a proper (SIG ?) page with all the relevant >> informations in the wiki? A quick wiki-writeup with the most important >> details can probably be done in less than ten minutes. That should be >> sufficient for now if F7 is pressing. > The release team has been loosely formed around me. [...] Thanks for those informations and your work Jesse. > I hope to get some time next week to > toss up a SIG page like you suggested, it makes sense. Is there a SIG > template to work from? I do great starting from templates, otherwise I just > stare at the blank Edit Wiki window for a while and get frustrated (: I'm not aware of any templates, but I'd say take two r three of the existing SIG pages as examples and go from there. CU thl From buildsys at fedoraproject.org Fri Mar 30 11:46:03 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 30 Mar 2007 07:46:03 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-03-30 Message-ID: <20070330114603.73166152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) dakingun AT gmail.com: exaile FE6 > FE7 (0:0.2.9-1.fc6 > 0:0.2.8-2.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) green AT redhat.com: rssowl FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) exaile: dakingun AT gmail.com FE6 > FE7 (0:0.2.9-1.fc6 > 0:0.2.8-2.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) rssowl: green AT redhat.com FE6 > FE7 (0:1.2.3-3.fc6 > 0:1.2.3-2.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Mar 30 14:33:30 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 30 Mar 2007 16:33:30 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <1175191917.3034.37.camel@aglarond.local> References: <1175191917.3034.37.camel@aglarond.local> Message-ID: <20070330163330.085bb73c@python3.es.egwn.lan> Jeremy Katz wrote : > Per the Fedora 7 release schedule[1], with the release of test3, we have > entered into the feature freeze. The purpose of the feature freeze is > to help ensure that changes have adequate time to be tested as well as > to provide some focus on bug-fixing for the release. > > This means that no new features or major version bumps are allowed for > packages in the Fedora collection without the approval of the release > team. New packages can continue to be reviewed, approved, committed and > built. For cases where you feel that a new feature or major version > bump is important enough to warrant an exception, please follow the > procedure at http://fedoraproject.org/wiki/Releases/FeatureFreezePolicy > > Jeremy > > [1] http://fedoraproject.org/wiki/Releases/7/Schedule I don't see any mention of a "mass rebuild" like it was previously done with Extras. Is this something we will no longer be doing? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 0.59 0.26 0.27 From Jerry.James at usu.edu Fri Mar 30 15:33:23 2007 From: Jerry.James at usu.edu (Jerry James) Date: Fri, 30 Mar 2007 09:33:23 -0600 Subject: PackageMaintainers/Join wiki edits Message-ID: I'm going through the process of submitting my first package to Fedora. As instructed, I am working my way through this page: http://fedoraproject.org/wiki/PackageMaintainers/Join I've found a couple of small edits that need to be made, but can't seem to find any information on how to communicate with those able to make the edits. Could someone direct me? Briefly, the "Import Your Package" section starts by explaining how to checkout your new module from CVS. This is followed by a "Checkout the module" section, which explains how to checkout your new module from CVS. Also, the "Get a Fedora Account" section instructed me to join this list. Near the bottom of the page is a "Join the Maintainers List" section, which also instructs me to join this list. Regards, -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From jkeating at redhat.com Fri Mar 30 15:36:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Mar 2007 11:36:40 -0400 Subject: Fedora 7 Feature Frozen In-Reply-To: <20070330163330.085bb73c@python3.es.egwn.lan> References: <1175191917.3034.37.camel@aglarond.local> <20070330163330.085bb73c@python3.es.egwn.lan> Message-ID: <200703301136.40501.jkeating@redhat.com> On Friday 30 March 2007 10:33:30 Matthias Saou wrote: > I don't see any mention of a "mass rebuild" like it was previously > done with Extras. Is this something we will no longer be doing? I'd like to do this only for technical reasons such as compiler changes or breaking inheritance from previous releases. I'd rather see other non-intrusive methods for finding awol maintainers. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Mar 30 16:22:56 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 30 Mar 2007 18:22:56 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <200703301136.40501.jkeating@redhat.com> References: <1175191917.3034.37.camel@aglarond.local> <20070330163330.085bb73c@python3.es.egwn.lan> <200703301136.40501.jkeating@redhat.com> Message-ID: <20070330182256.0910a771@python3.es.egwn.lan> Jesse Keating wrote : > On Friday 30 March 2007 10:33:30 Matthias Saou wrote: > > I don't see any mention of a "mass rebuild" like it was previously > > done with Extras. Is this something we will no longer be doing? > > I'd like to do this only for technical reasons such as compiler changes or > breaking inheritance from previous releases. I'd rather see other > non-intrusive methods for finding awol maintainers. Fair enough. At this point in the cycle, there are at least two areas where special attention should be paid (on the packaging side of things, apart from "functional bugs") : - The broken EVR upgrade paths from FC6 to F7 (I counted 10 as of today) - The failed F7 automatic rebuilds caught by Matt's scripts Maybe some manual poking of maintainers with packages in such situations would be in order? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 0.20 0.20 0.22 From jkeating at redhat.com Fri Mar 30 16:28:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Mar 2007 12:28:54 -0400 Subject: Fedora 7 Feature Frozen In-Reply-To: <20070330182256.0910a771@python3.es.egwn.lan> References: <1175191917.3034.37.camel@aglarond.local> <200703301136.40501.jkeating@redhat.com> <20070330182256.0910a771@python3.es.egwn.lan> Message-ID: <200703301228.54712.jkeating@redhat.com> On Friday 30 March 2007 12:22:56 Matthias Saou wrote: > Fair enough. At this point in the cycle, there are at least two areas > where special attention should be paid (on the packaging side of > things, apart from "functional bugs") : > - The broken EVR upgrade paths from FC6 to F7 (I counted 10 as of today) > - The failed F7 automatic rebuilds caught by Matt's scripts > > Maybe some manual poking of maintainers with packages in such > situations would be in order? Yes, these would be good things to tackle. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 30 16:53:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Mar 2007 18:53:21 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <200703301136.40501.jkeating@redhat.com> References: <1175191917.3034.37.camel@aglarond.local> <20070330163330.085bb73c@python3.es.egwn.lan> <200703301136.40501.jkeating@redhat.com> Message-ID: <460D4081.4090402@leemhuis.info> Jesse Keating schrieb: > On Friday 30 March 2007 10:33:30 Matthias Saou wrote: >> I don't see any mention of a "mass rebuild" like it was previously >> done with Extras. Is this something we will no longer be doing? > I'd like to do this only for technical reasons such as compiler changes or > breaking inheritance from previous releases. Just wondering: Do we care about packages currently in devel which still have the fc6 dist tag? $ lftp -c "open \ http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/extras/development/i386/;\ ls; quit" | grep '.fc6.' | wc -l 1330 I think it's a *bit* confusing to have a F7 tree later with lots of packages which have a fc6 in the filename... Maybe we should have something in the package guidelines that says "if you use a dist tag then you should try to rebuild the package once during a development cycle so the disttag matches the actually release." But as I said, it's just a detail. > I'd rather see other > non-intrusive methods for finding awol maintainers. Agreed. Anyway, if we haven't anything in place to find AWOL maintainers by F8T2 then my vote is to have a mass rebuild shorty after that again (but we might have new toolchain by then anyway that would make a rebuild likely). CU thl From opensource at till.name Fri Mar 30 17:13:28 2007 From: opensource at till.name (Till Maas) Date: Fri, 30 Mar 2007 19:13:28 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <460D4081.4090402@leemhuis.info> References: <1175191917.3034.37.camel@aglarond.local> <200703301136.40501.jkeating@redhat.com> <460D4081.4090402@leemhuis.info> Message-ID: <200703301913.52332.opensource@till.name> On Fr M?rz 30 2007, Thorsten Leemhuis wrote: > I think it's a *bit* confusing to have a F7 tree later with lots of > packages which have a fc6 in the filename... Maybe we should have > something in the package guidelines that says "if you use a dist tag > then you should try to rebuild the package once during a development > cycle so the disttag matches the actually release." > > But as I said, it's just a detail. Imho this is better than having to download / install every installed package on ones system, just because the new disttag looks nicer. This way at least some packages do not need to be reinstalled. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 30 17:27:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Mar 2007 19:27:35 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <200703301913.52332.opensource@till.name> References: <1175191917.3034.37.camel@aglarond.local> <200703301136.40501.jkeating@redhat.com> <460D4081.4090402@leemhuis.info> <200703301913.52332.opensource@till.name> Message-ID: <460D4887.4090407@leemhuis.info> Till Maas schrieb: > On Fr M?rz 30 2007, Thorsten Leemhuis wrote: > >> I think it's a *bit* confusing to have a F7 tree later with lots of >> packages which have a fc6 in the filename... Maybe we should have >> something in the package guidelines that says "if you use a dist tag >> then you should try to rebuild the package once during a development >> cycle so the disttag matches the actually release." >> But as I said, it's just a detail. > Imho this is better than having to download / install every installed package > on ones system, just because the new disttag looks nicer. This way at least > some packages do not need to be reinstalled. Totally agreed. But maybe for packages that don't need much updates it might be better to just not use the disttag to avoid the confusion it can create... CU thl From jamatos at fc.up.pt Fri Mar 30 17:33:40 2007 From: jamatos at fc.up.pt (=?iso-8859-15?q?Jos=E9_Matos?=) Date: Fri, 30 Mar 2007 18:33:40 +0100 Subject: Fedora 7 Feature Frozen In-Reply-To: <460D4887.4090407@leemhuis.info> References: <1175191917.3034.37.camel@aglarond.local> <200703301913.52332.opensource@till.name> <460D4887.4090407@leemhuis.info> Message-ID: <200703301833.40387.jamatos@fc.up.pt> On Friday 30 March 2007 6:27:35 pm Thorsten Leemhuis wrote: > > Totally agreed. But maybe for packages that don't need much updates it > might be better to just not use the disttag to avoid the confusion it > can create... There are packages that don't have releases during a development cycle, what is the proper procedure for those packages? Is this documented somewhere? Should I go to package/devel/, tag and request a rebuild? > CU > thl -- Jos? Ab?lio From bugs.michael at gmx.net Fri Mar 30 17:49:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 30 Mar 2007 19:49:50 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <460D4887.4090407@leemhuis.info> References: <1175191917.3034.37.camel@aglarond.local> <200703301136.40501.jkeating@redhat.com> <460D4081.4090402@leemhuis.info> <200703301913.52332.opensource@till.name> <460D4887.4090407@leemhuis.info> Message-ID: <20070330194950.097d38ad.bugs.michael@gmx.net> On Fri, 30 Mar 2007 19:27:35 +0200, Thorsten Leemhuis wrote: > Till Maas schrieb: > > On Fr M?rz 30 2007, Thorsten Leemhuis wrote: > > > >> I think it's a *bit* confusing to have a F7 tree later with lots of > >> packages which have a fc6 in the filename... Maybe we should have > >> something in the package guidelines that says "if you use a dist tag > >> then you should try to rebuild the package once during a development > >> cycle so the disttag matches the actually release." > >> But as I said, it's just a detail. > > Imho this is better than having to download / install every installed package > > on ones system, just because the new disttag looks nicer. This way at least > > some packages do not need to be reinstalled. > > Totally agreed. But maybe for packages that don't need much updates it > might be better to just not use the disttag to avoid the confusion it > can create... For the packages that *do* build during Matt's automated rebuilds, does anyone pay attention to the rpmdiff logs? One goal of rebuilds is to make sure that all build dependencies are still compatible and e.g. no features are dropped silently because of API changes and non-fatal configure checks. If no rebuilds are done, there can be a big surprise when an update is needed and it is found that some BuildRequires don't yield the expected results. From Axel.Thimm at ATrpms.net Fri Mar 30 18:20:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Mar 2007 20:20:20 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <200703301136.40501.jkeating@redhat.com> References: <1175191917.3034.37.camel@aglarond.local> <20070330163330.085bb73c@python3.es.egwn.lan> <200703301136.40501.jkeating@redhat.com> Message-ID: <20070330182020.GK30970@neu.nirvana> On Fri, Mar 30, 2007 at 11:36:40AM -0400, Jesse Keating wrote: > On Friday 30 March 2007 10:33:30 Matthias Saou wrote: > > I don't see any mention of a "mass rebuild" like it was previously > > done with Extras. Is this something we will no longer be doing? > > I'd like to do this only for technical reasons such as compiler changes or > breaking inheritance from previous releases. I'd rather see other > non-intrusive methods for finding awol maintainers. The awol detection was just a side-effect, and not worth by itself rebuilding the distro for. I think at least one mass rebuild towards the end of the release cycle makes sense, e.g. when the release is in freeze status: I've been doing that since several releases and was always very surprised to see what other dependencies both run-time and build-time changed and broke something, even from testX to testX+1. For example the recent glibc made some incompatible chownat changes. We do have some semi-official rebuilds made by Matt, but they don't get the attention they need. It would be different if Matt's rebuilds happened right into rawhide with the packagers being forced to face the bugs when using rawhide. But it may be too late in the release cycle for F7 to bring this up. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 30 18:03:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Mar 2007 20:03:06 +0200 Subject: Fedora 7 Feature Frozen In-Reply-To: <20070330194950.097d38ad.bugs.michael@gmx.net> References: <1175191917.3034.37.camel@aglarond.local> <200703301136.40501.jkeating@redhat.com> <460D4081.4090402@leemhuis.info> <200703301913.52332.opensource@till.name> <460D4887.4090407@leemhuis.info> <20070330194950.097d38ad.bugs.michael@gmx.net> Message-ID: <460D50DA.5060807@leemhuis.info> Michael Schwendt schrieb: > On Fri, 30 Mar 2007 19:27:35 +0200, Thorsten Leemhuis wrote: >> Till Maas schrieb: >>> On Fr M?rz 30 2007, Thorsten Leemhuis wrote: >>>> I think it's a *bit* confusing to have a F7 tree later with lots of >>>> packages which have a fc6 in the filename... Maybe we should have >>>> something in the package guidelines that says "if you use a dist tag >>>> then you should try to rebuild the package once during a development >>>> cycle so the disttag matches the actually release." >>>> But as I said, it's just a detail. >>> Imho this is better than having to download / install every installed package >>> on ones system, just because the new disttag looks nicer. This way at least >>> some packages do not need to be reinstalled. >> Totally agreed. But maybe for packages that don't need much updates it >> might be better to just not use the disttag to avoid the confusion it >> can create... > > For the packages that *do* build during Matt's automated rebuilds, does > anyone pay attention to the rpmdiff logs? [...] No idea. I'd say we in the long term should use idle time on our regular builders to rebuild all our packages regularly into a devel-scratch repo (where everything gets deleted after some days), use scripts to analyze the packages and especially the differences against the packages in the repo and send a report in case of errors to the maintainer and out QA guys. Especially the "send the report to the maintainers directly" part IMHO is quite important. Cu thl From ville.skytta at iki.fi Fri Mar 30 18:51:52 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 30 Mar 2007 21:51:52 +0300 Subject: PackageMaintainers/Join wiki edits In-Reply-To: References: Message-ID: <200703302151.53365.ville.skytta@iki.fi> On Friday 30 March 2007, Jerry James wrote: > I'm going through the process of submitting my first package to Fedora. Welcome! > As instructed, I am working my way through this page: > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > I've found a couple of small edits that need to be made, but can't seem > to find any information on how to communicate with those able to make > the edits. Could someone direct me? http://fedoraproject.org/wiki/WikiEditing Let me know your Wiki name when you have an account, and I'll add you. Hm, I suppose it wouldn't be a bad idea to add a one liner and a link to this to the PackageMaintainers/Join page. From Jerry.James at usu.edu Fri Mar 30 20:52:37 2007 From: Jerry.James at usu.edu (Jerry James) Date: Fri, 30 Mar 2007 14:52:37 -0600 Subject: Orphan: Moodle In-Reply-To: <45F7159D.9020806@redhat.com> (Mike McGrath's message of "Tue, 13 Mar 2007 16:20:29 -0500") References: <45F7159D.9020806@redhat.com> Message-ID: Mike McGrath , on Tue, 13 Mar 2007 at 16:20:29 -0500 you wrote: > I'm orphaning moodle, I took it up after ignacio left because we used it where > I work, that was two jobs ago :-D I don't use it now and shouldn't be > maintaining it. Anyone interested? I plan to use it next year in my classes. Nobody else is speaking up, so if you aren't too worried about passing the baton to a complete newbie like me, I'll take it. I'll probably need a little hand holding through the ownership change process. -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From mmcgrath at redhat.com Fri Mar 30 22:09:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 30 Mar 2007 17:09:28 -0500 Subject: Orphan: Moodle In-Reply-To: References: <45F7159D.9020806@redhat.com> Message-ID: <460D8A98.6050106@redhat.com> Jerry James wrote: > Mike McGrath , on Tue, 13 Mar 2007 at 16:20:29 > -0500 you wrote: > >> I'm orphaning moodle, I took it up after ignacio left because we used it where >> I work, that was two jobs ago :-D I don't use it now and shouldn't be >> maintaining it. Anyone interested? >> > > I plan to use it next year in my classes. Nobody else is speaking up, > so if you aren't too worried about passing the baton to a complete > newbie like me, I'll take it. I'll probably need a little hand holding > through the ownership change process. > Sure thing, do you already have commit access? -Mike