From katzj at redhat.com Tue Jan 3 17:28:45 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 03 Jan 2006 12:28:45 -0500 Subject: Reminder: FC5 Test2 Freeze Message-ID: <1136309325.6621.1.camel@bree.local.net> Reminder that the freeze for FC5 test2 is scheduled for Monday, January 9th. All string changes need to be complete by this time so that the translators can get translations in for testing in test3. As always, the schedule can be found at http://fedora.redhat.com/About/schedule/ Jeremy From tburke at redhat.com Tue Jan 3 17:39:19 2006 From: tburke at redhat.com (Tim Burke) Date: Tue, 03 Jan 2006 12:39:19 -0500 Subject: Fedora general improvements input survey invitation In-Reply-To: <437D3B1D.7050007@redhat.com> References: <437D3B1D.7050007@redhat.com> Message-ID: <43BAB6C7.4000509@redhat.com> Tim Burke wrote: > The Fedora Core team invites you to participate in a survey to help > identify the major ways in which Fedora can be improved for the > benefit of the community. The survey consists of 10 questions > involving Fedora Core and Fedora Extras. We are greatly interested in > your views and hope you can share your thoughts with us. > Thanks in advance for helping us to make Fedora better for all > involved. Upon conclusion of the survey, a summary of the results > will be shared. > > Hi Everyone, I hope you all had a great holiday. Sorry for the delay, and a sincere thanks to all who participated in the survey. The results of this survey are hung off the fedoraproject.org marketing page under a feedback section. http://fedoraproject.org/wiki/Marketing/Fedora From smooge at gmail.com Tue Jan 3 17:59:41 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 3 Jan 2006 10:59:41 -0700 Subject: Fedora general improvements input survey invitation In-Reply-To: <43BAB6C7.4000509@redhat.com> References: <437D3B1D.7050007@redhat.com> <43BAB6C7.4000509@redhat.com> Message-ID: <80d7e4090601030959n122a023eqac8ef91af50dd920@mail.gmail.com> On 1/3/06, Tim Burke wrote: > Tim Burke wrote: > > > The Fedora Core team invites you to participate in a survey to help > > identify the major ways in which Fedora can be improved for the > > benefit of the community. The survey consists of 10 questions > > involving Fedora Core and Fedora Extras. We are greatly interested in > > your views and hope you can share your thoughts with us. > > > > > Thanks in advance for helping us to make Fedora better for all > > involved. Upon conclusion of the survey, a summary of the results > > will be shared. > > > > > Hi Everyone, > > I hope you all had a great holiday. Sorry for the delay, and a sincere > thanks to all who participated in the survey. The results of this > survey are hung off the fedoraproject.org marketing page under a > feedback section. That would be http://fedoraproject.org/wiki/Marketing/Fedora for those who get lost in the wiki. > > http://fedoraproject.org/wiki/Marketing/Fedora > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Stephen J Smoogen. CSIRT/Linux System Administrator From SteveD at redhat.com Tue Jan 3 18:55:59 2006 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 03 Jan 2006 13:55:59 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. Message-ID: <43BAC8BF.7090408@RedHat.com> Hello, Over the last year or so there has been a number of libraries added nfs-utils rm for the v4 and gssapi support as well as an upstream lib (libevent) that is not in the FC release. In the past, to include the functionality of these libraries, I have been hacking the makefile of these libs and of the daemons that needed these libs to link everything statically.... This does work but its a major pain to upgrade plus the binaries are getting a bit large.... so... I would like to break up the current nfs-utils into three different rpms: nfs-utils - would include the daemons and init scripts nfs-utils-libs - libnfsidmap.so, libgssapi.so, librpcsecgss.so nfs-utils-devel - header files that a currently installed My questions are: 1) Does this sound reasonable? 2) I know there is a number of packages that do this but is there a package that does it the "right way" that I can use as an example? 3) How do I get the new rpms include in the distro? 4) The needed upstream library, libevent, should that be included in the nfs-utils rpm or should it be in its own or include in another rpm? 5) anything I'm missing?? tia, steved. From rdieter at math.unl.edu Tue Jan 3 21:14:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 03 Jan 2006 15:14:08 -0600 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BAC8BF.7090408@RedHat.com> References: <43BAC8BF.7090408@RedHat.com> Message-ID: <43BAE920.5070703@math.unl.edu> Steve Dickson wrote: > Over the last year or so there has been > a number of libraries added nfs-utils rm for > the v4 and gssapi support as well as an > upstream lib (libevent) that is not in > the FC release. ... > I would like to break up the current nfs-utils > into three different rpms: > > nfs-utils - would include the daemons and init scripts > nfs-utils-libs - libnfsidmap.so, libgssapi.so, librpcsecgss.so > nfs-utils-devel - header files that a currently installed > My questions are: > > 1) Does this sound reasonable? -devel makes sense. -libs makes sense only if you need the libs separated (ie, multi-arch), else just keep the libraries in the core nfs-utils pkg. > 2) I know there is a number of packages that do > this but is there a package that does it > the "right way" that I can use as an example? This method is as good as any. > 4) The needed upstream library, libevent, should that > be included in the nfs-utils rpm or should it be > in its own or include in another rpm? IMO, if upstream packages it(libevent) separately, so should you. -- Rex From skvidal at linux.duke.edu Tue Jan 3 21:35:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 03 Jan 2006 16:35:30 -0500 Subject: buildsys.fedoraproject.org downtime Message-ID: <1136324131.10551.47.camel@cutter> Hi Folks, Some network reconfiguration at Duke will take buildsys.fedoraproject.org down for hopefully only an hour this sunday: Beginning: 01/08/06 05:00am EDT Ending: 01/08/06 06:00am EDT Summary: Data Center network re-configuration During this time it won't be possible to submit jobs to the fedora extras build system. Thanks, -sv -------------- 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 Tue Jan 3 21:57:28 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 03 Jan 2006 22:57:28 +0100 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BAC8BF.7090408@RedHat.com> (Steve Dickson's message of "Tue, 03 Jan 2006 13:55:59 -0500") References: <43BAC8BF.7090408@RedHat.com> Message-ID: <87zmmdrn3r.fsf@kosh.bigo.ensc.de> SteveD at redhat.com (Steve Dickson) writes: > Over the last year or so there has been a number of libraries added > nfs-utils rm for the v4 and gssapi support as well as an upstream lib > (libevent) that is not in the FC release. > ... > I would like to break up the current nfs-utils > into three different rpms: > > nfs-utils - would include the daemons and init scripts > nfs-utils-libs - libnfsidmap.so, libgssapi.so, librpcsecgss.so > nfs-utils-devel - header files that a currently installed > > My questions are: > > 1) Does this sound reasonable? It everytime a good idea to split libraries and programs when there might be other packages using the libs. Else, monolithic packages might/will add of unneeded stuff or even dependencies to packages needing the libs only. An example for such a packaging bug is 'aspell': its libraries are used by foreign programs but you have to install 50 MB of unwanted bloat (perl, dictionaries) because the 'aspell' package was not split. > 4) The needed upstream library, libevent, should that be included in > the nfs-utils rpm or should it be in its own or include in another > rpm? afaik, there is already 'libevent' in Extras; when needed by nfs-utils this package should be moved to Core. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From SteveD at redhat.com Wed Jan 4 00:25:08 2006 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 03 Jan 2006 19:25:08 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <87zmmdrn3r.fsf@kosh.bigo.ensc.de> References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> Message-ID: <43BB15E4.4070208@RedHat.com> Enrico Scholz wrote: >>4) The needed upstream library, libevent, should that be included in >> the nfs-utils rpm or should it be in its own or include in another >> rpm? > > > afaik, there is already 'libevent' in Extras; when needed by nfs-utils > this package should be moved to Core. sweat! Well nfs-utils has needed since FC2... So how do I make this happen? steved. From SteveD at redhat.com Wed Jan 4 00:35:20 2006 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 03 Jan 2006 19:35:20 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <87zmmdrn3r.fsf@kosh.bigo.ensc.de> References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> Message-ID: <43BB1848.3070203@RedHat.com> Enrico Scholz wrote: > It everytime a good idea to split libraries and programs when there might > be other packages using the libs. Else, monolithic packages might/will > add of unneeded stuff or even dependencies to packages needing the libs > only. Ok another question... the autoconf files that build the nfs daemons and commands expect the needed libraries to be already installed on the build machine. So my question is, when I build things, should I change the autoconf file so that the build points to the libraries (and header files) in the build tree or should I require nfs-utils-lib to be installed on the build machine (i.e. Requires: nfs-utils-lib). I guess would guess its the former but I just want to make sure I'm doing things in the normal or expected way.... tia, steved. From pjones at redhat.com Wed Jan 4 16:30:43 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 04 Jan 2006 11:30:43 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BB1848.3070203@RedHat.com> References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> <43BB1848.3070203@RedHat.com> Message-ID: <1136392243.2840.15.camel@localhost.localdomain> On Tue, 2006-01-03 at 19:35 -0500, Steve Dickson wrote: > Enrico Scholz wrote: > > It everytime a good idea to split libraries and programs when there might > > be other packages using the libs. Else, monolithic packages might/will > > add of unneeded stuff or even dependencies to packages needing the libs > > only. > Ok another question... the autoconf files that build the nfs daemons > and commands expect the needed libraries to be already installed > on the build machine. So my question is, when I build things, should > I change the autoconf file so that the build points to the libraries > (and header files) in the build tree or should I require nfs-utils-lib > to be installed on the build machine (i.e. Requires: nfs-utils-lib). > > I guess would guess its the former but I just want to make sure > I'm doing things in the normal or expected way.... Definitely the former, or else you'd have to split out the source rpms too, not just the resultant binaries. And that's almost certainly not the intent. -- Peter From SteveD at redhat.com Wed Jan 4 16:37:02 2006 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 04 Jan 2006 11:37:02 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <1136392243.2840.15.camel@localhost.localdomain> References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> <43BB1848.3070203@RedHat.com> <1136392243.2840.15.camel@localhost.localdomain> Message-ID: <43BBF9AE.7020207@RedHat.com> Peter Jones wrote: > On Tue, 2006-01-03 at 19:35 -0500, Steve Dickson wrote: > >>Enrico Scholz wrote: >> >>>It everytime a good idea to split libraries and programs when there might >>>be other packages using the libs. Else, monolithic packages might/will >>>add of unneeded stuff or even dependencies to packages needing the libs >>>only. >> >>Ok another question... the autoconf files that build the nfs daemons >>and commands expect the needed libraries to be already installed >>on the build machine. So my question is, when I build things, should >>I change the autoconf file so that the build points to the libraries >>(and header files) in the build tree or should I require nfs-utils-lib >>to be installed on the build machine (i.e. Requires: nfs-utils-lib). >> >>I guess would guess its the former but I just want to make sure >>I'm doing things in the normal or expected way.... > > > Definitely the former, or else you'd have to split out the source rpms > too, not just the resultant binaries. And that's almost certainly not > the intent. The only problems is the top configure.in uses the AC_CHECK_LIB() and AC_CHECK_HEADERS() macros to see if certain libraries and header files are installed... I'm really not sure how to deal with those other than commenting them out before the autoconf is done... steved. From SteveD at redhat.com Wed Jan 4 17:15:22 2006 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 04 Jan 2006 12:15:22 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BBF9AE.7020207@RedHat.com> References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> <43BB1848.3070203@RedHat.com> <1136392243.2840.15.camel@localhost.localdomain> <43BBF9AE.7020207@RedHat.com> Message-ID: <43BC02AA.20203@RedHat.com> Steve Dickson wrote: > > > Peter Jones wrote: > >> On Tue, 2006-01-03 at 19:35 -0500, Steve Dickson wrote: >> >>> Enrico Scholz wrote: >>> >>>> It everytime a good idea to split libraries and programs when there >>>> might >>>> be other packages using the libs. Else, monolithic packages might/will >>>> add of unneeded stuff or even dependencies to packages needing the libs >>>> only. >>> >>> >>> Ok another question... the autoconf files that build the nfs daemons >>> and commands expect the needed libraries to be already installed >>> on the build machine. So my question is, when I build things, should >>> I change the autoconf file so that the build points to the libraries >>> (and header files) in the build tree or should I require nfs-utils-lib >>> to be installed on the build machine (i.e. Requires: nfs-utils-lib). >>> >>> I guess would guess its the former but I just want to make sure >>> I'm doing things in the normal or expected way.... >> >> >> >> Definitely the former, or else you'd have to split out the source rpms >> too, not just the resultant binaries. And that's almost certainly not >> the intent. > > The only problems is the top configure.in uses the > AC_CHECK_LIB() and AC_CHECK_HEADERS() macros to see if > certain libraries and header files are installed... > > I'm really not sure how to deal with those other than > commenting them out before the autoconf is done... Well taking with Nalin, what appears to make the most sense is to create separate rpms for libnfsidmap.so, libgssapi.so, librpcsecgss.so which will need to exist on the build machine. (Note: if I can combine libgssapi.so and librpcsecgss.so, I will) The theory is that since they are separate (standalone) source releases and only I'm breaking up an existing rpm into an number of smaller rpms there should not be any push back on getting these new rpms into both FC and RHEL releases... If this theory is flawed, please let me know asap... steved. From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 4 17:25:15 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Jan 2006 18:25:15 +0100 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BBF9AE.7020207@RedHat.com> (Steve Dickson's message of "Wed, 04 Jan 2006 11:37:02 -0500") References: <43BAC8BF.7090408@RedHat.com> <87zmmdrn3r.fsf@kosh.bigo.ensc.de> <43BB1848.3070203@RedHat.com> <1136392243.2840.15.camel@localhost.localdomain> <43BBF9AE.7020207@RedHat.com> Message-ID: <87k6dfsy6c.fsf@kosh.bigo.ensc.de> SteveD at redhat.com (Steve Dickson) writes: > The only problems is the top configure.in uses the AC_CHECK_LIB() and > AC_CHECK_HEADERS() macros to see if certain libraries and header files > are installed... I am not sure whether this is really needed in this case, but most of such autoconf checks can be overridden by setting 'ac_cv_header_XXX' or 'ac_cv_lib_XXX' variables before running %configure. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tcallawa at redhat.com Thu Jan 5 19:17:31 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 05 Jan 2006 13:17:31 -0600 Subject: Packaging/Review Guidelines change Message-ID: <1136488651.2369.146.camel@localhost.localdomain> As approved by FESCO today, the following change to the Fedora Extras Packaging and Review Guidelines is now in effect: MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora Extras should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. This is a policy that has been enforced for sometime, but never actually added to the guidelines (until now). Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From fedora at leemhuis.info Fri Jan 6 10:41:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Jan 2006 11:41:02 +0100 Subject: Heads-up: "RFC: kernel-modules in Fedora Extras" now on fedora-extras-list In-Reply-To: <1136543456.3146.19.camel@localhost.localdomain> References: <1136543456.3146.19.camel@localhost.localdomain> Message-ID: <1136544062.3146.30.camel@localhost.localdomain> Hi all! Sorry for crossposting, but I think a short heads-up is needed here. The Fedora Extras Steering Committee (FESCo) agreed on a standard for packaging kernel-modules in Fedora Extras. To look at the details see this mail: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00219.html The last chance to comment on it before it is getting used in devel/FC5 is: Now. Please use fedora-extras-list for the discussion -- please don't reply to this mail on this list. Instead click on reply and change the To: field to fedora-extras-list at redhat.com (the threading hopefully should work fine if you do it like this). Thanks! CU thl -- Thorsten Leemhuis From SteveD at redhat.com Fri Jan 6 23:09:29 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 06 Jan 2006 18:09:29 -0500 Subject: [RFC] Braking nfs-utils into -devel and -libs rpms. In-Reply-To: <43BAC8BF.7090408@RedHat.com> References: <43BAC8BF.7090408@RedHat.com> Message-ID: <43BEF8A9.1040701@RedHat.com> Ok here is how things shook out... First of all, thanks Nalin for your help and guidance it was much appreciated! the nfs-utils rpm is now dependent on * lib-event * nfs-utils-lib-devel (for building) * nfs-utils-lib (for runtime) The nfs-utils-lib-devel rpm is dependent on * nfs-utils-lib (for runtime) The nfs-utils-lib rpm is dependent on * libgssapi-devel (for building) * libgssapi (for runtime) The libgssapi-devel rpm is dependent on * libgssapi (for runtime) The libgssapi rpm is dependent on * krb5-libs (for runtime) Now what need to happen, something I can not do myself, is: 1) Move the lib-event from extra into core 2) Added both libgssapi and nfs-utils-lib to the Core or dist list. Note: I've already check both the libgssapi and nfs-utils-lib source rpms in to the CVS tree but I was unable to build them in beehive due to the "Specified package is not listed in the `dist' collection" error... Note2: This is all the same nfs-utils code that is in test1, its just now broken out into different rpms, which will make it much, much, much, much more manageable... Note3: I have done unit test of both the v4 and secure nfs code with no sign of regressions... at least not yet... ;-) So, How long will it take of the above to steps to happen? I would like to make the commits to nfs-utils and get some more testing asap... tia, steved. From jspaleta at gmail.com Sat Jan 7 04:38:04 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 6 Jan 2006 23:38:04 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <1136488651.2369.146.camel@localhost.localdomain> References: <1136488651.2369.146.camel@localhost.localdomain> Message-ID: <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> On 1/5/06, Tom 'spot' Callaway wrote: > This is a policy that has been enforced for sometime, but never actually > added to the guidelines (until now). Just a thought.... how exactly are we expect as reviewers to check for this? Basically what this says is new package foo shouldn't own a pre-existing package called baz. Doesn't this effectively require a way to check the full package space in Core+Extras to see if a directory is own by a pre-existing package? Not just whatever we happen to have installed on the system we are doing the review on... but all fedora packages regardless of whether they are installed or not. Can this be done with repoquery(which isn't working on rawhide systems at the momment if i recall correctly) I'm not sure this "MUST" can be effectively reviewed or enforced as written, unless repoquery can be used to ask "what other packages in the tree own this directory" -jef From jspaleta at gmail.com Sat Jan 7 04:54:45 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 6 Jan 2006 23:54:45 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> Message-ID: <604aa7910601062054p1b80938aka4ddfb0709c79af1@mail.gmail.com> On 1/6/06, Jeff Spaleta wrote: > Just a thought.... how exactly are we expect as reviewers to check for this? > Basically what this says is new package foo shouldn't own a > pre-existing package called baz. err...i meant to say foo shouldn't own a directory from a pre-existing package called baz -jef From pmatilai at laiskiainen.org Sun Jan 8 09:57:23 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 8 Jan 2006 01:57:23 -0800 (PST) Subject: Packaging/Review Guidelines change In-Reply-To: <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> Message-ID: On Fri, 6 Jan 2006, Jeff Spaleta wrote: > On 1/5/06, Tom 'spot' Callaway wrote: >> This is a policy that has been enforced for sometime, but never actually >> added to the guidelines (until now). > > > Just a thought.... how exactly are we expect as reviewers to check for this? > Basically what this says is new package foo shouldn't own a > pre-existing package called baz. > Doesn't this effectively require a way to check the full package space > in Core+Extras to see if a directory is own by a pre-existing package? > Not just whatever we happen to have installed on the system we are > doing the review on... but all fedora packages regardless of whether > they are installed or not. Can this be done with repoquery(which > isn't working on rawhide systems at the momment if i recall > correctly) I'm not sure this "MUST" can be effectively reviewed or > enforced as written, unless repoquery can be used to ask "what other > packages in the tree own this directory" You can do something like this: repoquery `rpm -qpl .rpm` If you get any output, you have overlapping files/directories with those packages. The CVS HEAD of yum-utils has repoquery which works on both FC4 and rawhide, we've been planning on doing a new release for some time now. I'll try to push things forward wrt that next week. - Panu - From pmatilai at laiskiainen.org Sun Jan 8 10:01:54 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 8 Jan 2006 02:01:54 -0800 (PST) Subject: Packaging/Review Guidelines change In-Reply-To: References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> Message-ID: On Sun, 8 Jan 2006, Panu Matilainen wrote: > > You can do something like this: > repoquery `rpm -qpl .rpm` Argh. should be "repoquery -f `rpm -qpl .rpm`" of course. Duh, time to make more coffee... - Panu - From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 8 10:32:18 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 08 Jan 2006 11:32:18 +0100 Subject: Packaging/Review Guidelines change In-Reply-To: <1136488651.2369.146.camel@localhost.localdomain> (Tom Callaway's message of "Thu, 05 Jan 2006 13:17:31 -0600") References: <1136488651.2369.146.camel@localhost.localdomain> Message-ID: <87d5j3qabx.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > MUST: Packages must not own files or directories already owned by > other packages. The rule of thumb here is that the first package to be > installed should own the files or directories that other packages may > rely upon. This means, for example, that no package in Fedora Extras > should ever share ownership with any of the files or directories owned > by the filesystem or man package. If you feel that you have a good > reason to own a file or directory that another package owns, then > please present that at package review time. > > This is a policy that has been enforced for sometime, but never actually > added to the guidelines (until now). What is with directories like /usr/share/locale/C /usr/share/locale/nl_BE /usr/share/locale/uk_UA ? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jspaleta at gmail.com Sun Jan 8 17:50:15 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Jan 2006 12:50:15 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> Message-ID: <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> On 1/8/06, Panu Matilainen wrote: > Argh. should be "repoquery -f `rpm -qpl .rpm`" of course. > Duh, time to make more coffee... I believe that this addition to review policy is the first one which requires use of repoquery to explore the existing repospace in order to properly perform the review. The existance of repoquery and how to use it for this specific review item should probably be added to the review guidelines page. -jef From nicolas.mailhot at laposte.net Sun Jan 8 18:21:16 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 08 Jan 2006 19:21:16 +0100 Subject: Packaging/Review Guidelines change In-Reply-To: <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> Message-ID: <1136744476.3362.1.camel@rousalka.dyndns.org> Le dimanche 08 janvier 2006 ? 12:50 -0500, Jeff Spaleta a ?crit : > On 1/8/06, Panu Matilainen wrote: > > Argh. should be "repoquery -f `rpm -qpl .rpm`" of course. > > Duh, time to make more coffee... > > I believe that this addition to review policy is the first one which > requires use of repoquery to explore the existing repospace in order > to properly perform the review. The existance of repoquery and how to > use it for this specific review item should probably be added to the > review guidelines page. Well, if Fedora is serious about this rule, should not Fedora's rpm be patched to emit a warning when operating on a dir owned by something else ? This is the only real way conflicts will be caught 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 paul at city-fan.org Sun Jan 8 18:52:03 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 08 Jan 2006 18:52:03 +0000 Subject: Packaging/Review Guidelines change In-Reply-To: <1136744476.3362.1.camel@rousalka.dyndns.org> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> Message-ID: <1136746323.28374.84.camel@laurel.intra.city-fan.org> On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > Le dimanche 08 janvier 2006 ? 12:50 -0500, Jeff Spaleta a ?crit : > > On 1/8/06, Panu Matilainen wrote: > > > Argh. should be "repoquery -f `rpm -qpl .rpm`" of course. > > > Duh, time to make more coffee... > > > > I believe that this addition to review policy is the first one which > > requires use of repoquery to explore the existing repospace in order > > to properly perform the review. The existance of repoquery and how to > > use it for this specific review item should probably be added to the > > review guidelines page. > > Well, if Fedora is serious about this rule, should not Fedora's rpm be > patched to emit a warning when operating on a dir owned by something > else ? I don't think so, since as has been discussed earlier, exceptions to this rule will be very common (e.g. perl modules). Paul. From pjones at redhat.com Mon Jan 9 04:51:23 2006 From: pjones at redhat.com (Peter Jones) Date: Sun, 08 Jan 2006 23:51:23 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <1136744476.3362.1.camel@rousalka.dyndns.org> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> Message-ID: <1136782284.11848.3.camel@localhost.localdomain> On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > Well, if Fedora is serious about this rule, should not Fedora's rpm be > patched to emit a warning when operating on a dir owned by something > else ? rpm knows about packages, not repos. -- Peter From skvidal at linux.duke.edu Mon Jan 9 05:09:21 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 09 Jan 2006 00:09:21 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <1136782284.11848.3.camel@localhost.localdomain> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> Message-ID: <1136783362.15724.10.camel@cutter> On Sun, 2006-01-08 at 23:51 -0500, Peter Jones wrote: > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > > > Well, if Fedora is serious about this rule, should not Fedora's rpm be > > patched to emit a warning when operating on a dir owned by something > > else ? > > rpm knows about packages, not repos. there's a thought that maybe fedora should think about discouraging the use of rpm as a command get people to use things like repoquery more. -sv From sundaram at redhat.com Mon Jan 9 05:11:19 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 10:41:19 +0530 Subject: Packaging/Review Guidelines change In-Reply-To: <1136783362.15724.10.camel@cutter> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <1136783362.15724.10.camel@cutter> Message-ID: <43C1F077.3090200@redhat.com> seth vidal wrote: >On Sun, 2006-01-08 at 23:51 -0500, Peter Jones wrote: > > >>On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: >> >> >> >>>Well, if Fedora is serious about this rule, should not Fedora's rpm be >>>patched to emit a warning when operating on a dir owned by something >>>else ? >>> >>> >>rpm knows about packages, not repos. >> >> > >there's a thought that maybe fedora should think about discouraging the >use of rpm as a command get people to use things like repoquery more. > >-sv > Formal docs in Fedora(http://fedora.redhat.com/docs) shouldnt be usually referring to RPM commands at all anymore but there are things like rpm -ql which are quite useful and dont have a yum equivalent. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From skvidal at linux.duke.edu Mon Jan 9 05:20:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 09 Jan 2006 00:20:08 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <43C1F077.3090200@redhat.com> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <1136783362.15724.10.camel@cutter> <43C1F077.3090200@redhat.com> Message-ID: <1136784009.15724.12.camel@cutter> > > > Formal docs in Fedora(http://fedora.redhat.com/docs) shouldnt be usually > referring to RPM commands at all anymore but there are things like rpm > -ql which are quite useful and dont have a yum equivalent. repoquery is the yum equivalent, really. it can do -ql on local or remote packages -sv From sundaram at redhat.com Mon Jan 9 05:28:10 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 10:58:10 +0530 Subject: Packaging/Review Guidelines change In-Reply-To: <1136784009.15724.12.camel@cutter> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <1136783362.15724.10.camel@cutter> <43C1F077.3090200@redhat.com> <1136784009.15724.12.camel@cutter> Message-ID: <43C1F46A.8030007@redhat.com> seth vidal wrote: >>Formal docs in Fedora(http://fedora.redhat.com/docs) shouldnt be usually >>referring to RPM commands at all anymore but there are things like rpm >>-ql which are quite useful and dont have a yum equivalent. >> >> > >repoquery is the yum equivalent, really. > >it can do -ql on local or remote packages > >-sv > The functionality offered by utilities packaged in yum-utils is mostly unknown since they are relatively new, dont have man pages, not installed by default and not prominently visible in yum's website. Moreover they arent in sync with yum currently and most of them dont work in rawhide. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From nicolas.mailhot at laposte.net Mon Jan 9 09:54:26 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 9 Jan 2006 10:54:26 +0100 (CET) Subject: Packaging/Review Guidelines change In-Reply-To: <1136782284.11848.3.camel@localhost.localdomain> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> Message-ID: <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> On Lun 9 janvier 2006 05:51, Peter Jones wrote: > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > >> Well, if Fedora is serious about this rule, should not Fedora's rpm be >> patched to emit a warning when operating on a dir owned by something >> else ? > > rpm knows about packages, not repos. rpm knows about its db state when performing installations/uninstallations. I meant a warning at rpm -U/-i or -e time not at rpmbuild time -- Nicolas Mailhot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 9 10:57:33 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 Jan 2006 11:57:33 +0100 Subject: Packaging/Review Guidelines change In-Reply-To: <87d5j3qabx.fsf@kosh.bigo.ensc.de> References: <1136488651.2369.146.camel@localhost.localdomain> <87d5j3qabx.fsf@kosh.bigo.ensc.de> Message-ID: <20060109115733.0a896615@python2> Enrico Scholz wrote : > tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > > > MUST: Packages must not own files or directories already owned by > > other packages. The rule of thumb here is that the first package to be > > installed should own the files or directories that other packages may > > rely upon. This means, for example, that no package in Fedora Extras > > should ever share ownership with any of the files or directories owned > > by the filesystem or man package. If you feel that you have a good > > reason to own a file or directory that another package owns, then > > please present that at package review time. > > > > This is a policy that has been enforced for sometime, but never actually > > added to the guidelines (until now). > > What is with directories like > > /usr/share/locale/C > /usr/share/locale/nl_BE > /usr/share/locale/uk_UA My guess : Let %find_lang do its magic for these, and if it owns them, then get that macro fixed ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1653_FC4 Load : 1.61 1.52 0.92 From pjones at redhat.com Mon Jan 9 15:16:40 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 09 Jan 2006 10:16:40 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> Message-ID: <1136819800.16127.1.camel@localhost.localdomain> On Mon, 2006-01-09 at 10:54 +0100, Nicolas Mailhot wrote: > On Lun 9 janvier 2006 05:51, Peter Jones wrote: > > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > > > >> Well, if Fedora is serious about this rule, should not Fedora's rpm be > >> patched to emit a warning when operating on a dir owned by something > >> else ? > > > > rpm knows about packages, not repos. > > rpm knows about its db state when performing installations/uninstallations. > > I meant a warning at rpm -U/-i or -e time not at rpmbuild time Then you're notifying the wrong people that something is wrong. If you're going to automagically probe for this and raise some error/warning/notification, it needs to happen when the package is added to a repo. Before then it's incorrect, and after then it doesn't help to know it's busted. -- Peter From nicolas.mailhot at laposte.net Mon Jan 9 15:51:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 9 Jan 2006 16:51:35 +0100 (CET) Subject: Packaging/Review Guidelines change In-Reply-To: <1136819800.16127.1.camel@localhost.localdomain> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> <1136819800.16127.1.camel@localhost.localdomain> Message-ID: <31376.192.54.193.25.1136821895.squirrel@rousalka.dyndns.org> On Lun 9 janvier 2006 16:16, Peter Jones wrote: > On Mon, 2006-01-09 at 10:54 +0100, Nicolas Mailhot wrote: >> On Lun 9 janvier 2006 05:51, Peter Jones wrote: >> > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: >> > >> >> Well, if Fedora is serious about this rule, should not Fedora's rpm >> be >> >> patched to emit a warning when operating on a dir owned by something >> >> else ? >> > >> > rpm knows about packages, not repos. >> >> rpm knows about its db state when performing >> installations/uninstallations. >> >> I meant a warning at rpm -U/-i or -e time not at rpmbuild time > > Then you're notifying the wrong people that something is wrong. Do you really believe it's not the user problem if its system is about to switch to a state where we know problem may happen ? > If > you're going to automagically probe for this and raise some > error/warning/notification, it needs to happen when the package is added > to a repo. Sure > Before then it's incorrect, Why ? > and after then it doesn't help to know it's busted. Of course it helps, do you really believe we catch every problem at the packaging stage ? You could as well advocate removal of every single warning/error in live systems, since problems should be fixed before software is shipped (in an ideal lalala world) Regards, -- Nicolas Mailhot From pjones at redhat.com Mon Jan 9 16:14:24 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 09 Jan 2006 11:14:24 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <31376.192.54.193.25.1136821895.squirrel@rousalka.dyndns.org> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> <1136819800.16127.1.camel@localhost.localdomain> <31376.192.54.193.25.1136821895.squirrel@rousalka.dyndns.org> Message-ID: <1136823264.16127.8.camel@localhost.localdomain> On Mon, 2006-01-09 at 16:51 +0100, Nicolas Mailhot wrote: > On Lun 9 janvier 2006 16:16, Peter Jones wrote: > > On Mon, 2006-01-09 at 10:54 +0100, Nicolas Mailhot wrote: > >> On Lun 9 janvier 2006 05:51, Peter Jones wrote: > >> > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: > >> > > >> >> Well, if Fedora is serious about this rule, should not Fedora's rpm > >> be > >> >> patched to emit a warning when operating on a dir owned by something > >> >> else ? > >> > > >> > rpm knows about packages, not repos. > >> > >> rpm knows about its db state when performing > >> installations/uninstallations. > >> > >> I meant a warning at rpm -U/-i or -e time not at rpmbuild time > > > > Then you're notifying the wrong people that something is wrong. > > Do you really believe it's not the user problem if its system is about to > switch to a state where we know problem may happen ? I really don't think this ever hurts a user, it's just a matter of tidiness. But more to the point, we can't restrict this sort of thing in other repos a user may be using, and we'll never be able to. I don't like spending effort on something we really can't address in any meaningful way. It's a policy for the repo, about the repo, regarding how packages that are part of the repo should behave. It is only a problem in the context of the repo. The checking belongs in the relationship between a package and the repo. Nowhere else. > > If > > you're going to automagically probe for this and raise some > > error/warning/notification, it needs to happen when the package is added > > to a repo. > > Sure > > > Before then it's incorrect, > > Why ? Because a single package can't conflict with itself in this way? The entire notion of the problem only exists within the context of a repo. You can't tell that a package is violating the rule unless you know where the package is going. Furthermore, the installed set of packages may not be a reliable source for what is and isn't going to be in the repo -- think about Obsoletes: . > > and after then it doesn't help to know it's busted. > > Of course it helps, do you really believe we catch every problem at the > packaging stage ? I really think we can throw an error when you try to add something broken to the repository. > You could as well advocate removal of every single > warning/error in live systems, since problems should be fixed before > software is shipped (in an ideal lalala world) This would be a warning message that's only useful to developers. As such, we should not be displaying it during installation, as it only serves to confuse most users. -- Peter From nicolas.mailhot at laposte.net Tue Jan 10 09:20:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Jan 2006 10:20:53 +0100 (CET) Subject: Packaging/Review Guidelines change In-Reply-To: <1136823264.16127.8.camel@localhost.localdomain> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601062038w407316ebr681404a93bd73951@mail.gmail.com> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> <1136819800.16127.1.camel@localhost.localdomain> <31376.192.54.193.25.1136821895.squirrel@rousalka.dyndns.org> <1136823264.16127.8.camel@localhost.localdomain> Message-ID: <51241.192.54.193.25.1136884853.squirrel@rousalka.dyndns.org> On Lun 9 janvier 2006 17:14, Peter Jones wrote: > On Mon, 2006-01-09 at 16:51 +0100, Nicolas Mailhot wrote: >> On Lun 9 janvier 2006 16:16, Peter Jones wrote: >> > On Mon, 2006-01-09 at 10:54 +0100, Nicolas Mailhot wrote: >> >> On Lun 9 janvier 2006 05:51, Peter Jones wrote: >> >> > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote: >> >> > >> >> >> Well, if Fedora is serious about this rule, should not Fedora's >> rpm >> >> be >> >> >> patched to emit a warning when operating on a dir owned by >> something >> >> >> else ? >> >> > >> >> > rpm knows about packages, not repos. >> >> >> >> rpm knows about its db state when performing >> >> installations/uninstallations. >> >> >> >> I meant a warning at rpm -U/-i or -e time not at rpmbuild time >> > >> > Then you're notifying the wrong people that something is wrong. >> >> Do you really believe it's not the user problem if its system is about >> to >> switch to a state where we know problem may happen ? > > I really don't think this ever hurts a user, it's just a matter of > tidiness. But more to the point, we can't restrict this sort of thing > in other repos a user may be using, and we'll never be able to. I don't > like spending effort on something we really can't address in any > meaningful way. > > It's a policy for the repo, about the repo, regarding how packages that > are part of the repo should behave. It is only a problem in the context > of the repo. Pure Fedora repo installs do not exist in real life. Even among FE packagers. Even I'd wager on Seth systems. What matters is installed systems. Everything else is mental masturbation no one sane should spend time on. > The checking belongs in the relationship between a package> > and the repo. Nowhere else. Repo checks by themselves have zero zip nill interest if they do not translate to real system checks at some point in time. >> > If >> > you're going to automagically probe for this and raise some >> > error/warning/notification, it needs to happen when the package is >> added >> > to a repo. >> >> Sure >> >> > Before then it's incorrect, >> >> Why ? > > Because a single package can't conflict with itself in this way? The > entire notion of the problem only exists within the context of a repo. > You can't tell that a package is violating the rule unless you know > where the package is going. Furthermore, the installed set of packages > may not be a reliable source for what is and isn't going to be in the > repo -- think about Obsoletes: . You're building on a particular system for the same kind of system. If the build system is not clean enough for your tastes, you can use mach. There's so many ways the build system can influence the build result it's not even fun pretending it's worth ignoring some part of it because the install system will be "different" >> > and after then it doesn't help to know it's busted. >> >> Of course it helps, do you really believe we catch every problem at the >> packaging stage ? > > I really think we can throw an error when you try to add something > broken to the repository. > >> You could as well advocate removal of every single >> warning/error in live systems, since problems should be fixed before >> software is shipped (in an ideal lalala world) > > This would be a warning message that's only useful to developers. As > such, we should not be displaying it during installation, as it only > serves to confuse most users. Who will report it which will enable someone to fix it. Either this is a real problem and it needs to be checked in real life (ie on the live system), or it's not and worrying about this point is useless. And the whole if ! bugs_I_m_interested_in do_not_warn_user is pretty disgusting if you want my opinion. We're here to support users not the other way around. Warning/error filtering should be based on user needs not Fedora packager needs. Users do not care if a potential problem has its root in Fedora or another repo. If the conflict if with a non-Fedora package it's perfectly ok to redirect users to the packagers of this third-party package. And that's assuming rpm will only catch errors with third-party packages. I'm far from confident the FE review process won't let some mistakes pass through And third party repos also means all the repos which eventually merge with Fedora (people.redhat.com repos, jpackage, etc) so letting packages rot there when we could have them fixed as soon as a problem is introduced is no t particularly productive. -- Nicolas Mailhot From jspaleta at gmail.com Tue Jan 10 14:19:51 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jan 2006 09:19:51 -0500 Subject: Packaging/Review Guidelines change In-Reply-To: <51241.192.54.193.25.1136884853.squirrel@rousalka.dyndns.org> References: <1136488651.2369.146.camel@localhost.localdomain> <604aa7910601080950o5420f2d7v14f658f295a3f55@mail.gmail.com> <1136744476.3362.1.camel@rousalka.dyndns.org> <1136782284.11848.3.camel@localhost.localdomain> <44644.192.54.193.37.1136800466.squirrel@rousalka.dyndns.org> <1136819800.16127.1.camel@localhost.localdomain> <31376.192.54.193.25.1136821895.squirrel@rousalka.dyndns.org> <1136823264.16127.8.camel@localhost.localdomain> <51241.192.54.193.25.1136884853.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601100619q41191de7n42028bd53a58aad@mail.gmail.com> On 1/10/06, Nicolas Mailhot wrote: > Pure Fedora repo installs do not exist in real life. -jef"I have a fedora pure system. Thus proving that I do not exist."spaleta From shahms at shahms.com Wed Jan 11 16:20:02 2006 From: shahms at shahms.com (Shahms King) Date: Wed, 11 Jan 2006 08:20:02 -0800 Subject: Cannot connect to build server Message-ID: <43C53032.8030609@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I keep getting the message: Error connecting to build server: '(-2, 'Name or service not known')' when trying to request a build. plague-client list_builders works, but plague-client list exits with: Error connecting to build server: '' So, whats up with the build server or is this due to some misconfiguration on my end? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDxTAy/qs2NkWy11sRAuOWAJ9QaLhmH7Sy5J7CPFDVIhNifV4MyQCcDtkU etK7J6V+ZqJMd25ViVAvoVw= =eVmF -----END PGP SIGNATURE----- From ville.skytta at iki.fi Thu Jan 12 16:35:07 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 12 Jan 2006 18:35:07 +0200 Subject: Cannot connect to build server In-Reply-To: <43C53032.8030609@shahms.com> References: <43C53032.8030609@shahms.com> Message-ID: <1137083707.19680.24.camel@bobcat.mine.nu> On Wed, 2006-01-11 at 08:20 -0800, Shahms King wrote: > Error connecting to build server: '(-2, 'Name or service not known')' I've seen these often in the past, and IIRC only with buildsys.fedoraproject.org (no problems noticed with other hostnames). Seth assisted in debugging it, but according to him, at that time everything looked ok. I grew tired of the failures and have had an entry for that hostname in /etc/hosts for quite some time now... From dennis at ausil.us Thu Jan 12 18:46:17 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Jan 2006 12:46:17 -0600 Subject: beagle Message-ID: <200601121246.17483.dennis@ausil.us> To make beagle as useful as possible it needs to be linked against some packages in extras. 1 is gnumetric to index spreadsheets 2 is wv to index word documents http://www.beagle-project.org/Optional_prerequisites ok looks like gnumetric is run time only so it should work as --enable-ssindex is enabled in gnumetric however end users may complain that indexing is not happening if they dont install gnumetric themselves. so wv would need to be added to core and to give users best experience gnumetric would need adding back so beagle could require it. a couple of things that bother me about beagle. and i could be wrong here. 1. there seems to be no way to index OpenDocument files. this is a big downer for me as i use them much more often than Word or excel. 2. it wants to link against older packages wv1 not wv2 sqlite2 not sqlite3 Dennis From gauret at free.fr Thu Jan 12 19:12:48 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 12 Jan 2006 20:12:48 +0100 Subject: beagle In-Reply-To: <200601121246.17483.dennis@ausil.us> References: <200601121246.17483.dennis@ausil.us> Message-ID: <200601122012.48843.gauret@free.fr> > so wv would need to be added to core and to give users best experience > gnumetric would need adding back so beagle could require it. Is beagle going to be in Core straight away ? I thought it would be in Extras first. In which case, no need to move packages around. > a couple of things that bother me about beagle. and i could be wrong > here. 1. there seems to be no way to index OpenDocument files. this is a > big downer for me as i use them much more often than Word or excel. Very strange, OpenDocuments are just zipped XML. Shouldn't be hard to index. > 2. it wants to link against older packages wv1 not wv2 sqlite2 not > sqlite3 I maintain wv in Extras. It's at version 1 for the moment, but I've had requests to upgrade it to version 2 (it can only be done in devel for the moment, because of dependencies). If Beagle requires wv < 2, I'll have to make a second package (wv2). Couldn't Beagle use wv2 ? Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr No, I coded it crappily on purpose, just so that I could say "There's plenty of room for optimization." From jspaleta at gmail.com Thu Jan 12 19:24:29 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jan 2006 14:24:29 -0500 Subject: beagle In-Reply-To: <200601121246.17483.dennis@ausil.us> References: <200601121246.17483.dennis@ausil.us> Message-ID: <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> On 1/12/06, Dennis Gilmore wrote: > To make beagle as useful as possible it needs to be linked against some > packages in extras. 1 is gnumetric to index spreadsheets 2 is wv to index > word documents > > http://www.beagle-project.org/Optional_prerequisites > > ok looks like gnumetric is run time only so it should work as > --enable-ssindex is enabled in gnumetric however end users may complain > that indexing is not happening if they dont install gnumetric themselves. > > so wv would need to be added to core and to give users best experience > gnumetric would need adding back so beagle could require it. The question is... is it appropriate to pull back the entire gnumeric code base.. to make an optional runtime feature a hard requirement? Should we be relying on a group definitions instead to pull the optional runtime features in instead of making them hard requirements in the packages? I will point out that the feature looses its "optional" status by making it a hard package requirement. How is this different than any optional plugin for other applications? The existing hard requirement on xpdf because it provides pdfinfo is also a runtime optional requirement which pulls in a non-default gui application. But luckily, this requirement is being replaced by popplers-utils soonish. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177446 The fact that poppler-utils only pulls in cmdline utlities helps mitigate the complexity of the issue, but I'm still not convinced that turning a runtime optional utility like pdfinfo into a hard requirement is a good idea as general policy with regard to how optional runtime options are treated in packaging. In my perfect world, runtime optional dependancies would be treated as runtime optional dependancies and not hard requirements. In my slightly better world of tomorrow, there would be the ability to split out the cmdline utility ssindex and ssconvert from the gnumeric application into a -utils subpackage so beagle could require the simple cmdline utility without pulling in the gnumeric application, a non-default gui application to sit in the menu structure next to openoffice. This is a real release engineering problem concern what the default desktop is going to look like. Is beagle being considered for default desktop functionality? Since nautilus's new search features require beagle i think its pretty safe to say that beagle is going to be integrated into the default desktop. nautilus requires libbeagle now, but beagle itself isn't explicitly required...yet. If beagle is destined for default destop installs, is the Core desktop group willing to pull in gnumeric into the default desktop next to openoffice in the menus solely to satify beagle's runtime optional dependancy for the cmdline utility ssindex? Or are they willing to ship beagle in a suboptimal default state. Quite honestly I don't see much point in beagle at all if its not able to index media. The magic, whether it be good or ill, is in the index funcationality If Core and Extras shared the same buildsystem, it would be much easier to implement ssindex as a gnumeric subpackage similar to what is happening poppler-utils. Alas, the policy that subpackages can not straddle the Core/Extras boundary makes implementation of ssindex as seperate Core item, leaving gnumeric in Extras difficult if not impossible. I really don't like seeing applications that were delibrately moved out of Core into Extras being required in Core again because of rather 2ndy requirement mechanisms. If gnumeric goes back in for fc5, what is to say that beagle wont be re-engineered by fc6 to not require gnumeric. Is the Core release team content to watch application level items swing into and out of Core on every release? I'm not. The fact that gnumeric has to be considered to be pulled back in for beagle... suggests strongly to me that the effort to keep Core and Extras as strictly seperate entities is simply a waste of effort. If there are benefits to community control in Extras, we continually erode them, by pulling items back into Core and out of the hands of community members. I hope the release team takes a look at how much this gnumeric situation..sucks... and thinks very deeply about how the selfhosting requirement of Core devoid of Core community package maintainership ability is undermining the larger goals of long term community involvement. I fear we will continue to see more and more problems like this develop because of the strict seperation of Core/Extras -jef"doom doom doom"spaleta From dennis at ausil.us Thu Jan 12 19:26:07 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Jan 2006 13:26:07 -0600 Subject: beagle In-Reply-To: <200601122012.48843.gauret@free.fr> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> Message-ID: <200601121326.07405.dennis@ausil.us> On Thursday 12 January 2006 13:12, Aurelien Bompard wrote: > > so wv would need to be added to core and to give users best experience > > gnumetric would need adding back so beagle could require it. > > Is beagle going to be in Core straight away ? I thought it would be in > Extras first. In which case, no need to move packages around. its already in core > > a couple of things that bother me about beagle. and i could be wrong > > here. 1. there seems to be no way to index OpenDocument files. this is a > > big downer for me as i use them much more often than Word or excel. > > Very strange, OpenDocuments are just zipped XML. Shouldn't be hard to > index. i know but it seems no one has written anything to index them > > 2. it wants to link against older packages wv1 not wv2 sqlite2 not > > sqlite3 > > I maintain wv in Extras. It's at version 1 for the moment, but I've had > requests to upgrade it to version 2 (it can only be done in devel for the > moment, because of dependencies). If Beagle requires wv < 2, I'll have to > make a second package (wv2). Couldn't Beagle use wv2 ? the link i posted in the first email states it does not work with wv2 Dennis From notting at redhat.com Thu Jan 12 19:41:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Jan 2006 14:41:05 -0500 Subject: beagle In-Reply-To: <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> References: <200601121246.17483.dennis@ausil.us> <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> Message-ID: <20060112194105.GB30822@devserv.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > The fact that poppler-utils only pulls in cmdline utlities helps > mitigate the complexity of the issue, but I'm still not convinced that > turning a runtime optional utility like pdfinfo into a hard > requirement is a good idea as general policy with regard to how > optional runtime options are treated in packaging. In my perfect > world, runtime optional dependancies would be treated as runtime > optional dependancies and not hard requirements. Well, you can look at it this way. If you're using Beagle, you're indexing your desktop & files on it. Are you really going to run a desktop without *some* sort of PDF viewer? > In my slightly better world of tomorrow, there would be the ability to > split out the cmdline utility ssindex and ssconvert from the gnumeric > application into a -utils subpackage so beagle could require the > simple cmdline utility without pulling in the gnumeric application, a > non-default gui application to sit in the menu structure next to > openoffice. Well, one idea would be to have a single document-parsing library that would do this sort of thing. This, of course, doesn't exist. Bill From notting at redhat.com Thu Jan 12 19:42:25 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Jan 2006 14:42:25 -0500 Subject: beagle In-Reply-To: <20060112194105.GB30822@devserv.devel.redhat.com> References: <200601121246.17483.dennis@ausil.us> <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> <20060112194105.GB30822@devserv.devel.redhat.com> Message-ID: <20060112194225.GC30822@devserv.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Well, one idea would be to have a single document-parsing library > that would do this sort of thing. This, of course, doesn't exist. Alternatively, you allow plugins to be added to beagle, and build said plugins in either extras or core with the relevant code - does beagle support this? Bill From gauret at free.fr Thu Jan 12 19:49:11 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 12 Jan 2006 20:49:11 +0100 Subject: beagle In-Reply-To: <200601121326.07405.dennis@ausil.us> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> <200601121326.07405.dennis@ausil.us> Message-ID: <200601122049.12438.gauret@free.fr> > > Is beagle going to be in Core straight away ? I thought it would be in > > Extras first. In which case, no need to move packages around. > > its already in core First it wasn't even fit for Fedora, and now it goes straight in Core. And we tried so hard not to make Extras a second-class citizen... Nevermind. > > Very strange, OpenDocuments are just zipped XML. Shouldn't be hard to > > index. > > i know but it seems no one has written anything to index them OK. It will probably happen shortly then. > > I maintain wv in Extras. It's at version 1 for the moment, but I've had > > requests to upgrade it to version 2 (it can only be done in devel for > > the moment, because of dependencies). If Beagle requires wv < 2, I'll > > have to make a second package (wv2). Couldn't Beagle use wv2 ? > > the link i posted in the first email states it does not work with wv2 Yes, I read the link (I did ! :) ). What I mean is : what is preventing Beagle from using wv2 ? Is it on the roadmap, or is it definitely not going to use it ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Science sans conscience n'est que ruine de l'?me." -- Rabelais From nicolas.mailhot at laposte.net Thu Jan 12 19:52:29 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jan 2006 20:52:29 +0100 Subject: beagle In-Reply-To: <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> References: <200601121246.17483.dennis@ausil.us> <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> Message-ID: <1137095549.32142.23.camel@rousalka.dyndns.org> Le jeudi 12 janvier 2006 ? 14:24 -0500, Jeff Spaleta a ?crit : > The fact that poppler-utils only pulls in cmdline utlities helps > mitigate the complexity of the issue, but I'm still not convinced that > turning a runtime optional utility like pdfinfo into a hard > requirement is a good idea as general policy with regard to how > optional runtime options are treated in packaging. In my perfect > world, runtime optional dependancies would be treated as runtime > optional dependancies and not hard requirements. So you would have every package with runtime deps (or depending on one or several other packages with runtime deps) have runtime behaviour depending on which combo of n-level optional runtime deps is present on the system ? Looks a great way to multiply the QA charge by several orders of magnitude. -- 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 jspaleta at gmail.com Thu Jan 12 19:53:46 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jan 2006 14:53:46 -0500 Subject: beagle In-Reply-To: <20060112194105.GB30822@devserv.devel.redhat.com> References: <200601121246.17483.dennis@ausil.us> <604aa7910601121124w79232803k2770362e16ed210c@mail.gmail.com> <20060112194105.GB30822@devserv.devel.redhat.com> Message-ID: <604aa7910601121153i3e52c522w24a0667d1ca61ad2@mail.gmail.com> On 1/12/06, Bill Nottingham wrote: > Well, you can look at it this way. If you're using Beagle, you're > indexing your desktop & files on it. Are you really going to > run a desktop without *some* sort of PDF viewer? I'm content with the poppler-utils solution for this. But everytime i see a runtime optional compoment be forced as an explicit requirement.. I rage internally at the idea of DA MAN telling me i must have that extras 3 kb of data on my 300 gig system. I know I can't make a compelling, rational case for not having this requirement. But you have to admit pulling in xpdf to get pdfinfo is a bit harder to swallow because you are now adding menu items. Similarly even if gnumeric gets pulled in, you really are going to want to split out the cmdline tools. > Well, one idea would be to have a single document-parsing library > that would do this sort of thing. This, of course, doesn't exist. No it never will. But you duck my larger concern. Pulling packages out of the hands of community maintainers in Extras to go back under RedHat only control in Core undermines the goals of community involvement. Something needs to change with regard to the strict seperation of Core/Extras as distinct entities or the selfhosting requirement. The pillaging of the Extras town center by the Core norseman, is sure to cause undue frustration on the poor villagers. -jef From jkeating at redhat.com Thu Jan 12 20:23:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jan 2006 15:23:14 -0500 Subject: beagle In-Reply-To: <200601122049.12438.gauret@free.fr> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> <200601121326.07405.dennis@ausil.us> <200601122049.12438.gauret@free.fr> Message-ID: <1137097394.2674.7.camel@ender> On Thu, 2006-01-12 at 20:49 +0100, Aurelien Bompard wrote: > First it wasn't even fit for Fedora, and now it goes straight in Core. And > we tried so hard not to make Extras a second-class citizen... > Nevermind. > beagle got pulled in because it was needed for some new nautilus search features which make use of beagle. The side effect is that all sorts of other things now could use beagle, but we just haven't coded for them yet. (or at all). We just haven't made any decisions regarding this. -- Jesse Keating Release Engineer: Fedora -------------- 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 Thu Jan 12 22:24:45 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 12 Jan 2006 15:24:45 -0700 Subject: beagle In-Reply-To: <1137097394.2674.7.camel@ender> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> <200601121326.07405.dennis@ausil.us> <200601122049.12438.gauret@free.fr> <1137097394.2674.7.camel@ender> Message-ID: <80d7e4090601121424y6c5c2ec3x4223d7b72b454ab3@mail.gmail.com> On 1/12/06, Jesse Keating wrote: > On Thu, 2006-01-12 at 20:49 +0100, Aurelien Bompard wrote: > > First it wasn't even fit for Fedora, and now it goes straight in Core. And > > we tried so hard not to make Extras a second-class citizen... > > Nevermind. > > > > beagle got pulled in because it was needed for some new nautilus search > features which make use of beagle. The side effect is that all sorts of > other things now could use beagle, but we just haven't coded for them > yet. (or at all). We just haven't made any decisions regarding this. > OK please don't take this as Monday morning quarterbacking but ideas from someone who has lived the hell of release time lessons learned for the future. As in the next time a last minute addition to the core system is going to be done (which will be about 2-3 releases if normal). 1) Lock down Fedora Core 5 without mono. 2) Have what you want to say to the community ready so you aren't making another deficit withdrawal from the trust bank. 3) Get the other apps ready for mono, desktop searching etc, 4) Set up a special DESKTOP yum repository that would be available. Put mono, etc in it. 5) Tell the community why/how things have gotten better to the best of what can be said from Red Hat legal about probably non-public agreements. 6) Tell the community about the DESKTOP repository and what it will have in it. 7) Finish off Fedora Core 5 without getting 3-4 more core engineers quiting and going to rpath/novell/etc. 8) Combine beagle into FC5/rawhide. 9) If it works out well put it in as package updates for FC5 like KDE3.5 etc have been done. 10) Roll these neat things into RHEL5 -- Stephen J Smoogen. CSIRT/Linux System Administrator From uwog at uwog.net Fri Jan 13 19:50:51 2006 From: uwog at uwog.net (J.M. Maurer) Date: Fri, 13 Jan 2006 20:50:51 +0100 Subject: beagle In-Reply-To: <200601122049.12438.gauret@free.fr> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> <200601121326.07405.dennis@ausil.us> <200601122049.12438.gauret@free.fr> Message-ID: <1137181851.19517.9.camel@tantalus.pinohuis.adsl.utwente.nl> > > > I maintain wv in Extras. It's at version 1 for the moment, but I've had > > > requests to upgrade it to version 2 (it can only be done in devel for > > > the moment, because of dependencies). If Beagle requires wv < 2, I'll > > > have to make a second package (wv2). Couldn't Beagle use wv2 ? > > > > the link i posted in the first email states it does not work with wv2 > > Yes, I read the link (I did ! :) ). What I mean is : what is preventing > Beagle from using wv2 ? Is it on the roadmap, or is it definitely not going > to use it ? wv2 was an attempt by some kde developers to rewrite wv, but as far as I know, wv2 is dead. Marc From tibbs at math.uh.edu Fri Jan 13 19:52:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 13 Jan 2006 13:52:58 -0600 Subject: Security fixes in Extras Message-ID: Because I maintain a package (denyhosts) which contains a daemon that runs continuously as root, the issue of how to handle security fixes for packages in extras interests me greatly. Some questions: Is there any defined procedure for handling security fixes? What if the maintainer is out of pocket? If I need to push a security fix, is there a way to jump ahead in the build queue and expedite the sign and push process? Is there somewhere I could send an update announcement? - J< From uwog at uwog.net Fri Jan 13 19:54:20 2006 From: uwog at uwog.net (J.M. Maurer) Date: Fri, 13 Jan 2006 20:54:20 +0100 Subject: beagle In-Reply-To: <200601122012.48843.gauret@free.fr> References: <200601121246.17483.dennis@ausil.us> <200601122012.48843.gauret@free.fr> Message-ID: <1137182060.19517.14.camel@tantalus.pinohuis.adsl.utwente.nl> On Thu, 2006-01-12 at 20:12 +0100, Aurelien Bompard wrote: > > so wv would need to be added to core and to give users best experience > > gnumetric would need adding back so beagle could require it. > > Is beagle going to be in Core straight away ? I thought it would be in > Extras first. In which case, no need to move packages around. > > > a couple of things that bother me about beagle. and i could be wrong > > here. 1. there seems to be no way to index OpenDocument files. this is a > > big downer for me as i use them much more often than Word or excel. > > Very strange, OpenDocuments are just zipped XML. Shouldn't be hard to index. Well, if beagle would just have an abiword backend you'd have instant support for MS Word, OpenDocument, OpenWriter, the old StarOffice, WordPerfect, PDF, Psion, HRText, RTF, XHTML and other document formats. Never understood why did didn't do this. You can even run AbiWord as a 'server' (gui-less) program/daemon to make the conversions really fast. Cheers, Marc From jwboyer at jdub.homelinux.org Fri Jan 13 21:15:46 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 13 Jan 2006 15:15:46 -0600 (CST) Subject: Security fixes in Extras In-Reply-To: References: Message-ID: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> > Because I maintain a package (denyhosts) which contains a daemon that > runs continuously as root, the issue of how to handle security fixes > for packages in extras interests me greatly. > > Some questions: > > Is there any defined procedure for handling security fixes? No. > What if the maintainer is out of pocket? Others with CVS access should make the fix in cases like this. > If I need to push a security fix, is there a way to jump ahead in the > build queue and expedite the sign and push process? Not that I know of. Expediting the sign/push process could be done by asking someone with access to the buildsys to do the push I suppose. > Is there somewhere I could send an update announcement? Here is the best place I think. There is no fedora-extras-announce list. Now the real question is, should there be some sort of defined policy for security fixes? josh From skvidal at linux.duke.edu Fri Jan 13 21:19:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 13 Jan 2006 16:19:54 -0500 Subject: Security fixes in Extras In-Reply-To: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: <1137187194.3112.9.camel@cutter> On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: > > Because I maintain a package (denyhosts) which contains a daemon that > > runs continuously as root, the issue of how to handle security fixes > > for packages in extras interests me greatly. > > > > Some questions: > > > > Is there any defined procedure for handling security fixes? > > No. > > > What if the maintainer is out of pocket? > > Others with CVS access should make the fix in cases like this. > > > If I need to push a security fix, is there a way to jump ahead in the > > build queue and expedite the sign and push process? > > Not that I know of. Expediting the sign/push process could be done by > asking someone with access to the buildsys to do the push I suppose. > > > Is there somewhere I could send an update announcement? > > Here is the best place I think. There is no fedora-extras-announce list. > > Now the real question is, should there be some sort of defined policy for > security fixes? > I'd be game with making a extras-security alert address that had the package signers and some other security folks on it so we could expedite things if need be. but a private list, for obvious reasons. -sv From jwboyer at jdub.homelinux.org Fri Jan 13 21:18:27 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 13 Jan 2006 15:18:27 -0600 (CST) Subject: Security fixes in Extras In-Reply-To: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: <20890.129.42.161.36.1137187107.squirrel@jdub.homelinux.org> >> Is there somewhere I could send an update announcement? > > Here is the best place I think. There is no fedora-extras-announce list. Er, I meant fedora-extras list. Sorry. Though this list wouldn't be bad to send it to either. josh "needs to pay better attention to what list he is reading" From jwboyer at jdub.homelinux.org Fri Jan 13 21:20:16 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 13 Jan 2006 15:20:16 -0600 (CST) Subject: Security fixes in Extras In-Reply-To: <1137187194.3112.9.camel@cutter> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <1137187194.3112.9.camel@cutter> Message-ID: <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> > On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: >> >> Now the real question is, should there be some sort of defined policy >> for >> security fixes? >> > > I'd be game with making a extras-security alert address that had the > package signers and some other security folks on it so we could expedite > things if need be. > > but a private list, for obvious reasons. I'll second this. Seems like a good idea to me. Should we talk about embargos though? josh From skvidal at linux.duke.edu Fri Jan 13 21:23:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 13 Jan 2006 16:23:37 -0500 Subject: Security fixes in Extras In-Reply-To: <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <1137187194.3112.9.camel@cutter> <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> Message-ID: <1137187417.3112.11.camel@cutter> On Fri, 2006-01-13 at 15:20 -0600, Josh Boyer wrote: > > On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: > >> > >> Now the real question is, should there be some sort of defined policy > >> for > >> security fixes? > >> > > > > I'd be game with making a extras-security alert address that had the > > package signers and some other security folks on it so we could expedite > > things if need be. > > > > but a private list, for obvious reasons. > > I'll second this. Seems like a good idea to me. > > Should we talk about embargos though? > why don't we just ask thorsten to add this to the agenda. and get it taken care of then? -sv From tibbs at math.uh.edu Fri Jan 13 21:42:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 13 Jan 2006 15:42:01 -0600 Subject: Security fixes in Extras In-Reply-To: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> (Josh Boyer's message of "Fri, 13 Jan 2006 15:15:46 -0600 (CST)") References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> Others with CVS access should make the fix in cases like this. This is a difficult issue, though. Take a current example: clamav. I'm not trying to pick on the clamav maintainer at all; this just happens to have piqued my curiosity about the process. Currently extras has 0.87.1, which is supposedly remotely exploitable. 0.88 was released on Jan 9. The maintainer did check the new version into all branches immediately, but currently only the development branch has been built. I have CVS access, so in theory I could tag and submit a build request. But there must be some reason why it hasn't built on the release branches yet. So I opened a bug (177761) and built the packages locally for testing. (They seem to be running fine, BTW.) So, assume for the sake of argument that the maintainer doesn't respond to the bug. At what point does someone need to take action? Who takes that action? JB> There is no fedora-extras-announce list. Does this strike anyone else as a bad idea in the long run? extras-list is too high-volume to expect people to watch for security releases, and I doubt Red Hat wants to open up the more official announcement lists to the likes of me. JB> Now the real question is, should there be some sort of defined JB> policy for security fixes? I think there has to be; the users deserve that much. - J< From notting at redhat.com Fri Jan 13 21:46:07 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Jan 2006 16:46:07 -0500 Subject: Security fixes in Extras In-Reply-To: References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: <20060113214607.GA28893@devserv.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > So, assume for the sake of argument that the maintainer doesn't > respond to the bug. At what point does someone need to take action? > Who takes that action? I suppose it could be up to the Extras Steering Committee, or any security team that they then designate. > JB> There is no fedora-extras-announce list. > > Does this strike anyone else as a bad idea in the long run? > extras-list is too high-volume to expect people to watch for security > releases, and I doubt Red Hat wants to open up the more official > announcement lists to the likes of me. Hm. I suppose it's possible to do updates in that manner (fedora-announce-list) Once we get the advisory format settled in the metadata, it should be easy enough for somebody to whack up a quick system that sends the mail & adds the data. My main concern with opening up fedora-announce-list is that I wonder if the increase of volume because of *non*-security updates would clutter the list. Bill From jspaleta at gmail.com Fri Jan 13 21:49:13 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jan 2006 16:49:13 -0500 Subject: Security fixes in Extras In-Reply-To: <20060113214607.GA28893@devserv.devel.redhat.com> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <20060113214607.GA28893@devserv.devel.redhat.com> Message-ID: <604aa7910601131349h952c50cpc674a9221a8c9669@mail.gmail.com> On 1/13/06, Bill Nottingham wrote: > Hm. I suppose it's possible to do updates in that manner (fedora-announce-list) > Once we get the advisory format settled in the metadata, it should > be easy enough for somebody to whack up a quick system that sends > the mail & adds the data. > My main concern with opening up fedora-announce-list is that I wonder > if the increase of volume because of *non*-security updates would > clutter the list. once the advisory format is settled in the metadata... we can get clientside tools that understand how to expose advisory text... and then the annouce-list isn't nearly as important a mechanism for the installed userbase and will serve hopefully as a historical/offline tool. -jef From jwboyer at jdub.homelinux.org Fri Jan 13 22:23:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 13 Jan 2006 16:23:38 -0600 (CST) Subject: Security fixes in Extras In-Reply-To: <604aa7910601131349h952c50cpc674a9221a8c9669@mail.gmail.com> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <20060113214607.GA28893@devserv.devel.redhat.com> <604aa7910601131349h952c50cpc674a9221a8c9669@mail.gmail.com> Message-ID: <18853.129.42.161.36.1137191018.squirrel@jdub.homelinux.org> > On 1/13/06, Bill Nottingham wrote: >> Hm. I suppose it's possible to do updates in that manner >> (fedora-announce-list) >> Once we get the advisory format settled in the metadata, it should >> be easy enough for somebody to whack up a quick system that sends >> the mail & adds the data. >> My main concern with opening up fedora-announce-list is that I wonder >> if the increase of volume because of *non*-security updates would >> clutter the list. > > once the advisory format is settled in the metadata... we can get > clientside tools that understand how to expose advisory text... and > then the annouce-list isn't nearly as important a mechanism for the > installed userbase and will serve hopefully as a historical/offline > tool. Yeah, maybe. But I think the announce list is a much nearer goal and it is still needed. I happen to read fedora-announce each day to determine whether or not I need to run yum update on my non-rawhide systems. I'm sure lots of other folks have machines running that aren't their primary machines and don't do yum updates on a daily basis to see if something needs updating. josh From fedora at leemhuis.info Sat Jan 14 09:02:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 14 Jan 2006 10:02:43 +0100 Subject: Security fixes in Extras In-Reply-To: <1137187417.3112.11.camel@cutter> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <1137187194.3112.9.camel@cutter> <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> <1137187417.3112.11.camel@cutter> Message-ID: <1137229363.4321.2.camel@localhost.localdomain> Am Freitag, den 13.01.2006, 16:23 -0500 schrieb seth vidal: > On Fri, 2006-01-13 at 15:20 -0600, Josh Boyer wrote: > > > On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: > > >> > > >> Now the real question is, should there be some sort of defined policy > > >> for security fixes? > > > I'd be game with making a extras-security alert address that had the > > > package signers and some other security folks on it so we could expedite > > > things if need be. > > > > > > but a private list, for obvious reasons. I'm not 100% sure if it needs to be private. I don't like "security by obscurity". But of course it needs to be private *if* we're discussing things under embargoed there. > > I'll second this. Seems like a good idea to me. > > Should we talk about embargos though? > why don't we just ask thorsten to add this to the agenda. Done. Created a page in the wiki at http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy Could those interested in the topic summarize this thread there? And create a action list about the details that need to be discussed? After that we should probably discuss those on fedora-extras list. -- Thorsten Leemhuis From j.w.r.degoede at hhs.nl Sat Jan 14 10:16:56 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Jan 2006 11:16:56 +0100 Subject: Security fixes in Extras In-Reply-To: <1137229363.4321.2.camel@localhost.localdomain> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <1137187194.3112.9.camel@cutter> <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> <1137187417.3112.11.camel@cutter> <1137229363.4321.2.camel@localhost.localdomain> Message-ID: <43C8CF98.30406@hhs.nl> I'm busy to add my 2 cents to the wiki page. You seem however to have forgot to add a note about this and a link to that page on the actual Schedule page. Regards, Hans Thorsten Leemhuis wrote: > Am Freitag, den 13.01.2006, 16:23 -0500 schrieb seth vidal: >> On Fri, 2006-01-13 at 15:20 -0600, Josh Boyer wrote: >>>> On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: >>>>> Now the real question is, should there be some sort of defined policy >>>>> for security fixes? >>>> I'd be game with making a extras-security alert address that had the >>>> package signers and some other security folks on it so we could expedite >>>> things if need be. >>>> >>>> but a private list, for obvious reasons. > > I'm not 100% sure if it needs to be private. I don't like "security by > obscurity". But of course it needs to be private *if* we're discussing > things under embargoed there. > >>> I'll second this. Seems like a good idea to me. >>> Should we talk about embargos though? >> why don't we just ask thorsten to add this to the agenda. > > Done. Created a page in the wiki at > http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy > > Could those interested in the topic summarize this thread there? And > create a action list about the details that need to be discussed? After > that we should probably discuss those on fedora-extras list. From fedora at leemhuis.info Sat Jan 14 10:18:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 14 Jan 2006 11:18:40 +0100 Subject: Security fixes in Extras In-Reply-To: <43C8CF98.30406@hhs.nl> References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <1137187194.3112.9.camel@cutter> <29551.129.42.161.36.1137187216.squirrel@jdub.homelinux.org> <1137187417.3112.11.camel@cutter> <1137229363.4321.2.camel@localhost.localdomain> <43C8CF98.30406@hhs.nl> Message-ID: <1137233920.4321.26.camel@localhost.localdomain> Am Samstag, den 14.01.2006, 11:16 +0100 schrieb Hans de Goede: > I'm busy to add my 2 cents to the wiki page. You seem however to have > forgot to add a note about this and a link to that page on the actual > Schedule page. /me checks. Missing. /me wonders why seem /me did not save the page after editing Fixed soon. CU thl > Thorsten Leemhuis wrote: > > Am Freitag, den 13.01.2006, 16:23 -0500 schrieb seth vidal: > >> On Fri, 2006-01-13 at 15:20 -0600, Josh Boyer wrote: > >>>> On Fri, 2006-01-13 at 15:15 -0600, Josh Boyer wrote: > >>>>> Now the real question is, should there be some sort of defined policy > >>>>> for security fixes? > >>>> I'd be game with making a extras-security alert address that had the > >>>> package signers and some other security folks on it so we could expedite > >>>> things if need be. > >>>> > >>>> but a private list, for obvious reasons. > > > > I'm not 100% sure if it needs to be private. I don't like "security by > > obscurity". But of course it needs to be private *if* we're discussing > > things under embargoed there. > > > >>> I'll second this. Seems like a good idea to me. > >>> Should we talk about embargos though? > >> why don't we just ask thorsten to add this to the agenda. > > > > Done. Created a page in the wiki at > > http://www.fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy > > > > Could those interested in the topic summarize this thread there? And > > create a action list about the details that need to be discussed? After > > that we should probably discuss those on fedora-extras list. > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Thorsten Leemhuis From bugs.michael at gmx.net Sat Jan 14 11:54:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 14 Jan 2006 12:54:52 +0100 Subject: Security fixes in Extras In-Reply-To: References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: <20060114125452.7fa06a10.bugs.michael@gmx.net> On Fri, 13 Jan 2006 15:42:01 -0600, Jason L Tibbitts III wrote: > >>>>> "JB" == Josh Boyer writes: > > JB> Others with CVS access should make the fix in cases like this. > > This is a difficult issue, though. Take a current example: clamav. > I'm not trying to pick on the clamav maintainer at all; this just > happens to have piqued my curiosity about the process. > > Currently extras has 0.87.1, which is supposedly remotely exploitable. > 0.88 was released on Jan 9. The maintainer did check the new version > into all branches immediately, but currently only the development > branch has been built. > > I have CVS access, so in theory I could tag and submit a build > request. To put it bluntly, this is like claiming "I can do updates much more quickly, with at least the same testing, than the current maintainer". While Fedora Extras is continueing to get in shape, let's assume that we have package maintainers for good reasons and that they take care of their own packages. Security updates may be important, but should still see a good bit of testing prior to release. Nothing is worse than updates which break something badly. I do understand the goal of this topic. I just find it odd to give such an example. Without talking to the current package maintainer, nobody should perform any upgrades of others' packages. If you have strong interest in a package, I still believe there's the possibility to build small teams, who work together on some packages. In particular, if over time specific packages turn out to have high maintenance requirements, it would be best to increase the number of maintainers per package. > But there must be some reason why it hasn't built on the > release branches yet. So I opened a bug (177761) and built the > packages locally for testing. (They seem to be running fine, BTW.) > > So, assume for the sake of argument that the maintainer doesn't > respond to the bug. At what point does someone need to take action? > Who takes that action? We should gather some statistics first. How often does it happen that a known security bug with an existing patch or version upgrade is not fixed within (let's say) two weeks? If such a security update takes more than a few days while the maintainer seems to be active, what are the reasons for the delay of the update? How long does it take for maintainers to respond to bugzilla tickets marked as "security"? So far, where extra commits or fixes in cvs have been needed, the sponsors (enough interest and insight provided) have done it (e.g. in the absence of a maintainer or to fix broken deps). Though, as I mentioned, clamav is a bad example, since the ticket was not opened before yesterday. > JB> There is no fedora-extras-announce list. > > Does this strike anyone else as a bad idea in the long run? > extras-list is too high-volume to expect people to watch for security > releases, and I doubt Red Hat wants to open up the more official > announcement lists to the likes of me. > > JB> Now the real question is, should there be some sort of defined > JB> policy for security fixes? > > I think there has to be; the users deserve that much. > > - J< From thomas at apestaart.org Sat Jan 14 15:26:12 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 14 Jan 2006 16:26:12 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <1137252372.1181.15.camel@otto> Hi, > 3) Generated docs > > These are tricky; sometimes commands can be called to make > sure that timestamps aren't inserted into the file, or architecture > notes aren't added. Alternatively, generated docs can be > packaged in separate subpackages. In the case of GStreamer, you only listed documentation. It seems pretty much all gtk-doc-style documentation is listed as conflicting, for any package. Do you know exactly where they differ ? There's nothing I can come up with myself that would cause them to be different. Thanks Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Ik heb vannacht gedronken en gezien Hoe jij van mij nooit krijgt wat je verdient <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From bugs.michael at gmx.net Sat Jan 14 18:47:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 14 Jan 2006 19:47:51 +0100 Subject: Packaging/Review Guidelines change In-Reply-To: <20060109115733.0a896615@python2> References: <1136488651.2369.146.camel@localhost.localdomain> <87d5j3qabx.fsf@kosh.bigo.ensc.de> <20060109115733.0a896615@python2> Message-ID: <20060114194751.3ea519f9.bugs.michael@gmx.net> On Mon, 9 Jan 2006 11:57:33 +0100, Matthias Saou wrote: > Enrico Scholz wrote : > > > Tom 'spot' Callaway writes: > > > > > MUST: Packages must not own files or directories already owned by > > > other packages. The rule of thumb here is that the first package to be > > > installed should own the files or directories that other packages may > > > rely upon. This means, for example, that no package in Fedora Extras > > > should ever share ownership with any of the files or directories owned > > > by the filesystem or man package. If you feel that you have a good > > > reason to own a file or directory that another package owns, then > > > please present that at package review time. > > > > > > This is a policy that has been enforced for sometime, but never actually > > > added to the guidelines (until now). > > > > What is with directories like > > > > /usr/share/locale/C > > /usr/share/locale/nl_BE > > /usr/share/locale/uk_UA > > My guess : Let %find_lang do its magic for these, and if it owns them, then > get that macro fixed ;-) I'm sure it is the opposite. %find_lang only includes the message object files, not the directories. And therefore, any of the locale directories are unowned unless glibc-common or a filesystem package includes them. (btw, some packages also add locales not supported by glibc) From toshio at tiki-lounge.com Sun Jan 15 04:53:11 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 14 Jan 2006 20:53:11 -0800 Subject: Packaging/Review Guidelines change Message-ID: <1137300791.10427.9.camel@localhost> /usr/share/xml is owned by several packages right now: $ repoquery -q --whatprovides /usr/share/xml libglade2-0:2.5.1-2.i386 libglade2-0:2.5.1-2.x86_64 gnome-doc-utils-0:0.2.0-2.noarch xml-common-0:0.6.3-17.noarch cvs2cl-0:2.59-2.noarch Should new packages depend on xml-common instead of owning it or does /usr/share/xml really belong in filesystem? -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 fedora at leemhuis.info Sun Jan 15 19:07:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jan 2006 20:07:59 +0100 Subject: FYI: Discussion about "Mass rebuild of Fedora Extras before FC5 and how to handle orphaned packges for FC5" now fedora-extras-list In-Reply-To: <1137351560.3473.70.camel@localhost.localdomain> References: <1137351560.3473.70.camel@localhost.localdomain> Message-ID: <1137352079.3473.80.camel@localhost.localdomain> Hi, just a FYI that there is a discussion about the state of Fedora Extras for Fedora Core 5 on fedora-extras-list currently. See this mail for details: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00936.html If you have anything to say on the topic please reply in the thread and not to this list so we have everything in one thread on one mailinglist. Here is the most important part for maintainers of packages in Fedora Extras: > Those people that have packages in Extras that were not rebuild in the > past 5 months IMHO should kick of a rebuild as soon as possible, just to > make sure everything still builds fine on FC5/rawhide. Note: Not all at > once please, it must be possible for others to request builds in case > they need to get a update with a security fix build. Thanks for you attention. CU thl From ville.skytta at iki.fi Sun Jan 15 22:20:54 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 16 Jan 2006 00:20:54 +0200 Subject: Packaging/Review Guidelines change In-Reply-To: <1137300791.10427.9.camel@localhost> References: <1137300791.10427.9.camel@localhost> Message-ID: <1137363654.28950.41.camel@bobcat.mine.nu> On Sat, 2006-01-14 at 20:53 -0800, Toshio Kuratomi wrote: > /usr/share/xml is owned by several packages right now: [...] > Should new packages depend on xml-common instead of owning it If they use something else than just expect the dir to be present from xml-common, I'd say depend on it. On the other hand, some of these own it for cleanup-on-erase purposes (at least cvs2cl does, will fix), so those can just have a dependency on the dir. IMHO, it doesn't matter that much if some others than xml-common own it, as long as it's not unowned. (Again assuming rpm's erase ordering issues will be fixed.) > or does /usr/share/xml really belong in filesystem? FHS says it's optional and "must be in /usr/share, if the corresponding subsystem is installed". xml-common probably qualifies as such a subsystem, and thus sounds like the correct package to include it in. http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS15 From skvidal at linux.duke.edu Mon Jan 16 17:27:28 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 16 Jan 2006 12:27:28 -0500 Subject: gedit in rawhide Message-ID: <1137432449.19719.16.camel@cutter> Hi, Any reason why gedit-devel in rawhide is missing a few include files? gedit-file.h and gedit-menus.h don't appear to be in gedit-devel and before I file a bug I wanted to make sure this wasn't intentional. -sv From mclasen at redhat.com Mon Jan 16 17:37:33 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 16 Jan 2006 12:37:33 -0500 Subject: gedit in rawhide In-Reply-To: <1137432449.19719.16.camel@cutter> References: <1137432449.19719.16.camel@cutter> Message-ID: <1137433053.19308.1.camel@golem.boston.redhat.com> On Mon, 2006-01-16 at 12:27 -0500, seth vidal wrote: > Hi, > Any reason why gedit-devel in rawhide is missing a few include files? > > gedit-file.h and gedit-menus.h don't appear to be in gedit-devel and > before I file a bug I wanted to make sure this wasn't intentional. > No, probably just an oversight. But if they are missing from the package, then make install must not install them, or the build system would have complained about unpackaged files. Matthias From tibbs at math.uh.edu Tue Jan 17 15:38:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 Jan 2006 09:38:59 -0600 Subject: Clamav security update (Was: Security fixes in Extras) In-Reply-To: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> (Josh Boyer's message of "Fri, 13 Jan 2006 15:15:46 -0600 (CST)") References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: >>>>> "JB" == Josh Boyer writes: >> What if the maintainer is out of pocket? JB> Others with CVS access should make the fix in cases like this. I believe we may have to test this. clamav in extras has what is potentially a remotely exploitable hole; an upstream update fixing the problem was released on January 9. I opened https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177761 on Friday but it has elicited no response from the maintainer. The maintainer checked the new version into CVS (on all branches) immediately upon its upstream release and sent a build request on the devel branch (but not any of the release branches). I tested the CVS code on FC-3 over the weekend on my primary MXes and found no issues. This begs the following questions: How long should the community wait for the maintainer? Who should issue the build request? I'm really trying hard to avoid stepping on toes here. I think clamav is a fine package, but the maintainer seems to be away, we have what could be a bad security issue and I'm starting to get private mail asking about an updated build. (I assume that's because of the bug I opened or traffic on this list.) I honestly don't want to be the clamav maintainer; I just happened to see the Gentoo update come across bugtraq on Friday and became concerned about my own servers. - J< From nicolas.mailhot at laposte.net Tue Jan 17 18:10:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 17 Jan 2006 19:10:28 +0100 Subject: Clamav security update (Was: Security fixes in Extras) In-Reply-To: References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: <43CD3314.6090507@laposte.net> Jason L Tibbitts III wrote: > This begs the following questions: > > How long should the community wait for the maintainer? > > Who should issue the build request? There is a long/old package queue in the FE buildsys right now, including I think some clamav bits So right now you are not waiting for the maintainer but for release people to flush this queue. -- Nicolas Mailhot From tibbs at math.uh.edu Tue Jan 17 18:14:22 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 Jan 2006 12:14:22 -0600 Subject: Clamav security update In-Reply-To: (Jason L. Tibbitts, III's message of "Tue, 17 Jan 2006 09:38:59 -0600") References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> Message-ID: >>>>> "JLT" == Jason L Tibbitts, writes: JLT> I believe we may have to test this. clamav in extras has what is JLT> potentially a remotely exploitable hole; [...] The maintainer has responded and had actually sent the build requests (2901 and 2902) late on Sunday. ("plague-client list" has started failing for me, so I didn't see the builds. Mea culpa.) If there's a chance that these could get signed and pushed soonish, clamav users would certainly be grateful. - J< From tibbs at math.uh.edu Tue Jan 17 18:19:15 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 Jan 2006 12:19:15 -0600 Subject: Clamav security update In-Reply-To: <43CD3314.6090507@laposte.net> (Nicolas Mailhot's message of "Tue, 17 Jan 2006 19:10:28 +0100") References: <5906.129.42.161.36.1137186946.squirrel@jdub.homelinux.org> <43CD3314.6090507@laposte.net> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> There is a long/old package queue in the FE buildsys right now, NM> including I think some clamav bits Yes, I just saw this; unfortunately "plague-client list" just gives me "Error connecting to build server: ''" when it used to work, so I didn't see this. The maintainer responded to the open bug report and I finally thought to check the web page. NM> So right now you are not waiting for the maintainer but for NM> release people to flush this queue. Which just moves my questions from "What to do if the maintainer doesn't respond?" to "Can we get packages signed quickly in an emergency?" - J< From dcbw at redhat.com Wed Jan 18 19:38:20 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 18 Jan 2006 14:38:20 -0500 Subject: Build system maintenance Message-ID: <1137613101.6161.0.camel@localhost.localdomain> Hi, I'm attempting to track down the hanging problems with openssl, so the buildsystem will be down for a bit. Dan From skvidal at linux.duke.edu Wed Jan 18 19:47:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jan 2006 14:47:29 -0500 Subject: Build system maintenance In-Reply-To: <1137613101.6161.0.camel@localhost.localdomain> References: <1137613101.6161.0.camel@localhost.localdomain> Message-ID: <1137613649.30710.47.camel@cutter> On Wed, 2006-01-18 at 14:38 -0500, Dan Williams wrote: > Hi, > > I'm attempting to track down the hanging problems with openssl, so the > buildsystem will be down for a bit. Thank you for looking at it. -sv From petersen at redhat.com Thu Jan 19 08:09:06 2006 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 Jan 2006 17:09:06 +0900 Subject: emacs 22 and FC Message-ID: <43CF4922.4040106@redhat.com> As some of you are probably well aware, Emacs 22 seems to be taking forever to be released, so some users are getting impatient to see a cvs snapshot of Emacs included in Fedora since Emacs 21 is getting a bit old now. Someone even filed an rfe to have Emacs-20.0.50 in FC5: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176171 and quite a number of users have asked for updates to http://people.redhat.com/petersen/emacs/ ;) This is kind of a difficult situation on the one hand we don't want to ship a pre-release if possible or to lessen the "pressure" on upstream to put out a stable release. On the other hand since there is a reasonable chance that Emacs 22.1 may be released before fc6 it would be good to get it tested as much as possible early. Of course if it then were not to be released in time for fc6 we would be in a sticky situation. So my take on this is to wait and see and hope it will be officially released in time for FC6 -- in the meantime I will try to update my snapshot packages on people to lessen the screaming. :) But I just thought I'd ask what other people think on this? Jens ps An alternative would be to add say an emacs22 package to Extras but since we tend to frown on this kind of thing it would probably just set a bad precedent. From smooge at gmail.com Thu Jan 19 21:04:08 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 19 Jan 2006 14:04:08 -0700 Subject: emacs 22 and FC In-Reply-To: <43CF4922.4040106@redhat.com> References: <43CF4922.4040106@redhat.com> Message-ID: <80d7e4090601191304o32924b75pb349c2b53d3171c5@mail.gmail.com> On 1/19/06, Jens Petersen wrote: > As some of you are probably well aware, Emacs 22 seems to be taking forever > to be released, so some users are getting impatient to see a cvs snapshot > of Emacs included in Fedora since Emacs 21 is getting a bit old now. > > Someone even filed an rfe to have Emacs-20.0.50 in FC5: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176171 > > and quite a number of users have asked for updates to > > http://people.redhat.com/petersen/emacs/ > ;) > > This is kind of a difficult situation on the one hand we don't want to ship a > pre-release if possible or to lessen the "pressure" on upstream to put out a > stable release. On the other hand since there is a reasonable chance that Pressure on Emacs upstream? When has that ever worked? It has always had the opposite effect of causing people to dig in and say its not perfect yet because they just found a small spelling error in the Meta-X translate-armenian-to-swahili-via-urdu that is very very important to all the Emacs users. I would vote for the pre-release.. I would also go with compat-emacs-22 versus emacs22. -- Stephen J Smoogen. CSIRT/Linux System Administrator From dcbw at redhat.com Fri Jan 20 16:57:10 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 20 Jan 2006 11:57:10 -0500 Subject: Extras buildsystem maintenance (again) Message-ID: <1137776231.26970.0.camel@localhost.localdomain> Hi, Buildsystem will be down for a while this afternoon (ie, around 1pm US EST) to tested fixes to the SSL hangs we've all cursed for the past week. Dan From dcbw at redhat.com Sun Jan 22 06:34:39 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 22 Jan 2006 01:34:39 -0500 Subject: Extras buildsystem maintenance (again) In-Reply-To: <1137776231.26970.0.camel@localhost.localdomain> References: <1137776231.26970.0.camel@localhost.localdomain> Message-ID: <1137911679.15096.2.camel@localhost.localdomain> On Fri, 2006-01-20 at 11:57 -0500, Dan Williams wrote: > Hi, > > Buildsystem will be down for a while this afternoon (ie, around 1pm US > EST) to tested fixes to the SSL hangs we've all cursed for the past > week. The buildsystem is back up at this time. There will be further downtime in the next few days to upgrade the builders themselves (and bring hammer3 back from the dead). Please continue to post timeout messages from plague-client if you get them, so I can be alerted to problems as they arise. Thanks for the patience, Dan (PS - Rawhide is broken right now due to udev->hotplug dependency, so your builds there will fail. FYI) From bugs.michael at gmx.net Thu Jan 26 08:38:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Jan 2006 09:38:24 +0100 Subject: Fedora Extras 3 and 4: Broken packages removed Message-ID: <20060126093824.015fb239.bugs.michael@gmx.net> After no response by package maintainers on the "broken deps" reports mailed in November or later, I have removed the following binary packages from the repository. Before triggering rebuilds of any updates, please make sure you don't reintroduce broken dependencies. Fedora Extras 3: python-nltk pyxdg smeg Fedora Extras 4: geomview-plugins-1.8.1-11 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpo at di.uminho.pt Sat Jan 28 01:53:24 2006 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 28 Jan 2006 01:53:24 +0000 Subject: Development repo: file removal request Message-ID: <43DACE94.80703@di.uminho.pt> Could someone remove the following files - perl-Archive-Zip-1.12-2.* (FC-4/5 core package) - perl-IO-String-1.06-2.* (FC-4/5 core package) - perl-XML-Simple-2.13-2.* (new FC-5 core package) - perl-XML-Simple-2.14-1.fc5.* (new FC-5 core package) from the development repository? Thanks in advance, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Sat Jan 28 09:49:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Jan 2006 10:49:53 +0100 Subject: Development repo: file removal request In-Reply-To: <43DACE94.80703@di.uminho.pt> References: <43DACE94.80703@di.uminho.pt> Message-ID: <20060128104953.582a51c0.bugs.michael@gmx.net> On Sat, 28 Jan 2006 01:53:24 +0000, Jos? Pedro Oliveira wrote: > Could someone remove the following files > > - perl-Archive-Zip-1.12-2.* (FC-4/5 core package) > - perl-IO-String-1.06-2.* (FC-4/5 core package) > - perl-XML-Simple-2.13-2.* (new FC-5 core package) > - perl-XML-Simple-2.14-1.fc5.* (new FC-5 core package) > > from the development repository? > > Thanks in advance, > jpo (FE apparently.) Done. From fedora at leemhuis.info Sun Jan 29 11:31:13 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 29 Jan 2006 12:31:13 +0100 Subject: New tracker bugs for the use of ExcludeArchs in packages Message-ID: <1138534273.2849.32.camel@localhost.localdomain> Hi, Sorry for crossposting -- replies please only to fedora-extras-list. tia! Just FYI, I created several new tracker bugs: 179258 - FE-ExcludeArch-x86 179259 - FE-ExcludeArch-x64 179260 - FE-ExcludeArch-PPC How should they get used? Simple: If you have a packages that uses ExcludeArch or ExclusiveArch to exclude some architectures from the build you need to file a separate bug for them [*1]. This bug should be marked as blocking the corresponding tracker bug(s) listed above -- this simplifies tracking such issues for other people interested in these archs that might want to take a look into the problem and fix it. Note: If the bug you created for your package is probably unfixable (Examples: apt for x86-64 will probably never happen; wine for ppc seems also unlikely; Packages specific to ppc that use a ExclusiveArch: ppc ppc64) then you should close the bug directly after reporting. Otherwise leave it open. CU thl [*1] -- Quote from http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines > MUST: If the package does not successfully compile, build or work on > an architecture, then those architectures should be listed in the spec > in ExcludeArch. Each architecture listed in ExcludeArch needs to have > a bug filed in bugzilla, describing the reason that the package does > not compile/build/work on that architecture. The bug number should > then be placed in a comment, next to the corresponding ExcludeArch > line. New packages will not have bugzilla entries during the review > process, so they should put this description in the comment until the > package is approved, then file the bugzilla entry, and replace the > long explanation with the bug number. -- Thorsten Leemhuis -------------- 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 Sun Jan 29 12:30:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 29 Jan 2006 13:30:36 +0100 Subject: New tracker bugs for the use of ExcludeArchs in packages In-Reply-To: <1138534273.2849.32.camel@localhost.localdomain> References: <1138534273.2849.32.camel@localhost.localdomain> Message-ID: <1138537836.14256.23.camel@mccallum.corsepiu.local> On Sun, 2006-01-29 at 12:31 +0100, Thorsten Leemhuis wrote: > Hi, > > Sorry for crossposting -- replies please only to fedora-extras-list. > tia! > > Just FYI, I created several new tracker bugs: > > 179258 - FE-ExcludeArch-x86 > 179259 - FE-ExcludeArch-x64 > 179260 - FE-ExcludeArch-PPC > > How should they get used? Why have users to cope with this at all? It probably wouldn't be too difficult to write script to iterate through all *.specs or srpms and update such bugzilla PRs automatically. Ralf From jorton at redhat.com Tue Jan 31 11:51:33 2006 From: jorton at redhat.com (Joe Orton) Date: Tue, 31 Jan 2006 11:51:33 +0000 Subject: neon soname bump Message-ID: <20060131115133.GB3466@redhat.com> neon 0.25.x is built in Raw Hide now, so RPM and OO.o need rebuilding - let me know if you want me to do this myself. There is a neon 0.24.x compat package in the buildroot (only) so that rpm is not broken in the mean time. Regards, joe From pnasrat at redhat.com Tue Jan 31 16:21:09 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 31 Jan 2006 11:21:09 -0500 Subject: neon soname bump In-Reply-To: <20060131115133.GB3466@redhat.com> References: <20060131115133.GB3466@redhat.com> Message-ID: <1138724470.2698.1.camel@enki.eridu> On Tue, 2006-01-31 at 11:51 +0000, Joe Orton wrote: > neon 0.25.x is built in Raw Hide now, so RPM and OO.o need rebuilding - > let me know if you want me to do this myself. Thanks for the heads off I'm just kicking off a build. > There is a neon 0.24.x compat package in the buildroot (only) so that > rpm is not broken in the mean time. Paul From jpo at di.uminho.pt Tue Jan 31 19:03:23 2006 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Tue, 31 Jan 2006 19:03:23 +0000 Subject: Perl modules that may be updated Message-ID: <43DFB47B.9020306@di.uminho.pt> Hi, I have started cooking a couple of scripts to crosscheck information regarding perl related packages in FE (right now only perl-* packages). The list below represents a possible list of perl modules [1] that *could* be updated by their maintainers. I say could because some of the modules may require additional reqs not yet available, may need perl core modules that will only be available in perl 5.8.8, etc. Development repodata vs CPAN 02packages.details.txt+blacklist --------------------------------------------------------------------- * Apache-Session-1.6 (Apache-Session-1.80.tar.gz) * Class-Autouse-1.21 (Class-Autouse-1.24.tar.gz) * Class-DBI-0.96 (Class-DBI-v3.0.14.tar.gz) * Class-DBI-AbstractSearch-0.05 (Class-DBI-AbstractSearch-0.07.tar.gz) * Class-DBI-Loader-0.22 (Class-DBI-Loader-0.29.tar.gz) * Class-DBI-Pg-0.06 (Class-DBI-Pg-0.07.tar.gz) * Class-DBI-Plugin-RetrieveAll-1.02 (Class-DBI-Plugin-RetrieveAll-1.04.tar.gz) * Class-MethodMaker-2.06 (Class-MethodMaker-2.08.tar.gz) * Crypt-Blowfish-2.09 (Crypt-Blowfish-2.10.tar.gz) * Crypt-CBC-2.14 (Crypt-CBC-2.15.tar.gz) * Exception-Class-1.22 (Exception-Class-1.23.tar.gz) * File-Slurp-9999.09 (File-Slurp-9999.11.tar.gz) * Image-ExifTool-5.89 (Image-ExifTool-5.87.tar.gz; see also the author's homepage) * Imager-0.45 (Imager-0.47.tar.gz) * Mail-SPF-Query-1.997 (Mail-SPF-Query-1.998.tar.gz) * Net-CIDR-Lite-0.18 (Net-CIDR-Lite-0.19.tar.gz) * Net-Patricia-1.010 (Net-Patricia-1.014.tar.gz) * Params-Validate-0.79 (Params-Validate-0.80.tar.gz) * Spreadsheet-WriteExcel-2.15 (Spreadsheet-WriteExcel-2.16.tar.gz) * Test-Builder-Tester-1.01 (v1.02 is a perl 5.8.8 core module) * Test-MockObject-0.15 (Test-MockObject-1.02.tar.gz) * Test-Pod-1.20 (Test-Pod-1.22.tar.gz) * Unicode-MapUTF8-1.09 (Unicode-MapUTF8-1.11.tar.gz) * Unicode-String-2.07 (Unicode-String-2.09.tar.gz) * Unix-Statgrab-0.03 (Unix-Statgrab-0.04.tar.gz) * Unix-Syslog-0.100 (Unix-Syslog-0.99.tar.gz) * X11-Protocol-0.54 (X11-Protocol-0.55.tar.gz) * libintl-1.11 (libintl-perl-1.16.tar.gz) * version-0.51 (version-0.53.tar.gz) I would appreciate if the maintainers of the listed modules could update them and/or report any problems, false positives to me. Thanks in advance, jpo References: [1] - Obtained by crosschecking the development repository version against the latest version available in CPAN. PS - Test-Builder-Tester, Test-MockObject, and Test-Pod are mine: * Test-Builder-Tester - the latest version is a perl 5.8.8 core module * Test-MockObject - requires new perl modules (IIRC one of them requires perl 5.8.8) * Test-Pod - requires perl 5.8.8 (Test::Builder::Tester, Test::More) -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: