From rdieter at math.unl.edu Mon May 1 00:15:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Apr 2006 19:15:27 -0500 Subject: cvs-import.sh problem (somewhat urgent) In-Reply-To: <44552B01.1000104@hhs.nl> References: <44552AB3.80609@hhs.nl> <44552B01.1000104@hhs.nl> Message-ID: Hans de Goede wrote: >> But thats not the problem, the problem is that cvs-import has decided to >> drop a couple of large .ogg files into CVS instead of the lookaside >> cache, should I abort the import with CTRL-C or? > Darn, to late how do I (we) fix this? cvs remove *.ogg make upload FILES=*.ogg -- Rex From tibbs at math.uh.edu Mon May 1 01:28:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 30 Apr 2006 20:28:52 -0500 Subject: How forbidden is RPATH? In-Reply-To: <1146377314.3878.8.camel@localhost> (Toshio Kuratomi's message of "Sat, 29 Apr 2006 23:08:33 -0700") References: <1146377314.3878.8.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> It's being added into the link line by libtool. Here's how to get TK> rid of it:: make LIBTOOL=/usr/bin/libtool Yes, that's one of the many things I tried. It fails to work for this package. - J< From davidswaty at gmail.com Mon May 1 02:02:51 2006 From: davidswaty at gmail.com (David Swaty) Date: Sun, 30 Apr 2006 21:02:51 -0500 Subject: [Bug 169717] Review Request: Internode DSL usage applet In-Reply-To: <200604191645.k3JGjrQc014254@www.beta.redhat.com> References: <200604191645.k3JGjrQc014254@www.beta.redhat.com> Message-ID: <87c8c03f0604301902g691cbe5x129d6456bab806a2@mail.gmail.com> please opt out On 4/19/06, bugzilla at redhat.com wrote: > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: Review Request: Internode DSL usage applet > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169717 > > > bugzilla at redhat.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC|fedora-extras- | > |list at redhat.com | > CC| |fedora-package- > | |review at redhat.com > CC|fedora-package- | > |review at redhat.com | > CC| |fedora-extras- > | |list at redhat.com > > wtogami at redhat.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > QAContact|dkl at redhat.com |fedora-package- > | |review at redhat.com > CC|fedora-extras- | > |list at redhat.com | > > > > > -- > Configure bugmail: > https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toshio at tiki-lounge.com Mon May 1 03:00:00 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 30 Apr 2006 20:00:00 -0700 Subject: How forbidden is RPATH? In-Reply-To: References: <1146377314.3878.8.camel@localhost> Message-ID: <1146452400.24326.6.camel@localhost> On Sun, 2006-04-30 at 20:28 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> It's being added into the link line by libtool. Here's how to get > TK> rid of it:: make LIBTOOL=/usr/bin/libtool > > Yes, that's one of the many things I tried. It fails to work for this > package. Strange. I tried it on the package in question (rapidsvn) before I posted, so I know it works here. Are you sure you did make LIBTOOL=/usr/bin/libtool rather than: LIBTOOL=libtool ./configure or: LIBTOOL=/usr/bin/libtool make If you look in the configure script, you'll see that it prevents env variables from overriding the LIBTOOL variable. There's no such restriction on make's commandline, however. Are you building on FC5 or devel? I tried it on FC5 .. libtool-1.5.22-2.2 -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 j.w.r.degoede at hhs.nl Mon May 1 05:15:25 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 07:15:25 +0200 Subject: cvs-import.sh problem (somewhat urgent) In-Reply-To: References: <44552AB3.80609@hhs.nl> <44552B01.1000104@hhs.nl> Message-ID: <4455996D.2000204@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: > >>> But thats not the problem, the problem is that cvs-import has decided to >>> drop a couple of large .ogg files into CVS instead of the lookaside >>> cache, should I abort the import with CTRL-C or? > >> Darn, to late how do I (we) fix this? > > cvs remove *.ogg > make upload FILES=*.ogg > Thanks, I already figured as much, fixed. Where do I report this erm feature of cvs-import.sh? Regards, Hans From nicolas.mailhot at laposte.net Mon May 1 08:18:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 01 May 2006 10:18:20 +0200 Subject: Unorphan: arc In-Reply-To: <44551F2B.40300@hhs.nl> References: <4454A9CB.90009@hhs.nl> <1146407357.2640.3.camel@rousalka.dyndns.org> <4454E121.30900@hhs.nl> <1146428335.2640.32.camel@rousalka.dyndns.org> <44551F2B.40300@hhs.nl> Message-ID: <1146471503.6445.1.camel@rousalka.dyndns.org> Le dimanche 30 avril 2006 ? 22:33 +0200, Hans de Goede a ?crit : > > Nicolas Mailhot wrote: > > since arc is taken care of, may I drop nomarch? > > > Erm, the idea was to lower the count of orphans, but you're a free man > and its a free world. Just kidding, though actually I don't think fedora needs two arc handlers (old legacy format after all). I'll only do it if I need time for something else -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon May 1 08:20:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 01 May 2006 11:20:20 +0300 Subject: cvs-import.sh problem (somewhat urgent) In-Reply-To: <4455996D.2000204@hhs.nl> References: <44552AB3.80609@hhs.nl> <44552B01.1000104@hhs.nl> <4455996D.2000204@hhs.nl> Message-ID: <1146471621.5802.0.camel@localhost.localdomain> On Mon, 2006-05-01 at 07:15 +0200, Hans de Goede wrote: > Where do I report this erm feature of cvs-import.sh? Fedora Infrastructure -> cvs in Bugzilla. From j.w.r.degoede at hhs.nl Mon May 1 08:37:19 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 10:37:19 +0200 Subject: Unorphan: arc In-Reply-To: <1146471503.6445.1.camel@rousalka.dyndns.org> References: <4454A9CB.90009@hhs.nl> <1146407357.2640.3.camel@rousalka.dyndns.org> <4454E121.30900@hhs.nl> <1146428335.2640.32.camel@rousalka.dyndns.org> <44551F2B.40300@hhs.nl> <1146471503.6445.1.camel@rousalka.dyndns.org> Message-ID: <4455C8BF.1020301@hhs.nl> Nicolas Mailhot wrote: > Le dimanche 30 avril 2006 ? 22:33 +0200, Hans de Goede a ?crit : >> Nicolas Mailhot wrote: > >>> since arc is taken care of, may I drop nomarch? >>> >> Erm, the idea was to lower the count of orphans, but you're a free man >> and its a free world. > > Just kidding, though actually I don't think fedora needs two arc > handlers (old legacy format after all). I'll only do it if I need time > for something else > That brings us off topic to the question of how to really remove packages? I think this should be done in the devel branch only, but it really needs to be done and we need some policy for this. For example etherdiag, netdiag and mknbi look like fine candidates for full removal to me. Are these still available from the devel repo, or are these only still in CVS? If so how do we differentiate in CVS between orphan but still available in devel repo could use a new maintainer. And orphan, (should be) removed from devel repo, concidered dead unless someone really still has a use for it and wants to pick it up? Regards, Hans From Christian.Iseli at licr.org Mon May 1 08:51:22 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 01 May 2006 10:51:22 +0200 Subject: Unorphan: arc In-Reply-To: Your message of "Mon, 01 May 2006 10:37:19 +0200." <4455C8BF.1020301@hhs.nl> Message-ID: <200605010851.k418pMqb018893@ludwig-alpha.unil.ch> j.w.r.degoede at hhs.nl said: > That brings us off topic to the question of how to really remove packages? I thought we'd agreed to do: - "cvs delete" of all the files in the devel branch - put an appropriate README file in their stead - remove package files from the devel repo When some maintainer decides to revive the package, it's easy enough to retrieve the previous CVS version and restart from there (probably go through a round of review, but I can't remember if this was agreed upon or not) Christian From j.w.r.degoede at hhs.nl Mon May 1 09:46:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 11:46:36 +0200 Subject: Removing packages (was Unorphan: arc) In-Reply-To: <200605010851.k418pMqb018893@ludwig-alpha.unil.ch> References: <200605010851.k418pMqb018893@ludwig-alpha.unil.ch> Message-ID: <4455D8FC.9000702@hhs.nl> Christian.Iseli at licr.org wrote: > j.w.r.degoede at hhs.nl said: >> That brings us off topic to the question of how to really remove packages? > > I thought we'd agreed to do: > - "cvs delete" of all the files in the devel branch > - put an appropriate README file in their stead > - remove package files from the devel repo > > When some maintainer decides to revive the package, it's easy enough to > retrieve the previous CVS version and restart from there (probably go through a > round of review, but I can't remember if this was agreed upon or not) > > Christian > Currently all the orphan packages have their specfile changed so that they don'y build and they might have been removed from the ddevel repo, I didn't check. I think the current way is goode for packages which are unorphaned because the maintainer is MIA or doesn't have time anymore, but which do have a future, I think your way is a good idea for packages which may assumed dead. That way we can differentiate between the two cases. Maybe we should put something about this in the wiki somewhere, but where and what? Regards, Hans From tibbs at math.uh.edu Mon May 1 09:54:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 01 May 2006 04:54:11 -0500 Subject: How forbidden is RPATH? In-Reply-To: <1146452400.24326.6.camel@localhost> (Toshio Kuratomi's message of "Sun, 30 Apr 2006 20:00:00 -0700") References: <1146377314.3878.8.camel@localhost> <1146452400.24326.6.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> Strange. I tried it on the package in question (rapidsvn) before TK> I posted, so I know it works here. OK, you're right; I had done LIBTOOL=libtool %configure. Your suggestion does work; there's a new static library gets installed which needs cleaning up, but that's no big deal. Thanks for your input. - J< From buildsys at fedoraproject.org Mon May 1 10:32:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 1 May 2006 06:32:34 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060501103234.1B72A152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 3 global-5.0-1.fc3 ocaml-3.09.2-1.fc3 zile-2.2.13-2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 1 10:34:35 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 1 May 2006 06:34:35 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060501103435.846E4152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 40 GeoIP-1.3.16-1.fc4 amaya-9.5-1.fc4 bsd-games-2.17-9.fc4 ccrtp-1.3.7-1.fc4 doctorj-5.0.0-4.fc4 gauche-0.8.7-4.fc4 git-1.3.1-1.fc4 global-5.0-1.fc4 heartbeat-2.0.5-1.fc4 mod_cband-0.9.7.3-2.fc4 ocaml-3.09.2-1.fc4 perl-DBM-Deep-0.983-1.fc4 perl-Email-Address-1.80-1.fc4 perl-Email-MIME-ContentType-1.01-1.fc4 perl-Email-MIME-Encodings-1.3-1.fc4 perl-Email-MessageID-1.31-1.fc4 perl-Email-Simple-1.92-1.fc4 perl-HTTP-Proxy-0.19-1.fc4 pl-5.6.12-1.fc4 qgit-1.2-1.fc4 wings-0.98.32b-5.fc4 xfce4-cpugraph-plugin-0.2.2-5.fc4 xfce4-datetime-plugin-0.3.1-6.fc4 xfce4-diskperf-plugin-1.5-5.fc4 xfce4-fsguard-plugin-0.2.1-3.fc4 xfce4-genmon-plugin-1.1-5.fc4 xfce4-minicmd-plugin-0.3.0-5.fc4 xfce4-modemlights-plugin-0.1.1-4.fc4 xfce4-mount-plugin-0.3.3-2.fc4 xfce4-netload-plugin-0.3.3-5.fc4 xfce4-screenshooter-plugin-0.0.8-2.fc4 xfce4-showdesktop-plugin-0.4.0-5.fc4 xfce4-systemload-plugin-0.3.6-5.fc4 xfce4-taskbar-plugin-0.2.2-5.fc4 xfce4-wavelan-plugin-0.4.1-5.fc4 xfce4-websearch-plugin-0.1.0-5.fc4 xfce4-windowlist-plugin-0.1.0-5.fc4 xfce4-xkb-plugin-0.3.5-2.fc4 xfce4-xmms-plugin-0.3.1-5.fc4 zile-2.2.13-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 1 10:35:28 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 1 May 2006 06:35:28 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060501103528.980A2152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 51 GeoIP-1.3.16-1.fc5 amaya-9.5-1.fc5 bsd-games-2.17-9.fc5 ccrtp-1.3.7-1.fc5 doctorj-5.0.0-3.fc5 doctorj-5.0.0-4.fc5 gauche-0.8.7-4.fc5 git-1.3.1-1.fc5 global-5.0-1.fc5 heartbeat-2.0.5-1.fc5 jhead-2.6-1.fc5 mod_cband-0.9.7.3-2.fc5 monkey-bubble-0.3.2-1.fc5 ocaml-3.09.2-1.fc5 perl-DBM-Deep-0.983-1.fc5 perl-Email-Address-1.80-1.fc5 perl-Email-MIME-ContentType-1.01-1.fc5 perl-Email-MIME-Encodings-1.3-1.fc5 perl-Email-MessageID-1.31-1.fc5 perl-Email-Simple-1.92-1.fc5 perl-HTTP-Proxy-0.19-1.fc5 pl-5.6.12-1.fc5 qgit-1.2-1.fc5 qof-0.6.4-3.fc5 rman-3.2-3.fc5 up-imapproxy-1.2.4-6.fc5 wings-0.98.32b-6.fc5 xfce4-battery-plugin-0.3.0-6.fc5 xfce4-clipman-plugin-0.4.1-6.fc5 xfce4-cpugraph-plugin-0.2.2-6.fc5 xfce4-datetime-plugin-0.3.1-7.fc5 xfce4-diskperf-plugin-1.5-6.fc5 xfce4-fsguard-plugin-0.2.1-4.fc5 xfce4-genmon-plugin-1.1-6.fc5 xfce4-minicmd-plugin-0.3.0-6.fc5 xfce4-modemlights-plugin-0.1.1-7.fc5 xfce4-mount-plugin-0.3.3-3.fc5 xfce4-netload-plugin-0.3.3-6.fc5 xfce4-notes-plugin-0.11.1-4.fc5 xfce4-quicklauncher-plugin-0.81-4.fc5 xfce4-sensors-plugin-0.7.0-5.fc5 xfce4-showdesktop-plugin-0.4.0-6.fc5 xfce4-systemload-plugin-0.3.6-6.fc5 xfce4-taskbar-plugin-0.2.2-6.fc5 xfce4-wavelan-plugin-0.4.1-6.fc5 xfce4-websearch-plugin-0.1.0-6.fc5 xfce4-windowlist-plugin-0.1.0-6.fc5 xfce4-xkb-plugin-0.3.5-2.fc5 xfce4-xmms-plugin-0.3.1-6.fc5 xlockmore-5.22-1.fc5 zile-2.2.13-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 1 10:38:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 1 May 2006 06:38:20 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060501103820.A9187152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 42 AllegroOGG-1.0.3-2.fc6 GeoIP-1.3.16-1.fc6 amaya-9.5-1.fc6 bogofilter-1.0.2-1.fc6 bsd-games-2.17-9.fc6 ccrtp-1.3.7-1.fc6 clamav-0.88.2-1.fc6 dclib-0.3.7-7.fc6 doctorj-5.0.0-3.fc6 doctorj-5.0.0-4.fc6 gauche-0.8.7-4.fc6 gcompris-7.4-4.fc6 ghc-6.4.2-2.fc6 git-1.3.1-1.fc6 global-5.0-1.fc6 heartbeat-2.0.5-1.fc6 hevea-1.08-4.fc6 hevea-1.08-5.fc6 jhead-2.6-1.fc6 kchmviewer-2.0-3.fc6 kismet-0.0.2006.04.R1-2.fc6 libsndfile-1.0.16-1.fc6 maxima-5.9.3-3.fc6 mod_cband-0.9.7.3-2.fc6 mod_extract_forwarded-2.0.2-1.fc6 monkey-bubble-0.3.2-1.fc6 ocaml-3.09.2-1.fc6 octave-forge-2006.03.17-3.fc6 pan-0.95-1.fc6 perl-Email-MIME-ContentType-1.01-1.fc6 perl-Email-MIME-Encodings-1.3-1.fc6 perl-Gtk2-1.121-2.fc6 pl-5.6.12-1.fc6 qgit-1.2-1.fc6 qof-0.6.4-3.fc6 raidem-0.3.1-1.fc6 raidem-0.3.1-2.fc6 up-imapproxy-1.2.4-6.fc6 valknut-0.3.7-8.fc6 wings-0.98.32b-5.fc6 xlockmore-5.22-1.fc6 zile-2.2.13-2.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From j.w.r.degoede at hhs.nl Mon May 1 10:47:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 12:47:08 +0200 Subject: optional game music files In-Reply-To: <445528B8.6020807@kobold.org> References: <445528B8.6020807@kobold.org> Message-ID: <4455E72C.6080800@hhs.nl> Wart wrote: > I recently reviewed a request for raidem-music: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 > > This package contains background music (ogg format) for the game raidem. > The music is not required to play the game, and is not part of the > upstream sources, but was written for the game. > > The packaging guidelines state: > > # Game levels are not considered content, since games without levels > would be non functional. > # Sound or graphics included with the source tarball that the program or > theme uses (or the documentation uses) are acceptable. > > but also say: > > Some examples of content which are not permissable: > > * Ogg/mp3 files > > Since these ogg files are part of the game, but not part of the upstream > sources, are they still considered acceptable? > Since there has been no reaction for the last 12 hours, may I assume that no-one objects or? Regards, Hans From ville.skytta at iki.fi Mon May 1 11:13:32 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 01 May 2006 14:13:32 +0300 Subject: optional game music files In-Reply-To: <4455E72C.6080800@hhs.nl> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> Message-ID: <1146482012.5802.37.camel@localhost.localdomain> On Mon, 2006-05-01 at 12:47 +0200, Hans de Goede wrote: > Wart wrote: > > > > Some examples of content which are not permissable: > > > > * Ogg/mp3 files > > > > Since these ogg files are part of the game, but not part of the upstream > > sources, are they still considered acceptable? > > > > Since there has been no reaction for the last 12 hours, may I assume > that no-one objects or? IMO 12 hours is much too little time for doing something which appears to be directly against the packaging guidelines, especially considering that today is a holiday in lots of countries and probably considerably less people than usual are reading their FE mail. Patience, please. I'm not saying that this case is not acceptable for inclusion, but it sounds somewhat like being against the intended purpose or the "spirit" of that rule. I guess it depends on exactly how optional those files are, how easy it is to properly install/remove them without them being rpm-packaged, and whether anyone would have any complaints about their inclusion if they'd be part of the upstream tarball which also contains the actual game. (There are some examples in the repo that I think would be better off handled by end users themselves and not packaged, so one should apply criticism when/if looking for previous examples. One example are the huge optional content blobs for uqm, of which only a subset changes between releases which can't be sanely handled in the current uqm-content package. But the uqm case predates the guideline...) From Christian.Iseli at licr.org Mon May 1 11:33:38 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 01 May 2006 13:33:38 +0200 Subject: Removing packages (was Unorphan: arc) In-Reply-To: Your message of "Mon, 01 May 2006 11:46:36 +0200." <4455D8FC.9000702@hhs.nl> Message-ID: <200605011133.k41BXcvq020121@ludwig-alpha.unil.ch> j.w.r.degoede at hhs.nl said: > Currently all the orphan packages have their specfile changed so that they > don'y build and they might have been removed from the ddevel repo, I didn't > check. Last time I ran the checking script, there were 58 orphans, and 15 of them had a package in the repo. So most of them are removed, but not all... I think they all should be. For devel, I think the policy should be "all the packages present in the repo must have a maintainer". The maintainer is free to offer the package to be taken over on the orphan wiki page, but either the current maintainer's email address stays in owners, or the package is removed from the repo. > I think the current way is goode for packages which are unorphaned because > the maintainer is MIA or doesn't have time anymore, but which do have a > future, I think your way is a good idea for packages which may assumed dead. > That way we can differentiate between the two cases. Ok, that makes sense. > Maybe we should put something about this in the wiki somewhere, but where > and what? Good question. The closest match is perhaps Extras/OrphanedPackages ? Or start a FE packages lifecycle page... I attempted something along those lines on the Extras/SIGs/QA wiki page... Cheers, Christian From j.w.r.degoede at hhs.nl Mon May 1 11:59:48 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 13:59:48 +0200 Subject: optional game music files In-Reply-To: <1146482012.5802.37.camel@localhost.localdomain> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> Message-ID: <4455F834.7090401@hhs.nl> Ville Skytt? wrote: > On Mon, 2006-05-01 at 12:47 +0200, Hans de Goede wrote: >> Wart wrote: >>> Some examples of content which are not permissable: >>> >>> * Ogg/mp3 files >>> >>> Since these ogg files are part of the game, but not part of the upstream >>> sources, are they still considered acceptable? >>> >> Since there has been no reaction for the last 12 hours, may I assume >> that no-one objects or? > > IMO 12 hours is much too little time for doing something which appears > to be directly against the packaging guidelines, especially considering > that today is a holiday in lots of countries and probably considerably > less people than usual are reading their FE mail. Patience, please. > I wasn't aware of the vacation bit, sure I'll wait a bit more. > I'm not saying that this case is not acceptable for inclusion, but it > sounds somewhat like being against the intended purpose or the "spirit" > of that rule. I guess it depends on exactly how optional those files > are, how easy it is to properly install/remove them without them being > rpm-packaged, and whether anyone would have any complaints about their > inclusion if they'd be part of the upstream tarball which also contains > the actual game. > Thats exactly my problem with the possible explanation of these rules as this being unacceptable, if these files were in the same upstream tarball as the game engine and other gamedata nobody would be complaining. I've packaged plenty of other game packages containing music, how is this _any_ different except that the music is in a seperate tarball? Which is acutally good, because this means that the raidem-music pakcage will probably never have to change saving bandwidth! I would actually love to see other upstreams do similar splits, see below. However this whole story seems to penalize the good upstream behaviour of spitting of almost never changing content > (There are some examples in the repo that I think would be better off > handled by end users themselves and not packaged) If the files are looked for by the package / game under /usr/share/%{name} I believe they should be packaged I don't want users dropping stuff there themselves potentially breaking upgrades, leaving cruft behind on uninstall, etc. >, so one should apply > criticism when/if looking for previous examples. One example are the > huge optional content blobs for uqm, of which only a subset changes > between releases which can't be sanely handled in the current > uqm-content package. But the uqm case predates the guideline...) > I know there are packages which could do with an upstream split in code and content so we could create seperate SRPMS for engine and content and thus easily (relative small download) upgrade the engine for bug fixes / new features. In general content tends to be much more static then the engines. I've actually been thinking about making 2 SRPMS both containing the same upstream tarball to fake this split. Unfortunatly this would take twice the space in the SRPMS dir on the mirrors, or I would have to create a split source tarbal myself. Regards, Hans From mpeters at mac.com Mon May 1 12:04:16 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 01 May 2006 05:04:16 -0700 Subject: Removing packages (was Unorphan: arc) In-Reply-To: <200605011133.k41BXcvq020121@ludwig-alpha.unil.ch> References: <200605011133.k41BXcvq020121@ludwig-alpha.unil.ch> Message-ID: <1146485056.6818.8.camel@atlantis.mpeters.local> On Mon, 2006-05-01 at 13:33 +0200, Christian.Iseli at licr.org wrote: > For devel, I think the policy should be "all the packages present in the repo > must have a maintainer". The maintainer is free to offer the package to be > taken over on the orphan wiki page, but either the current maintainer's email > address stays in owners, or the package is removed from the repo. I like that idea - if an orphaned package is needed by a non orphaned packages, it will quickly become apparent. From katzj at redhat.com Mon May 1 12:15:56 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 08:15:56 -0400 Subject: Unorphan: arc In-Reply-To: <200605010851.k418pMqb018893@ludwig-alpha.unil.ch> References: <200605010851.k418pMqb018893@ludwig-alpha.unil.ch> Message-ID: <1146485756.25113.2.camel@aglarond.local> On Mon, 2006-05-01 at 10:51 +0200, Christian.Iseli at licr.org wrote: > j.w.r.degoede at hhs.nl said: > > That brings us off topic to the question of how to really remove packages? > > I thought we'd agreed to do: > - "cvs delete" of all the files in the devel branch > - put an appropriate README file in their stead Using a unique filename (eg, dead.package or something like that) is better than README as then the automated branch done around a release time can more easily tell which packages shouldn't actually have a release branch made. Jeremy From Christian.Iseli at licr.org Mon May 1 12:22:29 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 01 May 2006 14:22:29 +0200 Subject: Unorphan: arc In-Reply-To: Your message of "Mon, 01 May 2006 08:15:56 EDT." <1146485756.25113.2.camel@aglarond.local> Message-ID: <200605011222.k41CMTkr020807@ludwig-alpha.unil.ch> katzj at redhat.com said: > Using a unique filename (eg, dead.package or something like that) is better > than README as then the automated branch done around a release time can more > easily tell which packages shouldn't actually have a release branch made. Agreed. Christian From mpeters at mac.com Mon May 1 13:03:24 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 01 May 2006 06:03:24 -0700 Subject: optional game music files In-Reply-To: <4455F834.7090401@hhs.nl> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> <4455F834.7090401@hhs.nl> Message-ID: <1146488605.6818.17.camel@atlantis.mpeters.local> On Mon, 2006-05-01 at 13:59 +0200, Hans de Goede wrote: > > I know there are packages which could do with an upstream split in code > and content so we could create seperate SRPMS for engine and content and > thus easily (relative small download) upgrade the engine for bug fixes / > new features. Yes - replacing large amounts of content that does not change for a small patch that has no effect on content whatsoever is an incredible waste of bandwidth, which some people have to pay for on a usage basis. There needs to be an exception defined to the rule for such cases, as splitting the static content from the code is a practice that should be encouraged, not discouraged. From bugs.michael at gmx.net Mon May 1 14:09:46 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 01 May 2006 14:09:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-01 Message-ID: <20060501140946.4434.5472@rawhide.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From bugs.michael at gmx.net Mon May 1 14:09:43 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 01 May 2006 14:09:43 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-01 Message-ID: <20060501140943.4431.50623@rawhide.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Mon May 1 14:09:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 01 May 2006 14:09:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-01 Message-ID: <20060501140950.4436.44692@rawhide.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gcompris-devel 7.4-4.fc6.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 sobby 0.3.0-2.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gcompris-devel 7.4-4.fc6.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc sobby 0.3.0-2.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gcompris-devel 7.4-4.fc6.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 sobby 0.3.0-2.fc5.x86_64 ====================================================================== New report for: j.w.r.degoede AT hhs.nl package: gcompris-devel - 7.4-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: gcompris-lib = 0:7.4 package: gcompris-devel - 7.4-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gcompris-lib = 0:7.4 package: gcompris-devel - 7.4-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: gcompris-lib = 0:7.4 ====================================================================== package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: sobby - 0.3.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: sobby - 0.3.0-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnet6-1.2.so.0()(64bit) libobby-0.3.so.0()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: sobby - 0.3.0-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 From fedora at leemhuis.info Mon May 1 15:21:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 01 May 2006 17:21:53 +0200 Subject: FESCo Elections 2006 Message-ID: <1146496913.2830.33.camel@localhost.localdomain> Hi All! As discussed on this list and during the last two FESCo meetings we're going to have a election of the members for the next FESCo. The plan how to do it exactly is a bit in the flux and will be adjusted in case that is needed -- we're doing it for the first time so please be patient and/or please help out where it seems to be needed. I put the rough plan into the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Election Everyone that wants to be in the next FESCo needs to nominate him/herself for it until May, 8 2006 0:00 UTC; that self-nomination should contain some information's like "Mission Statement, Past work summary and Future plans". I create a page in the wiki to collect the nominations: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Please put them there and send them to fedora-extras-list also. You can also nominate other people, but they have to write a self-nomination on their own. The actual election who will be part of the next FESCo is planed for the second week of May -- all members of the cvsextras group can vote. How this vote is actually done needs to be worked out before that timeframe. Help appreciated. As solution with public gpg-signed mails looks as the one that has the best chances currently. CU thl -- Thorsten Leemhuis From notting at redhat.com Mon May 1 17:16:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 May 2006 13:16:19 -0400 Subject: Security Response Team / EOL In-Reply-To: <200604301256.k3UCugct001761@devserv.devel.redhat.com> References: <44548DAA.2000004@timj.co.uk> <200604301256.k3UCugct001761@devserv.devel.redhat.com> Message-ID: <20060501171619.GG31572@devserv.devel.redhat.com> Josh Bressers (bressers at redhat.com) said: > There are other distributions that have used this policy in the past. The > result ends up being if the fix is bigger than a breadbox, it just never > gets fixed. The deciding factor should be which one is less invasive, and > that decision should be up to the packagers and the security response team. > There are times it's easier to apply a patch, there are times that one must > upgrade. A good example would be any sufficiently large and complex code base... the mozilla stack would apply here - in many cases, backporting would be an onerous task compared to simply upgrading to the new version with the security fix. Bill From icon at fedoraproject.org Mon May 1 18:51:35 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 01 May 2006 14:51:35 -0400 Subject: upload.cgi (Error 255) Message-ID: <445658B7.4080004@fedoraproject.org> make new-sources FILES="common-0.15.0.tar.gz" Checking : common-0.15.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 (generic whine here) :) -- Konstantin Ryabitsev McGill University WSG Book: "You got a plan?" Mal: "Hiding ain't a plan?" --"Serenity" From icon at fedoraproject.org Mon May 1 18:56:24 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 01 May 2006 14:56:24 -0400 Subject: upload.cgi (Error 255) In-Reply-To: <445658B7.4080004@fedoraproject.org> References: <445658B7.4080004@fedoraproject.org> Message-ID: <445659D8.8080208@fedoraproject.org> Konstantin Ryabitsev wrote: > make new-sources FILES="common-0.15.0.tar.gz" > > Checking : common-0.15.0.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-sources] Error 255 Please to be ignorink. My .fedora.cert is expirink. -- Konstantin Ryabitsev McGill University WSG Book: "You got a plan?" Mal: "Hiding ain't a plan?" --"Serenity" From katzj at redhat.com Mon May 1 18:58:14 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 14:58:14 -0400 Subject: upload.cgi (Error 255) In-Reply-To: <445659D8.8080208@fedoraproject.org> References: <445658B7.4080004@fedoraproject.org> <445659D8.8080208@fedoraproject.org> Message-ID: <1146509894.11225.45.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 14:56 -0400, Konstantin Ryabitsev wrote: > Konstantin Ryabitsev wrote: > > make new-sources FILES="common-0.15.0.tar.gz" > > > > Checking : common-0.15.0.tar.gz on > > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > ERROR: could not check remote file status > > make: *** [new-sources] Error 255 > > Please to be ignorink. My .fedora.cert is expirink. ... If someone wanted to send a patch for Makefile.common that checked for this case and said "hey silly! your cert expired!", I'd be glad to commit it... ;-) Jeremy From bugzilla at redhat.com Mon May 1 20:09:04 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 1 May 2006 16:09:04 -0400 Subject: [Bug 179852] FC4 buildsys fails - FC4 mock succeeds - wine-docs package In-Reply-To: Message-ID: <200605012009.k41K94Sj004909@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: FC4 buildsys fails - FC4 mock succeeds - wine-docs package https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852 ------- Additional Comments From williams at redhat.com 2006-05-01 16:08 EST ------- The output in the build log shows that the failure is in trying to generate the winedev-guide.txt file. The winedev-guide.sgml source has been successfully turned into HTML, PDF and Postscript by this point, so it's not a problem with the form of the source (unless the source has been whacked somehow). It happens on the first invocation of docbook2txt (which runs the elinks command internally). The only think I can think of do it is put a printf in the elinks source (to print out the name of the file it thinks is bad), regenerate the SRPM, put that SRPM into a local repository and then restart the build. Any other ideas? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From j.w.r.degoede at hhs.nl Mon May 1 20:39:16 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 22:39:16 +0200 Subject: comps where to put electronics simulation software (gnucap)? Message-ID: <445671F4.8040609@hhs.nl> Subject says it all. Regards, Hans From ville.skytta at iki.fi Mon May 1 20:55:30 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 01 May 2006 23:55:30 +0300 Subject: upload.cgi (Error 255) In-Reply-To: <1146509894.11225.45.camel@orodruin.boston.redhat.com> References: <445658B7.4080004@fedoraproject.org> <445659D8.8080208@fedoraproject.org> <1146509894.11225.45.camel@orodruin.boston.redhat.com> Message-ID: <1146516931.5802.62.camel@localhost.localdomain> On Mon, 2006-05-01 at 14:58 -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 14:56 -0400, Konstantin Ryabitsev wrote: > > Konstantin Ryabitsev wrote: > > > make new-sources FILES="common-0.15.0.tar.gz" > > > > > > Checking : common-0.15.0.tar.gz on > > > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > > ERROR: could not check remote file status > > > make: *** [new-sources] Error 255 > > > > Please to be ignorink. My .fedora.cert is expirink. > > ... > > If someone wanted to send a patch for Makefile.common that checked for > this case and said "hey silly! your cert expired!", I'd be glad to > commit it... ;-) Not a patch nor really tested, but maybe something naive like this would be helpful: cmd="openssl verify -CAfile $HOME/.fedora-upload-ca.cert $HOME/.fedora.cert" if ! $cmd 2>&1 | head -n 1 | grep -q ' OK$' ; then echo "Something seems to be wrong with your certificate:" $cmd exit 1 fi From katzj at redhat.com Mon May 1 21:02:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 17:02:47 -0400 Subject: upload.cgi (Error 255) In-Reply-To: <1146516931.5802.62.camel@localhost.localdomain> References: <445658B7.4080004@fedoraproject.org> <445659D8.8080208@fedoraproject.org> <1146509894.11225.45.camel@orodruin.boston.redhat.com> <1146516931.5802.62.camel@localhost.localdomain> Message-ID: <1146517367.11225.68.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 23:55 +0300, Ville Skytt? wrote: > On Mon, 2006-05-01 at 14:58 -0400, Jeremy Katz wrote: > > On Mon, 2006-05-01 at 14:56 -0400, Konstantin Ryabitsev wrote: > > > Konstantin Ryabitsev wrote: > > > > make new-sources FILES="common-0.15.0.tar.gz" > > > > > > > > Checking : common-0.15.0.tar.gz on > > > > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > > > ERROR: could not check remote file status > > > > make: *** [new-sources] Error 255 > > > > > > Please to be ignorink. My .fedora.cert is expirink. > > > > ... > > > > If someone wanted to send a patch for Makefile.common that checked for > > this case and said "hey silly! your cert expired!", I'd be glad to > > commit it... ;-) > > Not a patch nor really tested, but maybe something naive like this would > be helpful: Yeah, that was the thought on IRC, too, but OK is returned in the output no matter what... and I don't really think that parsing the output from openssl verify is likely to be something which long-term is sane to do. I wonder if there's a simple snippet that could be done with pyOpenSSL (since you have to have it installed for plague anyway) Jeremy From katzj at redhat.com Mon May 1 21:03:20 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 17:03:20 -0400 Subject: comps where to put electronics simulation software (gnucap)? In-Reply-To: <445671F4.8040609@hhs.nl> References: <445671F4.8040609@hhs.nl> Message-ID: <1146517400.11225.70.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 22:39 +0200, Hans de Goede wrote: > Subject says it all. I'd suggest the Engineering and Scientific software group Jeremy From icon at fedoraproject.org Mon May 1 21:07:35 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 01 May 2006 17:07:35 -0400 Subject: plague question Message-ID: <44567897.9060800@fedoraproject.org> Sorry, me again. I changed the email in my account from icon at linux.duke.edu to icon at fedoraproject.org. All bits work now, except I can't seem to be able to build any more: make build ... Server returned an error: Insufficient privileges. I've looked through the settings in the account system and they all seem sane, so I'm not sure where else I need to tweak to get back the privs. Any help? Cheers, -- Konstantin Ryabitsev McGill University WSG River: (near a woman in labor) "Who do you think is in there?" --Episode #13, "Heart of Gold" From skvidal at linux.duke.edu Mon May 1 21:16:10 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 01 May 2006 17:16:10 -0400 Subject: plague question In-Reply-To: <44567897.9060800@fedoraproject.org> References: <44567897.9060800@fedoraproject.org> Message-ID: <1146518170.7995.14.camel@cutter> On Mon, 2006-05-01 at 17:07 -0400, Konstantin Ryabitsev wrote: > Sorry, me again. > > I changed the email in my account from icon at linux.duke.edu to > icon at fedoraproject.org. All bits work now, except I can't seem to be > able to build any more: > > make build > ... > Server returned an error: Insufficient privileges. > > I've looked through the settings in the account system and they all seem > sane, so I'm not sure where else I need to tweak to get back the privs. Download a new ssl cert from the accounts interface. see if that works. -sv From dcbw at redhat.com Mon May 1 21:17:38 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 01 May 2006 17:17:38 -0400 Subject: plague question In-Reply-To: <1146518170.7995.14.camel@cutter> References: <44567897.9060800@fedoraproject.org> <1146518170.7995.14.camel@cutter> Message-ID: <1146518258.13675.0.camel@localhost.localdomain> On Mon, 2006-05-01 at 17:16 -0400, seth vidal wrote: > On Mon, 2006-05-01 at 17:07 -0400, Konstantin Ryabitsev wrote: > > Sorry, me again. > > > > I changed the email in my account from icon at linux.duke.edu to > > icon at fedoraproject.org. All bits work now, except I can't seem to be > > able to build any more: > > > > make build > > ... > > Server returned an error: Insufficient privileges. > > > > I've looked through the settings in the account system and they all seem > > sane, so I'm not sure where else I need to tweak to get back the privs. > > Download a new ssl cert from the accounts interface. > > see if that works. If not, then perhaps the new account sync job didn't complete? I think this message indicates that the SSL connection is OK, but that the user attempting to build stuff doesn't have the right bits set in the user permissions DB. If the sync didn't happen I can add you manually... Dan From skvidal at linux.duke.edu Mon May 1 21:38:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 01 May 2006 17:38:42 -0400 Subject: plague question In-Reply-To: <1146518258.13675.0.camel@localhost.localdomain> References: <44567897.9060800@fedoraproject.org> <1146518170.7995.14.camel@cutter> <1146518258.13675.0.camel@localhost.localdomain> Message-ID: <1146519522.7995.21.camel@cutter> On Mon, 2006-05-01 at 17:17 -0400, Dan Williams wrote: > On Mon, 2006-05-01 at 17:16 -0400, seth vidal wrote: > > On Mon, 2006-05-01 at 17:07 -0400, Konstantin Ryabitsev wrote: > > > Sorry, me again. > > > > > > I changed the email in my account from icon at linux.duke.edu to > > > icon at fedoraproject.org. All bits work now, except I can't seem to be > > > able to build any more: > > > > > > make build > > > ... > > > Server returned an error: Insufficient privileges. > > > > > > I've looked through the settings in the account system and they all seem > > > sane, so I'm not sure where else I need to tweak to get back the privs. > > > > Download a new ssl cert from the accounts interface. > > > > see if that works. > > If not, then perhaps the new account sync job didn't complete? I think > this message indicates that the SSL connection is OK, but that the user > attempting to build stuff doesn't have the right bits set in the user > permissions DB. > > If the sync didn't happen I can add you manually... I just ran the sync-committers script by hand - it looks like that was it. -sv From tcallawa at redhat.com Mon May 1 23:12:45 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 01 May 2006 18:12:45 -0500 Subject: optional game music files In-Reply-To: <1146488605.6818.17.camel@atlantis.mpeters.local> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> <4455F834.7090401@hhs.nl> <1146488605.6818.17.camel@atlantis.mpeters.local> Message-ID: <1146525166.21335.111.camel@localhost.localdomain> On Mon, 2006-05-01 at 06:03 -0700, Michael A. Peters wrote: > Yes - replacing large amounts of content that does not change for a > small patch that has no effect on content whatsoever is an incredible > waste of bandwidth, which some people have to pay for on a usage basis. > > There needs to be an exception defined to the rule for such cases, as > splitting the static content from the code is a practice that should be > encouraged, not discouraged. If the content is required for game functionality, but split into a separate tarball (e.g. game music, levels), then I see no reason that a package containing that content would not be permissible under FE Guidelines (assuming that the content is freely distributable without restriction). The "no OGG/MP3" rule was primarily to prevent people from doing something stupid, not to prevent games with static content in separate tarballs to be punished. ~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 andreas at bawue.net Mon May 1 23:17:59 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 2 May 2006 01:17:59 +0200 (CEST) Subject: optional game music files In-Reply-To: <445528B8.6020807@kobold.org> References: <445528B8.6020807@kobold.org> Message-ID: Chiming in here, after being pointed to the thread on #fedora-extras. On Sun, 30 Apr 2006, Wart wrote: > The packaging guidelines state: > > # Game levels are not considered content, since games without levels > would be non functional. > # Sound or graphics included with the source tarball that the program or > theme uses (or the documentation uses) are acceptable. Splitting the music and data files from the code is sensible, as the former are less volatile, then the latter. Thus I'd consider a second tarball containing music not to be against the spirit of these rules. > Since these ogg files are part of the game, but not part of the upstream > sources, are they still considered acceptable? My reading would be: Yes. If the sound files can be considered "part of the game", which would include IMNSHO being linked as a seperate file on the URL of the game, they should be packaged. bye, andreas From tcallawa at redhat.com Mon May 1 23:22:42 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 01 May 2006 18:22:42 -0500 Subject: optional game music files In-Reply-To: References: <445528B8.6020807@kobold.org> Message-ID: <1146525762.21335.114.camel@localhost.localdomain> On Tue, 2006-05-02 at 01:17 +0200, Andreas Thienemann wrote: > Chiming in here, after being pointed to the thread on #fedora-extras. > > On Sun, 30 Apr 2006, Wart wrote: > > > The packaging guidelines state: > > > > # Game levels are not considered content, since games without levels > > would be non functional. > > # Sound or graphics included with the source tarball that the program or > > theme uses (or the documentation uses) are acceptable. I'll propose a Guidelines change on Thursday that adds the following line: * Game music or audio content is permissible, as long as the content is freely distributable without restriction. ~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 andreas at bawue.net Mon May 1 23:25:42 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 2 May 2006 01:25:42 +0200 (CEST) Subject: optional game music files In-Reply-To: <1146482012.5802.37.camel@localhost.localdomain> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> Message-ID: On Mon, 1 May 2006, Ville Skytt? wrote: > IMO 12 hours is much too little time for doing something which appears > to be directly against the packaging guidelines, especially considering > that today is a holiday in lots of countries and probably considerably > less people than usual are reading their FE mail. Patience, please. +1 > I'm not saying that this case is not acceptable for inclusion, but it > sounds somewhat like being against the intended purpose or the "spirit" > of that rule. Nah. I don't think so. I'm reading the rules, specifically the spirit of the rules, as "don't package if you have to get the sounds from a third party fansite but package, if they belong to the game". Belonging to the game is clearly if the music is available from the same place as the source is. Example: I'm packaging vegastrike, an action space flight simulator, for fedora. Upstream doesn't offer tarballs, but advises to get the tagged files from cvs. To get the full gaming experience, one has to checkout "vegastrike", "data4.x" and "music". Acting by the letter of the ruling, the music must not be packaged, as it's not included with the sources. But considering that the music files are GPL licensed .ogg files (and even have a different license stating that the files are Creative Common licensed for distribution without the game), residing in the same cvs server as the source and the data files, I'd argue that including the music as an own rpm should be permissible by the current Guidelines. > I guess it depends on exactly how optional those files are, how easy it > is to properly install/remove them without them being rpm-packaged, and > whether anyone would have any complaints about their inclusion if they'd > be part of the upstream tarball which also contains the actual game. Usually the music is always optional. The games I've seen sofar even allow you to put in your own music. You can't make it any more optional. ;) But still, the should be offered as part of the "full" game. NB: I'd defintly argue against packaging MP3 music, which some games offer. But ogg should be okay, as the necessary support is included in core. bye, andreas From j.w.r.degoede at hhs.nl Tue May 2 05:02:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 02 May 2006 07:02:38 +0200 Subject: optional game music files In-Reply-To: References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> Message-ID: <4456E7EE.1090401@hhs.nl> Andreas Thienemann wrote: > On Mon, 1 May 2006, Ville Skytt? wrote: > > > NB: I'd defintly argue against packaging MP3 music, which some games > offer. > But ogg should be okay, as the necessary support is included in core. > In the case which sparked this discussion, raidem. I actually asked upstream to build in ogg support and to offer the music in ogg format. Which they did both after that I packaged the ogg library they used and updated raidem to the new version using the ogg lib, only to end up in this discussion :| Although it does seem to be heading in the right direction. Regards, Hans From j.w.r.degoede at hhs.nl Tue May 2 05:04:26 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 02 May 2006 07:04:26 +0200 Subject: comps where to put electronics simulation software (gnucap)? In-Reply-To: <1146517400.11225.70.camel@orodruin.boston.redhat.com> References: <445671F4.8040609@hhs.nl> <1146517400.11225.70.camel@orodruin.boston.redhat.com> Message-ID: <4456E85A.6010902@hhs.nl> Jeremy Katz wrote: > On Mon, 2006-05-01 at 22:39 +0200, Hans de Goede wrote: >> Subject says it all. > > I'd suggest the Engineering and Scientific software group > Currently the description of that group is more "Math" software then Engineering, also since geda is being packaged too and that is made up of lots of smaller parts (scheme, pbc, sim, projectmanager, etc) I forsee this group getting clouded any chance for a seperate group (be it now or once things get crowded)? Regards, Hans From andreas at bawue.net Tue May 2 11:42:57 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 2 May 2006 13:42:57 +0200 (CEST) Subject: optional game music files In-Reply-To: <4456E7EE.1090401@hhs.nl> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> <4456E7EE.1090401@hhs.nl> Message-ID: On Tue, 2 May 2006, Hans de Goede wrote: > In the case which sparked this discussion, raidem. I actually asked > upstream to build in ogg support and to offer the music in ogg format. Neato. > Which they did both after that I packaged the ogg library they used and > updated raidem to the new version using the ogg lib, only to end up in > this discussion :| Although it does seem to be heading in the right > direction. I wouldn't worry. Spot is asking FESCO for a clarification of the guidelines, just to make sure that seperate music is considered upstream and fine to package. What is more interesting is, that I've seen some game music being licensed under the Creative Commons NonCommercial ShareAlike license, which would make it impossible to be packaged for fedora, as the NonCommercial would make it non-free. regards, Andreas From paul at all-the-johnsons.co.uk Tue May 2 12:01:35 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 02 May 2006 13:01:35 +0100 Subject: Building in mock vs building outside of mock Message-ID: <1146571295.7662.22.camel@mrwibble.mrwobble> Hi, This has puzzled me for most of yesterday (I had the weekend off doing anything!) I have a couple of C# packages in BZ. Outside of mock, they build without a problem at all - when I inspect the packages, the contents are correct and everything is in the correct place. When I build it under mock, the build fails with an error that a particular directory is missing (it varies as to which depending on the package being built). Why does this happen? What is so different to mock as to building outside of mock? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From Axel.Thimm at ATrpms.net Tue May 2 12:30:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 2 May 2006 14:30:10 +0200 Subject: Building in mock vs building outside of mock In-Reply-To: <1146571295.7662.22.camel@mrwibble.mrwobble> References: <1146571295.7662.22.camel@mrwibble.mrwobble> Message-ID: <20060502123010.GB5950@neu.nirvana> On Tue, May 02, 2006 at 01:01:35PM +0100, PFJ wrote: > This has puzzled me for most of yesterday (I had the weekend off doing > anything!) > > I have a couple of C# packages in BZ. Outside of mock, they build > without a problem at all - when I inspect the packages, the contents are > correct and everything is in the correct place. > > When I build it under mock, the build fails with an error that a > particular directory is missing (it varies as to which depending on the > package being built). > > Why does this happen? What is so different to mock as to building > outside of mock? You are probably missing some BuildRequires and the package decides not to build certain parts when detecting that some (optional) dependencies are missing. Try comparing the build logs between the two builds, maybe that will reveal the missing depedency. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue May 2 13:07:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 02 May 2006 08:07:58 -0500 Subject: Building in mock vs building outside of mock In-Reply-To: <1146571295.7662.22.camel@mrwibble.mrwobble> References: <1146571295.7662.22.camel@mrwibble.mrwobble> Message-ID: PFJ wrote: > What is so different to mock as to building > outside of mock? Mock is a clean(er) build environment. -- Rex From rc040203 at freenet.de Tue May 2 17:18:11 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 02 May 2006 19:18:11 +0200 Subject: Security Response Team / EOL In-Reply-To: <1146300497.882.20.camel@rousalka.dyndns.org> References: <1146203217.20233.15.camel@thl.ct.heise.de> <20060428075334.GB5957@neu.nirvana> <1146255281.13972.2.camel@ender> <1146280624.31774.309.camel@mccallum.corsepiu.local> <1146300497.882.20.camel@rousalka.dyndns.org> Message-ID: <1146590291.5262.3.camel@mccallum.corsepiu.local> On Sat, 2006-04-29 at 10:48 +0200, Nicolas Mailhot wrote: > Le samedi 29 avril 2006 ? 05:17 +0200, Ralf Corsepius a ?crit : > > > Sorry, but I beg to differ: > > > > IMO, > > * wanting to discontinue FC(N-1) at FC(N+1)test2 is a fault, because it > > doesn't provide a sufficient overlap to FC(N+1), for users wanting to > > upgrade from FC(N-1) to FC(N+1) [e.g. FC3->FC5]. > > Which is intentional on the FC side and I don't see why FE should be any > better. You know perfectly well the FC EOL is not designed to allow > FC(N-1) to FC(N+1). Their management's politics - Not mine, and probably not in many user's interest - I consider the current policy as not helpful, neither to RH nor to Fedora. Ralf From mdehaan at redhat.com Tue May 2 18:30:33 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 02 May 2006 14:30:33 -0400 Subject: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff Message-ID: <4457A549.5050603@redhat.com> Bugzilla 189281 references the YAML parser for Python in FC-extras as being broken. The bug report went to oliver at linux-kernel.at on 4/18 and I've emailed him on 4/28 inquiring about the 4/18 bug report and volunteering to help. No replies yet on either account, I'm assuming long vacations and such are possible, such things are understandable and ok. Anyhow, I'd like to get the YAML situation fixed in the meantime -- seeing what was originally uploaded as syck-python never worked anyway, and couldn't have passed any unit tests that might have existed for it -- and as I'll make for a case below -- probably shouldn't be the preferred way to parse YAML in Python :) Essentially fixing the bugzilla problem would require that upstream syck be fixed (to enable the dump function) and the downstream changes incorporated into FC-extras, *OR* that instead an alternate version of YAML support be added and the existing module be removed. I am advocating the latter approach. The Python community has apparently seen that the syck bindings that ship with syck (current=0.55) are broken, so they've come up with a version of syck-python that is 0.61 (http://pyyaml.org) on their own . They are also working on a Python Yaml 3000 replacement library, that is apparently also a good candidate. My suggestion is that syck-python be orphaned due to the fact that (1) it's broken since it can't serialize anything at all (no dump function), and (2) syck isn't incredibly robust. Given this, I'm planning on packaging a "python-yaml" for extras using the Python-YAML 3000 or Python-Syck codebase here, which has syck at 0.61. We can then pull python-syck out of the repository. Yes, I'm signing up to do this, assuming we can orphan the broken package to reduce confusion. Any objections to orphaning the dead-end package in favor of a working replacement, please speak up :) --Michael DeHaan References: http://pyyaml.org/ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189281 http://whytheluckystiff.net/syck/ From buildsys at fedoraproject.org Tue May 2 18:55:22 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 2 May 2006 14:55:22 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060502185522.A43EC152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 clamav-0.88.2-1.fc3 dnsmasq-2.30-4.2.fc3.1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 2 18:55:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 2 May 2006 14:55:47 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060502185547.D52EE152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 15 bsd-games-2.17-10.fc4 clamav-0.88.2-1.fc4 dclib-0.3.7-8.fc4 dnsmasq-2.30-4.2.fc4 emacs-auctex-11.82-8.fc4 exim-4.62-1.fc4 exim-doc-4.62-2.fc4 gtkwave-3.0.0-1.fc4 hevea-1.08-5.fc4 mod_geoip-1.1.8-1.fc4 nautilus-actions-1.2-1.fc4 p7zip-4.39-1.fc4 perl-Image-Info-1.21-2.fc4 valknut-0.3.7-8.fc4 yap-5.1.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 2 18:57:13 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 2 May 2006 14:57:13 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060502185713.33277152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 28 AllegroOGG-1.0.3-2.fc5 bsd-games-2.17-10.fc5 cairomm-0.6.0-1.fc5 clamav-0.88.2-1.fc5 dclib-0.3.7-8.fc5 dnsmasq-2.30-4.2.fc5 emacs-auctex-11.82-8.fc5 exim-4.62-2.fc5 exim-doc-4.62-2.fc5 gajim-0.10-1.fc5 gcompris-7.4-5.fc5 gnomesword-2.1.6-2.fc5 gnucap-0.34-2.fc5 gossip-0.11-2.fc5 gtkwave-3.0.0-1.fc5 hevea-1.08-5.fc5 libassetml-1.2.1-2.fc5 libipoddevice-0.4.5-1.fc5 mod_geoip-1.1.8-1.fc5 nautilus-actions-1.2-1.fc5 p7zip-4.39-1.fc5 perl-Image-Info-1.21-2.fc5 pl-5.6.12-2.fc5 pl-5.6.12-3.fc5 proftpd-1.3.0-2.fc5 raidem-0.3.1-2.fc5 valknut-0.3.7-9.fc5 yap-5.1.1-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 2 19:00:01 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 2 May 2006 15:00:01 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060502190001.5EB7B152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 36 bitbake-1.4.0-1.fc6 bsd-games-2.17-10.fc6 cairomm-0.6.0-1.fc6 dclib-0.3.7-7.fc6 dnsmasq-2.30-4.2.fc6 dnsmasq-2.30-4.fc6 emacs-auctex-11.82-8.fc6 exim-4.62-1.fc6 exim-4.62-2.fc6 exim-doc-4.62-2.fc6 gajim-0.10-1.fc6 gcompris-7.4-5.fc6 gjots2-2.3.4-5.fc6 gnomesword-2.1.6-2.fc6 gossip-0.11-3.fc6 gramps-2.0.11-3.fc6 gtkwave-3.0.0-1.fc6 libipoddevice-0.4.5-1.fc6 mail-notification-2.0-12.fc6 mod_geoip-1.1.8-1.fc6 mtd-utils-1.0.0-2 nagios-2.2-3.fc6 nautilus-actions-1.2-1.fc6 p7zip-4.39-1.fc6 pan-0.95-3.fc6 perl-Email-MIME-1.82-2.fc6 perl-Email-MIME-Modifier-1.42-2.fc6 perl-File-Find-Rule-PPI-0.03-1.fc6 perl-HTTP-Recorder-0.05-1.fc6 perl-HTTP-Request-Params-1.01-1.fc6 perl-Image-Info-1.21-2.fc6 perl-PPI-1.112-1.fc6 pl-5.6.12-2.fc6 pl-5.6.12-3.fc6 valknut-0.3.7-8.fc6 yap-5.1.1-1.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From michael at knox.net.nz Tue May 2 19:24:14 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 03 May 2006 07:24:14 +1200 Subject: changes to the orphaned wiki page. Message-ID: <4457B1DE.2090007@knox.net.nz> Hi all, I have made some small changes to the orphaned packages wiki page. It now can document retired packages. With the lack of an official policy on how a package is to be retired, it's really up to the packager to make that choice. This is just a means to record this status. Some basic criteria: No upstream No activity upstream Release critical bugs (where there is no upstream to fix) Packager does not want to be responsible for the above. There is no policy about taking a package out of retired status, just have to be aware that you will take on responsibility for release critical bugs. Michael From mkevac at gmail.com Tue May 2 19:35:53 2006 From: mkevac at gmail.com (Kevac Marko) Date: Tue, 2 May 2006 23:35:53 +0400 Subject: evince, pdf and two side printing Message-ID: Why choosing even or odd page to print is unavailable when printing pdf file in evince? It is huge spend of paper to print 700 pages file only on one side. -- Kevac Marko From hugo at devin.com.br Tue May 2 19:56:06 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 02 May 2006 16:56:06 -0300 Subject: yakuake orphaned in FC5? Message-ID: <4457B956.2030205@devin.com.br> Hi guys, As pointed in IRC, I'm sending this mail to let you know that I packaged a "orphaned" package: yakukake. "orphaned"? Like a previous message here in this list from Dawid Gajownik (http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html) the maintainer is missing, so some guys updated the spec and package files (with new versions too). Can this package be orphaned? And the new maintainer get it? Some references: Inicial BUG: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186283 Review Package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471 Thanks! -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From toshio at tiki-lounge.com Tue May 2 19:56:04 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 02 May 2006 12:56:04 -0700 Subject: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff In-Reply-To: <4457A549.5050603@redhat.com> References: <4457A549.5050603@redhat.com> Message-ID: <1146599764.3163.41.camel@localhost> On Tue, 2006-05-02 at 14:30 -0400, Michael DeHaan wrote: > Bugzilla 189281 references the YAML parser for Python in FC-extras as > being broken. The bug report went to oliver at linux-kernel.at on 4/18 and > I've emailed him on 4/28 inquiring about the 4/18 bug report and > volunteering to help. No replies yet on either account, I'm assuming > long vacations and such are possible, such things are understandable and > ok. That bug doesn't show that it's broken, just poorly designed :-) (I'm not arguing that syck's python bindings aren't broken in other ways and deserve to get replaced....) [snip] > The Python community has apparently seen that the syck bindings that > ship with syck (current=0.55) are broken, so they've come up with a > version of syck-python that is 0.61 (http://pyyaml.org) on their own . > They are also working on a Python Yaml 3000 replacement library, that is > apparently also a good candidate. > > My suggestion is that syck-python be orphaned due to the fact that (1) > it's broken since it can't serialize anything at all (no dump function), > and (2) syck isn't incredibly robust. Given this, I'm planning on > packaging a "python-yaml" for extras using the Python-YAML 3000 or > Python-Syck codebase here, which has syck at 0.61. We can then pull > python-syck out of the repository. Yes, I'm signing up to do this, > assuming we can orphan the broken package to reduce confusion. I liked the idea of yaml but have refrained from using it due to the problems with the python-syck bindings. I think it would be valuable to have working bindings whether or not syck-python is orphaned. Here are some questions: pysyck: the pyyaml.org website provides a patched syck that is an svn snapshot plus pyyaml patches. Is an unpatched syck going to have significant deficiencies? Is upstream syck going to make new releases or is all development of the library concentrated in the ruby tree? Has the pysyck community proposed their changes to upstream syck? pyyaml3000: No released tarballs. Does upstream have a timeline for that or are we going to be making snapshots for quite a while? To me, making a pyyaml3000 package (with some idea of what we can expect from upstream) could go the route of any other Extras package. (After all, we have both libxml2 with python bindings and elementTree already.) pysyck could be treated the same way but seems like it would benefit from coordination with the syck maintainer (to Obsolete syck-python and stop building that as a subpackage, is upstream syck going to make python fixes, should we add pysyck patches to our syck library, etc) See if Oliver responds to inquiries about you packaging pysyck (or if he doesn't have time for syck anymore and is willing to hand it off to you.) -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 jonathan.underwood at gmail.com Tue May 2 20:27:01 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 2 May 2006 21:27:01 +0100 Subject: evince, pdf and two side printing In-Reply-To: References: Message-ID: <645d17210605021327i7e635a8bn803fd29b9c21f9b5@mail.gmail.com> On 02/05/06, Kevac Marko wrote: > Why choosing even or odd page to print is unavailable when printing > pdf file in evince? > > It is huge spend of paper to print 700 pages file only on one side. > Kevac - I think you have the wrong list, you should ask these sorts of questions on fedora-list. From mdehaan at redhat.com Tue May 2 20:49:25 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 02 May 2006 16:49:25 -0400 Subject: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff In-Reply-To: <1146599764.3163.41.camel@localhost> References: <4457A549.5050603@redhat.com> <1146599764.3163.41.camel@localhost> Message-ID: <4457C5D5.6020508@redhat.com> Toshio Kuratomi wrote: > On Tue, 2006-05-02 at 14:30 -0400, Michael DeHaan wrote: > >> Bugzilla 189281 references the YAML parser for Python in FC-extras as >> being broken. The bug report went to oliver at linux-kernel.at on 4/18 and >> I've emailed him on 4/28 inquiring about the 4/18 bug report and >> volunteering to help. No replies yet on either account, I'm assuming >> long vacations and such are possible, such things are understandable and >> ok. >> > > That bug doesn't show that it's broken, just poorly designed :-) (I'm > not arguing that syck's python bindings aren't broken in other ways and > deserve to get replaced....) > > [snip] > Not having a YAML package for Fedora that can serialize anything is pretty broken, IMHO :) > >> The Python community has apparently seen that the syck bindings that >> ship with syck (current=0.55) are broken, so they've come up with a >> version of syck-python that is 0.61 (http://pyyaml.org) on their own . >> They are also working on a Python Yaml 3000 replacement library, that is >> apparently also a good candidate. >> >> My suggestion is that syck-python be orphaned due to the fact that (1) >> it's broken since it can't serialize anything at all (no dump function), >> and (2) syck isn't incredibly robust. Given this, I'm planning on >> packaging a "python-yaml" for extras using the Python-YAML 3000 or >> Python-Syck codebase here, which has syck at 0.61. We can then pull >> python-syck out of the repository. Yes, I'm signing up to do this, >> assuming we can orphan the broken package to reduce confusion. >> > > I liked the idea of yaml but have refrained from using it due to the > problems with the python-syck bindings. I think it would be valuable to > have working bindings whether or not syck-python is orphaned. Agreed. > Here are > some questions: > > pysyck: the pyyaml.org website provides a patched syck that is an svn > snapshot plus pyyaml patches. Is an unpatched syck going to have > significant deficiencies? Yes. An unpatched syck doesn't have a working dump function, which makes it at least 50% broken, so I'd call those dependencies rather major. I have not researched their other fixes to syck. The one issue with packaging their pyyaml patched version now is the 1.1 compliance. We have to move to 1.1 at some point, and it looks to me that the 3000 version is good enough now. (See below on syck issues). > Is upstream syck going to make new releases > or is all development of the library concentrated in the ruby tree? Has > the pysyck community proposed their changes to upstream syck? > I've contacted whytheluckystiff (upstream) about his thoughts and relationship with pysyck. He is for all intents and purposes in the Ruby camp, and I'm not sure how much time (if any) is spent on the Python ones. The python brokeness has no doubt been reported at least once, which makes me believe upstream syck isn't the answer. Further, per a coworker of mine (I haven't followed up on this myself), syck's source doesn't do a good job of checking memory allocation calls, does some reallocs, and so forth ... so I am well inclined to use a non-native parser for stability/safety reasons. PyYaml 3000 would fit this niche nicely. > pyyaml3000: No released tarballs. Does upstream have a timeline for > that or are we going to be making snapshots for quite a while? > As for pyyaml3000, I have a RPM on my desktop now (already built) and am about to submit it to FC-extras for review. It seems very stable and I can contact them about plans on releasing snapshots. For now, I've built a tarball myself. > To me, making a pyyaml3000 package (with some idea of what we can expect > from upstream) could go the route of any other Extras package. (After > all, we have both libxml2 with python bindings and elementTree already.) > > pysyck could be treated the same way but seems like it would benefit > from coordination with the syck maintainer (to Obsolete syck-python and > stop building that as a subpackage, is upstream syck going to make > python fixes, should we add pysyck patches to our syck library, etc) > See if Oliver responds to inquiries about you packaging pysyck (or if he > doesn't have time for syck anymore and is willing to hand it off to > you.) > I've contacted whytheluckystiff to see his opinions on upstream pysyck's brokenness as well, just for good measure. I agree with you that having duplicate implementations won't hurt (if both work), but I do think that having just one broken implementation in there (syck-python) is not enough. So whether we orphan the broken syck-python or not, I'm backing the yaml 3000 as the right way to go. Package is currently named 'python-yaml', since we don't have one, and I don't want version numbers in the formal package name. Version is "0.3000.20060502". --Michael From orion at cora.nwra.com Tue May 2 21:32:09 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 02 May 2006 15:32:09 -0600 Subject: Taking ownership of perl-XML-DOM and requirements In-Reply-To: <4450F8B0.5000109@cora.nwra.com> References: <4450F8B0.5000109@cora.nwra.com> Message-ID: <4457CFD9.4030107@cora.nwra.com> Orion Poplawski wrote: > I'll take ownership of: > > perl-XML-DOM > perl-XML-RegExp > > If no one objects I'll change the owners.list file and update the wiki > page next week. > > Done -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugs.michael at gmx.net Tue May 2 23:27:41 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 02 May 2006 23:27:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-03 Message-ID: <20060502232741.7581.72010@rawhide.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From bugs.michael at gmx.net Tue May 2 23:27:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 02 May 2006 23:27:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-03 Message-ID: <20060502232745.7584.45441@rawhide.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Tue May 2 23:27:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 02 May 2006 23:27:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-03 Message-ID: <20060502232753.7586.76956@rawhide.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 sobby 0.3.0-2.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc sobby 0.3.0-2.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 sobby 0.3.0-2.fc5.x86_64 ====================================================================== New report for: tcallawa AT redhat.com package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 ====================================================================== New report for: matthias AT rpmforge.net package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 ====================================================================== package: sobby - 0.3.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: sobby - 0.3.0-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnet6-1.2.so.0()(64bit) libobby-0.3.so.0()(64bit) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: sobby - 0.3.0-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 From michael at knox.net.nz Tue May 2 23:32:38 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 03 May 2006 11:32:38 +1200 Subject: unorphan: lua Message-ID: <4457EC16.5070801@knox.net.nz> I am offering to take over lua if there is no objection. Michael From jwboyer at jdub.homelinux.org Wed May 3 01:52:25 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 02 May 2006 20:52:25 -0500 Subject: FESCo Elections 2006 In-Reply-To: <1146496913.2830.33.camel@localhost.localdomain> References: <1146496913.2830.33.camel@localhost.localdomain> Message-ID: <1146621145.14245.5.camel@vader.jdub.homelinux.org> On Mon, 2006-05-01 at 17:21 +0200, Thorsten Leemhuis wrote: > I put the rough plan into the wiki at: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Election > > Everyone that wants to be in the next FESCo needs to nominate > him/herself for it until May, 8 2006 0:00 UTC; that self-nomination > should contain some information's like "Mission Statement, Past work > summary and Future plans". Could you briefly explain what the difference between Mission Statement and Future plans is? I seem to recall there being a difference, but my feeble mind has since forgotten. > I create a page in the wiki to collect the nominations: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations > > Please put them there and send them to fedora-extras-list also. You can > also nominate other people, but they have to write a self-nomination on > their own. We need some {self-}nominations people! > > The actual election who will be part of the next FESCo is planed for the > second week of May -- all members of the cvsextras group can vote. How > this vote is actually done needs to be worked out before that timeframe. > Help appreciated. As solution with public gpg-signed mails looks as the > one that has the best chances currently. Who (if anyone) is working on this at the moment? And by the way, I griped about not having a fedora gpg-keyring available a while ago... it would seem that this or something much like it might be needed now. josh From mpeters at mac.com Wed May 3 02:34:13 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 02 May 2006 19:34:13 -0700 Subject: FESCo Elections 2006 In-Reply-To: <1146621145.14245.5.camel@vader.jdub.homelinux.org> References: <1146496913.2830.33.camel@localhost.localdomain> <1146621145.14245.5.camel@vader.jdub.homelinux.org> Message-ID: <1146623654.938.4.camel@atlantis.mpeters.local> On Tue, 2006-05-02 at 20:52 -0500, Josh Boyer wrote: > > And by the way, I griped about not having a fedora gpg-keyring available > a while ago... it would seem that this or something much like it might > be needed now. Since Fedora Extras doesn't have a test repo, there's an additional reason. If I want to put a new version up for testing and post it to the user list, a keyring means user can verify the GPG key I sign packages with matches GPG key in Extras keyring. I suppose they could verify it at MIT now, but ... What's involved in creating the keyring? (other than time) From jwboyer at jdub.homelinux.org Wed May 3 02:39:58 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 02 May 2006 21:39:58 -0500 Subject: FESCo Elections 2006 In-Reply-To: <1146623654.938.4.camel@atlantis.mpeters.local> References: <1146496913.2830.33.camel@localhost.localdomain> <1146621145.14245.5.camel@vader.jdub.homelinux.org> <1146623654.938.4.camel@atlantis.mpeters.local> Message-ID: <1146623998.14245.10.camel@vader.jdub.homelinux.org> On Tue, 2006-05-02 at 19:34 -0700, Michael A. Peters wrote: > On Tue, 2006-05-02 at 20:52 -0500, Josh Boyer wrote: > > > > > And by the way, I griped about not having a fedora gpg-keyring available > > a while ago... it would seem that this or something much like it might > > be needed now. > > Since Fedora Extras doesn't have a test repo, there's an additional > reason. If I want to put a new version up for testing and post it to the > user list, a keyring means user can verify the GPG key I sign packages > with matches GPG key in Extras keyring. > > I suppose they could verify it at MIT now, but ... > > What's involved in creating the keyring? (other than time) Couple things that I can think of. 1) Initial creation. Walking through a list of the accounts and adding the keys to a keyring and then exporting that somewhere. Lots of people can do the initial creation. 2) Automation. The accounts system needs a hook to add new keys to the keyring as people are granted cvsextras access. I brought it up before, I think it's important now, so I'll probably poke at it soon. josh From bugzilla at redhat.com Wed May 3 03:06:48 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 2 May 2006 23:06:48 -0400 Subject: [Bug 172803] Review Request: openssl097f - compat package to help transitioning to new openssl In-Reply-To: Message-ID: <200605030306.k4336mig000827@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openssl097f - compat package to help transitioning to new openssl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803 paul at xtdnet.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul at xtdnet.nl ------- Additional Comments From paul at xtdnet.nl 2006-05-02 23:06 EST ------- I found it and used it in our move from 0.9.7f to 0.9.8a to test various crypto code. I don't mind much where it is in, but please put it in either FC or FE. This is now making a transition to 0.9.8 unneccesarilly difficult. Thanks for this rpm though. Google found it :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed May 3 03:10:58 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 2 May 2006 23:10:58 -0400 Subject: [Bug 172803] Review Request: openssl097f - compat package to help transitioning to new openssl In-Reply-To: Message-ID: <200605030310.k433Aw2b001854@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openssl097f - compat package to help transitioning to new openssl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803 jkeating at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From michael at knox.net.nz Wed May 3 04:04:43 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 03 May 2006 16:04:43 +1200 Subject: FESCo Elections 2006 In-Reply-To: <1146621145.14245.5.camel@vader.jdub.homelinux.org> References: <1146496913.2830.33.camel@localhost.localdomain> <1146621145.14245.5.camel@vader.jdub.homelinux.org> Message-ID: <44582BDB.1@knox.net.nz> Josh Boyer wrote: >> I create a page in the wiki to collect the nominations: >> http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations >> >> Please put them there and send them to fedora-extras-list also. You can >> also nominate other people, but they have to write a self-nomination on >> their own. > > We need some {self-}nominations people! > I just nominated myself... point and giggle can now start :) Michael From fedora at leemhuis.info Wed May 3 05:09:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 May 2006 07:09:09 +0200 Subject: FESCo Elections 2006 In-Reply-To: <1146621145.14245.5.camel@vader.jdub.homelinux.org> References: <1146496913.2830.33.camel@localhost.localdomain> <1146621145.14245.5.camel@vader.jdub.homelinux.org> Message-ID: <1146632949.23779.11.camel@thl.ct.heise.de> Am Dienstag, den 02.05.2006, 20:52 -0500 schrieb Josh Boyer: > On Mon, 2006-05-01 at 17:21 +0200, Thorsten Leemhuis wrote: > > > I put the rough plan into the wiki at: > > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Election > > > > Everyone that wants to be in the next FESCo needs to nominate > > him/herself for it until May, 8 2006 0:00 UTC; that self-nomination > > should contain some information's like "Mission Statement, Past work > > summary and Future plans". > Could you briefly explain what the difference between Mission Statement > and Future plans is? I seem to recall there being a difference, but my > feeble mind has since forgotten. Well, those were the terms thrown into the ring during the last FESCo meeting. I can't really tell the difference myself. Maybe "Mission Statement" ist more a "Why am I the right one for the job" and "Future plans" is more a list of things you'll really plan to do during your time in FESCo. But I don't consider the difference important -- you don't have to use exactly this scheme. It's more a hint how it could look like. [...] > > The actual election who will be part of the next FESCo is planed for the > > second week of May -- all members of the cvsextras group can vote. How > > this vote is actually done needs to be worked out before that timeframe. > > Help appreciated. As solution with public gpg-signed mails looks as the > > one that has the best chances currently. > > Who (if anyone) is working on this at the moment? Nobody atm and afaics. CU thl From Christian.Iseli at licr.org Wed May 3 10:03:29 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 03 May 2006 12:03:29 +0200 Subject: FESCo Elections 2006 In-Reply-To: Your message of "Mon, 01 May 2006 17:21:53 +0200." <1146496913.2830.33.camel@localhost.localdomain> Message-ID: <200605031003.k43A3TYw003309@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > As solution with public gpg-signed mails looks as the one that > has the best chances currently. AFAIU, people prefer secret ballots. I don't see an easy way to use signed emails to produce secret ballots... Christian From jwboyer at jdub.homelinux.org Wed May 3 10:53:09 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 03 May 2006 05:53:09 -0500 Subject: FESCo Elections 2006 In-Reply-To: <200605031003.k43A3TYw003309@ludwig-alpha.unil.ch> References: <200605031003.k43A3TYw003309@ludwig-alpha.unil.ch> Message-ID: <1146653589.14245.16.camel@vader.jdub.homelinux.org> On Wed, 2006-05-03 at 12:03 +0200, Christian.Iseli at licr.org wrote: > fedora at leemhuis.info said: > > As solution with public gpg-signed mails looks as the one that > > has the best chances currently. > > AFAIU, people prefer secret ballots. I don't see an easy way to use signed > emails to produce secret ballots... Sure there is. In a script, verify the signature, record the results somewhere, record that person X voted (but not what his/her votes were), delete the email. It's only non-secret if someone has to manually look at the ballots and do the tally. josh From Christian.Iseli at licr.org Wed May 3 12:11:35 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 03 May 2006 14:11:35 +0200 Subject: FESCo Elections 2006 In-Reply-To: Your message of "Wed, 03 May 2006 05:53:09 CDT." <1146653589.14245.16.camel@vader.jdub.homelinux.org> Message-ID: <200605031211.k43CBZgs004188@ludwig-alpha.unil.ch> jwboyer at jdub.homelinux.org said: > Sure there is. In a script, verify the signature, record the results > somewhere, record that person X voted (but not what his/her votes were), > delete the email. Sure, that's fine with me. But the underlying question is: will you trust me to run this on my machine ? (In the question, you can replace "you", "me", and "my" with many other person/ company names) Christian From jwboyer at jdub.homelinux.org Wed May 3 12:51:06 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 3 May 2006 07:51:06 -0500 Subject: FESCo Elections 2006 In-Reply-To: <200605031211.k43CBZgs004188@ludwig-alpha.unil.ch> References: <1146653589.14245.16.camel@vader.jdub.homelinux.org> <200605031211.k43CBZgs004188@ludwig-alpha.unil.ch> Message-ID: <20060503125106.GA5495@yoda.jdub.homelinux.org> On Wed, May 03, 2006 at 02:11:35PM +0200, Christian.Iseli at licr.org wrote: > > jwboyer at jdub.homelinux.org said: > > Sure there is. In a script, verify the signature, record the results > > somewhere, record that person X voted (but not what his/her votes were), > > delete the email. > > Sure, that's fine with me. But the underlying question is: > will you trust me to run this on my machine ? > > (In the question, you can replace "you", "me", and "my" with many other person/ > company names) A fair point. One that I think is personally up to the individual. My plan would be to have the script running on a fedoraproject.org machine. They already provide the packages you install from Extras, so there is some level of trust implied :). I think it's obvious that the gpg-signed emails are intended only to track: 1) That the voter has completed the CLA and is in the cvsextras group 2) That ballot stuffing isn't occuring If there is another way that the above can be accomplished in a completely anonymous fashion, great. I haven't seen anything that won't take a significant amount of time. As a side note, I personally could care less whether the ballots were secret. However, it seems to be an important issue to others and we need to make sure everyone is comfortable with how this should work. josh From Christian.Iseli at licr.org Wed May 3 13:12:10 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 03 May 2006 15:12:10 +0200 Subject: FESCo Elections 2006 In-Reply-To: Your message of "Wed, 03 May 2006 07:51:06 CDT." <20060503125106.GA5495@yoda.jdub.homelinux.org> Message-ID: <200605031312.k43DCAhu004769@ludwig-alpha.unil.ch> jwboyer at jdub.homelinux.org said: > A fair point. One that I think is personally up to the individual. My plan > would be to have the script running on a fedoraproject.org machine. They > already provide the packages you install from Extras, so there is some level > of trust implied :). That'd be my preference too. > I think it's obvious that the gpg-signed emails are intended only to track: > 1) That the voter has completed the CLA and is in the cvsextras group > 2) That ballot stuffing isn't occuring Exactly. > If there is another way that the above can be accomplished in a completely > anonymous fashion, great. I haven't seen anything that won't take a > significant amount of time. Well, this is what I came across after some googling: | There doesn't seem to be a whole lot of software allowing for secret ballots | on freshmeat. There was supposed to be http://jfreevote.hispalinux.es/ but | this now brings up a page in spanish that seems not directly related. | I could also find GNU.FREE at http://www.j-dom.org/h/n/BIO/HOME/ALL/26/ and | http://sourceforge.net/projects/free/ but it seems unmaintained. It would probably take some significant effort to get a trusted system going. If there was some simple solution available, I'm pretty sure someone would have mentioned it by now. > As a side note, I personally could care less whether the ballots were secret. > However, it seems to be an important issue to others and we need to make sure > everyone is comfortable with how this should work. Same here :) Cheers, Christian From mdehaan at redhat.com Wed May 3 13:23:33 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 03 May 2006 09:23:33 -0400 Subject: Contributer License Agreement / Account System Problems Message-ID: <4458AED5.6020803@redhat.com> I recently applied for a Fedora account. I have recieved no emails from the account system, and clicking the "Send me the CLA" link on the Wiki *says* the CLA is being sent to my registered email address, but it does not get there. I have checked and my address (the one I'm using now) is in the system correctly. If I look at the account page, it shows the group "cla_done" with the role status "in progress". Which seems to imply it did send the CLA, while in fact I never recieved it. Who can I contact about getting this straightened out? I've heard of this happening to other folks as well. The Wiki pages did not list any contact info for what to do if the account system hiccupped, so I'm asking here. --Michael DeHaan From sundaram at fedoraproject.org Wed May 3 13:31:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 May 2006 19:01:08 +0530 Subject: Contributer License Agreement / Account System Problems In-Reply-To: <4458AED5.6020803@redhat.com> References: <4458AED5.6020803@redhat.com> Message-ID: <1146663068.3802.252.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-03 at 09:23 -0400, Michael DeHaan wrote: > I recently applied for a Fedora account. I have recieved no emails > from the account system, and clicking the "Send me the CLA" link on the > Wiki *says* the CLA is being sent to my registered email address, but it > does not get there. I have checked and my address (the one I'm using > now) is in the system correctly. > > If I look at the account page, it shows the group "cla_done" with the > role status "in progress". Which seems to imply it did send the CLA, > while in fact I never recieved it. > > Who can I contact about getting this straightened out? I've heard of > this happening to other folks as well. The Wiki pages did not list > any contact info for what to do if the account system hiccupped, so I'm > asking here. You can ask in #fedora-websites or mail accounts AT fedoraproject.org Rahul From qspencer at ieee.org Wed May 3 16:10:29 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 03 May 2006 11:10:29 -0500 Subject: What's going on with devel builds? Message-ID: <4458D5F5.4000704@ieee.org> I'm getting a build failure on devel, with the following error messages: Failed to add groups file for repository: core Error: Missing Dependency: libgomp.so.1 is needed by package gcc Error: Missing Dependency: libstdc++.so.6 is needed by package gcc-c++ unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category Cleaning up... Done. Is this some kind of rawhide breakage? -Quentin From tibbs at math.uh.edu Wed May 3 18:56:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 03 May 2006 13:56:45 -0500 Subject: What's going on with devel builds? In-Reply-To: <4458D5F5.4000704@ieee.org> (Quentin Spencer's message of "Wed, 03 May 2006 11:10:29 -0500") References: <4458D5F5.4000704@ieee.org> Message-ID: >>>>> "QS" == Quentin Spencer writes: QS> I'm getting a build failure on devel, with the following error QS> messages: Rawhide has some dependency issues; from IRC today: --- the x86_64 mock configs explicitly exclude i386 packages and gcc has (somewhat incorrectly) grown a dep on the 32bit libgomp. jakub was trying tomsething to fix --- - J< From ville.skytta at iki.fi Wed May 3 20:35:09 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 03 May 2006 23:35:09 +0300 Subject: Release bumps in old branches Message-ID: <1146688510.5802.177.camel@localhost.localdomain> Hi, I've noticed that an increasing number of packagers are making the mistake of bumping the release tag in older distro branches (only) so that they become newer than the corresponding packages in newer branches as far as rpm is concerned, which is not good wrt. distro upgrades. I've sent some personal nagmails but it seems this issue requires wider attention. Scenario: foo = 1.0-1%{?dist} in FC-4 and FC-5, and only FC-4 needs a fix. One solution is to add a digit to the very right of the release tag in FC-4, instead of bumping it the usual way. IOW, 1%{?dist}.1, not 2%{?dist}. Otherwise the situation becomes 1.0-2.fc4 > 1.0-1.fc5, whereas 1.0-1.fc4.1 < 1.0-1.fc5 would be ok. Another solution is to bump all >= FC-4 branches to 2%{?dist} but that's wasteful for the newer branches which wouldn't need the fix. I don't remember if this is mentioned somewhere in the Wiki and I'm too lazy to search right now, but if it's not there and there's a place where packagers would be likely to find the note, adding it wouldn't be a bad idea. Checking for expected NEVR order between distro branches sounds like a job for an automated script + public whinemail. Does anyone happen to have such a script or one that could be easily extended to do it already available? From mdehaan at redhat.com Wed May 3 21:49:13 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 03 May 2006 17:49:13 -0400 Subject: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff In-Reply-To: <4457C5D5.6020508@redhat.com> References: <4457A549.5050603@redhat.com> <1146599764.3163.41.camel@localhost> <4457C5D5.6020508@redhat.com> Message-ID: <44592559.3000309@redhat.com> Michael DeHaan wrote: > Toshio Kuratomi wrote: >> On Tue, 2006-05-02 at 14:30 -0400, Michael DeHaan wrote: >> >>> Bugzilla 189281 references the YAML parser for Python in FC-extras >>> as being broken. The bug report went to oliver at linux-kernel.at on >>> 4/18 and I've emailed him on 4/28 inquiring about the 4/18 bug >>> report and volunteering to help. No replies yet on either account, >>> I'm assuming long vacations and such are possible, such things are >>> understandable and ok. >>> >> >> That bug doesn't show that it's broken, just poorly designed :-) (I'm >> not arguing that syck's python bindings aren't broken in other ways and >> deserve to get replaced....) >> >> [snip] >> > > Not having a YAML package for Fedora that can serialize anything is > pretty broken, IMHO :) > >> >>> The Python community has apparently seen that the syck bindings that >>> ship with syck (current=0.55) are broken, so they've come up with a >>> version of syck-python that is 0.61 (http://pyyaml.org) on their own >>> . They are also working on a Python Yaml 3000 replacement library, >>> that is apparently also a good candidate. >>> >>> My suggestion is that syck-python be orphaned due to the fact that >>> (1) it's broken since it can't serialize anything at all (no dump >>> function), and (2) syck isn't incredibly robust. Given this, I'm >>> planning on packaging a "python-yaml" for extras using the >>> Python-YAML 3000 or Python-Syck codebase here, which has syck at >>> 0.61. We can then pull python-syck out of the repository. Yes, >>> I'm signing up to do this, assuming we can orphan the broken package >>> to reduce confusion. >>> >> >> I liked the idea of yaml but have refrained from using it due to the >> problems with the python-syck bindings. I think it would be valuable to >> have working bindings whether or not syck-python is orphaned. > Agreed. > >> Here are >> some questions: >> >> pysyck: the pyyaml.org website provides a patched syck that is an svn >> snapshot plus pyyaml patches. Is an unpatched syck going to have >> significant deficiencies? > Yes. An unpatched syck doesn't have a working dump function, which > makes it at least 50% broken, so I'd call those dependencies rather > major. I have not researched their other fixes to syck. The one > issue with packaging their pyyaml patched version now is the 1.1 > compliance. We have to move to 1.1 at some point, and it looks to me > that the 3000 version is good enough now. (See below on syck issues). > >> Is upstream syck going to make new releases >> or is all development of the library concentrated in the ruby tree? Has >> the pysyck community proposed their changes to upstream syck? >> > I've contacted whytheluckystiff (upstream) about his thoughts and > relationship with pysyck. He is for all intents and purposes in the > Ruby camp, and I'm not sure how much time (if any) is spent on the > Python ones. The python brokeness has no doubt been reported at > least once, which makes me believe upstream syck isn't the answer. > Further, per a coworker of mine (I haven't followed up on this > myself), syck's source doesn't do a good job of checking memory > allocation calls, does some reallocs, and so forth ... so I am well > inclined to use a non-native parser for stability/safety reasons. > PyYaml 3000 would fit this niche nicely. > >> pyyaml3000: No released tarballs. Does upstream have a timeline for >> that or are we going to be making snapshots for quite a while? >> > As for pyyaml3000, I have a RPM on my desktop now (already built) and > am about to submit it to FC-extras for review. It seems very stable > and I can contact them about plans on releasing snapshots. For now, > I've built a tarball myself. > >> To me, making a pyyaml3000 package (with some idea of what we can expect >> from upstream) could go the route of any other Extras package. (After >> all, we have both libxml2 with python bindings and elementTree already.) >> >> pysyck could be treated the same way but seems like it would benefit >> from coordination with the syck maintainer (to Obsolete syck-python and >> stop building that as a subpackage, is upstream syck going to make >> python fixes, should we add pysyck patches to our syck library, etc) >> See if Oliver responds to inquiries about you packaging pysyck (or if he >> doesn't have time for syck anymore and is willing to hand it off to >> you.) > I've contacted whytheluckystiff to see his opinions on upstream > pysyck's brokenness as well, just for good measure. I agree with you > that having duplicate implementations won't hurt (if both work), but I > do think that having just one broken implementation in there > (syck-python) is not enough. So whether we orphan the broken > syck-python or not, I'm backing the yaml 3000 as the right way to > go. Package is currently named 'python-yaml', since we don't have > one, and I don't want version numbers in the formal package name. > Version is "0.3000.20060502". > > --Michael > Given no other replies to this commentary, I think we're ok on the PyYaml 3000 front (what to do about syck-python is another issue, and I'm willing to let it slide if a good working alternative can get out there). I do have people interested in reviewing this (Toshio, you are welcome to as well), but I lack a potential sponsor for my first package. Can anyone jump on board and help me out? The module itself was already built with distutils, so the spec only moves it into a more reasonable namespace and numbering scheme. Here's the bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190493 Much appreciated! --Michael From tibbs at math.uh.edu Wed May 3 23:32:22 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 03 May 2006 18:32:22 -0500 Subject: Release bumps in old branches In-Reply-To: <1146688510.5802.177.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 03 May 2006 23:35:09 +0300") References: <1146688510.5802.177.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> Checking for expected NEVR order between distro branches sounds VS> like a job for an automated script + public whinemail. Does the CVS server have enough ready information to prevent this at tag time? I.e. prevent the tagging of a release that's greater than the devel branch? - J< From Christian.Iseli at licr.org Wed May 3 23:39:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 04 May 2006 01:39:19 +0200 Subject: Release bumps in old branches In-Reply-To: Your message of "Wed, 03 May 2006 23:35:09 +0300." <1146688510.5802.177.camel@localhost.localdomain> Message-ID: <200605032339.k43NdORn001801@mx3.redhat.com> Hi, ville.skytta at iki.fi said: > Checking for expected NEVR order between distro branches sounds like a job > for an automated script + public whinemail. Does anyone happen to have such > a script or one that could be easily extended to do it already available? Shouldn't be too hard to add to my parseBZbugList script (http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora) as it already snarfs the SRPMS list of all repos. I won't have much time available to work on this before May 15, so feel free to hack the script yourself if you like. Cheers, Christian From wtogami at redhat.com Thu May 4 02:57:52 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 03 May 2006 22:57:52 -0400 Subject: Release bumps in old branches In-Reply-To: References: <1146688510.5802.177.camel@localhost.localdomain> Message-ID: <44596DB0.8040407@redhat.com> Jason L Tibbitts III wrote: >>>>>> "VS" == Ville Skytt writes: > > VS> Checking for expected NEVR order between distro branches sounds > VS> like a job for an automated script + public whinemail. > > Does the CVS server have enough ready information to prevent this at > tag time? I.e. prevent the tagging of a release that's greater than > the devel branch? > > - J< > The CVS server itself cannot prevent this at tag time, but we could add the logic to the common/Makefile.common to parse the tag and rpmvercmp it to other branches. If anyone wants to volunteer to write this, see the code in /usr/bin/fedora-rpmvercmp from fedora-rpmdevtools for some python rpm ENVR comparison sample code. Warren Togami wtogami at redhat.com From michael at knox.net.nz Thu May 4 04:34:13 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 04 May 2006 16:34:13 +1200 Subject: FESCo self-nomination Message-ID: <44598445.1010906@knox.net.nz> OK, so I have decided to nominate myself for FESCo. No point re-typing what has bee said here: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Regards Michael From buildsys at fedoraproject.org Thu May 4 05:57:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 01:57:09 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060504055709.B500C152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 libxml++-2.14.0-1.fc3 oddjob-0.26-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 4 05:57:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 01:57:42 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060504055742.0E2E6152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 20 bitbake-1.4.0-1.fc4 erlang-R10B-10.3.fc4 fuse-2.5.3-1.fc4 fuse-encfs-1.3.1-1.fc4 galeon-2.0.1-3.fc4 galeon-2.0.1-4.fc4 gauche-0.8.7-5.fc4 libibverbs-1.0.3-1.fc4 libxml++-2.14.0-1.fc4 mod_extract_forwarded-2.0.2-1.fc4 nagios-2.2-3.fc4 nagios-2.3-1.fc4 oddjob-0.26-2 prozilla-1.3.7.4-3.fc4 putty-0.58-2.fc4 pygame-1.7.1-7.fc4 pylint-0.11.0-1.fc4 python-astng-0.16.0-0.fc4 wifiroamd-1.06-1.fc4 yumex-1.0.0-1.0.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 4 05:58:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 01:58:34 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060504055834.E68A1152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 23 bitbake-1.4.0-1.fc5 erlang-R10B-10.3.fc5 fuse-2.5.3-1.fc5 fuse-encfs-1.3.1-1.fc5 galeon-2.0.1-2.fc5 galeon-2.0.1-4.fc5 gauche-0.8.7-5.fc5 libibverbs-1.0.3-1.fc5 libxml++-2.14.0-1.fc5 mail-notification-2.0-12.fc5 mod_extract_forwarded-2.0.2-1.fc5 nagios-2.3-1.fc5 octave-2.9.5-3.fc5 octave-forge-2006.03.17-4.fc5 oddjob-0.26-3 prozilla-1.3.7.4-3.fc5 putty-0.58-2.fc5 pygame-1.7.1-7.fc5 pylint-0.11.0-1.fc5 python-astng-0.16.0-0.fc5 python-logilab-common-0.15.0-1.fc5 wifiroamd-1.06-1.fc5 yumex-1.0.0-1.0.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 4 05:58:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 01:58:47 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060504055847.EDB0A152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 4 libibverbs-1.0.3-1.fc6 libmthca-1.0-1.fc6 prozilla-1.3.7.4-3.fc6 putty-0.58-2.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From bugs.michael at gmx.net Thu May 4 08:11:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 4 May 2006 10:11:24 +0200 Subject: Release bumps in old branches In-Reply-To: <44596DB0.8040407@redhat.com> References: <1146688510.5802.177.camel@localhost.localdomain> <44596DB0.8040407@redhat.com> Message-ID: <20060504101124.e5206006.bugs.michael@gmx.net> On Wed, 03 May 2006 22:57:52 -0400, Warren Togami wrote: > Jason L Tibbitts III wrote: > >>>>>> "VS" == Ville Skytt writes: > > > > VS> Checking for expected NEVR order between distro branches sounds > > VS> like a job for an automated script + public whinemail. > > > > Does the CVS server have enough ready information to prevent this at > > tag time? I.e. prevent the tagging of a release that's greater than > > the devel branch? > > > > - J< > > > > The CVS server itself cannot prevent this at tag time, but we could add > the logic to the common/Makefile.common to parse the tag and rpmvercmp > it to other branches. That would be too limiting and error-prone. Would you want it to print a warning only? Or refuse to tag something because a newer branch is seen as older? Or create a new optional Makefile target? What is stored in CVS does not matter. What is built by the buildsys matters. What would you do if the FC-4 build succeeded and FC-5 failed? Until FC-5 build is fixed, FC-4 can be newer. CVS is not the point where to check this. From bugs.michael at gmx.net Thu May 4 08:19:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 4 May 2006 10:19:52 +0200 Subject: Release bumps in old branches In-Reply-To: <200605032339.k43NdORn001801@mx3.redhat.com> References: <1146688510.5802.177.camel@localhost.localdomain> <200605032339.k43NdORn001801@mx3.redhat.com> Message-ID: <20060504101952.459b8654.bugs.michael@gmx.net> On Thu, 04 May 2006 01:39:19 +0200, Christian.Iseli at licr.org wrote: > Hi, > > ville.skytta at iki.fi said: > > Checking for expected NEVR order between distro branches sounds like a job > > for an automated script + public whinemail. Does anyone happen to have such > > a script or one that could be easily extended to do it already available? > > Shouldn't be too hard to add to my parseBZbugList script > (http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora) > as it already snarfs the SRPMS list of all repos. > > I won't have much time available to work on this before May 15, so feel free > to hack the script yourself if you like. src.rpm packages don't suffice as you cannot access the Epoch without taking a look at RPM header details. You would check only NVR, not NEVR. Yum metadata is the way to go here, too. From Christian.Iseli at licr.org Thu May 4 08:41:45 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 04 May 2006 10:41:45 +0200 Subject: Release bumps in old branches In-Reply-To: Your message of "Thu, 04 May 2006 10:19:52 +0200." <20060504101952.459b8654.bugs.michael@gmx.net> Message-ID: <200605040841.k448fkre001791@mx3.redhat.com> bugs.michael at gmx.net said: > src.rpm packages don't suffice as you cannot access the Epoch without taking > a look at RPM header details. You would check only NVR, not NEVR. Yum > metadata is the way to go here, too. Ah right. Didn't think about the epoch problem... time for someone to have some fun with repoquery I guess... Cheers, Christian From bugs.michael at gmx.net Thu May 4 09:23:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 04 May 2006 09:23:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-04 Message-ID: <20060504092358.3957.20864@rawhide.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Thu May 4 09:24:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 04 May 2006 09:24:01 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-04 Message-ID: <20060504092401.3959.41323@rawhide.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 galeon 2.0.1-1.fc5.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 sobby 0.3.0-2.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc galeon 2.0.1-1.fc5.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc sobby 0.3.0-2.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 galeon 2.0.1-1.fc5.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 sobby 0.3.0-2.fc5.x86_64 ====================================================================== New report for: denis AT poolshark.org package: galeon - 2.0.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: mozilla = 37:1.7.12 package: galeon - 2.0.1-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: mozilla = 37:1.7.12 package: galeon - 2.0.1-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: mozilla = 37:1.7.12 ====================================================================== package: sobby - 0.3.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: sobby - 0.3.0-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnet6-1.2.so.0()(64bit) libobby-0.3.so.0()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: sobby - 0.3.0-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 From bugs.michael at gmx.net Thu May 4 09:23:57 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 04 May 2006 09:23:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-04 Message-ID: <20060504092357.3954.87026@rawhide.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg ====================================================================== package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From mpeters at mac.com Thu May 4 13:05:48 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 04 May 2006 06:05:48 -0700 Subject: FE-ACCEPT when sponsor needed Message-ID: <1146747949.5627.13.camel@atlantis.mpeters.local> Bug #190396 - netpanzer It has been reviewed and approved and put in FE-ACCEPT but the submitter needs a sponsor. Has policy changed on that? I thought that packages could not be formally approved until the packager had a sponsor. At any rate - the bug should probably block the NEEDS-SPONSOR bug, to make it easier for potential sponsors to find. From laurent.rineau__fc_extra at normalesup.org Thu May 4 13:39:05 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Thu, 4 May 2006 15:39:05 +0200 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <1146747949.5627.13.camel@atlantis.mpeters.local> References: <1146747949.5627.13.camel@atlantis.mpeters.local> Message-ID: <200605041539.05599@rineau.schtroumpfette> On Thursday 04 May 2006 15:05, Michael A. Peters wrote: > Bug #190396 - netpanzer > > It has been reviewed and approved and put in FE-ACCEPT but the submitter > needs a sponsor. > > Has policy changed on that? > I thought that packages could not be formally approved until the > packager had a sponsor. > > At any rate - the bug should probably block the NEEDS-SPONSOR bug, to > make it easier for potential sponsors to find. I have the same problem: I am the author of the following review request: Bug?#190070 ? Review Request: par2cmdline The day after the creation of the request, it has been accepted, and added to blockers of FE-ACCEPT. However, it was my first submission, and I tell that in the description of the request. I added FE-NEEDSSPONSOR to blockers of my request, the day after, a week ago. I suppose that my request awaits another review of a sponsor, so that I am sponsored. Perhaps my request #190070 should no longer block FE-NEEDSSPONSOR. Please tell me. From wtogami at redhat.com Thu May 4 13:47:01 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 May 2006 09:47:01 -0400 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <1146747949.5627.13.camel@atlantis.mpeters.local> References: <1146747949.5627.13.camel@atlantis.mpeters.local> Message-ID: <445A05D5.7090701@redhat.com> Michael A. Peters wrote: > Bug #190396 - netpanzer > > It has been reviewed and approved and put in FE-ACCEPT but the submitter > needs a sponsor. > > Has policy changed on that? > I thought that packages could not be formally approved until the > packager had a sponsor. > > At any rate - the bug should probably block the NEEDS-SPONSOR bug, to > make it easier for potential sponsors to find. > People should not sit in NEED-SPONSOR status and just expect sponsorship. The best way to get sponsorship is to continue doing other work, like reviewing other packages, giving helpful advice, or submitting more packages for review. Having approved packages is *NOT* the requirement for gaining cvsextras sponsorship. Instead demonstrating that you understand the packaging guidelines and Fedora process to sponsor members is what is necessary to gain sponsorship. Warren Togami wtogami at redhat.com From j.w.r.degoede at hhs.nl Thu May 4 14:04:22 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 04 May 2006 16:04:22 +0200 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <445A05D5.7090701@redhat.com> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <445A05D5.7090701@redhat.com> Message-ID: <445A09E6.80301@hhs.nl> Warren Togami wrote: > Michael A. Peters wrote: >> Bug #190396 - netpanzer >> >> It has been reviewed and approved and put in FE-ACCEPT but the submitter >> needs a sponsor. >> >> Has policy changed on that? >> I thought that packages could not be formally approved until the >> packager had a sponsor. >> >> At any rate - the bug should probably block the NEEDS-SPONSOR bug, to >> make it easier for potential sponsors to find. >> > > People should not sit in NEED-SPONSOR status and just expect > sponsorship. The best way to get sponsorship is to continue doing other > work, like reviewing other packages, giving helpful advice, or > submitting more packages for review. Having approved packages is *NOT* > the requirement for gaining cvsextras sponsorship. Instead > demonstrating that you understand the packaging guidelines and Fedora > process to sponsor members is what is necessary to gain sponsorship. > I can currently sponsor and as a member of the games SIG I concider myself a good sponsor candidate for this person, seeing how he has chosen a game as his first package. Judging from the quick response during the review and the fact that he has had IRC contact with the reviewer which is described as positive by the reviewer (Andreas Thienemann), and because the initial package was of ok quality (only minor changes needed) and the few issues left were fixed without the packager needing any handholding. I concider the packager (Hugo Cisneiros (hugo at devin.com.br)) ready for sponsoring. I'm however new to the whole sponsoring business, is the fact that I believe him to be ready good enough? Are my standards high enough or am I to easy with trusting someone? Regards, Hans From bdpepple at ameritech.net Thu May 4 13:27:28 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 04 May 2006 09:27:28 -0400 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <1146747949.5627.13.camel@atlantis.mpeters.local> References: <1146747949.5627.13.camel@atlantis.mpeters.local> Message-ID: <1146749248.26983.3.camel@shuttle.piedmont.com> On Thu, 2006-05-04 at 06:05 -0700, Michael A. Peters wrote: > Bug #190396 - netpanzer > > It has been reviewed and approved and put in FE-ACCEPT but the submitter > needs a sponsor. > > Has policy changed on that? > I thought that packages could not be formally approved until the > packager had a sponsor. Last I remember that is correct. > > At any rate - the bug should probably block the NEEDS-SPONSOR bug, to > make it easier for potential sponsors to find. > Correct. One has to wonder how much of the wiki the submitter has read, since this is addressed there. http://fedoraproject.org/wiki/Extras/Contributors#head-350f978b25c60398e0d16100bb3da317c1fd18c3 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu May 4 14:22:13 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 04 May 2006 16:22:13 +0200 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <200605041539.05599@rineau.schtroumpfette> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> Message-ID: <445A0E15.5080007@hhs.nl> Laurent Rineau wrote: > I have the same problem: I am the author of the following review request: > Bug #190070 ? Review Request: par2cmdline > > The day after the creation of the request, it has been accepted, and added to > blockers of FE-ACCEPT. > > However, it was my first submission, and I tell that in the description of the > request. I added FE-NEEDSSPONSOR to blockers of my request, the day after, a > week ago. I suppose that my request awaits another review of a sponsor, so > that I am sponsored. > > Perhaps my request #190070 should no longer block FE-NEEDSSPONSOR. Please tell > me. > No, blocking FE-NEEDSSPONSOR is correct untill you find a sponsor that is. I might be willing to sponsor you, but you first need to prove yourself somewhat more IMHO. Taking a spec file from Suse as a start is ok but hen not removing the Packager: Suse tag is somewhat sloppy. Also admitting that you use this tool for Legally gray area activities doesn't help building trust. Have you done other opensource work, if so pointers please. Otherwise opportunities to prove yourself are: -doing some reviews. Drop me in the CC-list so that I know that you're doing those. See: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-NEW -package some more software for example libpar and gpar from: http://sourceforge.net/projects/parchive/ Please add me to the CC field of the package review then I'll review it for you and if all goes well sponsor you. Regards, Hans From bdpepple at ameritech.net Thu May 4 13:52:21 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 04 May 2006 09:52:21 -0400 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <200605041539.05599@rineau.schtroumpfette> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> Message-ID: <1146750741.27712.1.camel@shuttle.piedmont.com> On Thu, 2006-05-04 at 15:39 +0200, Laurent Rineau wrote: > On Thursday 04 May 2006 15:05, Michael A. Peters wrote: > > Bug #190396 - netpanzer > > > > At any rate - the bug should probably block the NEEDS-SPONSOR bug, to > > make it easier for potential sponsors to find. > > I have the same problem: I am the author of the following review request: > Bug #190070 ? Review Request: par2cmdline > > The day after the creation of the request, it has been accepted, and added to > blockers of FE-ACCEPT. > > However, it was my first submission, and I tell that in the description of the > request. I added FE-NEEDSSPONSOR to blockers of my request, the day after, a > week ago. I suppose that my request awaits another review of a sponsor, so > that I am sponsored. > > Perhaps my request #190070 should no longer block FE-NEEDSSPONSOR. Please tell > me. > Personally, that bug should probably remain FE-NEEDSSPONSOR, and not be FE-ACCEPT, since it sounds like the person that approved your package cannot sponsor new contributors. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu May 4 14:36:22 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 04 May 2006 09:36:22 -0500 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <200605041539.05599@rineau.schtroumpfette> (Laurent Rineau's message of "Thu, 4 May 2006 15:39:05 +0200") References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> Message-ID: >>>>> "LR" == Laurent Rineau writes: LR> I have the same problem: I am the author of the following review LR> request: Bug?#190070 -------------- next part -------------- $(G!9(B Review Request: par2cmdline Yep, I'm sort of sitting on it because I (the person who reviewed the package in question) have been nominated for sponsor status; this will be decided in three hours or so, after which I'll decide what to do with the ticket. - J< From toshio at tiki-lounge.com Thu May 4 15:13:05 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 04 May 2006 08:13:05 -0700 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <445A09E6.80301@hhs.nl> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <445A05D5.7090701@redhat.com> <445A09E6.80301@hhs.nl> Message-ID: <1146755585.1803.8.camel@localhost> On Thu, 2006-05-04 at 16:04 +0200, Hans de Goede wrote: > Judging from the quick response during the review and the fact that he > has had IRC contact with the reviewer which is described as positive by > the reviewer (Andreas Thienemann), and because the initial package was > of ok quality (only minor changes needed) and the few issues left were > fixed without the packager needing any handholding. I concider the > packager (Hugo Cisneiros (hugo at devin.com.br)) ready for sponsoring. I'm > however new to the whole sponsoring business, is the fact that I believe > him to be ready good enough? Are my standards high enough or am I to > easy with trusting someone? You are responsible for looking out for your sponsoree (Giving helpful pointers, being available to answer questions, fixing things if the packager you sponsor breaks things.) So it is a question of your personal judgment and willingness to deal with the level of needs you think the sponsoree will require. -Toshio PS: I think your observations point in a distinctly positive direction for this packager. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu May 4 15:20:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 04 May 2006 10:20:25 -0500 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <1146749248.26983.3.camel@shuttle.piedmont.com> (Brian Pepple's message of "Thu, 04 May 2006 09:27:28 -0400") References: <1146747949.5627.13.camel@atlantis.mpeters.local> <1146749248.26983.3.camel@shuttle.piedmont.com> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> Correct. One has to wonder how much of the wiki the submitter has BP> read, since this is addressed there. To be completely fair, the NEEDSPONSOR blocking stuff was added only recently, probably as the submitter was preparing the package. The note about at least indicating the need for sponsorship has been there for quite some time. - J< From tcallawa at redhat.com Thu May 4 15:42:53 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 04 May 2006 10:42:53 -0500 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> Message-ID: <1146757373.3388.83.camel@localhost.localdomain> On Sun, 2006-04-30 at 12:18 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> You can look _into_ rpms just fine and skim over any included > MS> ChangeLog, NEWS, README files. > > Please tell us how you would do so. Assume the usual case, that the > package is in a remote yum repo. > > Remember that we have no announcement mechanism for Extras packages, > so we have no way to communicate possible incompatible updates to > users. Obviously the idea is to not introduce any incompatible > changes within a single Fedora release, but eventually it's going to > happen and surely a sentence in the %changelog can do nothing but > help. A sentence in the changelog for such an event would be acceptable (IMHO). Dumping big chunks of the package's ChangeLog into the spec would not be. :) ~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 bdpepple at ameritech.net Thu May 4 16:00:18 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 04 May 2006 12:00:18 -0400 Subject: FE-ACCEPT when sponsor needed In-Reply-To: References: <1146747949.5627.13.camel@atlantis.mpeters.local> <1146749248.26983.3.camel@shuttle.piedmont.com> Message-ID: <1146758418.30830.7.camel@shuttle.piedmont.com> On Thu, 2006-05-04 at 10:20 -0500, Jason L Tibbitts III wrote: > >>>>> "BP" == Brian Pepple writes: > > BP> Correct. One has to wonder how much of the wiki the submitter has > BP> read, since this is addressed there. > > To be completely fair, the NEEDSPONSOR blocking stuff was added only > recently, probably as the submitter was preparing the package. > The note about at least indicating the need for sponsorship has been > there for quite some time. It was originally added to the wiki when that blocker was added (back in January if I remember correctly), though I think it was on a different page originally. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Thu May 4 17:13:43 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 May 2006 13:13:43 -0400 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <445A09E6.80301@hhs.nl> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <445A05D5.7090701@redhat.com> <445A09E6.80301@hhs.nl> Message-ID: <445A3647.7080106@redhat.com> Hans de Goede wrote: > > Judging from the quick response during the review and the fact that he > has had IRC contact with the reviewer which is described as positive by > the reviewer (Andreas Thienemann), and because the initial package was > of ok quality (only minor changes needed) and the few issues left were > fixed without the packager needing any handholding. I concider the > packager (Hugo Cisneiros (hugo at devin.com.br)) ready for sponsoring. I'm > however new to the whole sponsoring business, is the fact that I believe > him to be ready good enough? Are my standards high enough or am I to > easy with trusting someone? As sponsor, your are responsible for education of the members that you sponsor. So if you feel they understand the guidelines you may sponsor that member. If they make any mistakes, you are expected to educate them. Warren Togami wtogami at redhat.com From tcallawa at redhat.com Thu May 4 17:25:57 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 04 May 2006 12:25:57 -0500 Subject: FESCo Nomination In-Reply-To: <1145818390.2767.34.camel@localhost.localdomain> References: <1145818390.2767.34.camel@localhost.localdomain> Message-ID: <1146763558.2859.17.camel@localhost.localdomain> Well, let me throw my hat into the ring. I'd like to nominate myself to retain the role that I have had on FESCo. Here are the necessary sections from my wiki entry: Mission Statement: To continue to shape and evolve the packaging standards for Fedora, to serve as a liaison between Red Hat and the open source community, and to help resolve the inevitable issues that the growing Fedora Extras ecosystem faces. Past work summary: I have been responsible for defining the packaging standards and guidelines for Fedora Extras since the inception of "Fedora Extras". I've been employed by Red Hat for more than 5 years, and I've been active in open source and Linux for almost 10 years. I maintain a port of Fedora Core to SPARC, called Aurora SPARC Linux, with two major releases to date. At one point, I was responsible for more package reviews that any other contributor, and I have sponsored more than 25 new packagers. Future plans: * Assist in the creation of a Fedora Packaging committee. * Work towards enabling Fedora to truly grow beyond x86/x86_64, with a multiple tiered architecture model * Continue to grow and revise Fedora Packaging guidelines Thank you, ~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! P.S. I also have an army of ninjas to help enforce my continued rule. From dennis at ausil.us Thu May 4 18:57:15 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 4 May 2006 13:57:15 -0500 Subject: Fesco nomination Message-ID: <200605041357.15407.dennis@ausil.us> I'd like to nominate myself to be a Fesco Member Mission Statement: To ensure that extras gets the security treatment it deserves and that it grows in a stable and strong manner. Help to ensure that fedora takes positive steps forward. Past work summary: I maintain a handful of packages in extras. I am a member of the Security Response Team (which is new and will be growing more). I maintain a port of extras for Aurora SPARC Linux. Future plans: * Work with the security Team to make sure that we are as proactive as possible in regards to security. * Work towards enabling Fedora to become truly cross platform. From lists at timj.co.uk Thu May 4 22:10:18 2006 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 04 May 2006 23:10:18 +0100 Subject: buildsys dead? Message-ID: <445A7BCA.3080802@timj.co.uk> Am I doing something silly or is the buildsys dead? http://buildsys.fedoraproject.org/logs/fedora-development-extras/8850-rapidsvn-0.9.1-3.fc6/ http://buildsys.fedoraproject.org/logs/fedora-development-extras/8851-rapidsvn-0.9.1-3.fc6/ root.log has stuff like: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-cdfe2cafe46616939ee5c3bbc2ab5fadba1459a2/root groupinstall build Failed to add groups file for repository: core python: rpmte.c:530: rpmteColorDS: Assertion `ix < Count' failed. unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category sh: line 1: 13761 Aborted /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-cdfe2cafe46616939ee5c3bbc2ab5fadba1459a2/root groupinstall build Cleaning up... Done. From andreas at bawue.net Thu May 4 22:17:53 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 5 May 2006 00:17:53 +0200 (CEST) Subject: buildsys dead? In-Reply-To: <445A7BCA.3080802@timj.co.uk> References: <445A7BCA.3080802@timj.co.uk> Message-ID: On Thu, 4 May 2006, Tim Jackson wrote: > Am I doing something silly or is the buildsys dead? Nope. Just rawhide is hosed. regards, andreas From lists at timj.co.uk Thu May 4 22:31:42 2006 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 04 May 2006 23:31:42 +0100 Subject: passing macros into mock Message-ID: <445A80CE.2020909@timj.co.uk> Is there any way (not in the live buildsys, but locally for testing purposes) to pass a macro that isn't normally defined into a mock build environment? I was hoping to do something like: mock --define "something 123" blah.src.rpm I had a search around but couldn't find any obvious answers. Any easy way short of rebuilding the SRPM outside the mock environment with the necessary macro defined? TIA, Tim From buildsys at fedoraproject.org Thu May 4 22:30:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 18:30:43 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060504223043.B4CC4152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 git-1.3.2-1.fc3 synergy-1.3.1-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 4 22:30:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 18:30:54 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060504223054.8B849152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 10 PyX-0.8.1-4.fc4 cpanspec-1.65-2.fc4 git-1.3.2-1.fc4 liferea-1.0.11-1.fc4 perl-Email-MIME-1.82-2.fc4 perl-Email-MIME-Modifier-1.42-2.fc4 perl-HTTP-Recorder-0.05-1.fc4 perl-HTTP-Request-Params-1.01-1.fc4 scim-tables-0.5.6-1.fc4 synergy-1.3.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 4 22:31:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 May 2006 18:31:16 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060504223116.32394152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 14 PyX-0.8.1-4.fc5 cpanspec-1.65-2.fc5 ghc-6.4.2-2.fc5 git-1.3.2-1.fc5 gramps-2.0.11-2.fc5 libgda-1.9.100-5.fc5 libgnomedb-1.9.100-7.fc5 liferea-1.0.11-2.fc5 mftrace-1.1.19-3.fc5 perl-Email-MIME-1.82-2.fc5 perl-Email-MIME-Modifier-1.42-2.fc5 perl-HTTP-Recorder-0.05-1.fc5 perl-HTTP-Request-Params-1.01-1.fc5 synergy-1.3.1-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Fri May 5 00:41:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 04 May 2006 19:41:48 -0500 Subject: passing macros into mock In-Reply-To: <445A80CE.2020909@timj.co.uk> References: <445A80CE.2020909@timj.co.uk> Message-ID: Tim Jackson wrote: > Is there any way (not in the live buildsys, but locally for testing > purposes) to pass a macro that isn't normally defined into a mock build > environment? I was hoping to do something like: > > mock --define "something 123" blah.src.rpm > > I had a search around but couldn't find any obvious answers. Any easy > way short of rebuilding the SRPM outside the mock environment with the > necessary macro defined? Put %define something 123 at the top of the specfile? -- Rex From ville.skytta at iki.fi Fri May 5 06:30:34 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 05 May 2006 09:30:34 +0300 Subject: passing macros into mock In-Reply-To: References: <445A80CE.2020909@timj.co.uk> Message-ID: <1146810634.5802.201.camel@localhost.localdomain> On Thu, 2006-05-04 at 19:41 -0500, Rex Dieter wrote: > Tim Jackson wrote: > > Is there any way (not in the live buildsys, but locally for testing > > purposes) to pass a macro that isn't normally defined into a mock build > > environment? I was hoping to do something like: > > > > mock --define "something 123" blah.src.rpm > > > > I had a search around but couldn't find any obvious answers. Any easy > > way short of rebuilding the SRPM outside the mock environment with the > > necessary macro defined? > > Put > %define something 123 > at the top of the specfile? Or you could use mach, which is the "father" of mock, and available from FE. It has the above feature and much more (in fact so much more that if I understand correctly, it was one of the reasons why mock was created...). But it works well for me. From bugs.michael at gmx.net Fri May 5 08:04:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 May 2006 10:04:20 +0200 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> Message-ID: <20060505100420.a5d06dd2.bugs.michael@gmx.net> On Sun, 30 Apr 2006 12:18:14 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> You can look _into_ rpms just fine and skim over any included > MS> ChangeLog, NEWS, README files. > > Please tell us how you would do so. Assume the usual case, that the > package is in a remote yum repo. A fearful user downloads new packages and performs a test upgrade on a test machine. A fearful user knows that any shiny new version upgrade may lead to severe regression, brown paperbag bugs, and other defects, regardless of how upstream advertises the NEWS in their doc files. If you mix upstream ChangeLog details and packaging %changelog details, you create a blurred picture of who did what. Further, some upstream developers are very verbose in their ChangeLogs, so as soon as you started trying to sum up the changes in a new version, you would either fail or end up copying the entire ChangeLog into your spec file. In general, let users assume that a version upgrade is bigger'n'better unless it failed during your packaging QA. The majority of end-users are not interested in implementation details in developer ChangeLogs unless they are confronted with run-time misbehaviour. And even then, many of them don't read ChangeLogs to find out which CVS commit may have been the culprit. > Remember that we have no announcement mechanism for Extras packages, > so we have no way to communicate possible incompatible updates to > users. Obviously the idea is to not introduce any incompatible > changes within a single Fedora release, but eventually it's going to > happen and surely a sentence in the %changelog can do nothing but > help. This belongs into the "spec %changelog should [...] cover important changes in the packaging" as an incompatible version upgrade means that you need to put a warning into your %changelog because _you created_ an _incompatible package_. From j.w.r.degoede at hhs.nl Fri May 5 09:30:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 05 May 2006 11:30:55 +0200 Subject: Where to install application .py files? Message-ID: <445B1B4F.2000405@hhs.nl> Hi, I'm trying to package some educational games written in python. Upstream delivers a horrible INSTALL.sh which drops the .py files under: /usr/lib/games/childsplay Now this is obviously wrong IMHO, but what is correct. pirut installs its .py files under /usr/lib/python2.4/site-packages/pirut, system-config-network installs them under /usr/share/system-config-network. I thought that /usr/lib/python2.4/site-packages was mainly for python modules / libs which can be used by multiple python programs and that .py files which are program code (iow not "sharable" / reusable) should indeed go under /usr/share/%{name}. Also on my 64bit system I have python stuff under both /usr/lib/python2.4/site-packages/ and /usr/lib64/python2.4/site-packages/ Thanks & Regards, Hans From jamatos at fc.up.pt Fri May 5 09:45:14 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 5 May 2006 10:45:14 +0100 Subject: Where to install application .py files? In-Reply-To: <445B1B4F.2000405@hhs.nl> References: <445B1B4F.2000405@hhs.nl> Message-ID: <200605051045.14875.jamatos@fc.up.pt> On Friday 05 May 2006 10:30, Hans de Goede wrote: > Hi, > > Also on my 64bit system I have python stuff under both > /usr/lib/python2.4/site-packages/ and /usr/lib64/python2.4/site-packages/ This is what /usr/share/fedora/spectemplate-python.spec says: %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} ... %files %defattr(-,root,root,-) %doc # Include files and dirs below %{python_sitelib} (for noarch packages) and # %{python_sitearch} (for arch-dependent packages) as appropriate, and mark # *.pyo as %ghost (do not include in package). > Thanks & Regards, > > Hans -- Jos? Ab?lio From lists at timj.co.uk Fri May 5 10:53:22 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 05 May 2006 11:53:22 +0100 Subject: passing macros into mock In-Reply-To: References: <445A80CE.2020909@timj.co.uk> Message-ID: <445B2EA2.3050505@timj.co.uk> Rex Dieter wrote: > Tim Jackson wrote: >> Is there any way (not in the live buildsys, but locally for testing >> purposes) to pass a macro that isn't normally defined into a mock build >> environment? I was hoping to do something like: >> >> mock --define "something 123" blah.src.rpm >> >> I had a search around but couldn't find any obvious answers. Any easy >> way short of rebuilding the SRPM outside the mock environment with the >> necessary macro defined? > > Put > %define something 123 > at the top of the specfile? Sorry, I thought it was implicit but perhaps I should have added "...without rebuilding the SRPM". Like when you do "rpmbuild --define 'foo bar' something.src.rpm". Tim From bugs.michael at gmx.net Fri May 5 11:06:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 05 May 2006 11:06:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-05 Message-ID: <20060505110629.8882.20041@faldor.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: ivazquez AT ivazquez.net package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 ====================================================================== New report for: tcallawa AT redhat.com package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 ====================================================================== New report for: petersen AT redhat.com package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From bugs.michael at gmx.net Fri May 5 11:06:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 05 May 2006 11:06:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-05 Message-ID: <20060505110632.8886.67116@faldor.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 ====================================================================== New report for: petersen AT redhat.com package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From bugs.michael at gmx.net Fri May 5 11:06:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 05 May 2006 11:06:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-05 Message-ID: <20060505110636.8888.2109@faldor.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 galeon 2.0.1-1.fc5.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 sobby 0.3.0-2.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc galeon 2.0.1-1.fc5.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc sobby 0.3.0-2.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 galeon 2.0.1-1.fc5.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 sobby 0.3.0-2.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 ====================================================================== New report for: matthias AT rpmforge.net package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 ====================================================================== package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: galeon - 2.0.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: mozilla = 37:1.7.12 package: sobby - 0.3.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: galeon - 2.0.1-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: mozilla = 37:1.7.12 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: sobby - 0.3.0-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnet6-1.2.so.0()(64bit) libobby-0.3.so.0()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: galeon - 2.0.1-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: mozilla = 37:1.7.12 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: sobby - 0.3.0-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From tla-ml at rasmil.dk Fri May 5 11:08:14 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Fri, 05 May 2006 13:08:14 +0200 Subject: Where to install application .py files? In-Reply-To: <445B1B4F.2000405@hhs.nl> References: <445B1B4F.2000405@hhs.nl> Message-ID: <445B321E.5090100@rasmil.dk> Hans de Goede wrote: > Hi, > > I'm trying to package some educational games written in python. Upstream > delivers a horrible INSTALL.sh which drops the .py files under: > /usr/lib/games/childsplay > > Now this is obviously wrong IMHO, but what is correct. pirut installs > its .py files under /usr/lib/python2.4/site-packages/pirut, > > system-config-network installs them under > /usr/share/system-config-network. I thought that > /usr/lib/python2.4/site-packages was mainly for python modules / libs > which can be used by multiple python programs and that .py files which > are program code (iow not "sharable" / reusable) should indeed go under > /usr/share/%{name}. > > Also on my 64bit system I have python stuff under both > /usr/lib/python2.4/site-packages/ and /usr/lib64/python2.4/site-packages/ > > Thanks & Regards, > > Hans > > The modules should go into /usr/lib/python2.4/site-packages/ and the rest should go into /usr/share/%{name} check out yum, it install a the yum python module into /usr/lib/python2.4/site-packages/yum and the code for the yum client is installed into /usr/share/yum-cli. it can depends on how the python application is coded, if you install a module in site-packages/ you can access the module by doing a import modulename in any python application, you can also install the module in /usr/share/appl.name/modulename, but then it can only be used python application located in /usr/share/appl.name/ . I think the best way, is to install modules under /usr/lib/python2.4/site-packages/ and the rest of the application in /usr/share/appl.name. This is the way i do it in yumex. Tim Lauridsen Tim From tibbs at math.uh.edu Fri May 5 14:04:02 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 05 May 2006 09:04:02 -0500 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: <20060505100420.a5d06dd2.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 5 May 2006 10:04:20 +0200") References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> A fearful user downloads new packages and performs a test upgrade MS> on a test machine. So, I guess I misunderstood what you meant when you said that you could look into rpms to read included documentation. It seems there isn't any such way, which is a shame. Obviously we can't assume that everyone who cares to just read the README before upgrading will have an extra system hanging around. It should be quite possible to script around yumdownloader with a call to rpm2cpio and a subshell exec. Maybe if I can find some time. MS> This belongs into the "spec %changelog should [...] cover MS> important changes in the packaging" as an incompatible version MS> upgrade means that you need to put a warning into your %changelog MS> because _you created_ an _incompatible package_. All of the underling would seem to suggest otherwise, but from my end it really looks like you're agreeing with me here, which I certainly can't complain about. - J< From paul at city-fan.org Fri May 5 14:22:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 May 2006 15:22:10 +0100 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> Message-ID: <1146838930.19738.54.camel@laurel.intra.city-fan.org> On Fri, 2006-05-05 at 09:04 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> A fearful user downloads new packages and performs a test upgrade > MS> on a test machine. > > So, I guess I misunderstood what you meant when you said that you > could look into rpms to read included documentation. It seems there > isn't any such way, which is a shame. Obviously we can't assume that > everyone who cares to just read the README before upgrading will have > an extra system hanging around. It should be quite possible to script > around yumdownloader with a call to rpm2cpio and a subshell exec. > Maybe if I can find some time. Try fedora-extract from fedora-rpmdevtools. Paul. From rdieter at math.unl.edu Fri May 5 14:35:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 05 May 2006 09:35:35 -0500 Subject: passing macros into mock References: <445A80CE.2020909@timj.co.uk> <445B2EA2.3050505@timj.co.uk> Message-ID: Tim Jackson wrote: > Rex Dieter wrote: >> Tim Jackson wrote: >>> Is there any way (not in the live buildsys, but locally for testing >>> purposes) to pass a macro that isn't normally defined into a mock build >>> environment? I was hoping to do something like: >>> mock --define "something 123" blah.src.rpm >> Put >> %define something 123 >> at the top of the specfile? > Sorry, I thought it was implicit but perhaps I should have added > "...without rebuilding the SRPM". Like when you do "rpmbuild --define > 'foo bar' something.src.rpm". AFAIK, mock currently does not have the ability to do that. -- Rex From andreas at bawue.net Fri May 5 14:52:12 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 5 May 2006 16:52:12 +0200 (CEST) Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> Message-ID: On Fri, 5 May 2006, Jason L Tibbitts III wrote: > It should be quite possible to script around yumdownloader with a call > to rpm2cpio and a subshell exec. Maybe if I can find some time. Why not simply call rpm directly? rpm -qp --changelog \ http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/mod_suphp-0.6.1-1.fc5.i386.rpm This should give you the changelog for mod_suphp. bye, andreas From tibbs at math.uh.edu Fri May 5 15:08:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 05 May 2006 10:08:36 -0500 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: (Andreas Thienemann's message of "Fri, 5 May 2006 16:52:12 +0200 (CEST)") References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> Message-ID: >>>>> "AT" == Andreas Thienemann writes: AT> Why not simply call rpm directly? AT> rpm -qp --changelog \ AT> http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/mod_suphp-0.6.1-1.fc5.i386.rpm AT> This should give you the changelog for mod_suphp. We've come full circle. My point was that the changelog is all you can see, so you should at least add a note of incompatible changes there. - J< From tibbs at math.uh.edu Fri May 5 15:12:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 05 May 2006 10:12:46 -0500 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: <1146838930.19738.54.camel@laurel.intra.city-fan.org> (Paul Howarth's message of "Fri, 05 May 2006 15:22:10 +0100") References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> <1146838930.19738.54.camel@laurel.intra.city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Try fedora-extract from fedora-rpmdevtools. At least for extracting RPMs, it doesn't seem much different from rpm2cpio|cpio -mumble, or am I missing something? Even if it just does that, I'd probably use it just so I don't have to read the cpio manpage again. - J< From tibbs at math.uh.edu Fri May 5 15:48:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 05 May 2006 10:48:45 -0500 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: (Jason L. Tibbitts, III's message of "Fri, 05 May 2006 10:12:46 -0500") References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> <1146838930.19738.54.camel@laurel.intra.city-fan.org> Message-ID: After a few minutes, here's a hack. You need yum-utils installed to get yumdownloader. Please don't blame me if this sucks. #!/bin/sh -x DIR=yumlook.$$.$RANDOM PKG=$1 FILE=`pwd`/$1 cd /tmp mkdir $DIR pushd $DIR yumdownloader $PKG # Should only be one file in this directory rpm2cpio $PKG* | cpio --quiet --no-absolute-filenames -idmv 2>&1 $SHELL popd rm -rf /tmp/$DIR For grins, here's another hack that works on local files and needs nothing (save RPM) installed: DIR=rpmlook.$$.$RANDOM FILE=`pwd`/$1 cd /tmp mkdir $DIR pushd /tmp/$DIR rpm2cpio "$FILE" | cpio --quiet --no-absolute-filenames -idmv 2>&1 $SHELL popd rm -rf /tmp/$DIR - J< From paul at city-fan.org Fri May 5 16:51:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 May 2006 17:51:49 +0100 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> <1146838930.19738.54.camel@laurel.intra.city-fan.org> Message-ID: <1146847909.19738.62.camel@laurel.intra.city-fan.org> On Fri, 2006-05-05 at 10:12 -0500, Jason L Tibbitts III wrote: > >>>>> "PH" == Paul Howarth writes: > > PH> Try fedora-extract from fedora-rpmdevtools. > > At least for extracting RPMs, it doesn't seem much different from > rpm2cpio|cpio -mumble, or am I missing something? > > Even if it just does that, I'd probably use it just so I don't have to > read the cpio manpage again. That's why I use it :-) It can also extract a variety of other things of course, but that's not relevant here. Paul. From hugo at devin.com.br Fri May 5 21:16:11 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 05 May 2006 18:16:11 -0300 Subject: yakuake orphaned in FC5? In-Reply-To: <4457B956.2030205@devin.com.br> References: <4457B956.2030205@devin.com.br> Message-ID: <445BC09B.5020505@devin.com.br> Any News about this? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471 Looking forward to build it for everyone :-) -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From chitlesh at fedoraproject.org Fri May 5 21:15:31 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 5 May 2006 23:15:31 +0200 Subject: yakuake orphaned in FC5? In-Reply-To: <445BC09B.5020505@devin.com.br> References: <4457B956.2030205@devin.com.br> <445BC09B.5020505@devin.com.br> Message-ID: <13dbfe4f0605051415h1314b04q6b50547370044760@mail.gmail.com> On 5/5/06, Hugo Cisneiros wrote: > Any News about this? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471 > > Looking forward to build it for everyone :-) > I don't know any updates yet. But this is a great kde-app :) Go on, ask the Fedora Extras Steering Communty to give you updates about it (they should be reading this mail :) ) Chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Fri May 5 21:19:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 May 2006 23:19:54 +0200 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> Message-ID: <20060505231954.91d00f16.bugs.michael@gmx.net> On Fri, 05 May 2006 10:08:36 -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Andreas Thienemann writes: > > AT> Why not simply call rpm directly? > > AT> rpm -qp --changelog \ > AT> http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/mod_suphp-0.6.1-1.fc5.i386.rpm > > AT> This should give you the changelog for mod_suphp. > > We've come full circle. My point was that the changelog is all you > can see, so you should at least add a note of incompatible changes > there. We agree a bit and probably disagree a bit, too. This is not anymore how this thread started. All boils down to what you mean with "include a summary of major changes in your package %changelog", since I really think it is not a good idea to sum up upstream development changes in the package %changelog in general. The original post, which started this thread, is not yours. Joost Soeterbroek suggested | %changelog | * Date Name Packager | - package changelog | + upstream changelog which is not practicable. And with that I loop back to my earlier replies. ;) From hugo at devin.com.br Fri May 5 21:35:36 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 05 May 2006 18:35:36 -0300 Subject: yakuake orphaned in FC5? In-Reply-To: <13dbfe4f0605051415h1314b04q6b50547370044760@mail.gmail.com> References: <4457B956.2030205@devin.com.br> <445BC09B.5020505@devin.com.br> <13dbfe4f0605051415h1314b04q6b50547370044760@mail.gmail.com> Message-ID: <445BC528.5060806@devin.com.br> Chitlesh GOORAH wrote: > On 5/5/06, Hugo Cisneiros wrote: >> Any News about this? >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471 >> >> Looking forward to build it for everyone :-) >> > > I don't know any updates yet. > But this is a great kde-app :) > > Go on, ask the Fedora Extras Steering Communty to give you updates > about it (they should be reading this mail :) ) Yes, indeed yakuake is a great and addictive application! It needs only approvation in the review process to begin building it in buildsys. -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From paul at all-the-johnsons.co.uk Fri May 5 21:44:42 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 05 May 2006 22:44:42 +0100 Subject: Not sure how to sort this mock problem Message-ID: <1146865482.25884.13.camel@T7.Linux> Hi, I'm slowly but surely fixing the problems with building mono apps under mock on my x86 box, and have sorted a very annoying one with boo. However, mock is now generating the following error. Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build I'm logged in as build (build is a standard user who is member of the mock group) Any ideas on what the problem is? TTFN Paul -- Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei denn man ?ffnet die Fenster -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 5 21:52:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 May 2006 17:52:39 -0400 Subject: Not sure how to sort this mock problem In-Reply-To: <1146865482.25884.13.camel@T7.Linux> References: <1146865482.25884.13.camel@T7.Linux> Message-ID: <1146865959.8821.9.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-05 at 22:44 +0100, Paul wrote: > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-development-i386-core/root > groupinstall build > > I'm logged in as build (build is a standard user who is member of the > mock group) > > Any ideas on what the problem is? > -devel is a bit broken right now. A glibc in the tree triggers an rpm bug. We've (hopefully) fixed this by fixing rpmbuild, and a new glibc should be coming out soon that is built with this new rpmbuild so that it won't be a bug anymore. After that, building in -development should work. -- 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 paul at all-the-johnsons.co.uk Fri May 5 21:59:00 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 05 May 2006 22:59:00 +0100 Subject: Not sure how to sort this mock problem In-Reply-To: <1146865959.8821.9.camel@dhcp83-49.boston.redhat.com> References: <1146865482.25884.13.camel@T7.Linux> <1146865959.8821.9.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146866340.25884.27.camel@T7.Linux> Hi, > -devel is a bit broken right now. A glibc in the tree triggers an rpm > bug. We've (hopefully) fixed this by fixing rpmbuild, and a new glibc > should be coming out soon that is built with this new rpmbuild so that > it won't be a bug anymore. After that, building in -development should > work. rpm seems a bit broken at the moment as well :-( (yum -y update results in an assert error once the headers are all down - x86 running rawhide - totally different machine to my buildsys) TTFN Paul -- Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei denn man ?ffnet die Fenster -------------- 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 michael at knox.net.nz Sat May 6 01:15:54 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 06 May 2006 13:15:54 +1200 Subject: FE Package Status of May 06, 2006 Message-ID: <445BF8CA.7040103@knox.net.nz> Hello all, The Fedora Extras package status has been updated. We still have some of the same packaging and bug reports outstanding from the last report. So I urge you, if you see a package you own or your email in the report, please take note and do what is needed to correct the issue. I will give a few days, then I will start filing bugs and email people to do whats needed. Lets keep Extras in top shape! Thanks Michael FE Package Status of May 6, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1689 packages - 51 orphans - 44 packages not available in extras devel or release Axel dot Thimm at ATrpms dot net synaptic andreas at bawue dot net dd_rescue andreas at bawue dot net mboxgrep cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode dennis at ausil dot us cryptplug dreadyman at gmail dot com yakuake fedora dot wickert at arcor dot de xfce4-mailwatch-plugin fredrik at dolda2000 dot com icmpdn gauret at free dot fr elmo gemi at bluewin dot ch inti gemi at bluewin dot ch drscheme ghenry at suretecsystems dot com gnome-applet-netmon ghenry at suretecsystems dot com rsnapshot hugo at devin dot com dot br netpanzer hugo at devin dot com dot br netpanzer-data ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache mpeters at mac dot com PyX notting at redhat dot com perl-Finanace-Quote notting at redhat dot com comps oliver at linux-kernel dot at squidGuard rpm at timj dot co dot uk rapidsvn sgrubb at redhat dot com libsafe tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com stripesnoop tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox ville dot skytta at iki dot fi lirc-kmod-common ville dot skytta at iki dot fi lirc-kmod wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 2 packages not available in extras devel but present in release andreas at bawue dot net echoping jonathan dot underwood at gmail dot com muse - 3 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080,190471 SquidGuard Oliver Falk webmin Jason Vas Dias yakuake Hugo Cisneiros - 7 packages present in the development repo which have no owners entry doctorj gnucap kchmviewer mtd-utils perl-Finance-Quote raptor wxPythonGTK2 - 13 orphaned packages, yet available in extras devel duplicity gtkglarea2 ks3switch lrmi lua ots perl-Chart perl-Net-Netmask perl-XML-XPath perl-XML-XQL s3switch tpb xosd - 36 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for FC5: tcallawa at redhat dot com check - 2 packages duplicated for devel: rdieter at math dot unl dot edu glib tcallawa at redhat dot com check FE-ACCEPT packages stats: - 760 accepted, closed package reviews - 6 accepted, closed package reviews not in repo - 8 accepted, closed package reviews not in owners - 0 accepted, open package reviews older than 4 weeks; - 15 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 82 open tickets - 9 tickets with no activity in eight weeks - 4 tickets with no activity in four weeks - 1 closed tickets FE-NEW packages stats: - 182 open tickets - 8 tickets with no activity in eight weeks - 27 tickets with no activity in four weeks - 2 closed tickets FE-NEEDSPONSOR packages stats: - 31 open tickets - 1 tickets with no activity in eight weeks - 4 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 209 open tickets - 82 tickets with no activity in eight weeks - 74 tickets with no activity in four weeks CVS stats: - 1716 packages with a devel directory - 31 packages with no owners entry gnucap gpasman grandr_applet gtk+ initng kchmviewer kernel-module-thinkpad kile-i18n libexif mtd-utils nethack-falconseye pcb perl-Convert-ASN1 perl-DateManip perl-Finance-Quote perl-GD-SVG perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX perl-XML-Writer perl-bioperl python-ldap raidem-music raptor unifdef - 5 packages in CVS devel *and* Core glib check libevent unifdef gtk+ Maintainers stats: - 183 maintainers - 2 inactive maintainers with open bugs Dropped FC packages: - 237 packages were dropped from core since FC 1 From jkeating at redhat.com Sat May 6 01:22:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 May 2006 21:22:55 -0400 Subject: Not sure how to sort this mock problem In-Reply-To: <1146866340.25884.27.camel@T7.Linux> References: <1146865482.25884.13.camel@T7.Linux> <1146865959.8821.9.camel@dhcp83-49.boston.redhat.com> <1146866340.25884.27.camel@T7.Linux> Message-ID: <1146878575.13101.3.camel@ender> On Fri, 2006-05-05 at 22:59 +0100, Paul wrote: > > rpm seems a bit broken at the moment as well :-( > > (yum -y update results in an assert error once the headers are all > down > - x86 running rawhide - totally different machine to my buildsys) This is the same issue you're seeing. The assert is what is triggered by the glibc build. -- 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 dwmw2 at infradead.org Sat May 6 01:28:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 06 May 2006 02:28:52 +0100 Subject: Fedora Extras 5 Package Build Report In-Reply-To: <20060502185713.33277152160@buildsys.fedoraproject.org> References: <20060502185713.33277152160@buildsys.fedoraproject.org> Message-ID: <1146878932.2503.38.camel@shinybook.infradead.org> On Tue, 2006-05-02 at 14:57 -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 5: 28 > exim-4.62-2.fc5 > exim-doc-4.62-2.fc5 Why don't I see these yet when I update? How long should it take to hit the mirrors? -- dwmw2 From mpeters at mac.com Sat May 6 01:37:59 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 05 May 2006 18:37:59 -0700 Subject: FE Package Status of May 06, 2006 In-Reply-To: <445BF8CA.7040103@knox.net.nz> References: <445BF8CA.7040103@knox.net.nz> Message-ID: <1146879479.2261.34.camel@atlantis.mpeters.local> On Sat, 2006-05-06 at 13:15 +1200, Michael J Knox wrote: > > Owners file stats: > - 1689 packages > - 51 orphans > - 44 packages not available in extras devel or release > mpeters at mac dot com PyX I'm a little confused - http://buildsys.fedoraproject.org/build-status/job.psp?uid=8813 lists the build as complete, but needs to be signed. http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00118.html lists it as built and released. But it isn't in http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/ My local yum mirror also doesn't have it - but it only updates once a day. Was the post from buildsys that it had been "built and released" misleading on the "released" part, and it still needs to be signed and actually released - or did some packages get eaten and need a re-cue? From jpo at lsd.di.uminho.pt Sat May 6 01:42:16 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 06 May 2006 02:42:16 +0100 Subject: FE Package Status of May 06, 2006 In-Reply-To: <445BF8CA.7040103@knox.net.nz> References: <445BF8CA.7040103@knox.net.nz> Message-ID: <445BFEF8.8000009@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael J Knox wrote: > FE Package Status of May 6, 2006 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus > > > Owners file stats: > - 1689 packages > - 51 orphans > - 44 packages not available in extras devel or release > ... > jpo at di dot uminho dot pt perl-Test-Builder-Tester perl-Test-Builder-Tester is included with perl 5.8.8 (a FC-5 core package). ... > > CVS stats: > - 1716 packages with a devel directory > - 31 packages with no owners entry > gnucap gpasman grandr_applet gtk+ initng kchmviewer > kernel-module-thinkpad kile-i18n libexif mtd-utils nethack-falconseye > pcb perl-Convert-ASN1 perl-DateManip perl-Finance-Quote perl-GD-SVG > perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG > perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport > perl-XML-SAX perl-XML-Writer perl-bioperl python-ldap raidem-music > raptor unifdef perl-Convert-ASN1, perl-RPM-Specfile, perl-XML-LibXML-Common, and perl-XML-NamespaceSupport are FC-5 core packages. 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEW/74l0metZG9hRsRAhZnAKCmLdZV9FBQnYc85lPS5u4H6/R6mgCgn8Wy 1OYxw8td7ViMUlEkoP4zCjo= =tUO+ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Sat May 6 03:52:00 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 06 May 2006 15:52:00 +1200 Subject: FE Package Status of May 06, 2006 In-Reply-To: <445BFEF8.8000009@lsd.di.uminho.pt> References: <445BF8CA.7040103@knox.net.nz> <445BFEF8.8000009@lsd.di.uminho.pt> Message-ID: <445C1D60.3010602@knox.net.nz> Jose Pedro Oliveira wrote: >> The full report can be found here: >> http://fedoraproject.org/wiki/Extras/PackageStatus >> >> >> Owners file stats: >> - 1689 packages >> - 51 orphans >> - 44 packages not available in extras devel or release >> ... >> jpo at di dot uminho dot pt perl-Test-Builder-Tester > > perl-Test-Builder-Tester is included with perl 5.8.8 (a FC-5 core package). If thats the case, should there still be an entry for it in the owners file? I would have thought not.. >> CVS stats: >> - 1716 packages with a devel directory >> - 31 packages with no owners entry >> gnucap gpasman grandr_applet gtk+ initng kchmviewer >> kernel-module-thinkpad kile-i18n libexif mtd-utils nethack-falconseye >> pcb perl-Convert-ASN1 perl-DateManip perl-Finance-Quote perl-GD-SVG >> perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG >> perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport >> perl-XML-SAX perl-XML-Writer perl-bioperl python-ldap raidem-music >> raptor unifdef > > perl-Convert-ASN1, perl-RPM-Specfile, perl-XML-LibXML-Common, and > perl-XML-NamespaceSupport are FC-5 core packages. Not sure how these slipped into the report. They don't appear in the repos that were used to generate the report. There is the off false positive.. the script that generates the report is still being actively worked on. If you spot these (false positives) please report them as such. Thanks! Michael From michael at knox.net.nz Sat May 6 03:53:23 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 06 May 2006 15:53:23 +1200 Subject: FE Package Status of May 06, 2006 In-Reply-To: <1146879479.2261.34.camel@atlantis.mpeters.local> References: <445BF8CA.7040103@knox.net.nz> <1146879479.2261.34.camel@atlantis.mpeters.local> Message-ID: <445C1DB3.3020009@knox.net.nz> Michael A. Peters wrote: > On Sat, 2006-05-06 at 13:15 +1200, Michael J Knox wrote: > >> Owners file stats: >> - 1689 packages >> - 51 orphans >> - 44 packages not available in extras devel or release > >> mpeters at mac dot com PyX > > I'm a little confused - > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=8813 > > lists the build as complete, but needs to be signed. > > http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00118.html > > lists it as built and released. > > But it isn't in > > http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/ > > My local yum mirror also doesn't have it - but it only updates once a > day. > > Was the post from buildsys that it had been "built and released" > misleading on the "released" part, and it still needs to be signed and > actually released - or did some packages get eaten and need a re-cue? > Sorry, can't help there :-/ I know nothing of how the push and signing works. Hopefully someone in the know will chime in :) Thanks Michael From mpeters at mac.com Sat May 6 05:34:51 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 05 May 2006 22:34:51 -0700 Subject: FE Package Status of May 06, 2006 In-Reply-To: <445C1D60.3010602@knox.net.nz> References: <445BF8CA.7040103@knox.net.nz> <445BFEF8.8000009@lsd.di.uminho.pt> <445C1D60.3010602@knox.net.nz> Message-ID: <1146893691.2261.69.camel@atlantis.mpeters.local> On Sat, 2006-05-06 at 15:52 +1200, Michael J Knox wrote: > Jose Pedro Oliveira wrote: > >> The full report can be found here: > >> http://fedoraproject.org/wiki/Extras/PackageStatus > >> > >> > >> Owners file stats: > >> - 1689 packages > >> - 51 orphans > >> - 44 packages not available in extras devel or release > >> ... > >> jpo at di dot uminho dot pt perl-Test-Builder-Tester > > > > perl-Test-Builder-Tester is included with perl 5.8.8 (a FC-5 core package). > > If thats the case, should there still be an entry for it in the owners > file? I would have thought not.. the owners file does not distinguish between versions of Fedora. If the perl modules are in fc5 and devel perl, but are not in fc3/fc4 perl, then they will be in the owners file because they are only packaged in Extras for fc3/fc4. It may be necessary to manually blacklist such cases from the report generation. From michael at knox.net.nz Sat May 6 05:41:26 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 06 May 2006 17:41:26 +1200 Subject: FE Package Status of May 06, 2006 In-Reply-To: <1146893691.2261.69.camel@atlantis.mpeters.local> References: <445BF8CA.7040103@knox.net.nz> <445BFEF8.8000009@lsd.di.uminho.pt> <445C1D60.3010602@knox.net.nz> <1146893691.2261.69.camel@atlantis.mpeters.local> Message-ID: <445C3706.3000406@knox.net.nz> Michael A. Peters wrote: > On Sat, 2006-05-06 at 15:52 +1200, Michael J Knox wrote: >> Jose Pedro Oliveira wrote: >>>> The full report can be found here: >>>> http://fedoraproject.org/wiki/Extras/PackageStatus >>>> >>>> >>>> Owners file stats: >>>> - 1689 packages >>>> - 51 orphans >>>> - 44 packages not available in extras devel or release >>>> ... >>>> jpo at di dot uminho dot pt perl-Test-Builder-Tester >>> perl-Test-Builder-Tester is included with perl 5.8.8 (a FC-5 core package). >> If thats the case, should there still be an entry for it in the owners >> file? I would have thought not.. > > the owners file does not distinguish between versions of Fedora. > If the perl modules are in fc5 and devel perl, but are not in fc3/fc4 > perl, then they will be in the owners file because they are only > packaged in Extras for fc3/fc4. > > It may be necessary to manually blacklist such cases from the report > generation. > Ah good point, I was a bit short sighted with my comment. I will mark it down to be blacklisted on the reports. Thanks Michael From tibbs at math.uh.edu Sat May 6 07:10:33 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 06 May 2006 02:10:33 -0500 Subject: Fedora Extras 5 Package Build Report In-Reply-To: <1146878932.2503.38.camel@shinybook.infradead.org> (David Woodhouse's message of "Sat, 06 May 2006 02:28:52 +0100") References: <20060502185713.33277152160@buildsys.fedoraproject.org> <1146878932.2503.38.camel@shinybook.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: >> exim-4.62-2.fc5 exim-doc-4.62-2.fc5 DW> Why don't I see these yet when I update? How long should it take DW> to hit the mirrors? I show them arriving at my local mirror on May 2nd (along with exim-mon and exim-sa). What mirror are you looking at that doesn't have them? - J< From Christian.Iseli at licr.org Sat May 6 07:44:59 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 06 May 2006 09:44:59 +0200 Subject: FE Package Status of May 06, 2006 In-Reply-To: Your message of "Sat, 06 May 2006 17:41:26 +1200." <445C3706.3000406@knox.net.nz> Message-ID: <200605060745.k467j4Rr007268@mx3.redhat.com> Hi Michael, michael at knox.net.nz said: > I will mark it down to be blacklisted on the reports. Yes, they need to be added to the Extras/PackagesNoLongerInDevel page. Cheers, Christian From Christian.Iseli at licr.org Sat May 6 07:49:07 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 06 May 2006 09:49:07 +0200 Subject: FE Package Status of May 06, 2006 In-Reply-To: Your message of "Sat, 06 May 2006 15:52:00 +1200." <445C1D60.3010602@knox.net.nz> Message-ID: <200605060749.k467nBJq008083@mx3.redhat.com> michael at knox.net.nz said: > > perl-Convert-ASN1, perl-RPM-Specfile, perl-XML-LibXML-Common, and > > perl-XML-NamespaceSupport are FC-5 core packages. > Not sure how these slipped into the report. They don't appear in the repos > that were used to generate the report. They slipped in because they now appear in Extras CVS repo... Why do they appear there is probably the correct question... My guess is that they might be migrating from Core to Extras, but in this case they need a review first. Cheers, Christian From gauret at free.fr Sat May 6 09:06:03 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 06 May 2006 11:06:03 +0200 Subject: FE Package Status of May 06, 2006 References: <445BF8CA.7040103@knox.net.nz> Message-ID: Michael J Knox wrote: > - 44 packages not available in extras devel or release > gauret at free dot fr elmo Elmo is retired from Fedora Extras, see the bottom of : http://fedoraproject.org/wiki/Extras/OrphanedPackages?highlight=elmo The upstream project is dead. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From bugs.michael at gmx.net Sat May 6 09:53:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 6 May 2006 11:53:18 +0200 Subject: FE Package Status of May 06, 2006 In-Reply-To: <445C1DB3.3020009@knox.net.nz> References: <445BF8CA.7040103@knox.net.nz> <1146879479.2261.34.camel@atlantis.mpeters.local> <445C1DB3.3020009@knox.net.nz> Message-ID: <20060506115318.874d1ee9.bugs.michael@gmx.net> On Sat, 06 May 2006 15:53:23 +1200, Michael J Knox wrote: > Michael A. Peters wrote: > > On Sat, 2006-05-06 at 13:15 +1200, Michael J Knox wrote: > > > >> Owners file stats: > >> - 1689 packages > >> - 51 orphans > >> - 44 packages not available in extras devel or release > > > >> mpeters at mac dot com PyX > > > > I'm a little confused - > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=8813 > > > > lists the build as complete, but needs to be signed. > > > > http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00118.html > > > > lists it as built and released. > > > > But it isn't in > > > > http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/ > > > > My local yum mirror also doesn't have it - but it only updates once a > > day. > > > > Was the post from buildsys that it had been "built and released" > > misleading on the "released" part, and it still needs to be signed and > > actually released - or did some packages get eaten and need a re-cue? > > > > Sorry, can't help there :-/ I know nothing of how the push and signing > works. > > Hopefully someone in the know will chime in :) Seems those pushed binaries have not been sync into the master repository yet. This is happening now while I'm typing this. From buildsys at fedoraproject.org Sat May 6 10:04:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 6 May 2006 06:04:08 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060506100408.AB0D8152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 scim-tables-0.5.6-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 6 10:04:22 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 6 May 2006 06:04:22 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060506100422.E79F8152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 7 environment-modules-3.2.2-1.fc4 kdemultimedia-extras-3.5.2-5.fc4 mboxgrep-0.7.9-2.fc4 netpanzer-0.8-3.fc4 python-paramiko-1.5.4-2.fc4 python-psyco-1.5.1-2.fc4 xfce4-mailwatch-plugin-1.0.0-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 6 10:05:13 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 6 May 2006 06:05:13 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060506100513.4640F152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 13 environment-modules-3.2.2-1.fc5 gcompris-7.4-6.fc5 gnumeric-1.6.3-1.fc5 goffice-0.2.1-1.fc5 kdemultimedia-extras-3.5.2-5.fc5 mboxgrep-0.7.9-2.fc5 netpanzer-0.8-3.fc5 perl-File-Find-Rule-PPI-0.03-1.fc5 perl-PPI-1.112-1.fc5 python-paramiko-1.5.4-2.fc5 python-psyco-1.5.1-2.fc5 rapidsvn-0.9.1-3.fc5 xfce4-mailwatch-plugin-1.0.0-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 6 10:15:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 6 May 2006 06:15:16 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060506101516.EE176152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 12 crystal-stacker-1.5-1.fc6 erlang-R10B-10.3.fc6 gauche-0.8.7-5.fc6 gcompris-7.4-6.fc6 gnumeric-1.6.3-1.fc6 goffice-0.2.1-1.fc6 hddtemp-0.3-0.8.beta15.fc6 libgda-1.9.100-5.fc6 libgnomedb-1.9.100-7.fc6 openct-0.6.7-1.fc6 opensc-0.11.0-1.fc6 raidem-music-1.0-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From ville.skytta at iki.fi Sat May 6 11:58:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 06 May 2006 14:58:33 +0300 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: <1146847909.19738.62.camel@laurel.intra.city-fan.org> References: <44548AA3.3020406@soeterbroek.com> <20060430181347.3be9fbbd.bugs.michael@gmx.net> <20060505100420.a5d06dd2.bugs.michael@gmx.net> <1146838930.19738.54.camel@laurel.intra.city-fan.org> <1146847909.19738.62.camel@laurel.intra.city-fan.org> Message-ID: <1146916713.5802.272.camel@localhost.localdomain> On Fri, 2006-05-05 at 17:51 +0100, Paul Howarth wrote: > On Fri, 2006-05-05 at 10:12 -0500, Jason L Tibbitts III wrote: > > >>>>> "PH" == Paul Howarth writes: > > > > PH> Try fedora-extract from fedora-rpmdevtools. > > > > At least for extracting RPMs, it doesn't seem much different from > > rpm2cpio|cpio -mumble, or am I missing something? > > > > Even if it just does that, I'd probably use it just so I don't have to > > read the cpio manpage again. > > That's why I use it :-) Another reason to use it instead of rpm2cpio | cpio is that it extracts into a subdir instead of dumping stuff into $PWD. Of course, whether that's actually desirable depends on the case. From andy at smile.org.ua Sat May 6 12:18:18 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 06 May 2006 15:18:18 +0300 Subject: evince [was: Re: evince, pdf and two side printing] In-Reply-To: <645d17210605021327i7e635a8bn803fd29b9c21f9b5@mail.gmail.com> References: <645d17210605021327i7e635a8bn803fd29b9c21f9b5@mail.gmail.com> Message-ID: <445C940A.1080302@smile.org.ua> Jonathan Underwood ?????: > Kevac - I think you have the wrong list, you should ask these sorts of > questions on fedora-list. For this moment, what about core packages where their functionality may be expanded with FE? I mean FE repo contains djvulibre and evince can reviews the djvu books. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From giallu at gmail.com Sat May 6 15:36:05 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 6 May 2006 17:36:05 +0200 Subject: QSA (Qt Script for Applications) Message-ID: I would like to have this package in extras (it's a requirement for another one I would be interested in), so tried to start packaging it for an eventual submission. The first problem I have is that it builds and arun a program which checks for the kind of applicable license (it's dual licensed like Qt) and fails because it looks for a LICENSE.GPL in $QTDIR. Do you think I should patch the sources to avoid the check and force GPL mode? thanks Gianluca From tibbs at math.uh.edu Sat May 6 16:12:50 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 06 May 2006 11:12:50 -0500 Subject: QSA (Qt Script for Applications) In-Reply-To: (Gianluca Sforna's message of "Sat, 6 May 2006 17:36:05 +0200") References: Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> Do you think I should patch the sources to avoid the check and GS> force GPL mode? If you wanted to preserve the spirit of the check, you could patch it to look under /usr/share/doc, but that assumes that the buildsystem won't one day stop installing docfiles (which would make sense). I would just patch out the check, but document what you're doing clearly in the specfile. - J< From dwmw2 at infradead.org Sun May 7 00:02:41 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 07 May 2006 01:02:41 +0100 Subject: Fedora Extras 5 Package Build Report In-Reply-To: References: <20060502185713.33277152160@buildsys.fedoraproject.org> <1146878932.2503.38.camel@shinybook.infradead.org> Message-ID: <1146960161.2503.143.camel@shinybook.infradead.org> On Sat, 2006-05-06 at 02:10 -0500, Jason L Tibbitts III wrote: > DW> Why don't I see these yet when I update? How long should it take > DW> to hit the mirrors? > > I show them arriving at my local mirror on May 2nd (along with > exim-mon and exim-sa). What mirror are you looking at that doesn't > have them? I still don't see them. I ran 'yum --downloadonly' once and it saw them and seemed to download them... but then on the next run it downloaded the metadata again, and then on that and 20 or so subsequent runs it didn't even see the the new packages. The mirrors seem mostly out of sync... --00:54:47-- http://download.fedora.redhat.com/pub/fedora/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm 00:54:48 (79.80 KB/s) - `exim-sa-4.62-2.fc5.ppc.rpm' saved [56806/56806] --00:54:48-- http://mirror.linux.duke.edu/pub/fedora/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm 00:54:50 (46.06 KB/s) - `exim-sa-4.62-2.fc5.ppc.rpm.1' saved [56806/56806] --00:54:50-- http://mirror.hiwaay.net/redhat/fedora/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm 00:54:51 (101.90 KB/s) - `exim-sa-4.62-2.fc5.ppc.rpm.2' saved [56806/56806] --00:54:51-- ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm No such file `exim-sa-4.62-2.fc5.ppc.rpm'. --00:54:53-- http://www.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm 00:54:54 ERROR 404: Not Found. --00:54:54-- http://mirror.clarkson.edu/pub/distributions/fedora/linux/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm 00:54:55 ERROR 404: Not Found. --00:54:55-- ftp://fedora.mirrors.tds.net/pub/fedora-core-extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm No such file `exim-sa-4.62-2.fc5.ppc.rpm'. --00:54:56-- ftp://fedora.bu.edu/fedora/extras/5/ppc/exim-sa-4.62-2.fc5.ppc.rpm => `exim-sa-4.62-2.fc5.ppc.rpm.3' No such directory `fedora/extras/5/ppc'. -- dwmw2 From tibbs at math.uh.edu Sun May 7 02:37:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 06 May 2006 21:37:45 -0500 Subject: Fedora Extras 5 Package Build Report In-Reply-To: <1146960161.2503.143.camel@shinybook.infradead.org> (David Woodhouse's message of "Sun, 07 May 2006 01:02:41 +0100") References: <20060502185713.33277152160@buildsys.fedoraproject.org> <1146878932.2503.38.camel@shinybook.infradead.org> <1146960161.2503.143.camel@shinybook.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> I still don't see them. I ran 'yum --downloadonly' once and it saw DW> them and seemed to download them... but then on the next run it DW> downloaded the metadata again, and then on that and 20 or so DW> subsequent runs it didn't even see the the new packages. Now that you mention it, I'm seeing packages that have made it to the mirror but aren't showing up in the repo. For example, mftrace-1.1.19-3.fc5.x86_64.rpm is dated 2006-05-04 17:31 but the repodata is dated 2006-05-04 01:34. This doesn't explain your exim problem but it illustrates that something's up. Perhaps someone could force the repodata to be regenerated and mirrored out? - J< From bugs.michael at gmx.net Sun May 7 11:59:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 7 May 2006 13:59:42 +0200 Subject: Fedora Extras 5 Package Build Report In-Reply-To: References: <20060502185713.33277152160@buildsys.fedoraproject.org> <1146878932.2503.38.camel@shinybook.infradead.org> <1146960161.2503.143.camel@shinybook.infradead.org> Message-ID: <20060507135942.ab620b84.bugs.michael@gmx.net> On Sat, 06 May 2006 21:37:45 -0500, Jason L Tibbitts III wrote: > >>>>> "DW" == David Woodhouse writes: > > DW> I still don't see them. I ran 'yum --downloadonly' once and it saw > DW> them and seemed to download them... but then on the next run it > DW> downloaded the metadata again, and then on that and 20 or so > DW> subsequent runs it didn't even see the the new packages. > > Now that you mention it, I'm seeing packages that have made it to the > mirror but aren't showing up in the repo. For example, > mftrace-1.1.19-3.fc5.x86_64.rpm is dated 2006-05-04 17:31 but the > repodata is dated 2006-05-04 01:34. This doesn't explain your exim > problem but it illustrates that something's up. > > Perhaps someone could force the repodata to be regenerated and > mirrored out? The extras_signers are currently waiting for somebody with more privileges to fix the ownership of several files and directories. Until then, repodata cannot be recreated unfortunately. From skvidal at linux.duke.edu Sun May 7 13:14:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 07 May 2006 09:14:29 -0400 Subject: Fedora Extras 5 Package Build Report In-Reply-To: <20060507135942.ab620b84.bugs.michael@gmx.net> References: <20060502185713.33277152160@buildsys.fedoraproject.org> <1146878932.2503.38.camel@shinybook.infradead.org> <1146960161.2503.143.camel@shinybook.infradead.org> <20060507135942.ab620b84.bugs.michael@gmx.net> Message-ID: <1147007669.1963.2.camel@cutter> On Sun, 2006-05-07 at 13:59 +0200, Michael Schwendt wrote: > On Sat, 06 May 2006 21:37:45 -0500, Jason L Tibbitts III wrote: > > > >>>>> "DW" == David Woodhouse writes: > > > > DW> I still don't see them. I ran 'yum --downloadonly' once and it saw > > DW> them and seemed to download them... but then on the next run it > > DW> downloaded the metadata again, and then on that and 20 or so > > DW> subsequent runs it didn't even see the the new packages. > > > > Now that you mention it, I'm seeing packages that have made it to the > > mirror but aren't showing up in the repo. For example, > > mftrace-1.1.19-3.fc5.x86_64.rpm is dated 2006-05-04 17:31 but the > > repodata is dated 2006-05-04 01:34. This doesn't explain your exim > > problem but it illustrates that something's up. > > > > Perhaps someone could force the repodata to be regenerated and > > mirrored out? > > The extras_signers are currently waiting for somebody with more privileges > to fix the ownership of several files and directories. Until then, > repodata cannot be recreated unfortunately. fixed. -sv From buildsys at fedoraproject.org Sun May 7 14:00:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 10:00:49 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060507140049.A12A1152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 6 SOAPpy-0.11.6-3.fc4 perl-Log-Message-0.01-1.fc4 perl-Log-Message-Simple-0.01-1.fc4 perl-Term-UI-0.12-1.fc4 spamass-milter-0.3.1-2.fc4 syslog-ng-1.6.11-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 7 14:00:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 10:00:44 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060507140044.3DEA9152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 spamass-milter-0.3.1-2.fc3 syslog-ng-1.6.11-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 7 14:01:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 10:01:43 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060507140143.6BF06152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 12 SOAPpy-0.11.6-3.fc5 arc-5.21o-2.fc5 gcl-2.6.7-11.fc5 gcompris-7.4-8.fc5 perl-Log-Message-0.01-1.fc5 perl-Log-Message-Simple-0.01-1.fc5 perl-Term-UI-0.12-1.fc5 pipenightdreams-0.10.0-3.fc5 rssowl-1.2.1-1.fc5 spamass-milter-0.3.1-2.fc5 syslog-ng-1.6.11-1.fc5 yum-utils-0.6-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 7 14:03:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 10:03:59 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060507140359.4178D152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 51 PyX-0.8.1-4.fc6 SOAPpy-0.11.6-3.fc6 arc-5.21o-2.fc6 awstats-6.6-0.1.beta.fc6 cpanspec-1.65-2.fc6 ctapi-common-1.0-2.fc6 gcl-2.6.7-11.fc6 gcompris-7.4-7.fc6 gcompris-7.4-8.fc6 gnome-ppp-0.3.23-1.fc6 liferea-1.0.11-3.fc6 netpanzer-0.8-3.fc6 netpanzer-data-0.8-3 openct-0.6.7-2.fc6 pan-0.96-1.fc6 perl-CPANPLUS-0.061-2.fc6 perl-Graphics-ColorNames-1.06-1.fc6 perl-Module-Info-0.30-2.fc6 perl-Test-Differences-0.47-1.fc6 perl-Test-Prereq-1.030-1.fc6 pipenightdreams-0.10.0-3.fc6 rapidsvn-0.9.1-3.fc6 spamass-milter-0.3.1-2.fc6 syslog-ng-1.6.11-1.fc6 wifiroamd-1.06-1.fc6 xfce4-battery-plugin-0.3.0-6.fc6 xfce4-clipman-plugin-0.4.1-6.fc6 xfce4-cpugraph-plugin-0.2.2-6.fc6 xfce4-datetime-plugin-0.3.1-7.fc6 xfce4-diskperf-plugin-1.5-6.fc6 xfce4-fsguard-plugin-0.2.1-4.fc6 xfce4-genmon-plugin-1.1-6.fc6 xfce4-mailwatch-plugin-1.0.0-2.fc6 xfce4-minicmd-plugin-0.3.0-6.fc6 xfce4-modemlights-plugin-0.1.1-7.fc6 xfce4-mount-plugin-0.3.3-3.fc6 xfce4-netload-plugin-0.3.3-6.fc6 xfce4-notes-plugin-0.11.1-4.fc6 xfce4-quicklauncher-plugin-0.81-4.fc6 xfce4-screenshooter-plugin-0.0.8-3.fc6 xfce4-sensors-plugin-0.7.0-5.fc6 xfce4-showdesktop-plugin-0.4.0-6.fc6 xfce4-systemload-plugin-0.3.6-6.fc6 xfce4-taskbar-plugin-0.2.2-6.fc6 xfce4-wavelan-plugin-0.4.1-6.fc6 xfce4-websearch-plugin-0.1.0-6.fc6 xfce4-windowlist-plugin-0.1.0-6.fc6 xfce4-xkb-plugin-0.3.5-2.fc6 xfce4-xmms-plugin-0.3.1-6.fc6 yum-utils-0.6-1.fc6 yum-utils-0.6-2.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Sun May 7 15:06:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 07 May 2006 17:06:48 +0200 Subject: Summary from the last FESCo meeting Message-ID: <1147014408.2312.0.camel@localhost.localdomain> == Summary == Present from FESCo: thl, f13, skvidal, jeremy, spot, scop, jpo * kernel modules * was removed from the schedule -- still needs some fine tuning, but works in general * I think this item is pretty much done, we just need some kmods reviewed and into the repo (or new maintainers for the thinkpad/lirc ones) * warren will poke around internally at redhat so GFS and Co are changed to the new standard * EOL / Security Team * we agreed to go forward with the plan proposed in https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html ; tibbs, bress and f13 will sure the information makes in into the wiki * FESCo future * there was some confusion if all FESCo seat in the planed election will be voted on; yes, a voting on a complete new FESCo this time (quoting spot:"it means something that the FESCO members are chosen by FE even if it ends up being the same people"). Maybe in the future we'll switch to a scheme where each election after each release of core will be on 50% of the seats. * only a small number of self-nominations where there until Thursday; as a result skvidal nominated some people from the old FESCo. They don't have a mission statement in the wiki page, but this is considered to be okay for existing FESCo members (it's probably also okay for non-existing FESCo members, but it probably nowers chances to be elected). * deadline is Sunday night (CET); but we have no system how to actualy do the election so the deadline is extended until we have a proper system. When it will be ready there is a 24 hour gap for last-minute nominations and another 24 hour gap until the actual voting begins (both things will be announced on fedora-extras-list) * the election will happen with a scheme "We have X FESCo seats and Y nominees for it. vote for X people" * would be nice if we could use the accounts system to manage the voting; jwb and spot are looking into that (help from python hackers appreciated) * Weekly sponsorship nomination * tibbs, Jason L Tibbitts III accepted * changes to the packaging/review guidelines * discussed and agreed on: * "Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered." * "If the packager needs a sponser, the reviewer must be capable of sponsoring to take ownership of the review. Other parties are welcome to make suggestions and add themselves to the CC of hte bug, but should not take ownership of the bug or the review." * free discussion * seems we need a better way to track and resolve legal issues == Full Log == [...] to big for this list -- see http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060504 -- Thorsten Leemhuis From mmcgrath at fedoraproject.org Sun May 7 17:32:03 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 7 May 2006 12:32:03 -0500 Subject: Packaging guidelines for web applications? Message-ID: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> Should we a different set of packing guidelines for web applications. At present there exists a directory: /var/www/ What exactly is supposed to be put in this directory if not web applications? Right now it seems that most web packages get installed in /usr/share/ This, however, seems a bit un-natural to me. After all if I were to install a php app on the machine from source I, and I suspect many others, would stick it in /var/www/packagename or /var/www/html/packagename I can't think of a single web-app that I've used that was designed with FHS in mind and it seems a bit odd that we have to rig all of our web apps with links and patches and things to get them to work in Fedora. Why don't we put all of our web content in /var/www/? After all /var/www/error/* and /var/www/icons/* are all things that seem like they should be in /usr/share/. -Mike From nicolas.mailhot at laposte.net Sun May 7 17:51:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 07 May 2006 19:51:45 +0200 Subject: Packaging guidelines for web applications? In-Reply-To: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> Message-ID: <1147024307.2959.11.camel@rousalka.dyndns.org> Le dimanche 07 mai 2006 ? 12:32 -0500, Mike McGrath a ?crit : > I can't think of a single web-app that I've used that was designed > with FHS in mind and it seems a bit odd that we have to rig all of our > web apps with links and patches and things to get them to work in > Fedora. If you think the FHS is arbitrary why, you're right. However if you believe like me the FHS is based on very carefully thought-of unix administration policies, there's absolutely no reason not to apply them to webapps. Sure, existing webapps make it hard. This does not reflect on FHS inadequacies IMHO, but more how many webapps are originally designed as sub-apps with no regard for i18n, HIG or in our case administration. Of course successful webapps have to bolt on this on later, and this includes the Fedora FHS packaging. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Sun May 7 18:07:50 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 07 May 2006 11:07:50 -0700 Subject: Packaging guidelines for web applications? In-Reply-To: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> Message-ID: <1147025270.8410.80.camel@atlantis.mpeters.local> On Sun, 2006-05-07 at 12:32 -0500, Mike McGrath wrote: > Should we a different set of packing guidelines for web applications. > At present there exists a directory: /var/www/ What exactly is > supposed to be put in this directory if not web applications? Right > now it seems that most web packages get installed in /usr/share/ > This, however, seems a bit un-natural to me. After all if I were to > install a php app on the machine from source I, and I suspect many > others, would stick it in /var/www/packagename or > /var/www/html/packagename The latter is certainly incorrect for an rpm install, because it puts things into what is suppose to be a DocumentRoot. The former I think is incorrect, in fact, I personally don't think /var/www should even exist. > > I can't think of a single web-app that I've used that was designed > with FHS in mind and it seems a bit odd that we have to rig all of our > web apps with links and patches and things to get them to work in > Fedora. > > Why don't we put all of our web content in /var/www/? After all > /var/www/error/* and /var/www/icons/* are all things that seem like > they should be in /usr/share/. non arch dependent Web applications belong in /usr/share. User created content intended to be served (except for nfs type serving) such as web content, ftp content, svn content, etc. imho belongs is /srv The benefit to this is that /srv can be a different partition/logical volume and preserved (not formatted) from install to install w/o also having to save stuff that doesn't need to be kept between installs (like /var/cache) The apache stuff in /var/www probably should be in /usr/share (except the default DocumentRoot root which IMHO should be in /srv/www/html ) The Fedora apache package imho does not conform to FHS guidelines. /var (in my mind anyway) is for files that can and do change by action of applications (cache files, log files, lock files, etc). But just because the core apache package does not conform to (what I perceive) as proper FHS guidelines does not mean that Extras packages can be lazy as well. Back in RH 5.x (and I think 6.x) web content by default was in /home/httpd. When that changed to /var/www (RH 7.x if I remember) it was a change for the better, I don't remember whether or not it was done for FHS guideline reasons or not. I'm guessing it will at some point change again to /srv/www/ (with the static rpm owned files going in /usr/share) You shouldn't need to patch anything to get it to work from /usr/share instead of /var/www - it should be done with a config file in /etc/httpd/conf.d/ Nothing should ever be put in the DocumentRoot directly via rpm. There should not be any RPMs owning any files within /var/www/html - doing so causes the web application to break the minute the user changes their DocumentRoot - which is a user configurable directive. What type of patching are you required to do for FHS guideline compliance? DISCLAIMER: Everything in my response is my opinion based upon my interpretation of the FHS guidelines and their intent, and not derived from an official Fedora / Extras guidelines. From mmcgrath at fedoraproject.org Sun May 7 18:26:39 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 7 May 2006 13:26:39 -0500 Subject: Packaging guidelines for web applications? In-Reply-To: <1147025270.8410.80.camel@atlantis.mpeters.local> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> <1147025270.8410.80.camel@atlantis.mpeters.local> Message-ID: <3237e4410605071126i238a945ds1be3ea0c36f8b9d2@mail.gmail.com> On 5/7/06, Michael A. Peters wrote: > The apache stuff in /var/www probably should be in /usr/share (except > the default DocumentRoot root which IMHO should be in /srv/www/html ) the whole /var/www/ thing has puzzled me as well. I think we should have a partitioned place for web applications. Perhaps just because I use a lot of web apps. /usr/share/www/packagename/ seems very reasonable to me. > You shouldn't need to patch anything to get it to work from /usr/share > instead of /var/www - it should be done with a config file > in /etc/httpd/conf.d/ I've run into issues with config files for the actual application which, according to FHS, should be in /etc. But the web apps don't like it when we just move stuff on 'em. And then if you have a web app that does polling and stores files those shouldn't be in /usr/share but in /var/something depending on the type of content. Some web apps also have their own logs. > What type of patching are you required to do for FHS guideline > compliance? Basically just letting apps know that they will be storing files (logs, config's, spools, cache, misc) in /var/whatever instead of a path relative to the app which its used to. -Mike From mpeters at mac.com Sun May 7 19:03:14 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 07 May 2006 12:03:14 -0700 Subject: Packaging guidelines for web applications? In-Reply-To: <3237e4410605071126i238a945ds1be3ea0c36f8b9d2@mail.gmail.com> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> <1147025270.8410.80.camel@atlantis.mpeters.local> <3237e4410605071126i238a945ds1be3ea0c36f8b9d2@mail.gmail.com> Message-ID: <1147028594.8410.105.camel@atlantis.mpeters.local> On Sun, 2006-05-07 at 13:26 -0500, Mike McGrath wrote: > On 5/7/06, Michael A. Peters wrote: > > > The apache stuff in /var/www probably should be in /usr/share (except > > the default DocumentRoot root which IMHO should be in /srv/www/html ) > > the whole /var/www/ thing has puzzled me as well. I think we should > have a partitioned place for web applications. Perhaps just because I > use a lot of web apps. /usr/share/www/packagename/ seems very > reasonable to me. That's not too unreasonable. I don't think it is necessary but I don't think it is objectionable. > > > You shouldn't need to patch anything to get it to work from /usr/share > > instead of /var/www - it should be done with a config file > > in /etc/httpd/conf.d/ > > I've run into issues with config files for the actual application > which, according to FHS, should be in /etc. But the web apps don't > like it when we just move stuff on 'em. And then if you have a web > app that does polling and stores files those shouldn't be in > /usr/share but in /var/something depending on the type of content. > Some web apps also have their own logs. Yes - those require patching though even if put in /var/www. Config files should never be in the web app root for security reasons. With php - I know you can make a php includes directory that php can see what apache can't. That's what I do for things like database passwords etc. The /var/something is important also for security reasons - especially with SELinux. > > > What type of patching are you required to do for FHS guideline > > compliance? > > Basically just letting apps know that they will be storing files > (logs, config's, spools, cache, misc) in /var/whatever instead of a > path relative to the app which its used to. Try to get those patches upstream, as upstream is broken in those cases. Where to put log files and cache etc. should be in the configuration file and not in the web app code itself. -=- I personally don't do a lot with web applications (I did in a former job) - but maybe we need a web app SIG to come to a consensus on how they should be done, and submit docs to FESCO for approval or rejection, so that people packaging them can have somewhere to look. From Jochen at herr-schmitt.de Sun May 7 19:58:21 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 07 May 2006 21:58:21 +0200 Subject: Trouble while uploading source to CVS Message-ID: <445E515D.4000503@herr-schmitt.de> Hello, during importing of lightning into cvs I have go the following error message: Checking : lightning-1.2.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status It will be nice, if anyone have a hint to solve this problem. Best Regards: Jochen Schmitt From skvidal at linux.duke.edu Sun May 7 20:09:20 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 07 May 2006 16:09:20 -0400 Subject: Trouble while uploading source to CVS In-Reply-To: <445E515D.4000503@herr-schmitt.de> References: <445E515D.4000503@herr-schmitt.de> Message-ID: <1147032560.4918.2.camel@cutter> On Sun, 2006-05-07 at 21:58 +0200, Jochen Schmitt wrote: > Hello, > > during importing of lightning into cvs I have go the following error > message: > > Checking : lightning-1.2.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > > It will be nice, if anyone have a hint to solve this problem. > download a new fedora cert from the accounts page. -sv From bugs.michael at gmx.net Sun May 7 20:18:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 07 May 2006 20:18:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-07 Message-ID: <20060507201822.7463.71968@rawhide.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Sun May 7 20:18:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 07 May 2006 20:18:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-07 Message-ID: <20060507201829.7472.40986@rawhide.intranet> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- netpanzer 0.8-3.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- netpanzer 0.8-3.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- netpanzer 0.8-3.fc5.x86_64 ====================================================================== New report for: hugo AT devin.com.br package: netpanzer - 0.8-3.fc5.i386 from fedora-extras-5-i386 unresolved deps: netpanzer-data = 0:0.8 package: netpanzer - 0.8-3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: netpanzer-data = 0:0.8 package: netpanzer - 0.8-3.fc5.ppc from fedora-extras-5-ppc unresolved deps: netpanzer-data = 0:0.8 From bugs.michael at gmx.net Sun May 7 20:18:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 07 May 2006 20:18:25 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-07 Message-ID: <20060507201825.7471.77807@rawhide.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- netpanzer 0.8-3.fc4.i386 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- netpanzer 0.8-3.fc4.ppc plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- netpanzer 0.8-3.fc4.x86_64 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: hugo AT devin.com.br package: netpanzer - 0.8-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: netpanzer-data = 0:0.8 package: netpanzer - 0.8-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: netpanzer-data = 0:0.8 package: netpanzer - 0.8-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: netpanzer-data = 0:0.8 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From bugs.michael at gmx.net Sun May 7 20:18:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 07 May 2006 20:18:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-07 Message-ID: <20060507201832.7473.9201@rawhide.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 galeon 2.0.1-1.fc5.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 sobby 0.3.0-2.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc galeon 2.0.1-1.fc5.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc sobby 0.3.0-2.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 galeon 2.0.1-1.fc5.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 sobby 0.3.0-2.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: sobby - 0.3.0-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: galeon - 2.0.1-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: mozilla = 37:1.7.12 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: galeon - 2.0.1-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: mozilla = 37:1.7.12 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: sobby - 0.3.0-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnet6-1.2.so.0()(64bit) libobby-0.3.so.0()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: galeon - 2.0.1-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: mozilla = 37:1.7.12 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: sobby - 0.3.0-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: libnet6-1.2.so.0 libobby-0.3.so.0 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 From Jochen at herr-schmitt.de Sun May 7 20:28:20 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 07 May 2006 22:28:20 +0200 Subject: Trouble with uploading sources to cvs Message-ID: <445E5864.5030401@herr-schmitt.de> Hello, I have the following problem, I am trying to upload the current source ball of stellarium into the cvs. Unfortunately I have got the following error message: $ make new-sources FILES="stellarium-0.8.0.tar.gz" Checking : stellarium-0.8.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Fehler 255 It will be nice, if anyone have a hint to solve this problem. Best Regards: Jochen Schmitt From nicolas.mailhot at laposte.net Sun May 7 20:42:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 07 May 2006 22:42:51 +0200 Subject: Packaging guidelines for web applications? In-Reply-To: <1147028594.8410.105.camel@atlantis.mpeters.local> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> <1147025270.8410.80.camel@atlantis.mpeters.local> <3237e4410605071126i238a945ds1be3ea0c36f8b9d2@mail.gmail.com> <1147028594.8410.105.camel@atlantis.mpeters.local> Message-ID: <1147034574.24334.7.camel@rousalka.dyndns.org> Le dimanche 07 mai 2006 ? 12:03 -0700, Michael A. Peters a ?crit : > On Sun, 2006-05-07 at 13:26 -0500, Mike McGrath wrote: > > On 5/7/06, Michael A. Peters wrote: > > > > > The apache stuff in /var/www probably should be in /usr/share (except > > > the default DocumentRoot root which IMHO should be in /srv/www/html ) > > > > the whole /var/www/ thing has puzzled me as well. It's just a better /home/httpd than the previous one, and is far worse than doing a proper FHS layout > I think we should > > have a partitioned place for web applications. Perhaps just because I > > use a lot of web apps. /usr/share/www/packagename/ seems very > > reasonable to me. > > That's not too unreasonable. As long as you're not doing a simple /home/httpd -> /var/www/ -> /usr/share/www/ The core of the problem is webapp authors choose monolithic filetree deployments for ease-of-development and ease-of-deployment reasons while the FHS mandates split trees for ease-of-administration reasons. And that all the infrastructure which makes pleasing admins not too hard for app authors is severily lacking for webapp authors. ... > personally don't do a lot with web applications (I did in a former > job) - but maybe we need a web app SIG to come to a consensus on how > they should be done, and submit docs to FESCO for approval or rejection, > so that people packaging them can have somewhere to look. You'll probably need more some kind of bottled argument for packagers to forward upstream. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bdpepple at ameritech.net Sun May 7 21:15:50 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 07 May 2006 17:15:50 -0400 Subject: Mono SIG Message-ID: <1147036550.8193.5.camel@shuttle.piedmont.com> I just created a sub page for the Mono SIG. http://fedoraproject.org/wiki/Extras/SIGs/Mono If you are interested in seeing more Mono packages in Extras, add yourself to the members list on the page and/or any packages you submit to FE. Hopefully, by actively reviewing each others mono packages this will shorten the time it takes to get mono packages approved and imported into Extras For more information on SIG's see http://fedoraproject.org/wiki/Extras/SIGs /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Sun May 7 22:01:05 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 08 May 2006 10:01:05 +1200 Subject: Orphan process. Message-ID: <445E6E21.1070609@knox.net.nz> OK, SO I am wondering how we orphan a package where the maintainer has gone AWOL? Take this email as an example: http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html Its now going on 3 weeks with no movement. (3 weeks seems a bit short, we all have lives :) ) So, what do people think should be a suitable timeframe for a package to have no response from its maintainer to be considered a orphan and not step on anyone's toes? Regards Michael From laurent.rineau__fc_extra at normalesup.org Sun May 7 22:34:36 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Mon, 8 May 2006 00:34:36 +0200 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <445A0E15.5080007@hhs.nl> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> <445A0E15.5080007@hhs.nl> Message-ID: <200605080034.36301@rineau.schtroumpfette> On Thursday 04 May 2006 16:22, Hans de Goede wrote: > No, blocking FE-NEEDSSPONSOR is correct untill you find a sponsor that > is. I might be willing to sponsor you, but you first need to prove > yourself somewhat more IMHO. Taking a spec file from Suse as a start is > ok but hen not removing the Packager: Suse tag is somewhat sloppy. Also > admitting that you use this tool for Legally gray area activities > doesn't help building trust. > > Have you done other opensource work, if so pointers please. Otherwise > opportunities to prove yourself are: > -doing some reviews. I did not know I could do reviews, while not being a packager. > -package some more software for example libpar and gpar from: > http://sourceforge.net/projects/parchive/ > Please add me to the CC field of the package review then I'll > review it for you and if all goes well sponsor you. I just submitted libpar2 (#190091) and gpar2 (#190092), and added you and Jason to the CC?fields (sorry for the spam: I should have added you to CC lists after having set up blockers and depends fields). I discovered that par2cmdline is no longer maintained. Its code has forked to libpar2, which is the base of gpar2. I'll try soon to make par2cmdline compile with the new libpar2, and submit it to upstream. However, I still maintain request #190071 for par2cmdline. This tool is the only command line tool for PAR2 files. Even if its code is obsolete, it still compile and run correctly (the upstream par2cmdline package has a test suite, while libpar2 package not longer has one). From mpeters at mac.com Sun May 7 22:51:33 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 07 May 2006 15:51:33 -0700 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <200605080034.36301@rineau.schtroumpfette> References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> <445A0E15.5080007@hhs.nl> <200605080034.36301@rineau.schtroumpfette> Message-ID: <1147042293.8410.136.camel@atlantis.mpeters.local> On Mon, 2006-05-08 at 00:34 +0200, Laurent Rineau wrote: > On Thursday 04 May 2006 16:22, Hans de Goede wrote: > > No, blocking FE-NEEDSSPONSOR is correct untill you find a sponsor that > > is. I might be willing to sponsor you, but you first need to prove > > yourself somewhat more IMHO. Taking a spec file from Suse as a start is > > ok but hen not removing the Packager: Suse tag is somewhat sloppy. Also > > admitting that you use this tool for Legally gray area activities > > doesn't help building trust. > > > > Have you done other opensource work, if so pointers please. Otherwise > > opportunities to prove yourself are: > > -doing some reviews. > > I did not know I could do reviews, while not being a packager. You can not approve packages, but you can comment on packages and point out what needs to be done better / fixed. From tibbs at math.uh.edu Sun May 7 23:14:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 07 May 2006 18:14:45 -0500 Subject: FE-ACCEPT when sponsor needed In-Reply-To: <200605080034.36301@rineau.schtroumpfette> (Laurent Rineau's message of "Mon, 8 May 2006 00:34:36 +0200") References: <1146747949.5627.13.camel@atlantis.mpeters.local> <200605041539.05599@rineau.schtroumpfette> <445A0E15.5080007@hhs.nl> <200605080034.36301@rineau.schtroumpfette> Message-ID: >>>>> "LR" == Laurent Rineau writes: LR> I just submitted libpar2 (#190091) and gpar2 (#190092), and added LR> you and Jason to the CC?fields (sorry for the spam: I should have LR> added you to CC lists after having set up blockers and depends LR> fields). I saw the messages. I also have sponsor status now, and seeing that you've submitted other packages I'd like to get this moving. But (and there's always one of those) the issue isn't making sure that the package is of quality (we know that it is) but that the submitter will be around to maintain the package. Obviously we can't tell what's going to happen in the future but we can look at the submitters community involvement. It sounds like you have long term plans for this package and the others, and you were quick to respond to comments during the review process, so I'll be happy to sponsor you. Go ahead and set up your account as documented in http://fedoraproject.org/wiki/Extras/Contributors - J< From buildsys at fedoraproject.org Mon May 8 00:33:25 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 20:33:25 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060508003325.6710D152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 nsd-2.3.4-5.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 8 00:33:25 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 20:33:25 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060508003325.F2B90152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 13 awstats-6.5-2.fc4 ctapi-common-1.0-2.fc4 gnome-ppp-0.3.23-1.fc4 lua-5.1-2.fc4 mtd-utils-1.0.0-2.fc4 nsd-2.3.4-4.fc4 perl-CPANPLUS-0.061-2.fc4 perl-DBD-XBase-0.241-4.fc4 perl-Graphics-ColorNames-1.06-1.fc4 perl-Module-Info-0.30-2.fc4 perl-Test-Differences-0.47-1.fc4 perl-Test-Prereq-1.030-1.fc4 stratagus-2.1-6.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 8 00:33:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 20:33:26 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060508003326.D4EF7152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 17 awstats-6.5-4.fc5 bakery-2.4.0-1.fc5 ctapi-common-1.0-2.fc5 gnome-ppp-0.3.23-1.fc5 hddtemp-0.3-0.8.beta15.fc5 lua-5.1-2.fc5 mtd-utils-1.0.0-2.fc5 openct-0.6.7-2.fc5 opensc-0.11.0-2.fc5 perl-CPANPLUS-0.061-2.fc5 perl-DBD-XBase-0.241-4.fc5 perl-Graphics-ColorNames-1.06-1.fc5 perl-Module-Info-0.30-2.fc5 perl-Test-Differences-0.47-1.fc5 perl-Test-Prereq-1.030-1.fc5 raptor-1.4.9-2.fc5 stratagus-2.1-6.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 8 00:33:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 May 2006 20:33:34 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060508003334.0081B15216A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 10 bakery-2.4.0-1.fc6 galeon-2.0.1-4.fc6 lua-5.1-2.fc6 mtd-utils-1.0.0-2.fc6 nsd-2.3.4-3.fc6 opensc-0.11.0-2.fc6 perl-Module-ScanDeps-0.59-2.fc6 raptor-1.4.9-2.fc6 sobby-0.4.0-2.rc1.fc6 xemacs-21.5.26-5.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From mike at flyn.org Mon May 8 02:05:38 2006 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 7 May 2006 21:05:38 -0500 (CDT) Subject: Pitivi package will not build using plague Message-ID: <58215.63.13.191.109.1147053938.squirrel@zero.voxel.net> I am having trouble building the latest pitivi package on Fedora Rawhide using plague. The build log is available at: http://buildsys.fedoraproject.org/logs/fedora-development-extras/9022-pitivi-0.10.0-3/noarch/build.log The interesting part states: checking for gnonlin >= 0.10.2... ./configure: line 2641: 25551 Illegal instruction $PYTHON -c "$prog" 1>&5 2>&5 not found configure: error: You need to install the gnonlin plugins and make sure they are in your $GST_PLUGIN_PATH. The package BuildRequires gnonlin. The package builds using "make i386" on x86 and in mock on PowerPC. Does anyone know what could be causing this build failure? -- Mike From michael at knox.net.nz Mon May 8 04:38:26 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 08 May 2006 16:38:26 +1200 Subject: Package reviews. Message-ID: <445ECB42.5000809@knox.net.nz> People doing the reviews and/or wanting a review. Please remember to close the package review once the package has been imported and built! I have closed some today, even found one that has been needing closing since Sept 05 !! Lets keep not bog bugzilla down with unneeded open tickets - please :) Thanks! Michael From paul at all-the-johnsons.co.uk Mon May 8 10:36:55 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 08 May 2006 11:36:55 +0100 Subject: Mock problem Message-ID: <1147084615.14565.13.camel@mrwibble.mrwobble> Hi, I'm trying to build boo via mock and have hit a problem which I'm not sure where things are going wrong with. If I build the rpm using rpmbuild, shared-mime-info prefix (as reported by the configure script) is /usr - this is correct. When I run it through mock, nothing is defined for this prefix and it's causing the build to fail. I have shared-mime-info installed and nothing else is failing on the build (all deps are met). Any ideas if this is a mock thing or the package being broken? It's not an selinux problem as I've not got selinux running on the box. The system the package is being built on is a bog standard x86 with FC5 on (and updated nightly) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Mon May 8 11:40:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 08 May 2006 06:40:13 -0500 Subject: Mock problem In-Reply-To: <1147084615.14565.13.camel@mrwibble.mrwobble> References: <1147084615.14565.13.camel@mrwibble.mrwobble> Message-ID: PFJ wrote: > Hi, > > I'm trying to build boo via mock and have hit a problem which I'm not > sure where things are going wrong with. > > If I build the rpm using rpmbuild, shared-mime-info prefix (as reported > by the configure script) is /usr - this is correct. When I run it > through mock, nothing is defined for this prefix and it's causing the > build to fail. > > I have shared-mime-info installed and nothing else is failing on the > build (all deps are met). Most likely, not all the deps are truly being met. The only way to know for sure, is to actually look at the configure script to see how it determines the shared-mime-info prefix. -- Rex From paul at all-the-johnsons.co.uk Mon May 8 12:06:34 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 08 May 2006 13:06:34 +0100 Subject: Mock problem In-Reply-To: References: <1147084615.14565.13.camel@mrwibble.mrwobble> Message-ID: <1147089994.14565.27.camel@mrwibble.mrwobble> Hi, > > I have shared-mime-info installed and nothing else is failing on the > > build (all deps are met). > > Most likely, not all the deps are truly being met. The only way to know > for sure, is to actually look at the configure script to see how it > determines the shared-mime-info prefix. According to the script... Extract the first word of "pkg-config" so it can be a program name with args set dummy pkg-config; ac_word=$2 if test "${ac_cv_path_PKG_CONFIG+set}" = set; then echo else case $PKG_CONFIG in [\\/]* | ?:[\\/]*) ac_cv_path_PKG_CONFIG="$PKG_CONFIG" # let the user overide the test with a path ;; *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR for as_dir in $PATH do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext" break 2 fi done done test -z "$ac_cv_path_PKG_CONFIG" && ac_cv_path_PKG_CONFIG="no" ;; esac fi PKG_CONFIG=$ac_cv_path_PKG_CONFIG MIME_PREFIX=`$PKG_CONFIG --variable=prefix shared-mime-info` GTKSOURCEVIEW_PREFIX=`$PKG_CONFIG --variable=prefix gtksourceview-1.0` I have gtksourceview and shared-mime-info in my Requires within the spec file. There doesn't seem to be anything out of the ordinary in the configure file either (as the above shows) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dtimms at bigpond.net.au Mon May 8 14:34:50 2006 From: dtimms at bigpond.net.au (David Timms) Date: Tue, 09 May 2006 00:34:50 +1000 Subject: Adding a new mirror to the Extras mirror list Message-ID: <445F570A.4040706@bigpond.net.au> How would one go about getting a new mirror added to the mirrorlist: http://fedora.redhat.com/download/mirrors/fedora-extras-5 ? Recently, my local mirror has begin rsyncing extras, I also noticed that there are many more mirrors listed that could be added to the yum accessible list - after checking they are OK ? http://fedoraproject.org/wiki/Extras/Mirrors DaveT. From katzj at redhat.com Mon May 8 14:37:36 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 May 2006 10:37:36 -0400 Subject: Mock problem In-Reply-To: <1147089994.14565.27.camel@mrwibble.mrwobble> References: <1147084615.14565.13.camel@mrwibble.mrwobble> <1147089994.14565.27.camel@mrwibble.mrwobble> Message-ID: <1147099056.981.6.camel@orodruin.boston.redhat.com> On Mon, 2006-05-08 at 13:06 +0100, PFJ wrote: > MIME_PREFIX=`$PKG_CONFIG --variable=prefix shared-mime-info` > GTKSOURCEVIEW_PREFIX=`$PKG_CONFIG --variable=prefix gtksourceview-1.0` > > I have gtksourceview and shared-mime-info in my Requires within the spec > file. (dumb obvious question) Do you have gtksourceview listed or gtksourceview-devel? And as BuildRequires, not Requires. Jeremy From paul at all-the-johnsons.co.uk Mon May 8 14:39:23 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 08 May 2006 15:39:23 +0100 Subject: Mock problem In-Reply-To: <1147099056.981.6.camel@orodruin.boston.redhat.com> References: <1147084615.14565.13.camel@mrwibble.mrwobble> <1147089994.14565.27.camel@mrwibble.mrwobble> <1147099056.981.6.camel@orodruin.boston.redhat.com> Message-ID: <1147099163.14565.44.camel@mrwibble.mrwobble> Hi, On Mon, 2006-05-08 at 10:37 -0400, Jeremy Katz wrote: > Do you have gtksourceview listed or gtksourceview-devel? And as > BuildRequires, not Requires. No question is ever dumb! BR : gtksourceview-devel R : gtksourceview TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From jdennis at redhat.com Mon May 8 15:47:00 2006 From: jdennis at redhat.com (John Dennis) Date: Mon, 08 May 2006 11:47:00 -0400 Subject: Packaging guidelines for web applications? In-Reply-To: <1147034574.24334.7.camel@rousalka.dyndns.org> References: <3237e4410605071032t608ac31dj31f09ba72fa99ee7@mail.gmail.com> <1147025270.8410.80.camel@atlantis.mpeters.local> <3237e4410605071126i238a945ds1be3ea0c36f8b9d2@mail.gmail.com> <1147028594.8410.105.camel@atlantis.mpeters.local> <1147034574.24334.7.camel@rousalka.dyndns.org> Message-ID: <1147103220.3001.68.camel@finch.boston.redhat.com> On Sun, 2006-05-07 at 22:42 +0200, Nicolas Mailhot wrote: > The core of the problem is webapp authors choose monolithic filetree > deployments for ease-of-development and ease-of-deployment reasons while > the FHS mandates split trees for ease-of-administration reasons. And > that all the infrastructure which makes pleasing admins not too hard for > app authors is severily lacking for webapp authors. Having packaged a number of webapps and previously researched a number of these issues here are my working guidelines as of the moment (subject to change on a whim :-) * It's the job of the packager to split the webapp into separate installation locations based on FHS and existing Fedora conventions. This should be done via some type of parametrization, (e.g. adding options to the autotool configure script). Those installation parameters should default to match upstream but are overridden in the rpm spec file. Those changes need to be submitted upstream, but because everything defaults to match upstream there should be little resistance to accepting the patch. * The current convention of /var/www is probably broken, but the pain of changing it is probably not worth it. * Install the webapp "code" into /var/www/ (or /usr/lib/), config files into /etc/, temporary files created by the webapp belong in /var/cache/ * Provide a /etc/httpd/conf.d/.conf file which configures the webapp for use with the Fedora conventions. (e.g. providing ScriptAlias, modrewrite rules to map URL's to installation location, etc.) * Absolutely nothing should install into the docroot. * Not following existing Fedora conventions will play havoc with SELinux which will cause much pain :-) Note: I've studied FHS a number of times trying to make sure I follow the guidelines and its clear to me that FHS is often ambiguous, or rather that reasonable people could reasonably apply the FHS guidelines differently but be compliant. Therefore don't get too hung up on FHS, try to follow the spirit and when uncertain look for existing precedent in Fedora. -- John Dennis Red Hat Inc. From toshio at tiki-lounge.com Mon May 8 15:57:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 08 May 2006 08:57:20 -0700 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: <44548AA3.3020406@soeterbroek.com> References: <44548AA3.3020406@soeterbroek.com> Message-ID: <1147103840.3174.17.camel@localhost> On Sun, 2006-04-30 at 12:00 +0200, Joost Soeterbroek wrote: > %changelog > * Thu Apr 27 2006 Joost Soeterbroek - 2.0.5-1 > - upstream version 2.0.5 > - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer > set in cts/CM_LinuxHAv2.py.in > + Version 2.0.5 - significant bug fixes and a few feature deficits fixed > + various portability fixes > + enable GUI to run with pygtk 2.4 > + significant GUI improvements and speedups > Many ChangeLogs are logs of what has changed in every cvs checkin. That is of little use in a spec file's ChangeLog. What you have here is a summary of changes which is more what I think of in a traditional NEWS file. This seems within the realm of reason. However, even here somethings are extraneous: "various portability fixes" -- If it's architecture portability we care, if it's OS portability it's better off in the ChangeLog file. "enable GUI to run with pygtk 2.4" -- We don't really care what pygtk version upstream has ported to. We care what versions of Core the heartbeat package runs on. The package maintainer could have added patches to make it work with a different pygtk version. Core could have a version of pygtk on which heartbeat worked before these changes. Summary: duplicating information into the spec ChangeLog that fit better in a different file makes little sense. This argues that a packager can list the major features that upstream has implemented (and fixes to bugs that are in bugzilla.redhat.com) but they should consider what they are adding to the spec file. Even summaries of features as seen in the NEWS file can contain information not relevant to the consumers of pre-packaged binaries. Sidenote: Organizationally, I'd put the upstream changes under the note about upstream version:: - upstream version 2.0.5 + significant bug fixes and a few feature deficits fixed + various portability fixes - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer set in cts/CM_LinuxHAv2.py.in -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 hugo at devin.com.br Mon May 8 16:41:57 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Mon, 08 May 2006 13:41:57 -0300 Subject: Adding a new mirror to the Extras mirror list In-Reply-To: <445F570A.4040706@bigpond.net.au> References: <445F570A.4040706@bigpond.net.au> Message-ID: <445F74D5.1010902@devin.com.br> David Timms wrote: > How would one go about getting a new mirror added to the mirrorlist: > http://fedora.redhat.com/download/mirrors/fedora-extras-5 ? > > Recently, my local mirror has begin rsyncing extras, I also noticed that > there are many more mirrors listed that could be added to the yum > accessible list - after checking they are OK ? > http://fedoraproject.org/wiki/Extras/Mirrors The mirror admin could be reached on mirror-admin at fedoraproject.org. I'll check your mirror and include if it's ok. I'll send a private email shortly about this to you. > DaveT. -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From jpo at lsd.di.uminho.pt Mon May 8 17:26:42 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 08 May 2006 18:26:42 +0100 Subject: Package reviews (suggestion) In-Reply-To: <445ECB42.5000809@knox.net.nz> References: <445ECB42.5000809@knox.net.nz> Message-ID: <445F7F52.7080400@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, > People doing the reviews and/or wanting a review. > > Please remember to close the package review once the package has been > imported and built! I have closed some today, even found one that has > been needing closing since Sept 05 !! Next time please ask the maintainer/reviewers to close them first (and give them a couple of days to act on them). At least two of the tickets you have closed were open by a reason: - still waiting for the FC-4 and FC-5 CVS branches to be created (some of us only close the review ticket after the package has been pushed for all distro versions). - waiting for the maintainer to acknowledge a late suggestion and build the package for FC-4 and FC-5. Regards, jpo PS - It is much easier to look for the opened tickets in the bugzilla personal bug list than to track closed bugs ids in the mail. - -- 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEX39Sl0metZG9hRsRAtnaAJ9NPhpmAUm8NV0+n4bUS8M9aQBj5ACg8JhF 7QDLaFhThH9pILigizkjR6I= =vMhN -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From orion at cora.nwra.com Mon May 8 17:50:09 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 May 2006 11:50:09 -0600 Subject: Pitivi package will not build using plague In-Reply-To: <58215.63.13.191.109.1147053938.squirrel@zero.voxel.net> References: <58215.63.13.191.109.1147053938.squirrel@zero.voxel.net> Message-ID: <445F84D1.7020307@cora.nwra.com> W. Michael Petullo wrote: > I am having trouble building the latest pitivi package on Fedora Rawhide > using plague. > > The build log is available at: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/9022-pitivi-0.10.0-3/noarch/build.log > > The interesting part states: > > checking for gnonlin >= 0.10.2... ./configure: line 2641: 25551 Illegal > instruction $PYTHON -c "$prog" 1>&5 2>&5 > not found > configure: error: You need to install the gnonlin plugins and make sure > they are in your $GST_PLUGIN_PATH. My guess would be a gcc/glibc issue for PPC with the latest rawhide that's generating a bad python binary (or perhaps a gnonlin binary). You might look for open bugs or check fedora-devel/-testers for posts. What is $prog above? Try running the test in gdb to see where it crashes. You might wait a day or two for rawhide to magically fix it. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon May 8 17:51:51 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 May 2006 11:51:51 -0600 Subject: Pitivi package will not build using plague In-Reply-To: <58215.63.13.191.109.1147053938.squirrel@zero.voxel.net> References: <58215.63.13.191.109.1147053938.squirrel@zero.voxel.net> Message-ID: <445F8537.7090206@cora.nwra.com> W. Michael Petullo wrote: > I am having trouble building the latest pitivi package on Fedora Rawhide > using plague. > > The build log is available at: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/9022-pitivi-0.10.0-3/noarch/build.log > > The interesting part states: > > checking for gnonlin >= 0.10.2... ./configure: line 2641: 25551 Illegal > instruction $PYTHON -c "$prog" 1>&5 2>&5 > not found > configure: error: You need to install the gnonlin plugins and make sure > they are in your $GST_PLUGIN_PATH. > > The package BuildRequires gnonlin. > > The package builds using "make i386" on x86 and in mock on PowerPC. > > Does anyone know what could be causing this build failure? > > -- > Mike > This might be related too: Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- ... gnonlin-devel 0.10.0.5-6.i386 -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From gauret at free.fr Mon May 8 20:10:28 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 08 May 2006 22:10:28 +0200 Subject: weekly "new pacakges in Extras" (Was: Fedora Package Announcement List Split) References: <1146124978.16095.15.camel@thl.ct.heise.de> <200604271202.k3RC26Jq008968@ludwig-alpha.unil.ch> <1146141362.12671.33.camel@cutter> Message-ID: Aurelien Bompard wrote: > My idea would be to diff the owners.list and to create a repodata folder > with the usual info, but about new packages only. Then the other > repodata-aware tools would be available, including repo-rss and repoview > (which already does groups). And the only thing left to do is to write a > mail sender script which uses the repodata. I've written some scripts about this: - fedora-extras-newest.py outputs on stdout a list of recently added packages (in extras). It uses owners.list from CVS to do so. - repogrep.py takes one repo metadata and keeps only the packages given on the command line. It creates a repodata dir with the usual metadata, and no actual rpm in it (only the metadata). Here's a way to use those scripts : ./fedora-extras-newest.py | xargs ./repogrep.py And that will create an extras dir with a repodata subdir, with only the selected packages. Then, we can run the other repo scripts on it, like repo-rss and repoview, which generate interesting output. I've submitted today a patch to add groups support (as in comps.xml) to repo-rss, so if it is included it will be very easy to create separate feeds for new packages in a category. See bug 191061. What's left to do is a script which sends the email reminder. Should be pretty easy. It should not be too buggy, please try that and tell me if there are things to change. Aur?lien PS: the only reference implementation of metadata creation is in createrepo, right ? It would be nice to have a proper python module (in /usr/lib/python2.*/site-packages/repomd for this task in the future...) -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-extras-newest.py Type: application/x-python Size: 2914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: repogrep.py Type: application/x-python Size: 7758 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon May 8 20:41:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 08 May 2006 16:41:19 -0400 Subject: weekly "new pacakges in Extras" (Was: Fedora Package Announcement List Split) In-Reply-To: References: <1146124978.16095.15.camel@thl.ct.heise.de> <200604271202.k3RC26Jq008968@ludwig-alpha.unil.ch> <1146141362.12671.33.camel@cutter> Message-ID: <1147120880.1951.65.camel@cutter> On Mon, 2006-05-08 at 22:10 +0200, Aurelien Bompard wrote: > Aurelien Bompard wrote: > > My idea would be to diff the owners.list and to create a repodata folder > > with the usual info, but about new packages only. Then the other > > repodata-aware tools would be available, including repo-rss and repoview > > (which already does groups). And the only thing left to do is to write a > > mail sender script which uses the repodata. > > I've written some scripts about this: > - fedora-extras-newest.py outputs on stdout a list of recently added > packages (in extras). It uses owners.list from CVS to do so. > - repogrep.py takes one repo metadata and keeps only the packages given on > the command line. It creates a repodata dir with the usual metadata, and no > actual rpm in it (only the metadata). why is this useful? Why not just add support for a list of pkg names/globs to repo-rss and cut out the middle man? Alternatively why don't we take a step back and make a list of all the features we want and write one tool that'll handle all of those items w/o lots of intermediate steps. I'll start with the feature set: 1. new packages to extras - including owners.list knowledge 2. rss feed of the new packages 3. rss feed of the new packages per-comps.xml-based group what else? -sv From green at redhat.com Mon May 8 21:16:53 2006 From: green at redhat.com (Anthony Green) Date: Mon, 08 May 2006 14:16:53 -0700 Subject: package naming question: muse -vs - MusE Message-ID: <1147123014.2910.248.camel@localhost.localdomain> There are some discussions about merging parts of PlanetCCRMA into Fedora Extras. One of the problems has to do with package namespace conflicts. For instance, PlanetCCRMA has had a "muse" package for many years (http://www.muse-sequencer.org). But now FE has an emacs extension package called "muse". So, assuming the emacs extension package can't be renamed, we need a new name for the musical muse package. One of the suggestions was to use the official project spelling of "MusE" for the package name. Do the Extras packaging guidelines allow this (having both MusE and muse package)? AG From sundaram at fedoraproject.org Mon May 8 21:20:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 09 May 2006 02:50:41 +0530 Subject: package naming question: muse -vs - MusE In-Reply-To: <1147123014.2910.248.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> Message-ID: <1147123241.4310.118.camel@sundaram.pnq.redhat.com> On Mon, 2006-05-08 at 14:16 -0700, Anthony Green wrote: > There are some discussions about merging parts of PlanetCCRMA into > Fedora Extras. One of the problems has to do with package namespace > conflicts. For instance, PlanetCCRMA has had a "muse" package for many > years (http://www.muse-sequencer.org). But now FE has an emacs > extension package called "muse". So, assuming the emacs extension > package can't be renamed, we need a new name for the musical muse > package. Why cant it be renamed? emacs-muse would be better for a emacs extension. > > One of the suggestions was to use the official project spelling of > "MusE" for the package name. Do the Extras packaging guidelines allow > this (having both MusE and muse package)? I dont see a conflict but it is confusing and it might be better to stick with small case for package name. Rahul From gauret at free.fr Mon May 8 21:22:12 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 08 May 2006 23:22:12 +0200 Subject: weekly "new pacakges in Extras" (Was: Fedora Package Announcement List Split) References: <1146124978.16095.15.camel@thl.ct.heise.de> <200604271202.k3RC26Jq008968@ludwig-alpha.unil.ch> <1146141362.12671.33.camel@cutter> <1147120880.1951.65.camel@cutter> Message-ID: seth vidal wrote: > why is this useful? Why not just add support for a list of pkg > names/globs to repo-rss and cut out the middle man? Because then we can use the repodata to send weekly mails, we can run repoview on it, etc... > Alternatively why don't we take a step back and make a list of all the > features we want and write one tool that'll handle all of those items > w/o lots of intermediate steps. It's the two opposite designs: one big app which does everything, but gets complicated, versus several small app which do only one thing, and use the repodata as a common data format. I like the second option better, sound more Unixy to me. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr If one keeps trying, one successes eventually. Therefore, the more one fails, the closer one is to success. -- Shadok moto. From notting at redhat.com Mon May 8 21:32:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 May 2006 17:32:08 -0400 Subject: package naming question: muse -vs - MusE In-Reply-To: <1147123014.2910.248.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> Message-ID: <20060508213208.GB23374@devserv.devel.redhat.com> Anthony Green (green at redhat.com) said: > There are some discussions about merging parts of PlanetCCRMA into > Fedora Extras. One of the problems has to do with package namespace > conflicts. For instance, PlanetCCRMA has had a "muse" package for many > years (http://www.muse-sequencer.org). But now FE has an emacs > extension package called "muse". So, assuming the emacs extension > package can't be renamed, we need a new name for the musical muse > package. > > One of the suggestions was to use the official project spelling of > "MusE" for the package name. Do the Extras packaging guidelines allow > this (having both MusE and muse package)? Some combination of CVS, bugzilla, and/or the buildsystem I suspect would break. Frankly, I'd rename the emacs thing emacs-muse, but that's just me. :) Bill From green at redhat.com Mon May 8 21:48:23 2006 From: green at redhat.com (Anthony Green) Date: Mon, 08 May 2006 14:48:23 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060508213208.GB23374@devserv.devel.redhat.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> Message-ID: <1147124903.2910.263.camel@localhost.localdomain> On Mon, 2006-05-08 at 17:32 -0400, Bill Nottingham wrote: > Some combination of CVS, bugzilla, and/or the buildsystem I suspect would > break. > > Frankly, I'd rename the emacs thing emacs-muse, but that's just me. :) It's not just you. A few of us are of the same opinion. Unfortunately the emacs muse package is now in Extras. Is it too late to rename it? The name is a problem for anybody with mixed Extras & PlanetCCRMA repositories. AG From kevin-fedora-extras at scrye.com Mon May 8 22:20:36 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 08 May 2006 16:20:36 -0600 (MDT) Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> Message-ID: <20060508.162036.833082439.kevin@scrye.com> >>>>> "Anthony" == Anthony Green writes: Anthony> On Mon, 2006-05-08 at 17:32 -0400, Bill Nottingham wrote: >> Some combination of CVS, bugzilla, and/or the buildsystem I suspect >> would break. >> >> Frankly, I'd rename the emacs thing emacs-muse, but that's just >> me. :) Anthony> It's not just you. A few of us are of the same opinion. Anthony> Unfortunately the emacs muse package is now in Extras. Is it Anthony> too late to rename it? The name is a problem for anybody Anthony> with mixed Extras & PlanetCCRMA repositories. emacs-muse was discussed when the package was under review, but the package isn't just an emacs package, it also works with xemacs. I expect it would confuse a user of the xemacs-muse version to file bugs against a package called emacs-muse. Perhaps we could use 'el-muse' or 'elisp-muse' or 'muse-mode' ? also, currently none of the other elisp packages use any particular namespace, they are just using the name of the upstream application... ie, mew, auctex, etc. Anthony> AG kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cweyl at alumni.drew.edu Mon May 8 22:20:50 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 8 May 2006 15:20:50 -0700 Subject: fedorabugs process... Message-ID: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> Hey all -- The wiki page Packaging/ReviewGuidelines says that reviewers should add themselves to the "fedorabugs" group (to be able to manipulate bugs in the specified manner, I suspect). I did so, six days ago; is there a further step I need to take? Thanks:) -Chris -- Chris Weyl Ex astris, scientia From gemi at bluewin.ch Mon May 8 22:45:34 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 09 May 2006 00:45:34 +0200 Subject: package naming question: muse -vs - MusE In-Reply-To: <20060508213208.GB23374@devserv.devel.redhat.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> Message-ID: <1147128334.31566.1.camel@scriabin.tannenrauch.ch> On Mon, 2006-05-08 at 17:32 -0400, Bill Nottingham wrote: > Anthony Green (green at redhat.com) said: > > There are some discussions about merging parts of PlanetCCRMA into > > Fedora Extras. One of the problems has to do with package namespace > > conflicts. For instance, PlanetCCRMA has had a "muse" package for many > > years (http://www.muse-sequencer.org). But now FE has an emacs > > extension package called "muse". So, assuming the emacs extension > > package can't be renamed, we need a new name for the musical muse > > package. Not only that, there is also a software called MuSE (http://muse.dyne.org/) which could also be a candidate for packaging. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From Christian.Iseli at licr.org Mon May 8 22:39:00 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 09 May 2006 00:39:00 +0200 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: Message from Bill Nottingham of "Mon, 08 May 2006 17:32:08 EDT." <20060508213208.GB23374@devserv.devel.redhat.com> Message-ID: <200605082332.k48NVxed008677@mx1.redhat.com> notting at redhat.com said: > Anthony Green (green at redhat.com) said: > > One of the suggestions was to use the official project spelling of > > "MusE" for the package name. Do the Extras packaging guidelines allow > > this (having both MusE and muse package)? Let's please not go that route... even though I can't find anything in the guidelines that mention this case (yet...) > Some combination of CVS, bugzilla, and/or the buildsystem I suspect would > break. Yes, and for the end user it might get quite confusing... > Frankly, I'd rename the emacs thing emacs-muse, but that's just me. :) Not just you. If RPM can handle this, maybe an emacs-muse package that Provides muse for a short while... I think spot wanted to explicitly mention emacs/xemacs in the addon packages section. Cheers, Christian From Christian.Iseli at licr.org Mon May 8 23:58:28 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 09 May 2006 01:58:28 +0200 Subject: FESCo Elections 2006 In-Reply-To: Your message of "Mon, 01 May 2006 17:21:53 +0200." <1146496913.2830.33.camel@localhost.localdomain> Message-ID: <200605082358.k48NwXu0015189@mx3.redhat.com> Hi folks, fedora at leemhuis.info said: > I create a page in the wiki to collect the nominations: http:// > www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations I thought that page would fill up quicker... oh well. I kinda hoped other people might have more time available than I do, but I guess it's the same everywhere. Whatever little free time I can find here, I'll gladly contribute to FE. So I put my name on there... Cheers, Christian From tibbs at math.uh.edu Mon May 8 23:58:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 08 May 2006 18:58:25 -0500 Subject: fedorabugs process... In-Reply-To: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> (Chris Weyl's message of "Mon, 8 May 2006 15:20:50 -0700") References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> Message-ID: >>>>> "CW" == Chris Weyl writes: CW> I did so, six days ago; is there a further step I need to take? You're showing up in the list as unapproved. I tried and failed to upgrade your status to approved; I'm not sure who is authorized to do that. - J< From cweyl at alumni.drew.edu Tue May 9 00:21:49 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 8 May 2006 17:21:49 -0700 Subject: fedorabugs process... In-Reply-To: References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> Message-ID: <7dd7ab490605081721x363b67d0rc33f9742012a9f0f@mail.gmail.com> On 5/8/06, Jason L Tibbitts III wrote: > >>>>> "CW" == Chris Weyl writes: > > CW> I did so, six days ago; is there a further step I need to take? > > You're showing up in the list as unapproved. I tried and failed to > upgrade your status to approved; I'm not sure who is authorized to do > that. Unfortunately that's exactly what my sponsor said, too :( Thanks tho :) -Chris -- Chris Weyl Ex astris, scientia From jwboyer at jdub.homelinux.org Tue May 9 00:32:54 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 May 2006 19:32:54 -0500 Subject: fedorabugs process... In-Reply-To: <7dd7ab490605081721x363b67d0rc33f9742012a9f0f@mail.gmail.com> References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> <7dd7ab490605081721x363b67d0rc33f9742012a9f0f@mail.gmail.com> Message-ID: <1147134774.2512.25.camel@vader.jdub.homelinux.org> On Mon, 2006-05-08 at 17:21 -0700, Chris Weyl wrote: > On 5/8/06, Jason L Tibbitts III wrote: > > >>>>> "CW" == Chris Weyl writes: > > > > CW> I did so, six days ago; is there a further step I need to take? > > > > You're showing up in the list as unapproved. I tried and failed to > > upgrade your status to approved; I'm not sure who is authorized to do > > that. > > Unfortunately that's exactly what my sponsor said, too :( > > Thanks tho :) Yeah, I tried that already. Apparently sponsors don't have access to the fedorabugs group. Hopefully someone with semi-$deity like powers hears the pleas of us mortals and grants our whimsical prayers. ;) josh From mpeters at mac.com Tue May 9 00:33:03 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 08 May 2006 17:33:03 -0700 Subject: FESCo Elections 2006 In-Reply-To: <1146496913.2830.33.camel@localhost.localdomain> References: <1146496913.2830.33.camel@localhost.localdomain> Message-ID: <1147134783.20987.0.camel@atlantis.mpeters.local> On Mon, 2006-05-01 at 17:21 +0200, Thorsten Leemhuis wrote: > Hi All! > > As discussed on this list and during the last two FESCo meetings we're > going to have a election of the members for the next FESCo. *snip* > > I create a page in the wiki to collect the nominations: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations > > Please put them there and send them to fedora-extras-list also. You can > also nominate other people, but they have to write a self-nomination on > their own. I would like to nominate Toshio Kuratomi - but I'm not going to put him on the wiki page, just encouraging him to self nominate if he wants the commitment ... From katzj at redhat.com Tue May 9 00:54:40 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 May 2006 20:54:40 -0400 Subject: fedorabugs process... In-Reply-To: <1147134774.2512.25.camel@vader.jdub.homelinux.org> References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> <7dd7ab490605081721x363b67d0rc33f9742012a9f0f@mail.gmail.com> <1147134774.2512.25.camel@vader.jdub.homelinux.org> Message-ID: <1147136080.13841.8.camel@aglarond.local> On Mon, 2006-05-08 at 19:32 -0500, Josh Boyer wrote: > On Mon, 2006-05-08 at 17:21 -0700, Chris Weyl wrote: > > On 5/8/06, Jason L Tibbitts III wrote: > > > >>>>> "CW" == Chris Weyl writes: > > > > > > CW> I did so, six days ago; is there a further step I need to take? > > > > > > You're showing up in the list as unapproved. I tried and failed to > > > upgrade your status to approved; I'm not sure who is authorized to do > > > that. > > > > Unfortunately that's exactly what my sponsor said, too :( > > > > Thanks tho :) > > Yeah, I tried that already. Apparently sponsors don't have access to > the fedorabugs group. Hopefully someone with semi-$deity like powers > hears the pleas of us mortals and grants our whimsical prayers. My ninja duties for the day are now complete ;) Chris -- you should be all set Jeremy From cweyl at alumni.drew.edu Tue May 9 01:12:30 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 8 May 2006 18:12:30 -0700 Subject: fedorabugs process... In-Reply-To: <1147136080.13841.8.camel@aglarond.local> References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> <7dd7ab490605081721x363b67d0rc33f9742012a9f0f@mail.gmail.com> <1147134774.2512.25.camel@vader.jdub.homelinux.org> <1147136080.13841.8.camel@aglarond.local> Message-ID: <7dd7ab490605081812m2c8a1950p869dacdc9ca53a95@mail.gmail.com> On 5/8/06, Jeremy Katz wrote: > My ninja duties for the day are now complete ;) > > Chris -- you should be all set Thanks! with speed and dispatch ninjas tweaked fedorabugs-- reviews may be done. ( with apologies for the bad haiku;) ) -Chris -- Chris Weyl Ex astris, scientia From green at redhat.com Tue May 9 01:52:22 2006 From: green at redhat.com (Anthony Green) Date: Mon, 08 May 2006 18:52:22 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060508.162036.833082439.kevin@scrye.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> Message-ID: <1147139543.2910.287.camel@localhost.localdomain> On Mon, 2006-05-08 at 16:20 -0600, Kevin Fenzi wrote: > emacs-muse was discussed when the package was under review, but the > package isn't just an emacs package, it also works with xemacs. > I expect it would confuse a user of the xemacs-muse version to file > bugs against a package called emacs-muse. Perhaps, but it shouldn't. The "emacs" most people talk about is more properly called "GNU emacs". "emacs" actually describes a family of extensible editors, members of which are GNU emacs, xemacs, TECO emacs and Gosling emacs. So by this measure the original "emacs" package name is the confusing one. I'm not, however, proposing that we change the GNU "emacs" package name. :-) AG From nando at ccrma.Stanford.EDU Tue May 9 01:52:46 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 08 May 2006 18:52:46 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <445FD067.2010605@ajs.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> Message-ID: <1147139566.5758.14.camel@cmn3.stanford.edu> On Mon, 2006-05-08 at 19:12 -0400, Aaron Sherman wrote: > Bill Nottingham wrote: > > Anthony Green (green at redhat.com) said: > > > >> There are some discussions about merging parts of PlanetCCRMA into > >> Fedora Extras. One of the problems has to do with package namespace > >> conflicts. For instance, PlanetCCRMA has had a "muse" package for many > >> years (http://www.muse-sequencer.org). But now FE has an emacs > >> extension package called "muse". > >> > >> One of the suggestions was to use the official project spelling of > >> "MusE" for the package name. Do the Extras packaging guidelines allow > >> this (having both MusE and muse package)? > >> Some combination of CVS, bugzilla, and/or the buildsystem I suspect would > >> break. > >> > >> Frankly, I'd rename the emacs thing emacs-muse, but that's just me. :) > > Why not call the CCRMA packages "-CCRMA"? That way there's no > conflicts. Because they are not part of CCRMA. Same reason for not naming extras packages "extras-whatever". -- Fernando > If this is just a spec file change, it won't affect CVS, and > it's a relatively trivial build change. As for Bugzilla... well, I don't > know what kind of automatic hooks the software has into submitting bug > reports, but it should not be hard to strip the trailing -CCRMA for > submitting. > > However, in this one case, I agree with the idea that if muse is an > emacs add-on, it should probably be emacs-muse. From rtlm10 at gmail.com Tue May 9 03:34:16 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Mon, 8 May 2006 23:34:16 -0400 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147139566.5758.14.camel@cmn3.stanford.edu> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> Message-ID: <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> Out of curiosity, Assuming that the current extras package was renamed would it only be implemented in the current development / future versions? Using RPM how would we go about upgrading the current package to the new name. Using obsoletes would work initially to replace it if there wasn't a new package coming in with the same name. That would then cause anyone installing emacs-muse after muse to have their muse package removed. What is the proper way of doing this? My understanding of RPM leads me to believe that the "cleanest" way to include the new muse package in FC5 is for its package to be renamed, even though the current package is the "proper" candidate for renaming. The other option is to change the names for FC6+ and call it done. Am I right about this or is there a mechanism I'm unaware of? On 5/8/06, Fernando Lopez-Lezcano wrote: > > On Mon, 2006-05-08 at 19:12 -0400, Aaron Sherman wrote: > > Bill Nottingham wrote: > > > Anthony Green (green at redhat.com) said: > > > > > >> There are some discussions about merging parts of PlanetCCRMA into > > >> Fedora Extras. One of the problems has to do with package namespace > > >> conflicts. For instance, PlanetCCRMA has had a "muse" package for > many > > >> years (http://www.muse-sequencer.org). But now FE has an emacs > > >> extension package called "muse". > > >> > > >> One of the suggestions was to use the official project spelling of > > >> "MusE" for the package name. Do the Extras packaging guidelines > allow > > >> this (having both MusE and muse package)? > > >> Some combination of CVS, bugzilla, and/or the buildsystem I suspect > would > > >> break. > > >> > > >> Frankly, I'd rename the emacs thing emacs-muse, but that's just me. > :) > > > > Why not call the CCRMA packages "-CCRMA"? That way there's no > > conflicts. > > Because they are not part of CCRMA. Same reason for not naming extras > packages "extras-whatever". > > -- Fernando > > > If this is just a spec file change, it won't affect CVS, and > > it's a relatively trivial build change. As for Bugzilla... well, I don't > > know what kind of automatic hooks the software has into submitting bug > > reports, but it should not be hard to strip the trailing -CCRMA for > > submitting. > > > > However, in this one case, I agree with the idea that if muse is an > > emacs add-on, it should probably be emacs-muse. > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Tue May 9 04:17:00 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 08 May 2006 21:17:00 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> Message-ID: <1147148220.27330.4.camel@atlantis.mpeters.local> On Mon, 2006-05-08 at 23:34 -0400, Russell Harrison wrote: > Out of curiosity, > > Assuming that the current extras package was renamed would it only be > implemented in the current development / future versions? Using RPM > how would we go about upgrading the current package to the new name. > Using obsoletes would work initially to replace it if there wasn't a > new package coming in with the same name. That would then cause > anyone installing emacs-muse after muse to have their muse package > removed. > > What is the proper way of doing this? My understanding of RPM leads > me to believe that the "cleanest" way to include the new muse package > in FC5 is for its package to be renamed, even though the current > package is the "proper" candidate for renaming. The other option is > to change the names for FC6+ and call it done. > > Am I right about this or is there a mechanism I'm unaware of? I think (not sure) you can have emacs-muse obsolete specific versions ranges of muse, but I'm not positive. Personally - I say do the emacs-muse thing now, as in yesterday, with obsolete/provides for muse. Then in FC-6/devel, drop the obsolete/provides. FC-5 users will have muse replaced with emacs-muse and then when fc-6 is released, they will get an emacs-muse that does not obsolete muse - and can install this other package. People trying to yum update from FC-4 to FC-6 really should make a pit stop in FC-5 first anyhow. From rtlm10 at gmail.com Tue May 9 04:25:47 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Tue, 9 May 2006 00:25:47 -0400 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147148220.27330.4.camel@atlantis.mpeters.local> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> Message-ID: <1ed4a0130605082125y70ec0976tbfec46eaa772e6a3@mail.gmail.com> That sounds like it would work. The trick is making sure the obsoletes gets removed for FC6. On 5/9/06, Michael A. Peters wrote: > > On Mon, 2006-05-08 at 23:34 -0400, Russell Harrison wrote: > > Out of curiosity, > > > > Assuming that the current extras package was renamed would it only be > > implemented in the current development / future versions? Using RPM > > how would we go about upgrading the current package to the new name. > > Using obsoletes would work initially to replace it if there wasn't a > > new package coming in with the same name. That would then cause > > anyone installing emacs-muse after muse to have their muse package > > removed. > > > > What is the proper way of doing this? My understanding of RPM leads > > me to believe that the "cleanest" way to include the new muse package > > in FC5 is for its package to be renamed, even though the current > > package is the "proper" candidate for renaming. The other option is > > to change the names for FC6+ and call it done. > > > > Am I right about this or is there a mechanism I'm unaware of? > > I think (not sure) you can have emacs-muse obsolete specific versions > ranges of muse, but I'm not positive. > > Personally - I say do the emacs-muse thing now, as in yesterday, with > obsolete/provides for muse. > > Then in FC-6/devel, drop the obsolete/provides. > > FC-5 users will have muse replaced with emacs-muse and then when fc-6 is > released, they will get an emacs-muse that does not obsolete muse - and > can install this other package. > > People trying to yum update from FC-4 to FC-6 really should make a pit > stop in FC-5 first anyhow. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Tue May 9 06:24:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 May 2006 08:24:08 +0200 Subject: fedorabugs process... In-Reply-To: References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> Message-ID: <44603588.9010904@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "CW" == Chris Weyl writes: > > CW> I did so, six days ago; is there a further step I need to take? > > You're showing up in the list as unapproved. I tried and failed to > upgrade your status to approved; I'm not sure who is authorized to do > that. > If you want to sponsor him just sponser him then he will get approved too. Regards, Hans From lists at timj.co.uk Tue May 9 10:22:22 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 09 May 2006 11:22:22 +0100 Subject: Squirrelmail plugin packaging naming Message-ID: <44606D5E.5040405@timj.co.uk> There are a couple of Squirrelmail plugins I'd like to package. I've worked out things from the packaging side and been successfully using them for a while, but I'm not sure about the naming. Let's take for example the change_pass plugin. Here are some viable options for naming: 1. squirrelmail-plugin-change_pass 2. squirrelmail-plugin-change-pass 3. squirrelmail-change_pass 4. squirrelmail-change-pass Option 1 from the above is what I've used to date, with the following reasoning: a) squirrelmail-XXX as opposed to squirrelmail-plugin-XXX makes it sound like XXX is a subpackage of squirrelmail as opposed to some random third party plugin that is completely separate. The use of "*-plugins-*" is not without precedent; see libopensync for example. b) Although underscores are not normally allowed in names, use of "change_pass" as opposed to "change-pass" makes sense because the PackageNamingGuidelines say "...packages where the upstream name naturally contains an underscore are excluded from this". In this case, underscores are conventionally used by Squirrelmail plugins and this is no exception - see upstream at http://www.squirrelmail.org/plugin_download.php?id=21&rev=1072 . Comments welcome. Thanks, Tim From jwboyer at jdub.homelinux.org Tue May 9 10:44:31 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 09 May 2006 05:44:31 -0500 Subject: fedorabugs process... In-Reply-To: <44603588.9010904@hhs.nl> References: <7dd7ab490605081520s85f64d1v25d3e71ff3d21ea4@mail.gmail.com> <44603588.9010904@hhs.nl> Message-ID: <1147171471.2512.30.camel@vader.jdub.homelinux.org> On Tue, 2006-05-09 at 08:24 +0200, Hans de Goede wrote: > > Jason L Tibbitts III wrote: > >>>>>> "CW" == Chris Weyl writes: > > > > CW> I did so, six days ago; is there a further step I need to take? > > > > You're showing up in the list as unapproved. I tried and failed to > > upgrade your status to approved; I'm not sure who is authorized to do > > that. > > > > If you want to sponsor him just sponser him then he will get approved too. Um, no. I already sponsored Chris. FE sponsors don't have authority to allow people to be in the fedorabugs group. So it requires someone with that authority to add them. josh From lists at timj.co.uk Tue May 9 13:07:05 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 09 May 2006 14:07:05 +0100 Subject: Documentation-only packages Message-ID: <446093F9.8010808@timj.co.uk> Since nobody objected or said they were working on it when I asked before, I'm going to create a PHP manual package. As a doc-only package, I'm not sure about a few things (the wiki doesn't seem to say a lot) so I'd appreciate any comments/suggestions on the following points: 1. Naming. "php-docs" would fit with the usual convention. "php-manual" would be more descriptive of what it actually is. Preferences anyone? 2. Versioning. The docs aren't actually versioned as such, but dated. OK to use date e.g. "20060421" as version number? 3. Filesystem location. %{_datadir}/doc/%{name} OK? Or should it be %{_datadir}/doc/%{name}-%{version}? 4. Localisation. The manual is available in many different languages, distributed separately. I am only proposing to package the English version at the moment. This creates two issues: a) Name - should the package actually be name php-docs-en (or php-manual-en) rather than php-docs/php-manual? b) File location - regardless of %{name}, and assuming php-manual was chosen as the convention, should the file location be: %{_datadir}/doc/php-manual/en/* or %{_datadir}/doc/php-manual-en/* ? Also, although at the moment I am only proposing to package HTML version, other versions are available. This adds another variable. Therefore, should location be: %{_datadir}/doc/php-manual-en/html/ or %{_datadir}/doc/php-manual/en/html/ or %{_datadir}/doc/php-manual/html/en/ Thanks, Tim From Jochen at herr-schmitt.de Tue May 9 15:17:36 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 09 May 2006 17:17:36 +0200 Subject: Trouble with uploading sources to cvs In-Reply-To: <445E5864.5030401@herr-schmitt.de> References: <445E5864.5030401@herr-schmitt.de> Message-ID: <0ML25U-1FdTy41lDP-0008LW@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 07 May 2006 22:28:20 +0200, you wrote: >I have the following problem, I am trying to upload the current source >ball of stellarium into the cvs. Unfortunately I have got the following >error message: > >$ make new-sources FILES="stellarium-0.8.0.tar.gz" > >Checking : stellarium-0.8.0.tar.gz on >https://cvs.fedora.redhat.com/repo/extras/upload.cgi... >ERROR: could not check remote file status >make: *** [new-sources] Fehler 255 > >It will be nice, if anyone have a hint to solve this problem. I have found a solution for my problem. After I have downloaded a new .fedora.cert from the accounting system, the upload worked fine. Best Regards. Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBRGCym09gByurcX4MEQJPDACeKoot2XN22gW+wm7fGNcW10I8QsYAnRHZ Rx2vBi2qC6SFfKpoZzq+qbyy =ZSjn -----END PGP SIGNATURE----- From cweyl at alumni.drew.edu Tue May 9 15:24:17 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 9 May 2006 08:24:17 -0700 Subject: Documentation-only packages In-Reply-To: <446093F9.8010808@timj.co.uk> References: <446093F9.8010808@timj.co.uk> Message-ID: <7dd7ab490605090824l6b3637cev728505d7739d524d@mail.gmail.com> On 5/9/06, Tim Jackson wrote: > 1. Naming. "php-docs" would fit with the usual convention. "php-manual" > would be more descriptive of what it actually is. Preferences anyone? That's not uncommon; a quick search shows 20 packages name *-manual. Admittedly most are in core, but packages like httpd-manual have been around for as long as I can remember using redhat. I'd think -manual makes more sense for a standalone package, if I saw X-docs show up in extras I'd probably wonder where X was. -Chris -- Chris Weyl Ex astris, scientia From jwboyer at jdub.homelinux.org Tue May 9 16:09:09 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 9 May 2006 11:09:09 -0500 Subject: Documentation-only packages In-Reply-To: <7dd7ab490605090824l6b3637cev728505d7739d524d@mail.gmail.com> References: <446093F9.8010808@timj.co.uk> <7dd7ab490605090824l6b3637cev728505d7739d524d@mail.gmail.com> Message-ID: <20060509160909.GC2418@yoda.jdub.homelinux.org> On Tue, May 09, 2006 at 08:24:17AM -0700, Chris Weyl wrote: > On 5/9/06, Tim Jackson wrote: > >1. Naming. "php-docs" would fit with the usual convention. "php-manual" > >would be more descriptive of what it actually is. Preferences anyone? > > That's not uncommon; a quick search shows 20 packages name *-manual. > Admittedly most are in core, but packages like httpd-manual have been > around for as long as I can remember using redhat. I'd think -manual > makes more sense for a standalone package, if I saw X-docs show up in > extras I'd probably wonder where X was. Right. -doc(s) packages tend to be subpackages, so -manual makes more sense to me as well. josh From bugzilla at drussell.dnsalias.com Tue May 9 17:49:35 2006 From: bugzilla at drussell.dnsalias.com (Don Russell) Date: Tue, 09 May 2006 10:49:35 -0700 Subject: Documentation-only packages In-Reply-To: <446093F9.8010808@timj.co.uk> References: <446093F9.8010808@timj.co.uk> Message-ID: <4460D62F.6010309@drussell.dnsalias.com> Tim Jackson wrote: > Since nobody objected or said they were working on it when I asked > before, I'm going to create a PHP manual package. > > As a doc-only package, I'm not sure about a few things (the wiki > doesn't seem to say a lot) so I'd appreciate any comments/suggestions > on the following points: > > 1. Naming. "php-docs" would fit with the usual convention. > "php-manual" would be more descriptive of what it actually is. > Preferences anyone? I would prefer php-manual. It's intuitive, and as you say, "more descriptive of what it actually is". Isn't that where the "man" command from? "manual "? "docs" is slang; "manual" is a word people can look up. (Maybe not a real problem, but why perpetuate something not necessary when a very good alternative is available? :-) There are various -manual files... you won't be setting a precedent. From nando at ccrma.Stanford.EDU Tue May 9 17:51:39 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 09 May 2006 10:51:39 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147148220.27330.4.camel@atlantis.mpeters.local> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> Message-ID: <1147197099.22392.23.camel@cmn3.stanford.edu> On Mon, 2006-05-08 at 21:17 -0700, Michael A. Peters wrote: > On Mon, 2006-05-08 at 23:34 -0400, Russell Harrison wrote: > > Out of curiosity, > > > > Assuming that the current extras package was renamed would it only be > > implemented in the current development / future versions? Using RPM > > how would we go about upgrading the current package to the new name. > > Using obsoletes would work initially to replace it if there wasn't a > > new package coming in with the same name. That would then cause > > anyone installing emacs-muse after muse to have their muse package > > removed. > > > > What is the proper way of doing this? My understanding of RPM leads > > me to believe that the "cleanest" way to include the new muse package > > in FC5 is for its package to be renamed, even though the current > > package is the "proper" candidate for renaming. The other option is > > to change the names for FC6+ and call it done. > > > > Am I right about this or is there a mechanism I'm unaware of? > > I think (not sure) you can have emacs-muse obsolete specific versions > ranges of muse, but I'm not positive. > > Personally - I say do the emacs-muse thing now, as in yesterday, with > obsolete/provides for muse. > > Then in FC-6/devel, drop the obsolete/provides. > > FC-5 users will have muse replaced with emacs-muse and then when fc-6 is > released, they will get an emacs-muse that does not obsolete muse - and > can install this other package. > > People trying to yum update from FC-4 to FC-6 really should make a pit > stop in FC-5 first anyhow. It is regretful that the existing (emacs) muse version is 3.02.6b is higher than the (sequencer/audio recorder) muse version (0.8.1a). Which means that fc5 Planet CCRMA users would not be able to install (audio) muse as emacs-muse would obsolete it, right? Unless emacs-muse obsoletes just the current version of muse in extras. -- Fernando From qspencer at ieee.org Tue May 9 18:18:43 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 09 May 2006 13:18:43 -0500 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147197099.22392.23.camel@cmn3.stanford.edu> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> Message-ID: <4460DD03.1030603@ieee.org> Fernando Lopez-Lezcano wrote: > On Mon, 2006-05-08 at 21:17 -0700, Michael A. Peters wrote: > >> On Mon, 2006-05-08 at 23:34 -0400, Russell Harrison wrote: >> >>> Out of curiosity, >>> >>> Assuming that the current extras package was renamed would it only be >>> implemented in the current development / future versions? Using RPM >>> how would we go about upgrading the current package to the new name. >>> Using obsoletes would work initially to replace it if there wasn't a >>> new package coming in with the same name. That would then cause >>> anyone installing emacs-muse after muse to have their muse package >>> removed. >>> >>> What is the proper way of doing this? My understanding of RPM leads >>> me to believe that the "cleanest" way to include the new muse package >>> in FC5 is for its package to be renamed, even though the current >>> package is the "proper" candidate for renaming. The other option is >>> to change the names for FC6+ and call it done. >>> >>> Am I right about this or is there a mechanism I'm unaware of? >>> >> I think (not sure) you can have emacs-muse obsolete specific versions >> ranges of muse, but I'm not positive. >> >> Personally - I say do the emacs-muse thing now, as in yesterday, with >> obsolete/provides for muse. >> >> Then in FC-6/devel, drop the obsolete/provides. >> >> FC-5 users will have muse replaced with emacs-muse and then when fc-6 is >> released, they will get an emacs-muse that does not obsolete muse - and >> can install this other package. >> >> People trying to yum update from FC-4 to FC-6 really should make a pit >> stop in FC-5 first anyhow. >> > > It is regretful that the existing (emacs) muse version is 3.02.6b is > higher than the (sequencer/audio recorder) muse version (0.8.1a). > > Which means that fc5 Planet CCRMA users would not be able to install > (audio) muse as emacs-muse would obsolete it, right? > > Unless emacs-muse obsoletes just the current version of muse in extras. > Do I dare suggest that this might be a place where using an epoch might be justified? -Quentin From buildsys at fedoraproject.org Tue May 9 18:48:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 9 May 2006 14:48:49 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060509184849.BB06F152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 5 abiword-2.4.4-2.fc3 dnsmasq-2.31-1.fc3 fwrestart-1.04-1.fc3 gtkwave-3.0.1-1.fc3 hping2-2.0.0-0.6.rc3.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 9 18:49:18 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 9 May 2006 14:49:18 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060509184918.80368152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 20 abiword-2.4.4-3.fc4 awstats-6.5-3.fc4 dnsmasq-2.31-1.fc4 fonttools-2.0-0.6.20050624cvs.fc4 fwrestart-1.04-1.fc4 gtkwave-3.0.1-1.fc4 hping2-2.0.0-0.6.rc3.fc4 lasi-1.0.5-2.fc4 liboil-0.3.8-1.fc4 monotone-0.26-2.fc4 p0f-2.0.6-1.fc4 par2cmdline-0.4-8.fc4 perl-Class-Inspector-1.15-1.fc4 perl-Crypt-DSA-0.14-1.fc4 perl-Module-ScanDeps-0.59-2.fc4 perl-Params-Util-0.13-1.fc4 perl-Params-Validate-0.81-1.fc4 stellarium-0.8.0-2.fc4 svnmailer-1.0.8-1.fc4 wifiroamd-1.08-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 9 18:59:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 9 May 2006 14:59:07 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060509185907.63866152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 29 abiword-2.4.4-3.fc5 adns-1.2-1 adns-1.2-2 awstats-6.5-5.fc5 dnsmasq-2.31-1.fc5 flumotion-0.2.1-1.fc5 fonttools-2.0-0.6.20050624cvs.fc5 fwrestart-1.04-1.fc5 gtkwave-3.0.1-1.fc5 hping2-2.0.0-0.8.rc3 lasi-1.0.5-2.fc5 monotone-0.26-2.fc5 nsd-2.3.4-4.fc5 p0f-2.0.6-1.fc5 par2cmdline-0.4-8.fc5 pcsc-tools-1.4.5-1.fc5 perl-Class-Inspector-1.15-1.fc5 perl-Crypt-DSA-0.14-1.fc5 perl-IO-Tty-1.03-1.fc5 perl-Module-Install-0.62-2.fc5 perl-Module-ScanDeps-0.59-2.fc5 perl-Params-Util-0.13-1.fc5 perl-Test-Base-0.50-2.fc5 plplot-5.6.0-1.fc5 rssowl-1.2.1-2.fc5 scribes-0.2.4.3-3.fc5 stellarium-0.8.0-2.fc5 svnmailer-1.0.8-1.fc5 wifiroamd-1.08-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 9 19:02:01 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 9 May 2006 15:02:01 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060509190201.093CF152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 dnsmasq-2.31-1.fc6 environment-modules-3.2.2-1.fc6 fonttools-2.0-0.6.20050624cvs.fc6 fwrestart-1.04-1.fc6 glibmm24-2.10.1-1 gtkmm24-2.8.5-1 gtkwave-3.0.1-1.fc6 hping2-2.0.0-0.7.rc3 hping2-2.0.0-0.7.rc3.fc6 lasi-1.0.5-2.fc6 libshout-2.2-3.fc6 lightning-1.2-3.fc6 monotone-0.26-2.fc6 octave-2.9.5-6.fc6 octave-forge-2006.03.17-4.fc6 oddjob-0.26-4 p0f-2.0.6-1.fc6 pan-0.96-2.fc6 par2cmdline-0.4-8.fc6 pcsc-tools-1.4.5-1.fc6 perl-Class-Inspector-1.15-1.fc6 perl-Crypt-DSA-0.14-1.fc6 perl-IO-Tty-1.03-1.fc6 perl-Module-Install-0.62-2.fc6 perl-Params-Util-0.13-1.fc6 perl-Test-Base-0.50-2.fc6 perl-YAML-0.58-2.fc6 plplot-5.6.0-1.fc6 scribes-0.2.4.3-3.fc6 stellarium-0.8.0-3.fc6 svnmailer-1.0.8-1.fc6 wifiroamd-1.08-1.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 9 19:20:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 9 May 2006 15:20:06 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060509192006.80CCB152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 2 perl-IO-Tty-1.03-1.fc4 plplot-5.6.0-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at all-the-johnsons.co.uk Tue May 9 21:51:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 09 May 2006 22:51:23 +0100 Subject: Still not getting any closer with mock Message-ID: <1147211483.29857.6.camel@T7.Linux> Hi, I've systematically gone through my spec files for boo and gtksourceview-sharp to try and trace what is missing to cause the mock builds to fail and not the rpmbuild builds to fail and can find nothing - the configure files within the main packages look fine and there is nothing in the makefiles to cause a problem. Both of them seem to exhibit the same problem in that shared-mine-info directories prefix aren't picked up in mock. I can't see anything missing in the spec file either (everything seems to be in the right place). Could some kind soul help me here? (BZ refs are 178901 and 189092 for sourceview-sharp and boo respectively) Thanks TTFN Paul -- Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei denn man ?ffnet die Fenster -------------- 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 mpeters at mac.com Wed May 10 04:42:17 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 09 May 2006 21:42:17 -0700 Subject: Still not getting any closer with mock In-Reply-To: <1147211483.29857.6.camel@T7.Linux> References: <1147211483.29857.6.camel@T7.Linux> Message-ID: <1147236137.27330.83.camel@atlantis.mpeters.local> On Tue, 2006-05-09 at 22:51 +0100, Paul wrote: > Hi, > > I've systematically gone through my spec files for boo and > gtksourceview-sharp to try and trace what is missing to cause the mock > builds to fail and not the rpmbuild builds to fail and can find nothing > - the configure files within the main packages look fine and there is > nothing in the makefiles to cause a problem. What happens when you diff the config.log files? From toshio at tiki-lounge.com Wed May 10 08:10:41 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 10 May 2006 01:10:41 -0700 Subject: FESCo Elections 2006 In-Reply-To: <1147134783.20987.0.camel@atlantis.mpeters.local> References: <1146496913.2830.33.camel@localhost.localdomain> <1147134783.20987.0.camel@atlantis.mpeters.local> Message-ID: <1147248642.4011.34.camel@localhost> On Mon, 2006-05-08 at 17:33 -0700, Michael A. Peters wrote: > On Mon, 2006-05-01 at 17:21 +0200, Thorsten Leemhuis wrote: > > Hi All! > > > > As discussed on this list and during the last two FESCo meetings we're > > going to have a election of the members for the next FESCo. > > I would like to nominate Toshio Kuratomi - but I'm not going to put him > on the wiki page, just encouraging him to self nominate if he wants the > commitment ... Thanks Michael, I've been pretty busy lately but democracy doesn't work if there's no one to vote for (or against). I'm willing to self-nominate and have put my information on the wiki. I noticed there are a lot of other people who haven't self nominated but have commitment and ideas for Fedora. In the same spirit as Michael I'd like to encourage a few of them: Ignacio Vazquez -- I know you were thinking about this and some of the potential projects on your blog looked very interesting. Josh Boyer -- You have intelligent comments and you're present for all the meetings anyway :-) Michael Schwendt, I see Seth nominated you but there's no indication you've accepted. If you're not burnt out, it would be good to see you back. -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 gajownik at fedora.pl Wed May 10 10:15:38 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 10 May 2006 12:15:38 +0200 Subject: Desktop entries and terminal applications. Message-ID: <4461BD4A.50201@fedora.pl> Hi! I wanted to update htop to newer version but I noticed that it now installs htop.desktop file. Should terminal applications install desktop entries? If yes, should I run desktop-file-install with `--add-category X-Fedora` option? It's not an X app but http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines distinctly says that it's a must. Here are packages: http://fedora.pl/~gajownik/htop-0.6.1-1.i386.rpm http://fedora.pl/~gajownik/htop-0.6.1-1.src.rpm Regards, Dawid -- ^_* From buildsys at fedoraproject.org Wed May 10 11:06:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 10 May 2006 07:06:23 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060510110623.8D6A315216A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 8 bogofilter-1.0.2-1.fc5 gauche-gl-0.4.1-5.fc5 gcompris-7.4-9.fc5 gtkwave-3.0.2-1.fc5 lightning-1.2-3.fc5 nagios-2.3-3.fc5 njam-1.25-3.fc5 yumex-1.0.1-1.0.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 10 11:06:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 10 May 2006 07:06:23 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060510110623.7D0A6152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 8 gauche-gl-0.4.1-4.fc6 gcompris-7.4-9.fc6 jed-0.99.18-2 nagios-2.3-2.fc6 njam-1.25-3.fc6 pessulus-0.10.1-2.fc6 xsp-1.1.13-3.fc6 yumex-1.0.1-1.0.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 10 11:06:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 10 May 2006 07:06:23 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060510110623.96CD115216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 6 gauche-gl-0.4.1-4.fc4 gtkwave-3.0.2-1.fc4 lightning-1.2-3.fc4 nagios-2.3-3.fc4 php-eaccelerator-5.0.1_0.9.4-1.fc4 yumex-1.0.1-1.0.fc4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 10 11:06:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 10 May 2006 07:06:23 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060510110623.9D8CC15216C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 gtkwave-3.0.2-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Wed May 10 13:50:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 10 May 2006 08:50:37 -0500 Subject: Still not getting any closer with mock References: <1147211483.29857.6.camel@T7.Linux> Message-ID: Paul wrote: > I've systematically gone through my spec files for boo and > gtksourceview-sharp to try and trace what is missing to cause the mock > builds to fail and not the rpmbuild builds to fail and can find nothing > - the configure files within the main packages look fine and there is > nothing in the makefiles to cause a problem. > > Both of them seem to exhibit the same problem in that shared-mine-info > directories prefix aren't picked up in mock. boo's configure script contains: MIME_PREFIX=`$PKG_CONFIG --variable=prefix shared-mime-info` GTKSOURCEVIEW_PREFIX=`$PKG_CONFIG --variable=prefix gtksourceview-1.0` So, in the least, it appears you're missing: BuildRequires: shared-mime-info -- Rex From tibbs at math.uh.edu Wed May 10 13:57:43 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 10 May 2006 08:57:43 -0500 Subject: Desktop entries and terminal applications. In-Reply-To: <4461BD4A.50201@fedora.pl> (Dawid Gajownik's message of "Wed, 10 May 2006 12:15:38 +0200") References: <4461BD4A.50201@fedora.pl> Message-ID: >>>>> "DG" == Dawid Gajownik writes: DG> Should terminal applications install desktop entries? It's certainly not required, but I don't see why it would be prevented. DG> If yes, should I run desktop-file-install with `--add-category DG> X-Fedora` option? It's not an X app [...] As I understand things, the "X-" doesn't indicate an X application, it indicates a nonstandard category in the same way that the standards for email headers set aside the prefix "X-" to designate headers which are not defined by the standard. - J< From bugzilla at redhat.com Wed May 10 14:20:23 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 10 May 2006 10:20:23 -0400 Subject: [Bug 176288] Review Request: kdemultimedia-extras In-Reply-To: Message-ID: <200605101420.k4AEKNRw003849@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kdemultimedia-extras https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176288 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From rdieter at math.unl.edu 2006-05-10 10:20 EST ------- *** Bug 145965 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gajownik at fedora.pl Wed May 10 15:02:57 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 10 May 2006 17:02:57 +0200 Subject: Desktop entries and terminal applications. In-Reply-To: References: <4461BD4A.50201@fedora.pl> Message-ID: <446200A1.4080709@fedora.pl> Dnia 05/10/2006 03:58 PM, U?ytkownik Jason L Tibbitts III napisa?: > DG> Should terminal applications install desktop entries? > > It's certainly not required, but I don't see why it would be > prevented. Ok, thanks for the clarification. Regards, Dawid -- ^_* From lists at timj.co.uk Wed May 10 15:07:31 2006 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 10 May 2006 16:07:31 +0100 Subject: Documentation-only packages In-Reply-To: <4460D62F.6010309@drussell.dnsalias.com> References: <446093F9.8010808@timj.co.uk> <4460D62F.6010309@drussell.dnsalias.com> Message-ID: <446201B3.6000405@timj.co.uk> Don Russell wrote: > Tim Jackson wrote: >> 1. Naming. "php-docs" would fit with the usual convention. >> "php-manual" would be more descriptive of what it actually is. >> Preferences anyone? > I would prefer php-manual. It's intuitive, and as you say, "more > descriptive of what it actually is". Great, that's two votes then (and it's my preferred one in any case). Tim From jonathan.underwood at gmail.com Wed May 10 15:42:10 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 10 May 2006 16:42:10 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060508.162036.833082439.kevin@scrye.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> Message-ID: <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> On 08/05/06, Kevin Fenzi wrote: > Anthony> It's not just you. A few of us are of the same opinion. > Anthony> Unfortunately the emacs muse package is now in Extras. Is it > Anthony> too late to rename it? The name is a problem for anybody > Anthony> with mixed Extras & PlanetCCRMA repositories. > > emacs-muse was discussed when the package was under review, but the > package isn't just an emacs package, it also works with xemacs. > I expect it would confuse a user of the xemacs-muse version to file > bugs against a package called emacs-muse. OK, I'm the culprit (i.e. I'm the packager for muse). The naming issue was thrashed about in the review A LOT. FE guidelines state that extentsion packages must be prepended with the package that they are extending. Following this would require the emacs muse package to be called... emacs-muse. BUT, the same tar ball builds for xemacs. So it should also be called xemacs-muse. Ugh, see the problem. The same tarball builds extension packages for TWO different packages, and so he prepending guideline doesn't work. So, the solution I proposed, (and it was mailed to the FE list for discussion) was, for the muse package, several RPMs get spun: muse (containing common files and docs, and required by all the packages below) emacs-muse (containing compiled lisp stuff for emacs) xemacs-muse (containing compiled lisp files for xemacs) emacs-muse-el (source lisp files installed into the emacs tree) xemacs-muse-el (source lisp files installed into the xemacs tree). Now, this is the best I could do to fit with guidelines. But I'm more than happy to change the package naming _IF_ we can come up with a standard guideline for this situation. I am currently working with the emacs-auctex packager to provide xemacs packages, so the issue will come up there. And other packages I will submit soon. I can give a number of examples. Basically, we need a standard naming guideline for when a package builds add-ons for more than one other package. Once we have a set of guidlines, some of the (x)emacs packages in FE that were inherited from core (eg mew, apel, flim) will have to be adjusted to fit, as well. So - can anyone come up with a better naming scheme than the one above? I hope so :) Unfortunately I can't find the review bugzilla where the lengthy discussion of this previously took place (are review bugs deleted from bugzilla once the package is submitted?). Jonathan. From laurent.rineau__fc_extra at normalesup.org Wed May 10 16:01:57 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Wed, 10 May 2006 18:01:57 +0200 Subject: buildsys dead? In-Reply-To: References: <445A7BCA.3080802@timj.co.uk> Message-ID: <200605101801.57708@rineau.schtroumpfette> On Friday 05 May 2006 00:17, Andreas Thienemann wrote: > On Thu, 4 May 2006, Tim Jackson wrote: > > Am I doing something silly or is the buildsys dead? > > Nope. Just rawhide is hosed. Rawhide is broken again: Several build jobs have root.log with such lines: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-x86_64-core-361492e51d0aa82e0f0ac270524d38f1a578bd1a/root groupinstall build Failed to add groups file for repository: core Error: Missing Dependency: setransd is needed by package libselinux Example: http://buildsys.fedoraproject.org/logs/fedora-development-extras/9182-par2cmdline-0.4-9.fc6/x86_64/root.log Jobs 9167, 9174, 9175, 9176, and 9177 have failed with same reason. on all arches. From paul at city-fan.org Wed May 10 16:13:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 May 2006 17:13:11 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> Message-ID: <44621117.9090600@city-fan.org> Jonathan Underwood wrote: > Unfortunately I can't find the review bugzilla where the lengthy > discussion of this previously took place (are review bugs deleted from > bugzilla once the package is submitted?). I think you're referring to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 Paul. From jonathan.underwood at gmail.com Wed May 10 16:20:47 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 10 May 2006 17:20:47 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <44621117.9090600@city-fan.org> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <44621117.9090600@city-fan.org> Message-ID: <645d17210605100920g3426935fl7a635afa2f5a2f27@mail.gmail.com> On 10/05/06, Paul Howarth wrote: > Jonathan Underwood wrote: > > Unfortunately I can't find the review bugzilla where the lengthy > > discussion of this previously took place (are review bugs deleted from > > bugzilla once the package is submitted?). > > I think you're referring to: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 Yes, that's the chap, thanks. I really must refine my bugzilla searching skills. J. From toshio at tiki-lounge.com Wed May 10 16:30:29 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 10 May 2006 09:30:29 -0700 Subject: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff In-Reply-To: <44592559.3000309@redhat.com> References: <4457A549.5050603@redhat.com> <1146599764.3163.41.camel@localhost> <4457C5D5.6020508@redhat.com> <44592559.3000309@redhat.com> Message-ID: <1147278630.3170.9.camel@localhost> On Wed, 2006-05-03 at 17:49 -0400, Michael DeHaan wrote: > Given no other replies to this commentary, I think we're ok on the > PyYaml 3000 front (what to do about syck-python is another issue, and > I'm willing to let it slide if a good working alternative can get out > there). > > I do have people interested in reviewing this (Toshio, you are welcome > to as well), but I lack a potential sponsor for my first package. Can > anyone jump on board and help me out? The module itself was already > built with distutils, so the spec only moves it into a more reasonable > namespace and numbering scheme. > If you put together a good package, I'll sponsor you. I don't have much time right now (I've promised to review python-ctypes and I have to get an upstream release of qa-assistant out the door.) If someone else wants to do an initial review to make sure the package conforms to the Fedora Guidelines and runs okay I can do a final review for sponsorship much quicker. It would also be nice if you reviewed one or two packages before being sponsored. This helps in two ways: 1) it shows that you've read and understand the packaging guidelines. 2) it's good packaging karma (someone has to review your package, you review someone else's) > Here's the bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190493 Looks like you're keeping up to date with upstream which is good. I'll leave notes in the bug. -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 jspaleta at gmail.com Wed May 10 17:07:21 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 May 2006 13:07:21 -0400 Subject: Desktop entries and terminal applications. In-Reply-To: References: <4461BD4A.50201@fedora.pl> Message-ID: <604aa7910605101007l34761477saf3661eb65ba95a0@mail.gmail.com> On 5/10/06, Jason L Tibbitts III wrote: > DG> Should terminal applications install desktop entries? what does the desktop entry accomplish in this specific case? Does this item show up in the menus and spawn a terminal? Is there mimetype information that needs to be registered. -jef From gajownik at fedora.pl Wed May 10 17:30:22 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 10 May 2006 19:30:22 +0200 Subject: Desktop entries and terminal applications. In-Reply-To: <604aa7910605101007l34761477saf3661eb65ba95a0@mail.gmail.com> References: <4461BD4A.50201@fedora.pl> <604aa7910605101007l34761477saf3661eb65ba95a0@mail.gmail.com> Message-ID: <4462232E.1010206@fedora.pl> Dnia 05/10/2006 07:07 PM, U?ytkownik Jeff Spaleta napisa?: > what does the desktop entry accomplish in this specific case? Does > this item show up in the menus and spawn a terminal? Yes, that's the purpose of this desktop entry: [rpm-build at X wget]$ cat /usr/share/applications/fedora-htop.desktop [Desktop Entry] Encoding=UTF-8 Version=0.6.1 Name=Htop Type=Application Comment=Show System Processes Terminal=true Exec=htop Path= Icon=htop Categories=ConsoleOnly;System;Application;X-Fedora; GenericName=Process Viewer X-Desktop-File-Install-Version=0.10 [rpm-build at X wget]$ > Is there mimetype information that needs to be registered. No, there is any MimeType key. Regards, Dawid -- ^_* From cweyl at alumni.drew.edu Wed May 10 17:38:15 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 10 May 2006 10:38:15 -0700 Subject: Documentation-only packages In-Reply-To: <446201B3.6000405@timj.co.uk> References: <446093F9.8010808@timj.co.uk> <4460D62F.6010309@drussell.dnsalias.com> <446201B3.6000405@timj.co.uk> Message-ID: <7dd7ab490605101038k4462b917g8184ad6724c0c728@mail.gmail.com> On 5/10/06, Tim Jackson wrote: > Great, that's two votes then (and it's my preferred one in any case). Not three? :) -Chris -- Chris Weyl Ex astris, scientia From gajownik at fedora.pl Wed May 10 17:41:45 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 10 May 2006 19:41:45 +0200 Subject: Desktop entries and terminal applications. In-Reply-To: <4462232E.1010206@fedora.pl> References: <4461BD4A.50201@fedora.pl> <604aa7910605101007l34761477saf3661eb65ba95a0@mail.gmail.com> <4462232E.1010206@fedora.pl> Message-ID: <446225D9.8020204@fedora.pl> Dnia 05/10/2006 07:27 PM, U?ytkownik Dawid Gajownik napisa?: > No, there is any MimeType key. s/is/isn't/ Aghh, silly me. -- ^_* From petersen at redhat.com Wed May 10 21:27:52 2006 From: petersen at redhat.com (Jens Petersen) Date: Thu, 11 May 2006 06:27:52 +0900 Subject: Emacs CVS for Fedora Core 5 In-Reply-To: References: Message-ID: <44625AD8.5000007@redhat.com> [CC'ing fedora-extras-list since you're not the first person to ask me this ;-)] Jes?s Corrius wrote: > Will [there] be an Emacs CVS testing repository for FC5? My idea is to have an emacs22 package contributed to Fedora Extras, it is somewhere on my todo list, though I still hope someone else or upstream beats me to it.... ;-) Jens From j.w.r.degoede at hhs.nl Wed May 10 21:44:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 10 May 2006 23:44:32 +0200 Subject: Splitting content and engine for games where they come 1 one upstream tarbal Message-ID: <44625EC0.2000607@hhs.nl> Hi, I've been pushing about one gcompris release / day the last few days (I fixed a simple bug, but as these things go the fix introduced new bugS). That means that I've been pushing a whopping 60Mb / day. Which IMHO is not really acceptable. I know better testing -> less releases, but sometimes things don't work like that. For example todays gcompris release fixes a bug which is gnome-panel configuration dependent and now amount of testing would have shown it with my panel config. So I was thinking that I really need a seperate package for the gcompris-data where most of the Mb's are. Just creating a seperate sub-package won't help since that will get build with a new release of the main engine package too and will have the same newer e-v-r, resulting in the unchanged data still being updated. So I could make 2 spec files, so 2 really seperate packages, both with the same Source0, 3 problems: 1) ugly as hell 2) 2 large srpms, one of which will get updated each engine fix still eating mirror bandwidth to mirror 3) this will take twice the space for srpms on mirrors Now I had this idea which I would like to share: Add a %define which makes building the data sub-package conditonal and when a new release is needed with only engine fixes unset this define in the spec so that the -data subpackage doesn't get rebuild. Advantages: 1) No bandwidth wasted by mirrors mirroring huge data package for each small engine bugfix 2) Even more bandwidth saved by people who regular do a yum update and now only need to download the small engine update. Disadvantage: 1) The SRPM will still be large and get updated as a whole for each engine bugfix. This will take some bandwidth to mirror, but since not many people actually download SRPM's their won't be much other bandwidth usage caused by this. 2) Someone building from an SRPM which was just an engine fix release will first need to set the define to true otherwise he will get an incomplete (no -data package) build. I think that the advantages out way the disadvantages, what do you think? Regards, Hans From bugzilla at redhat.com Wed May 10 23:43:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 10 May 2006 19:43:18 -0400 Subject: [Bug 175237] Review Request: bzr - bazaar-ng distributed revision control system In-Reply-To: Message-ID: <200605102343.k4ANhITC007815@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bzr - bazaar-ng distributed revision control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175237 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From mlh at zip.com.au 2006-05-10 19:43 EST ------- bzr 0.8 is out and much improved. it also likely to be very stable and used for a long time as it is the version most likely to be included with ubuntu's 'long term support' linux release. Is 0.8 expected to make it into extras soon? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed May 10 23:44:24 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 10 May 2006 19:44:24 -0400 Subject: [Bug 175237] Review Request: bzr - bazaar-ng distributed revision control system In-Reply-To: Message-ID: <200605102344.k4ANiOgX008002@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bzr - bazaar-ng distributed revision control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175237 mlh at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mlh at zip.com.au ------- Additional Comments From mlh at zip.com.au 2006-05-10 19:44 EST ------- bzr 0.8 is out and much improved. it also likely to be very stable and used for a long time as it is the version most likely to be included with ubuntu's 'long term support' linux release. Is 0.8 expected to make it into extras soon? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From peter at thecodergeek.com Thu May 11 04:18:49 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 10 May 2006 21:18:49 -0700 Subject: Documentation-only packages In-Reply-To: <446093F9.8010808@timj.co.uk> References: <446093F9.8010808@timj.co.uk> Message-ID: <4462BB29.5050807@thecodergeek.com> Tim Jackson wrote: > 1. Naming. "php-docs" would fit with the usual convention. "php-manual" > would be more descriptive of what it actually is. Preferences anyone? As others have mentioned, I'm in agreement with the "php-manual" naming, as libfoo-docs seems to be the documentation as a subpackage of libfoo. > 2. Versioning. The docs aren't actually versioned as such, but dated. OK > to use date e.g. "20060421" as version number? Seems reasonable to me. Just make sure you note how you obtain the specific dated tarball if needed. > 3. Filesystem location. %{_datadir}/doc/%{name} OK? Or should it be > %{_datadir}/doc/%{name}-%{version}? Why not just make it all %doc and let the RPM macro deal with that? :) > 4. Localisation. The manual is available in many different languages, > distributed separately. I am only proposing to package the English > version at the moment. This creates two issues: > > a) Name - should the package actually be name php-docs-en (or > php-manual-en) rather than php-docs/php-manual? Perhaps you could make one big php-manual package, then make subpackages as needed for each language? -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Thu May 11 05:40:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 06:40:39 +0100 Subject: Splitting content and engine for games where they come 1 one upstream tarbal In-Reply-To: <44625EC0.2000607@hhs.nl> References: <44625EC0.2000607@hhs.nl> Message-ID: <1147326040.20848.5.camel@laurel.intra.city-fan.org> On Wed, 2006-05-10 at 23:44 +0200, Hans de Goede wrote: > Hi, > > I've been pushing about one gcompris release / day the last few days (I > fixed a simple bug, but as these things go the fix introduced new bugS). > > That means that I've been pushing a whopping 60Mb / day. Which IMHO is > not really acceptable. I know better testing -> less releases, but > sometimes things don't work like that. For example todays gcompris > release fixes a bug which is gnome-panel configuration dependent and now > amount of testing would have shown it with my panel config. > > So I was thinking that I really need a seperate package for the > gcompris-data where most of the Mb's are. Just creating a seperate > sub-package won't help since that will get build with a new release of > the main engine package too and will have the same newer e-v-r, > resulting in the unchanged data still being updated. > > So I could make 2 spec files, so 2 really seperate packages, both with > the same Source0, 3 problems: > 1) ugly as hell > 2) 2 large srpms, one of which will get updated each engine fix still > eating mirror bandwidth to mirror > 3) this will take twice the space for srpms on mirrors > > Now I had this idea which I would like to share: > > Add a %define which makes building the data sub-package conditonal and > when a new release is needed with only engine fixes unset this define in > the spec so that the -data subpackage doesn't get rebuild. > Advantages: > 1) No bandwidth wasted by mirrors mirroring huge data package for each > small engine bugfix > 2) Even more bandwidth saved by people who regular do a yum update and > now only need to download the small engine update. > Disadvantage: > 1) The SRPM will still be large and get updated as a whole for each > engine bugfix. This will take some bandwidth to mirror, but since not > many people actually download SRPM's their won't be much other > bandwidth usage caused by this. > 2) Someone building from an SRPM which was just an engine fix release > will first need to set the define to true otherwise he will get an > incomplete (no -data package) build. > > > I think that the advantages out way the disadvantages, what do you think? Another disadvantage is that after a couple of engine-only pushes, the SRPM from which the released game data package was built will no lnger be available on the mirrors. Paul. From paul at city-fan.org Thu May 11 05:47:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 06:47:49 +0100 Subject: Documentation-only packages In-Reply-To: <4462BB29.5050807@thecodergeek.com> References: <446093F9.8010808@timj.co.uk> <4462BB29.5050807@thecodergeek.com> Message-ID: <1147326469.20848.12.camel@laurel.intra.city-fan.org> On Wed, 2006-05-10 at 21:18 -0700, Peter Gordon wrote: > Tim Jackson wrote: > > 1. Naming. "php-docs" would fit with the usual convention. "php-manual" > > would be more descriptive of what it actually is. Preferences anyone? > As others have mentioned, I'm in agreement with the "php-manual" naming, > as libfoo-docs seems to be the documentation as a subpackage of libfoo. +1 > > 2. Versioning. The docs aren't actually versioned as such, but dated. OK > > to use date e.g. "20060421" as version number? > Seems reasonable to me. Just make sure you note how you obtain the > specific dated tarball if needed. +1 > > 3. Filesystem location. %{_datadir}/doc/%{name} OK? Or should it be > > %{_datadir}/doc/%{name}-%{version}? %{_datadir}/doc/%{name} would be better for people wanting to bookmark stuff. > Why not just make it all %doc and let the RPM macro deal with that? :) I think the only %doc stuff in this package should be docs about the manual, not the manual itself. After all, the purpose of installing the package is to get the manual, and if it was all %doc then anyone defaulting rpm to use --excludedocs would get nothing when the package was installed. > > 4. Localisation. The manual is available in many different languages, > > distributed separately. I am only proposing to package the English > > version at the moment. This creates two issues: > > > > a) Name - should the package actually be name php-docs-en (or > > php-manual-en) rather than php-docs/php-manual? > Perhaps you could make one big php-manual package, then make subpackages > as needed for each language? As the languages are distributed separately and could be updated at different times, it makes more sense to keep them as separate packages. Adding the language suffix is a good idea IMHO. Paul. From ville.skytta at iki.fi Thu May 11 06:10:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 11 May 2006 09:10:57 +0300 Subject: Splitting content and engine for games where they come 1 one upstream tarbal In-Reply-To: <1147326040.20848.5.camel@laurel.intra.city-fan.org> References: <44625EC0.2000607@hhs.nl> <1147326040.20848.5.camel@laurel.intra.city-fan.org> Message-ID: <1147327858.2746.7.camel@localhost.localdomain> On Thu, 2006-05-11 at 06:40 +0100, Paul Howarth wrote: > On Wed, 2006-05-10 at 23:44 +0200, Hans de Goede wrote: > > > I think that the advantages out way the disadvantages, what do you think? > > Another disadvantage is that after a couple of engine-only pushes, the > SRPM from which the released game data package was built will no lnger > be available on the mirrors. Right, and for the devel repo, one push would be enough. And anyway, it would cause headaches for people who rebuild the packages for whatever reason. If you're worried about the SRPM sizes, you could ship a trimmed down tarball in both, just include the info how to recreate them from the upstream one. "Ugly as hell" would be an overstatement about this. From Christian.Iseli at licr.org Thu May 11 06:31:32 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 11 May 2006 08:31:32 +0200 Subject: Splitting content and engine for games where they come 1 one upstream tarbal In-Reply-To: Your message of "Thu, 11 May 2006 09:10:57 +0300." <1147327858.2746.7.camel@localhost.localdomain> Message-ID: <200605110631.k4B6Va7L006248@mx3.redhat.com> ville.skytta at iki.fi said: > If you're worried about the SRPM sizes, you could ship a trimmed down tarball > in both, just include the info how to recreate them from the upstream one. > "Ugly as hell" would be an overstatement about this. That'd be my preference too. And you might also try to convince upstream to do the split (for all the reasons you mentioned)... Cheers, Christian From laurent.rineau__fc_extra at normalesup.org Thu May 11 07:04:41 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Thu, 11 May 2006 09:04:41 +0200 Subject: SSL certificate of https://admin.fedora.redhat.com/ Message-ID: <200605110904.41317@rineau.schtroumpfette> Does anybody know where one can download the certificate of the certificate authority (CA) that issued the certificate of https://admin.fedora.redhat.com/? I prefere to download CA (in order to make my browser trust them) instead of trusting individual webserver certificates. Another annoying stuff: the certificate of https://admin.fedora.redhat.com/ has "admin.fedoraproject.org" as Common Name. It should be "admin.fedora.redhat.com", so avoid warnings of several web browsers. And last question: in https://admin.fedora.redhat.com/accounts/userbox.cgi, in the field named "SSHv2 Public Key", can I upload a .ssh/authorized_keys, instead of only one ~/.ssh/id_dsa.pub? I use several unix accounts, with different ssh keys. I would enjoy to be able to use these different accounts to connect to cvs.fedora.redhat.com. From buildsys at fedoraproject.org Thu May 11 08:16:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 04:16:52 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060511081652.89A7715216C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 3 cfengine-2.1.20-3.fc3 lablgl-1.02-7.fc3 lablgtk-2.6.0-4.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 08:16:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 04:16:52 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060511081652.8101415216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 7 bzr-0.8-1.fc4 cfengine-2.1.20-3.fc4 htop-0.6.1-2.fc4 lablgl-1.02-7.fc4 lablgtk-2.6.0-4.fc4 par2cmdline-0.4-9.fc4 unifdef-1.171-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 08:16:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 04:16:52 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060511081652.7452415216A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 7 bzr-0.8-1.fc5 cfengine-2.1.20-3.fc5 htop-0.6.1-2.fc5 lablgl-1.02-7.fc5 lablgtk-2.6.0-4.fc5 par2cmdline-0.4-9.fc5 unifdef-1.171-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 08:16:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 04:16:52 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060511081652.6977D152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From tcallawa at redhat.com Thu May 11 11:55:15 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 11 May 2006 06:55:15 -0500 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <4460DD03.1030603@ieee.org> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> <4460DD03.1030603@ieee.org> Message-ID: <1147348515.6598.14.camel@localhost.localdomain> On Tue, 2006-05-09 at 13:18 -0500, Quentin Spencer wrote: > Do I dare suggest that this might be a place where using an epoch might > be justified? Actually, this would be one of the rare valid cases for epoch. ~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 jima at beer.tclug.org Thu May 11 13:13:05 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 11 May 2006 08:13:05 -0500 (CDT) Subject: SSL certificate of https://admin.fedora.redhat.com/ In-Reply-To: <200605110904.41317@rineau.schtroumpfette> References: <200605110904.41317@rineau.schtroumpfette> Message-ID: On Thu, 11 May 2006, Laurent Rineau wrote: > Does anybody know where one can download the certificate of the certificate > authority (CA) that issued the certificate of > https://admin.fedora.redhat.com/? > > I prefere to download CA (in order to make my browser trust them) instead of > trusting individual webserver certificates. I can't answer this, but I agree with the idea. > And last question: in https://admin.fedora.redhat.com/accounts/userbox.cgi, in > the field named "SSHv2 Public Key", can I upload a .ssh/authorized_keys, > instead of only one ~/.ssh/id_dsa.pub? I use several unix accounts, with > different ssh keys. I would enjoy to be able to use these different accounts > to connect to cvs.fedora.redhat.com. Why don't you just use the same keyfile on all of your hosts? The filename doesn't *need* to be named id_dsa; you can configure ssh to use a different file as per these instructions: https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c73 Jima From laurent.rineau__fc_extra at normalesup.org Thu May 11 13:24:44 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Thu, 11 May 2006 15:24:44 +0200 Subject: SSL certificate of https://admin.fedora.redhat.com/ In-Reply-To: References: <200605110904.41317@rineau.schtroumpfette> Message-ID: <200605111524.44065@rineau.schtroumpfette> On Thursday 11 May 2006 15:13, Jima wrote: > Why don't you just use the same keyfile on all of your hosts? Because it is *bad*? :-) Seriously, I avoid to compromise my keys by transporting them on the network (even cyphered). > The > filename doesn't *need* to be named id_dsa; you can configure ssh to use a > different file as per these instructions: > https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c73 Incorrect link. :-( Anyway, I know the use of .ssh/config If I cannot specify several SSH keys, I will create a special key for my CVS account, that I will transport on all my unix accounts, as you suggest. From jima at beer.tclug.org Thu May 11 13:32:59 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 11 May 2006 08:32:59 -0500 (CDT) Subject: SSL certificate of https://admin.fedora.redhat.com/ In-Reply-To: <200605111524.44065@rineau.schtroumpfette> References: <200605110904.41317@rineau.schtroumpfette> <200605111524.44065@rineau.schtroumpfette> Message-ID: On Thu, 11 May 2006, Laurent Rineau wrote: > On Thursday 11 May 2006 15:13, Jima wrote: >> Why don't you just use the same keyfile on all of your hosts? > > Because it is *bad*? :-) > > Seriously, I avoid to compromise my keys by transporting them on the network > (even cyphered). If you can't trust SSH (well, SCP) to transfer keyfiles securely, can you trust it for *anything*? >> The >> filename doesn't *need* to be named id_dsa; you can configure ssh to use a >> different file as per these instructions: > >> https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c73 > > Incorrect link. :-( Oops! :-P https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369#c73 Funny, I guess after you submit a comment, the resulting page has broken links. Cute. > Anyway, I know the use of .ssh/config > > If I cannot specify several SSH keys, I will create a special key for my CVS > account, that I will transport on all my unix accounts, as you suggest. That's what I did, yeah. I'm not sure how much overhead would be entailed in adding authorized_keys support. Jima From bugzilla at redhat.com Thu May 11 14:12:51 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 11 May 2006 10:12:51 -0400 Subject: [Bug 175237] Review Request: bzr - bazaar-ng distributed revision control system In-Reply-To: Message-ID: <200605111412.k4BECpEI011457@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: bzr - bazaar-ng distributed revision control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175237 ------- Additional Comments From shahms at shahms.com 2006-05-11 10:12 EST ------- Packages compiled yesterday should be in today's push. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From orion at cora.nwra.com Thu May 11 14:43:58 2006 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 11 May 2006 08:43:58 -0600 (MDT) Subject: repodata on download.fedora.redhat.com not up to date Message-ID: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> It looks like the repodata directories for fedora extras on download.fedora.redhat.com have not been updated since May 8. [DIR] repodata/ 08-May-2006 09:04 - - Orion From laurent.rineau__fc_extra at normalesup.org Thu May 11 14:53:48 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Thu, 11 May 2006 16:53:48 +0200 Subject: repodata on download.fedora.redhat.com not up to date In-Reply-To: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> References: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> Message-ID: <200605111653.48106@rineau.schtroumpfette> On Thursday 11 May 2006 16:43, orion at cora.nwra.com wrote: > It looks like the repodata directories for fedora extras on > download.fedora.redhat.com have not been updated since May 8. No package has been signed since Mon May 8 14:17. See: http://buildsys.fedoraproject.org/build-status/success.psp Just wait. :-) From tibbs at math.uh.edu Thu May 11 15:42:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 11 May 2006 10:42:25 -0500 Subject: repodata on download.fedora.redhat.com not up to date In-Reply-To: <200605111653.48106@rineau.schtroumpfette> (Laurent Rineau's message of "Thu, 11 May 2006 16:53:48 +0200") References: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> <200605111653.48106@rineau.schtroumpfette> Message-ID: >>>>> "LR" == Laurent Rineau writes: LR> No package has been signed since Mon May 8 14:17. See: LR> http://buildsys.fedoraproject.org/build-status/success.psp Packages are not removed from that page when they are signed; you cannot use it to determine when the last push was. - J< From bugs.michael at gmx.net Thu May 11 15:46:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 May 2006 17:46:58 +0200 Subject: repodata on download.fedora.redhat.com not up to date In-Reply-To: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> References: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> Message-ID: <20060511174658.5693b798.bugs.michael@gmx.net> On Thu, 11 May 2006 08:43:58 -0600 (MDT), orion at cora.nwra.com wrote: > It looks like the repodata directories for fedora extras on > download.fedora.redhat.com have not been updated since May 8. > > [DIR] repodata/ 08-May-2006 09:04 - > > - Orion Known problem for at least FE-4 and FE-5. I can't do anything about it since further file access permissions are wrong. This has gone unnoticed due to a bad error return code (see my earlier CVS commit of today). From jpo at lsd.di.uminho.pt Thu May 11 15:49:22 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 11 May 2006 16:49:22 +0100 Subject: repodata on download.fedora.redhat.com not up to date (and inconsistent) In-Reply-To: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> References: <1097.71.208.222.217.1147358638.squirrel@www.cora.nwra.com> Message-ID: <44635D02.9070207@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 orion at cora.nwra.com wrote: > It looks like the repodata directories for fedora extras on > download.fedora.redhat.com have not been updated since May 8. > > [DIR] repodata/ 08-May-2006 09:04 - And the one that is still available has this problems: ... Downloading Packages: (1/3): perl-Test-Differences-0.47-1.fc5.noarch.rpm 15 kB 00:00 ftp://ftp.di.uminho.pt/pub/fedora/extras/5/i386/perl-Test-Differences-0.47-1.fc5.noarch.rpm: [Errno -1] Package does not match checksum Trying other mirror. (2/3): perl-Test-Prereq-1.030-1.fc5.noarch.rpm 16 kB 00:00 ftp://ftp.di.uminho.pt/pub/fedora/extras/5/i386/perl-Test-Prereq-1.030-1.fc5.noarch.rpm: [Errno -1] Package does not match checksum Trying other mirror. (3/3): perl-Module-Info-0.30-2.fc5.noarch.rpm 40 kB 00:00 ftp://ftp.di.uminho.pt/pub/fedora/extras/5/i386/perl-Module-Info-0.30-2.fc5.noarch.rpm: [Errno -1] Package does not match checksum Trying other mirror. 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEY10Cl0metZG9hRsRAiliAKCXtCVcKMPrLt0zyDOG4GCIDQWhPgCfU4fC 0W7H3KLBlQ4hnrNEwkWmC4I= =27wZ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From jonathan.underwood at gmail.com Thu May 11 16:05:17 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 11 May 2006 17:05:17 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147348515.6598.14.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> <4460DD03.1030603@ieee.org> <1147348515.6598.14.camel@localhost.localdomain> Message-ID: <645d17210605110905g27fdf14awf6e824fea612d995@mail.gmail.com> On 11/05/06, Tom 'spot' Callaway wrote: > On Tue, 2006-05-09 at 13:18 -0500, Quentin Spencer wrote: > > > Do I dare suggest that this might be a place where using an epoch might > > be justified? > > Actually, this would be one of the rare valid cases for epoch. Not very friendly from the user perspective though - how is Joe User supposed to know which epoch refers to which package? Or did I misunderstand the suggestion? From cweyl at alumni.drew.edu Thu May 11 16:16:43 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 11 May 2006 09:16:43 -0700 Subject: mono / ".pc files in -devel packges" guideline Message-ID: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> Hey all-- I need a little guidance here. I'm at the tail end of reviewing daap-sharp, and the one sticky point is that the package includes a pkgconfig file -- and no other development files. The review guidelines list it as a "MUST" to package .pc files in a -devel package. The mono sig/packaging page says:[1] "Most mono packages install a .pc file. Normally, the .pc file is part of the -devel package. However, mono packages don't typically come with the sorts of things you'd find in -devel packages (headers etc), so the -devel package would contain just the .pc file. "You can still generate a -devel file, but given the above, it would probably be acceptable to include the .pc in the non -devel rpm itself." I tend to agree with the point of the mono-packaging page, esp. as it's what is commonly done with perl modules. (e.g. perl-DBI includes its .h files, such that when building DBD's we can just say "BuildRequires: perl(DBI)" rather than trying to figure out how to split off the (typically) one header file and then require it at build time seamlessly.) Unfortunately, it still goes against the "MUST". Is this a hard and fast rule? Or is there leeway to bend it in cases like this, where it clearly makes sense to do so for a specific package or category of packages? -Chris [1] http://fedoraproject.org/wiki/Packaging/Mono -- Chris Weyl Ex astris, scientia From jonathan.underwood at gmail.com Thu May 11 16:26:20 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 11 May 2006 17:26:20 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> Message-ID: <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> On 10/05/06, Jonathan Underwood wrote: > So - can anyone come up with a better naming scheme than the one > above? I hope so :) To answer my own question - here's a proposal: I could rename the muse package to emacsen-muse, such that the binary rpms are: emacsen-muse (containing the common stuff, and required by the packages below) emacs-muse xemacs-muse emacs-muse-el xemacsen-muse.el The SRPM would be emacsen-muse, and that would also then be the module name in bugzilla etc. Terrible idea? Should this be the guideline specific to (x)emacs packages which build for both flavours? If the FESCO could reach a decision on this it would be useful - then I can move the emacs muse package out of the way, and let the packagers of the other two muse programs fight over the vacant namespace :) J From rdieter at math.unl.edu Thu May 11 16:51:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 11 May 2006 11:51:05 -0500 Subject: mono / ".pc files in -devel packges" guideline References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> Message-ID: Chris Weyl wrote: > I need a little guidance here. I'm at the tail end of reviewing > daap-sharp, and the one sticky point is that the package includes a > pkgconfig file -- and no other development files. > > The review guidelines list it as a "MUST" to package .pc files in a > -devel package. What is the purpose of this .pc file? Most .pc files I've seen are -devel related, but that doesn't mean *all* of them are. They should be packaged according to its purpose. -- Rex From ville.skytta at iki.fi Thu May 11 17:11:21 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 11 May 2006 20:11:21 +0300 Subject: extras-buildsys/utils extras-push-new,1.8,1.9 In-Reply-To: <200605111649.k4BGn1EJ025320@cvs-int.fedora.redhat.com> References: <200605111649.k4BGn1EJ025320@cvs-int.fedora.redhat.com> Message-ID: <1147367481.2746.24.camel@localhost.localdomain> On Thu, 2006-05-11 at 09:49 -0700, Michael Schwendt wrote: > syncing twice is nice in theory, but since extras-repobuild.py kills > repoview data, it is not so good unless we improve extras-repobuild.py > to backup/reinstall repoview data FYI, there's a patch for createrepo that makes it tolerate (auto-restore) unknown files in repodata dirs which would make blowing away the repoview data unnecessary at https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=595 From kevin-fedora-extras at scrye.com Thu May 11 18:02:02 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 11 May 2006 12:02:02 -0600 (MDT) Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> Message-ID: <20060511.120202.170164697.kevin@scrye.com> >>>>> "Jonathan" == Jonathan Underwood writes: Jonathan> On 10/05/06, Jonathan Underwood Jonathan> wrote: >> So - can anyone come up with a better naming scheme than the one >> above? I hope so :) Jonathan> To answer my own question - here's a proposal: I could Jonathan> rename the muse package to emacsen-muse, such that the Jonathan> binary rpms are: Jonathan> emacsen-muse (containing the common stuff, and required by Jonathan> the packages below) emacs-muse xemacs-muse emacs-muse-el Jonathan> xemacsen-muse.el Jonathan> The SRPM would be emacsen-muse, and that would also then be Jonathan> the module name in bugzilla etc. Jonathan> Terrible idea? No, I like that idea. emacsen seems to convey that it works for more than one emacs variant. :) Debian appears to use that in at least one package (emacsen-common), and http://www.emacswiki.org/cgi-bin/emacs-en/Emacsen has it defined. Jonathan> Should this be the guideline specific to (x)emacs packages Jonathan> which build for both flavours? I think it should. Would be good to have them all be consistent. Jonathan> If the FESCO could reach a decision on this it would be Jonathan> useful - then I can move the emacs muse package out of the Jonathan> way, and let the packagers of the other two muse programs Jonathan> fight over the vacant namespace :) Sounds good. It didn't get discussed at this weeks meeting, but perhaps one of the FESCO folks could put it up on the adgenda for next week? Jonathan> J kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cweyl at alumni.drew.edu Thu May 11 18:30:57 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 11 May 2006 11:30:57 -0700 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> Message-ID: <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> On 5/11/06, Rex Dieter wrote: > What is the purpose of this .pc file? Most .pc files I've seen are -devel > related, but that doesn't mean *all* of them are. They should be packaged > according to its purpose. It "looks" like devel to me, but I'm no mono guy -- Brian? :) [build at zeus daap-sharp-0.3.3]$ cat daap-sharp.pc.in prefix=@prefix@ exec_prefix=@exec_prefix@ libdir=@libdir@ includedir=@includedir@ Libraries=@libdir@/daap-sharp/daap-sharp.dll Name: daap-sharp Description: daap-sharp Version: @VERSION@ Requires: Libs: -r:${Libraries} --EOF-- (Of course, that's the unretouched source file, but you get the idea.) Even if it is for development, is it worth forcing it off into a -devel package for just one file? -Chris -- Chris Weyl Ex astris, scientia From chris.stone at gmail.com Thu May 11 18:25:29 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 11 May 2006 11:25:29 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060511.120202.170164697.kevin@scrye.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> Message-ID: What's wrong with "emacs-common-muse"? Use of epochs would make sense to resolve Obsolete/Provides confilits. From peter at thecodergeek.com Thu May 11 18:44:45 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 11 May 2006 11:44:45 -0700 (PDT) Subject: Documentation-only packages In-Reply-To: <1147326469.20848.12.camel@laurel.intra.city-fan.org> References: <446093F9.8010808@timj.co.uk> <4462BB29.5050807@thecodergeek.com> <1147326469.20848.12.camel@laurel.intra.city-fan.org> Message-ID: <50259.127.0.0.1.1147373085.squirrel@thecodergeek.com> Paul Howarth wrote: > %{_datadir}/doc/%{name} would be better for people wanting to bookmark > stuff. Well, the kernel-doc package installs its Documentation to %{_datadir}/doc/%{name}-%{version}, but is that something that should be consistent in other packages (since that -doc is a subpackage and this is not)? > I think the only %doc stuff in this package should be docs about the > manual, not the manual itself. After all, the purpose of installing the > package is to get the manual, and if it was all %doc then anyone > defaulting rpm to use --excludedocs would get nothing when the package > was installed. Ah. I see. Thanks. :) > As the languages are distributed separately and could be updated at > different times, it makes more sense to keep them as separate packages. > Adding the language suffix is a good idea IMHO. I hadn't thought of that. Thanks for clearing it up for me. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From buildsys at fedoraproject.org Thu May 11 19:13:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:13:26 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060511191326.B6669152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 23 anjuta-1.2.4a-2.fc6 bzflag-2.0.6-1.fc6 bzr-0.8-1.fc6 ctapi-cyberjack-2.0.8-13.fc6 gcompris-7.4-10.fc6 gtkwave-3.0.2-1.fc6 htop-0.6.1-2.fc6 lablgl-1.02-7.fc6 lablgtk-2.6.0-4.fc6 libgda-1.9.100-6.fc6 libnfnetlink-0.0.14-3.fc6 par2cmdline-0.4-9.fc6 perl-Config-Tiny-2.07-1.fc6 perl-IPC-Run-0.80-1.fc6 perl-PPI-1.113-1.fc6 perl-Test-Cmd-1.05-1.fc6 php-eaccelerator-5.1.3_0.9.5-0.2.beta2.fc6 proftpd-1.3.0-3.fc6 python-clientform-0.2.2-4.fc6 python-paramiko-1.5.4-2.fc6 python-psyco-1.5.1-2.fc6 synergy-1.3.1-1.fc6 xemacs-sumo-20060510-1.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:13:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:13:26 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060511191326.D866515216C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:13:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:13:26 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060511191326.C3CCA15216A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 7 ctapi-cyberjack-2.0.8-13.fc5 gcompris-7.4-10.fc5 libgda-1.9.100-6.fc5 perl-Config-Tiny-2.07-1.fc5 perl-IPC-Run-0.80-1.fc5 perl-PPI-1.113-1.fc5 perl-Test-Cmd-1.05-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:13:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:13:26 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060511191326.CE9C915216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 5 ctapi-cyberjack-2.0.8-13.fc4 libkexif-0.2.2-3.fc4 perl-Config-Tiny-2.07-1.fc4 perl-IPC-Run-0.80-1.fc4 perl-Test-Cmd-1.05-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at city-fan.org Thu May 11 19:28:58 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 20:28:58 +0100 Subject: Documentation-only packages In-Reply-To: <50259.127.0.0.1.1147373085.squirrel@thecodergeek.com> References: <446093F9.8010808@timj.co.uk> <4462BB29.5050807@thecodergeek.com> <1147326469.20848.12.camel@laurel.intra.city-fan.org> <50259.127.0.0.1.1147373085.squirrel@thecodergeek.com> Message-ID: <1147375739.21889.1.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 11:44 -0700, Peter Gordon wrote: > Paul Howarth wrote: > > %{_datadir}/doc/%{name} would be better for people wanting to bookmark > > stuff. > Well, the kernel-doc package installs its Documentation to > %{_datadir}/doc/%{name}-%{version}, but is that something that should be > consistent in other packages (since that -doc is a subpackage and this is > not)? The kernel is a special case really as it's normal for multiple versions to be installed at the same time and it's necessary to distinguish between the versions. Paul. From buildsys at fedoraproject.org Thu May 11 19:35:58 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:35:58 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060511193558.EED42152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 perl-Net-SSLeay-1.26-2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:36:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:36:08 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060511193608.959CF15216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 2 abcm2ps-4.12.17-1.fc5 gpa-0.7.3-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:36:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:36:03 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060511193603.DFBC215216A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 2 abcm2ps-4.12.17-1.fc4 perl-Net-SSLeay-1.26-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 11 19:36:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 11 May 2006 15:36:15 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060511193615.829B515216C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 6 abcm2ps-4.12.17-1.fc6 childsplay-0.81.8-3.fc6 childsplay_plugins-0.80.7-3.fc6 glib-1.2.10-21.fc6 gpa-0.7.3-2.fc6 gtk+-1.2.10-52.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From jonathan.underwood at gmail.com Thu May 11 19:56:07 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 11 May 2006 20:56:07 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> Message-ID: <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> On 11/05/06, Christopher Stone wrote: > What's wrong with "emacs-common-muse"? Because that would be the package name, and the name appearing in bugzilla. Not easy for an xemacs-muse user with a bug to find and file a bug against. From bdpepple at ameritech.net Thu May 11 19:08:33 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 11 May 2006 15:08:33 -0400 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> Message-ID: <1147374513.14342.8.camel@shuttle.piedmont.com> On Thu, 2006-05-11 at 11:30 -0700, Chris Weyl wrote: > On 5/11/06, Rex Dieter wrote: > > What is the purpose of this .pc file? Most .pc files I've seen are -devel > > related, but that doesn't mean *all* of them are. They should be packaged > > according to its purpose. > > It "looks" like devel to me, but I'm no mono guy -- Brian? :) > > [build at zeus daap-sharp-0.3.3]$ cat daap-sharp.pc.in > prefix=@prefix@ > exec_prefix=@exec_prefix@ > libdir=@libdir@ > includedir=@includedir@ > Libraries=@libdir@/daap-sharp/daap-sharp.dll > > > Name: daap-sharp > Description: daap-sharp > Version: @VERSION@ > Requires: > Libs: -r:${Libraries} > --EOF-- > > (Of course, that's the unretouched source file, but you get the idea.) > > Even if it is for development, is it worth forcing it off into a > -devel package for just one file? Correct, this is used by pkconfig to pull in lib path when compiling. The practice has been in Core & Extras for the most part (the only exception I can think of is mono-devel) to include this in the main package. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Thu May 11 21:04:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 May 2006 21:04:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-11 Message-ID: <20060511210427.4558.33575@rawhide.intranet> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Thu May 11 21:04:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 May 2006 21:04:24 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-11 Message-ID: <20060511210424.4555.37139@rawhide.intranet> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From bugs.michael at gmx.net Thu May 11 21:04:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 May 2006 21:04:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-11 Message-ID: <20060511210442.4560.94157@rawhide.intranet> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 Terminal 0.2.4-7.fc5.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 grip 1:3.2.0-10.fc5.i386 gtktalog 1.0.4-7.fc5.i386 gtkterm 0.99.5-1.fc6.i386 perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.i386 xbindkeys 1.7.2-4.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc Terminal 0.2.4-7.fc5.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc grip 1:3.2.0-10.fc5.ppc gtktalog 1.0.4-7.fc5.ppc gtkterm 0.99.5-1.fc6.ppc perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.ppc xbindkeys 1.7.2-4.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 Terminal 0.2.4-7.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 grip 1:3.2.0-10.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 gtkterm 0.99.5-1.fc6.x86_64 perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.x86_64 xbindkeys 1.7.2-4.fc5.x86_64 ====================================================================== New report for: eric.tanguy AT univ-nantes.fr package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 ====================================================================== New report for: gauret AT free.fr package: xbindkeys - 1.7.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 package: xbindkeys - 1.7.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) package: xbindkeys - 1.7.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 ====================================================================== New report for: steve AT silug.org package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 ====================================================================== New report for: kevin-redhat-bugzilla AT tummy.com package: Terminal - 0.2.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: Terminal - 0.2.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: Terminal - 0.2.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 ====================================================================== New report for: j.w.r.degoede AT hhs.nl package: gtkterm - 0.99.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gtkterm - 0.99.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: gtkterm - 0.99.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 ====================================================================== New report for: toshio AT tiki-lounge.com package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 ====================================================================== New report for: gemi AT bluewin.ch package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 ====================================================================== New report for: toth_bandi AT users.sourceforge.net package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 ====================================================================== New report for: adrian AT lisas.de package: grip - 1:3.2.0-10.fc5.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: grip - 1:3.2.0-10.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: grip - 1:3.2.0-10.fc5.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From jwboyer at jdub.homelinux.org Thu May 11 23:39:51 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 11 May 2006 18:39:51 -0500 Subject: New python-clientform owner Message-ID: <1147390791.2512.135.camel@vader.jdub.homelinux.org> Luke Macken now owns the python-clientform package. He had a dependency on it and showed interest so it sounded like a good idea to me. Thanks Luke! FYI. josh -------------- 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 michael at knox.net.nz Fri May 12 02:48:47 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 12 May 2006 14:48:47 +1200 Subject: AWOL owners and stale packages. Message-ID: <4463F78F.1080908@knox.net.nz> This is a request for comment and perhaps an informal proposal for how to handle packages with AWOL owners. I have spent sometime discussing this process with a work college, a debian developer, on how best practice and the appropriate etiquette could be shown to the current owner of a said package. He suggested that debian's NMU or Non-Maintainer Upload, processed worked well within the debian development community. I have read through this policy of debian's and think that it addresses the issues nicely of ensuring that packages are not left to become stale and not offend packager owners. I am proposing we (Fedora Extras) adopt the same process. It would need to be made Fedora relevant and I would hope that people will see the plus in such a process. The over all aim is to avoid "stale" packages in Extras, more swiftly pick up on unmaintained packages and hopefully encourage people to work on these packages by providing a process in which people can fix them. An example would be: http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html This also allows people to demonstrate that they have a willingness to maintain a package and are capable of doing so. You can review debian's process here: http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu Some items that would need clarifying, would be the time needed to be considered "reasonable" in the time of contact and delay. Also, there would need to be persons responsible for "approving" the take over of a package. Please note, this is not to address or replace the orphan process, but to help in cases where the package has not been orphaned and the maintainer is not contactable. If a process like this is received well, then I am happy to draft it for FESCo to ponder. Regards Michael From peter at thecodergeek.com Fri May 12 05:20:23 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 11 May 2006 22:20:23 -0700 Subject: Documentation-only packages In-Reply-To: <1147375739.21889.1.camel@laurel.intra.city-fan.org> References: <446093F9.8010808@timj.co.uk> <4462BB29.5050807@thecodergeek.com> <1147326469.20848.12.camel@laurel.intra.city-fan.org> <50259.127.0.0.1.1147373085.squirrel@thecodergeek.com> <1147375739.21889.1.camel@laurel.intra.city-fan.org> Message-ID: <44641B17.8080203@thecodergeek.com> Paul Howarth wrote: > The kernel is a special case really as it's normal for multiple versions > to be installed at the same time and it's necessary to distinguish > between the versions. Oh yeah. For a moment there I complete forgot about the multiple-installed-versions thing. Thanks for clearing that up for me. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From alexl at users.sourceforge.net Fri May 12 06:36:45 2006 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 11 May 2006 23:36:45 -0700 Subject: stellarium is broken on FC-4 Message-ID: With recent push, stellarium appears to fail to install properly on FC-4. I have filed a bug: https://bugzilla.redhat.com/191456 Downloading Packages: (1/1): stellarium-0.8.0-2 100% |=========================| 5.0 MB 01:44 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: stellarium ######################### [1/1] error: unpacking of archive failed on file /usr/share/stellarium/textures/constellation-art/hercules.png;4463fdbc: cpio: read Application runs, but image files are missing. rpm reports the package as not being installed at all: $ rpm -q stellarium package stellarium is not installed From Eric.Tanguy at univ-nantes.fr Fri May 12 09:39:38 2006 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Fri, 12 May 2006 11:39:38 +0200 (CEST) Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] Message-ID: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> Someone could help me with this ? there is new guile package version in rawhide, i have just to rebuild the package against the new packages to solve this ? Thanks Eric ---------------------------- Message original ---------------------------- Objet: Broken dependencies in Fedora Extras development - 2006-05-11 De: "Michael Schwendt" Date: Jeu 11 mai 2006 23:04 ?: eric.tanguy at univ-nantes.fr -------------------------------------------------------------------------- This is an automated mail created by an experimental script. Your following packages in the repository contain broken dependencies: package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 From paul at all-the-johnsons.co.uk Fri May 12 09:41:54 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Fri, 12 May 2006 10:41:54 +0100 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> Message-ID: <1147426914.2350.18.camel@mrwibble.mrwobble> Hi, > there is new guile package version in rawhide, i have just to rebuild the > package against the new packages to solve this ? Yep. It happened with anjuta and the latest version of vte as well. Has anyone rebuilt grip yet as vte shot that one as well. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugs.michael at gmx.net Fri May 12 11:19:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 12 May 2006 13:19:55 +0200 Subject: AWOL owners and stale packages. In-Reply-To: <4463F78F.1080908@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> Message-ID: <20060512131955.5d5055a4.bugs.michael@gmx.net> On Fri, 12 May 2006 14:48:47 +1200, Michael J. Knox wrote: > This is a request for comment and perhaps an informal proposal for how > to handle packages with AWOL owners. > > I have spent sometime discussing this process with a work college, a > debian developer, on how best practice and the appropriate etiquette > could be shown to the current owner of a said package. He suggested that > debian's NMU or Non-Maintainer Upload, processed worked well within the > debian development community. > > I have read through this policy of debian's and think that it addresses > the issues nicely of ensuring that packages are not left to become stale > and not offend packager owners. > > I am proposing we (Fedora Extras) adopt the same process. It would need > to be made Fedora relevant and I would hope that people will see the > plus in such a process. > > The over all aim is to avoid "stale" packages in Extras, more swiftly > pick up on unmaintained packages and hopefully encourage people to work > on these packages by providing a process in which people can fix them. First of all, I think you mix a few things. Specifically, the NMU talks about "fixes", "bugs" and "serious problems", while you talk about "stale", "unmaintained" packages and "the take over of a package". Not sure whether you want to merge all that into a single policy. The main reason why NMUs are done is when a developer needs to fix another developer's packages in order to address serious problems or crippling bugs or when the package maintainer is unable to release a fix in a timely fashion. I find that description poor. It is not clear when and why "another developer's packages" are touched without the package maintainer doing it. Because as soon as developers talk to eachother (e.g. in bugzilla), collaborative package development becomes possible without additional bureaucracy. Packagers at FE have done this multiple times before for rebuilds, fixes and even version upgrades. If the NMU is only about unreachable maintainers, the Debian folk has added a lot of bureaucracy and complexity with questionable benefit and increased requirements for tracking (e.g. that applied changes are not reverted the next time the maintainer returns and imports his own package). Noticably, the NMU is independent from what the security team does. When a security bug is detected, the security team may do an NMU, using their own rules. Please refer to Handling security-related bugs, Section 5.8.5 for more information. Here are the sections on dealing with MIA/AWOL maintainers: Orphaning a package http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-orphaning Adopting a package (!) http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-adopting Dealing with inactive and/or unreachable maintainers http://www.debian.org/doc/manuals/developers-reference/ch-beyond-pkging.en.html#s-mia-qa Collaborative maintenance http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-collaborative-maint What we most certainly don't want is that arbitrary developers use a procedure like the NMU to do version upgrades without good reason. I like that the NMU requires developers to file bug reports (including unified diffs) for the changes they plan to apply. And if a package maintainer is believed to be MIA/AWOL, we don't want that arbitrary developers use this opportunity to do upgrades without the package getting a new maintainer. The NMU requires developers to watch incoming bug reports, since their changes may cause new problems. This adds quite some complexity to the package maintainership model. > An example would be: > > http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html Start tracking the date and number of contact attempts inside the bugzilla ticket. Mention whether your email bounced. Announce that you plan to take over the package next week. See below. > This also allows people to demonstrate that they have a willingness to > maintain a package and are capable of doing so. > > You can review debian's process here: > > http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu > > Some items that would need clarifying, would be the time needed to be > considered "reasonable" in the time of contact and delay. Also, there > would need to be persons responsible for "approving" the take over of a > package. > > Please note, this is not to address or replace the orphan process, but > to help in cases where the package has not been orphaned and the > maintainer is not contactable. Too much at once. If a maintainer has not responded for more than six weeks (as in the given example where a build is missing!), it should be in the maintainers best interest that somebody else takes over package development. And we ought to start tracking maintainers, which are believed to be MIA/AWOL. > If a process like this is received well, then I am happy to draft it for > FESCo to ponder. What I don't like at all is the uncertain package status and ownership. Packages without a maintainer, but which are touched occasionally by arbitrary people. With the next big problems inside the package and nobody interested in contributing maintenance, we would be back at the drawing board, since the package is still without maintainer/owner. I would appreciate if we started bottom-up with a procedure for "Adoption of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then we enhance the procedure in order to permit certain actions (like requesting (re-)builds, fixing grave bugs) while it is still being waited for a response by the maintainer. It will probably, except for security issues, look like: - notify maintainer - wait X days - notify maintainer about planned take-over and planned actions [e.g. (re-)builds, fixes] - wait another X-Y days - touch the package - maybe wait another Z days - take over the package in owners.list From fedora at camperquake.de Fri May 12 11:26:31 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 12 May 2006 13:26:31 +0200 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> Message-ID: <20060512132631.5fa7d17c@duras.int.addix.net> Hi. On Fri, 12 May 2006 11:39:38 +0200 (CEST), Eric TANGUY wrote: > Someone could help me with this ? > there is new guile package version in rawhide, i have just to rebuild > the package against the new packages to solve this ? If you are lucky, yes. It may be that the programming interface changed so that patches for your application are necessary. From paul at city-fan.org Fri May 12 13:17:34 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 May 2006 14:17:34 +0100 Subject: License query Message-ID: <44648AEE.40702@city-fan.org> I'm thinking of packaging perl-NTLM; it has the following license terms: COPYRIGHT AND LICENCE This application is free software. This code is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may freely use, copy and distribute this software as long as all copyright notices, including this notice, remain intact and that you do not try to claim it as your own or try to sell it. You may alter the code as long as you send me any diffs (this will ensure that you have an easier time of it when you upgrade ;). It looks quite free apart from the "as long as ... you do not ... try to sell it" clause, which I think disqualifies it as free software despite what the first sentence of the license terms states. Is this OK for Extras or not? Paul. From nphilipp at redhat.com Fri May 12 13:20:31 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 12 May 2006 15:20:31 +0200 Subject: License query In-Reply-To: <44648AEE.40702@city-fan.org> References: <44648AEE.40702@city-fan.org> Message-ID: <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> On Fri, 2006-05-12 at 14:17 +0100, Paul Howarth wrote: > I'm thinking of packaging perl-NTLM; it has the following license terms: > > COPYRIGHT AND LICENCE > > This application is free software. This code is distributed in the hope > that it will be useful, but WITHOUT ANY WARRANTY; without even the > implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > You may freely use, copy and distribute this software as long as all > copyright notices, including this notice, remain intact and that you do > not try to claim it as your own or try to sell it. You may alter the > code as long as you send me any diffs (this will ensure that you have an > easier time of it when you upgrade ;). > > > > > It looks quite free apart from the "as long as ... you do not ... try to > sell it" clause, which I think disqualifies it as free software despite > what the first sentence of the license terms states. Is this OK for > Extras or not? I don't think so. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From tcallawa at redhat.com Fri May 12 13:53:39 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 May 2006 08:53:39 -0500 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> Message-ID: <1147442019.6598.63.camel@localhost.localdomain> On Thu, 2006-05-11 at 20:56 +0100, Jonathan Underwood wrote: > On 11/05/06, Christopher Stone wrote: > > What's wrong with "emacs-common-muse"? > > Because that would be the package name, and the name appearing in > bugzilla. Not easy for an xemacs-muse user with a bug to find and file > a bug against. And "emacsen-foo" is easier? I think we're seriously over analyzing this. If we're consistent with "emacs-common-foo" as "common addon packages that work with all bundled emacs frontends", people will be able to find it. We could even have: Provides: emacs-foo = %{version}-%{release} Provides: xemacs-foo = %{version}-%{release} inside the spec, so people doing "yum search" on the wrong name will find it. ~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 tcallawa at redhat.com Fri May 12 13:55:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 May 2006 08:55:24 -0500 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605110905g27fdf14awf6e824fea612d995@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> <4460DD03.1030603@ieee.org> <1147348515.6598.14.camel@localhost.localdomain> <645d17210605110905g27fdf14awf6e824fea612d995@mail.gmail.com> Message-ID: <1147442124.6598.65.camel@localhost.localdomain> On Thu, 2006-05-11 at 17:05 +0100, Jonathan Underwood wrote: > On 11/05/06, Tom 'spot' Callaway wrote: > > On Tue, 2006-05-09 at 13:18 -0500, Quentin Spencer wrote: > > > > > Do I dare suggest that this might be a place where using an epoch might > > > be justified? > > > > Actually, this would be one of the rare valid cases for epoch. > > Not very friendly from the user perspective though - how is Joe User > supposed to know which epoch refers to which package? Or did I > misunderstand the suggestion? No, the use of epoch here is solely to have the new muse audio application (0.8.1a) show up as "newer" than the old muse emacs plugin (3.02.6b), when the package names change. ~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 tcallawa at redhat.com Fri May 12 13:59:29 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 May 2006 08:59:29 -0500 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <1147374513.14342.8.camel@shuttle.piedmont.com> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> Message-ID: <1147442369.6598.69.camel@localhost.localdomain> On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > Even if it is for development, is it worth forcing it off into a > > -devel package for just one file? If the .pc file is the ONLY file that would qualify for -devel (aka, no headers, no static libs, nothing to develop a program against), then there is no reason to force a -devel subpackage just for it. HOWEVER: If you have any development headers/libraries, they need to be in -devel. Pointing at Core packages as a "see, FC doesn't do this", doesn't count as precedence, given that all Core packages don't even come remotely close to meeting the Packaging Guidelines right now. :) By FC-6, well, then we'll have a different story. ~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 tcallawa at redhat.com Fri May 12 14:01:27 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 May 2006 09:01:27 -0500 Subject: License query In-Reply-To: <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> References: <44648AEE.40702@city-fan.org> <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1147442487.6598.72.camel@localhost.localdomain> On Fri, 2006-05-12 at 15:20 +0200, Nils Philippsen wrote: > > It looks quite free apart from the "as long as ... you do not ... try to > > sell it" clause, which I think disqualifies it as free software despite > > what the first sentence of the license terms states. Is this OK for > > Extras or not? > > I don't think so. That counts as a use-restriction license. I say no. (See if you can get the author to remove the "as long as you do not try to sell it" clause) ~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 TQMcube.com Fri May 12 14:04:08 2006 From: Fedora at TQMcube.com (David Cary Hart) Date: Fri, 12 May 2006 10:04:08 -0400 Subject: WARNING - php-eaccellerator update Message-ID: <20060512100408.0c5d33a9@dch.TQMcube.com> I'll file a bug report but, if you have encoded pages, yesterday's update probably hosed them. Check your logs. -- Our DNSRBL - Eliminate Spam: http://www.TQMcube.com Multi-RBL Check: http://www.TQMcube.com/rblcheck.php The Dirty Dozen Spammiest Ranges: http://tqmcube.com/dirty12.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Fri May 12 15:10:12 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 12 May 2006 16:10:12 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147442124.6598.65.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> <4460DD03.1030603@ieee.org> <1147348515.6598.14.camel@localhost.localdomain> <645d17210605110905g27fdf14awf6e824fea612d995@mail.gmail.com> <1147442124.6598.65.camel@localhost.localdomain> Message-ID: <645d17210605120810t45913b10hbed87e2f6a23dfd0@mail.gmail.com> On 12/05/06, Tom 'spot' Callaway wrote: > No, the use of epoch here is solely to have the new muse audio > application (0.8.1a) show up as "newer" than the old muse emacs plugin > (3.02.6b), when the package names change. OK, gotcha. Yeah, that's clearly useful. J From jonathan.underwood at gmail.com Fri May 12 15:12:57 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 12 May 2006 16:12:57 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147442019.6598.63.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> Message-ID: <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> On 12/05/06, Tom 'spot' Callaway wrote: > I think we're seriously over analyzing this. If we're consistent with > "emacs-common-foo" as "common addon packages that work with all bundled > emacs frontends", people will be able to find it. We could even have: > > Provides: emacs-foo = %{version}-%{release} > Provides: xemacs-foo = %{version}-%{release} > > inside the spec, so people doing "yum search" on the wrong name will > find it. Yeah. We just need to pick a scheme and stick to it. Over to FESCO on that, I guess. From cweyl at alumni.drew.edu Fri May 12 15:23:25 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 12 May 2006 08:23:25 -0700 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <1147442369.6598.69.camel@localhost.localdomain> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> Message-ID: <7dd7ab490605120823sb521cc5ofd0bd7282db8eed4@mail.gmail.com> On 5/12/06, Tom 'spot' Callaway wrote: > On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > > > Even if it is for development, is it worth forcing it off into a > > > -devel package for just one file? > > If the .pc file is the ONLY file that would qualify for -devel (aka, no > headers, no static libs, nothing to develop a program against), then > there is no reason to force a -devel subpackage just for it. So just to be explicit here, can we change Packaging/ReviewGuidelines from: "- MUST: Files used by pkgconfig (.pc files) must be in a -devel package." to something like: "-MUST: If there is a -devel package, files used by pkgconfig (.pc files) must be in -devel." Thanks :) -Chris -- Chris Weyl Ex astris, scientia From fedora at leemhuis.info Fri May 12 15:47:21 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 12 May 2006 17:47:21 +0200 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <1147124903.2910.263.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> Message-ID: <1147448842.2300.2.camel@localhost.localdomain> Am Freitag, den 12.05.2006, 16:12 +0100 schrieb Jonathan Underwood: > On 12/05/06, Tom 'spot' Callaway wrote: > > I think we're seriously over analyzing this. If we're consistent with > > "emacs-common-foo" as "common addon packages that work with all bundled > > emacs frontends", people will be able to find it. We could even have: > > > > Provides: emacs-foo = %{version}-%{release} > > Provides: xemacs-foo = %{version}-%{release} > > > > inside the spec, so people doing "yum search" on the wrong name will > > find it. > Yeah. We just need to pick a scheme and stick to it. Over to FESCO on > that, I guess. I think we should be able to get this sorted out on the list, too. I'm not an emacs users, but from all I can see I'll vote for the solution spot suggested (e.g. emacs-common-foo). Other opinions? CU thl -- Thorsten Leemhuis From rc040203 at freenet.de Fri May 12 15:57:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 12 May 2006 17:57:04 +0200 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <7dd7ab490605120823sb521cc5ofd0bd7282db8eed4@mail.gmail.com> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> <7dd7ab490605120823sb521cc5ofd0bd7282db8eed4@mail.gmail.com> Message-ID: <1147449424.28040.41.camel@mccallum.corsepiu.local> On Fri, 2006-05-12 at 08:23 -0700, Chris Weyl wrote: > On 5/12/06, Tom 'spot' Callaway wrote: > > On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > > > > > Even if it is for development, is it worth forcing it off into a > > > > -devel package for just one file? > > > > If the .pc file is the ONLY file that would qualify for -devel (aka, no > > headers, no static libs, nothing to develop a program against), then > > there is no reason to force a -devel subpackage just for it. > > So just to be explicit here, can we change Packaging/ReviewGuidelines from: > > "- MUST: Files used by pkgconfig (.pc files) must be in a -devel package." > > to something like: > "-MUST: If there is a -devel package, files used by pkgconfig (.pc > files) must be in -devel." + If a devel files are contained in a non-devel package, the non-devel package MUST "provide: *-devel = %{version}-%{release} Ralf From jonathan.underwood at gmail.com Fri May 12 16:03:41 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 12 May 2006 17:03:41 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147448842.2300.2.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> Message-ID: <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> On 12/05/06, Thorsten Leemhuis wrote: > I'm not an emacs users, but from all I can see I'll vote for the > solution spot suggested (e.g. emacs-common-foo). I much prefer emacsen-foo. Why do we need the word "common" in a package name? It makes sense in a subpackage name, but in a package name, it's confusing. J From jonathan.underwood at gmail.com Fri May 12 16:11:59 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 12 May 2006 17:11:59 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> Message-ID: <645d17210605120911j654b2a33sa1369ff6eb6b112d@mail.gmail.com> On 12/05/06, Jonathan Underwood wrote: > On 12/05/06, Thorsten Leemhuis wrote: > > > I'm not an emacs users, but from all I can see I'll vote for the > > solution spot suggested (e.g. emacs-common-foo). > > I much prefer emacsen-foo. > > Why do we need the word "common" in a package name? It makes sense in > a subpackage name, but in a package name, it's confusing. To go full circle, we could call the packlage emacs-foo, which builds xemacs-foo as a subpackage, and also a emacs-foo-common subpackage, required by both emacs-foo and xemacs-foo. This would no longer be treating the xemacs package on an equal footing, but hey ho. From bugs.michael at gmx.net Fri May 12 16:27:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 12 May 2006 18:27:51 +0200 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <1147442369.6598.69.camel@localhost.localdomain> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> Message-ID: <20060512182751.c4a86e30.bugs.michael@gmx.net> On Fri, 12 May 2006 08:59:29 -0500, Tom 'spot' Callaway wrote: > On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > > > Even if it is for development, is it worth forcing it off into a > > > -devel package for just one file? > > If the .pc file is the ONLY file that would qualify for -devel (aka, no > headers, no static libs, nothing to develop a program against), then > there is no reason to force a -devel subpackage just for it. There is one good reason: The .pc file contains dependencies on other .pc files, which are located in -devel packages. In this case, you would need a dependency ("Requires") from your non-devel package to -devel packages. Without that dependency, your package would break the pkgconfig dependency chain and several pkgconfig query commands. To keep development files in -devel packages is the only clean solution. From rdieter at math.unl.edu Fri May 12 16:31:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 12 May 2006 11:31:54 -0500 Subject: mono / ".pc files in -devel packges" guideline References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> <20060512182751.c4a86e30.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > On Fri, 12 May 2006 08:59:29 -0500, Tom 'spot' Callaway wrote: > >> On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: >> >> > > Even if it is for development, is it worth forcing it off into a >> > > -devel package for just one file? >> >> If the .pc file is the ONLY file that would qualify for -devel (aka, no >> headers, no static libs, nothing to develop a program against), then >> there is no reason to force a -devel subpackage just for it. > > There is one good reason: The .pc file contains dependencies on other .pc > files, which are located in -devel packages. In this case, you would need > a dependency ("Requires") from your non-devel package to -devel packages. > Without that dependency, your package would break the pkgconfig dependency > chain and several pkgconfig query commands. > > To keep development files in -devel packages is the only clean solution. Keep in mind recent rpm versions (in development) automatically include all the Provides/Requires from .pc files as well. -- Rrex From nphilipp at redhat.com Fri May 12 16:35:15 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 12 May 2006 18:35:15 +0200 Subject: License query In-Reply-To: <1147442487.6598.72.camel@localhost.localdomain> References: <44648AEE.40702@city-fan.org> <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> <1147442487.6598.72.camel@localhost.localdomain> Message-ID: <1147451715.3308.48.camel@gibraltar.stuttgart.redhat.com> On Fri, 2006-05-12 at 09:01 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-05-12 at 15:20 +0200, Nils Philippsen wrote: > > > > It looks quite free apart from the "as long as ... you do not ... try to > > > sell it" clause, which I think disqualifies it as free software despite > > > what the first sentence of the license terms states. Is this OK for > > > Extras or not? > > > > I don't think so. > > That counts as a use-restriction license. I say no. > > (See if you can get the author to remove the "as long as you do not try > to sell it" clause) and probably the "You may alter the code as long as you send me any diffs" clause as well. Finding out we may not fix bugs because the author isn't reachable is a not a pleasant thing I say. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From cweyl at alumni.drew.edu Fri May 12 17:06:55 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 12 May 2006 10:06:55 -0700 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <1147449424.28040.41.camel@mccallum.corsepiu.local> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> <7dd7ab490605120823sb521cc5ofd0bd7282db8eed4@mail.gmail.com> <1147449424.28040.41.camel@mccallum.corsepiu.local> Message-ID: <7dd7ab490605121006y7c29dc17n67490782c8afbb6a@mail.gmail.com> On 5/12/06, Ralf Corsepius wrote: > On Fri, 2006-05-12 at 08:23 -0700, Chris Weyl wrote: > > So just to be explicit here, can we change Packaging/ReviewGuidelines from: > > > > "- MUST: Files used by pkgconfig (.pc files) must be in a -devel package." > > > > to something like: > > "-MUST: If there is a -devel package, files used by pkgconfig (.pc > > files) must be in -devel." > > + If a devel files are contained in a non-devel package, the non-devel > package MUST "provide: *-devel = %{version}-%{release} I like that. Makes the devel provides explicit, and makes it easier to cleave it off into an actual -devel package down the road iff needs be. -Chris -- Chris Weyl Ex astris, scientia From paul at city-fan.org Fri May 12 17:25:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 May 2006 18:25:22 +0100 Subject: rpms/perl-Module-Build/devel .cvsignore, 1.9, 1.10 perl-Module-Build.spec, 1.15, 1.16 sources, 1.9, 1.10 In-Reply-To: <200605121708.k4CH8CZu002604@cvs-int.fedora.redhat.com> References: <200605121708.k4CH8CZu002604@cvs-int.fedora.redhat.com> Message-ID: <4464C502.4090000@city-fan.org> Steven Pritchard (steve) wrote: > Author: steve > > Update of /cvs/extras/rpms/perl-Module-Build/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2583 > > Modified Files: > .cvsignore perl-Module-Build.spec sources > Log Message: > Update to 0.28. > Epoch bump to make 0.28 > 0.2612. > Various spec cleanups to closer match cpanspec output. > > > > Index: .cvsignore > =================================================================== > RCS file: /cvs/extras/rpms/perl-Module-Build/devel/.cvsignore,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -u -r1.9 -r1.10 > --- .cvsignore 12 Mar 2006 02:14:33 -0000 1.9 > +++ .cvsignore 12 May 2006 17:08:10 -0000 1.10 > @@ -1 +1 @@ > -Module-Build-0.2612.tar.gz > +Module-Build-0.28.tar.gz > > > Index: perl-Module-Build.spec > =================================================================== > RCS file: /cvs/extras/rpms/perl-Module-Build/devel/perl-Module-Build.spec,v > retrieving revision 1.15 > retrieving revision 1.16 > diff -u -r1.15 -r1.16 > --- perl-Module-Build.spec 16 Mar 2006 01:54:11 -0000 1.15 > +++ perl-Module-Build.spec 12 May 2006 17:08:10 -0000 1.16 > @@ -1,26 +1,35 @@ > Name: perl-Module-Build > -Version: 0.2612 > -Release: 2%{?dist} > +Version: 0.28 > +Release: 1%{?dist} > +Epoch: 1 > Summary: Perl module for building and installing Perl modules > -Group: Development/Libraries > License: GPL or Artistic > +Group: Development/Libraries > URL: http://search.cpan.org/dist/Module-Build/ > Source0: http://www.cpan.org/authors/id/K/KW/KWILLIAMS/Module-Build-%{version}.tar.gz > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > BuildArch: noarch > BuildRequires: perl(Archive::Tar) >= 1.08 > -BuildRequires: perl(ExtUtils::CBuilder) >= 0.02 > -BuildRequires: perl(ExtUtils::ParseXS) >= 2.02 > -BuildRequires: perl(YAML) >= 0.35, perl(YAML) < 0.49 > +BuildRequires: perl(ExtUtils::CBuilder) >= 0.15 > +BuildRequires: perl(ExtUtils::ParseXS) >= 1.02 > +BuildRequires: perl(YAML) > +BuildRequires: perl(Pod::Readme) >= 0.04 > Requires: perl(Archive::Tar) >= 1.08 > -Requires: perl(ExtUtils::CBuilder) >= 0.02 > -Requires: perl(ExtUtils::ParseXS) >= 2.02 > -Requires: perl(YAML) >= 0.35, perl(YAML) < 0.49 > +Requires: perl(ExtUtils::CBuilder) >= 0.15 > +Requires: perl(ExtUtils::ParseXS) >= 1.02 > +Requires: perl(Pod::Readme) >= 0.04 > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) > > %description > -Perl module for building and installing Perl modules, a replacement to > -ExtUtils::MakeMaker. > +Module::Build is a system for building, testing, and installing Perl > +modules. It is meant to be an alternative to ExtUtils::MakeMaker. > +Developers may alter the behavior of the module through subclassing in a > +much more straightforward way than with MakeMaker. It also does not require > +a make on your system - most of the Module::Build code is pure-perl and > +written in a very cross-platform way. In fact, you don't even need a shell, > +so even platforms like MacOS (traditional) can use it fairly easily. Its > +only prerequisites are modules that are included with perl 5.6.0, and it > +works fine on perl 5.005 if you can install a few additional modules. > > %prep > %setup -q -n Module-Build-%{version} > @@ -33,14 +42,10 @@ > rm -rf $RPM_BUILD_ROOT > > ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0 > - > find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null \; > > chmod -R u+rwX,go+rX,go-w $RPM_BUILD_ROOT/* > > -perldoc -t perlgpl > COPYING > -perldoc -t perlartistic > Artistic > - > %check > ./Build test > > @@ -49,13 +54,18 @@ > > %files > %defattr(-,root,root,-) > -%doc Changes README COPYING Artistic > +%doc Changes README > %{_bindir}/config_data > %{perl_vendorlib}/Module > %{_mandir}/man1/config_data.1* > %{_mandir}/man3/Module::Build*.3* > > %changelog > +* Fri May 12 2006 Steven Pritchard - 1:0.28-1 > +- Update to 0.28. > +- Epoch bump to make 0.28 > 0.2612. > +- Various spec cleanups to closer match cpanspec output. > + A bit OT, but have you managed to get Module::Build 0.28 to run the test suite successfully on anything older than FC4? The "compat" test seems to fail in various ways on FC3 and RHL9 here. Paul. From ndbecker2 at gmail.com Fri May 12 18:10:55 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 12 May 2006 14:10:55 -0400 Subject: How do I know if someone is already working on a package? Message-ID: How can I check if someone is already working on a submission (that isn't already part of extras?) From peter at thecodergeek.com Fri May 12 18:20:16 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 12 May 2006 11:20:16 -0700 (PDT) Subject: How do I know if someone is already working on a package? In-Reply-To: References: Message-ID: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Neal Becker wrote: > How can I check if someone is already working on a submission (that isn't > already part of extras?) Email this list? ;) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From eric.tanguy at univ-nantes.fr Fri May 12 18:32:06 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Fri, 12 May 2006 20:32:06 +0200 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> Message-ID: <1147458726.2643.8.camel@bureau.maison> Le vendredi 12 mai 2006 ? 11:39 +0200, Eric TANGUY a ?crit : > Someone could help me with this ? > there is new guile package version in rawhide, i have just to rebuild the > package against the new packages to solve this ? > Thanks > Eric > > ---------------------------- Message original ---------------------------- > Objet: Broken dependencies in Fedora Extras development - 2006-05-11 > De: "Michael Schwendt" > Date: Jeu 11 mai 2006 23:04 > ?: eric.tanguy at univ-nantes.fr > -------------------------------------------------------------------------- > > This is an automated mail created by an experimental script. > Your following packages in the repository contain broken dependencies: > > package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 > unresolved deps: > libguile.so.12 > libguile-ltdl.so.1 > libqthreads.so.12 > > package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 > unresolved deps: > libguile.so.12()(64bit) > libguile-ltdl.so.1()(64bit) > > package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc > unresolved deps: > libguile.so.12 > libguile-ltdl.so.1 Trying to rebuild it with mock give this error during building : g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -o drgeo drgenius_main.o drgenius_mdi.o drgenius_config.o drgeo_adaptDialog.o drgenius_view.o geo_view.o editor_view.o drgeo_init.o drgeo_printer.o -Wl,--export-dynamic ./geo/libgeo.a -lglade-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lxml2 -lz -pthread /usr/lib/libguile.so -L/usr/lib -lgmp -lm -lltdl -lcrypt /usr/bin/ld: cannot find -lltdl collect2: ld returned 1 exit status Someone could help me to understand or solve it ? Thanks Eric From chris.stone at gmail.com Fri May 12 18:42:00 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 12 May 2006 11:42:00 -0700 Subject: How do I know if someone is already working on a package? In-Reply-To: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: On 5/12/06, Peter Gordon wrote: > > Email this list? ;) Or you could just seach bugzilla. From ndbecker2 at gmail.com Fri May 12 18:56:13 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 12 May 2006 14:56:13 -0400 Subject: How do I know if someone is already working on a package? References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: Christopher Stone wrote: > On 5/12/06, Peter Gordon > wrote: >> >> Email this list? ;) > > Or you could just seach bugzilla. > I don't think you want me to pester everyone evertime. I tried bugzilla, but not sure what to search for. Any hint? From jspaleta at gmail.com Fri May 12 19:03:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 12 May 2006 15:03:58 -0400 Subject: How do I know if someone is already working on a package? In-Reply-To: References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: <604aa7910605121203p306dc37cied5760e7305656e3@mail.gmail.com> On 5/12/06, Neal Becker wrote: > I tried bugzilla, but not sure what to search for. Any hint? You look down list of bugs that block FE-NEW : 163776 FE-REVIEW : 163778 and possibly FE-NEEDSPONSER : 177841 , though these should all be listed under FE-NEW or FE-REVIEW i think. -jef From chris.stone at gmail.com Fri May 12 19:08:09 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 12 May 2006 12:08:09 -0700 Subject: How do I know if someone is already working on a package? In-Reply-To: References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: On 5/12/06, Neal Becker wrote: > Christopher Stone wrote: > > > On 5/12/06, Peter Gordon > > wrote: > >> > >> Email this list? ;) > > > > Or you could just seach bugzilla. > > > > I don't think you want me to pester everyone evertime. > > I tried bugzilla, but not sure what to search for. Any hint? Well for example, the package metisse is being worked on but not currently in the owners.list file. You can go to bugzilla.redhat.com and put "metisse" in the quick search box and a bug will show up saying the package is currently under review. If you don't know the name of the package, you can also just type "review request" in the quick search box to see all the bugs in a list, or else look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163778 From tibbs at math.uh.edu Fri May 12 19:10:53 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 12 May 2006 14:10:53 -0500 Subject: How do I know if someone is already working on a package? In-Reply-To: (Neal Becker's message of "Fri, 12 May 2006 14:56:13 -0400") References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: >>>>> "NB" == Neal Becker writes: NB> I tried bugzilla, but not sure what to search for. Any hint? Search "summary" for the name of the package. That will turn up any review requests. - J< From Axel.Thimm at ATrpms.net Fri May 12 19:30:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 12 May 2006 21:30:03 +0200 Subject: How do I know if someone is already working on a package? In-Reply-To: References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: <20060512193003.GA23904@neu.nirvana> On Fri, May 12, 2006 at 02:56:13PM -0400, Neal Becker wrote: > Christopher Stone wrote: > > > On 5/12/06, Peter Gordon > > wrote: > >> > >> Email this list? ;) > > > > Or you could just seach bugzilla. > > > > I don't think you want me to pester everyone evertime. > > I tried bugzilla, but not sure what to search for. Any hint? The FE-NEW and -ACCEPT package submissions to narrow down the search. But you can also simply dump the query into bugzilla's summary. Only catch is if the package has a different name than what you guess it may have, so you should try different versions and check the naming conventions in the wiki to derive the proper name. There is also a mailing list of submissions (fedora-package-review) that you could search through. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Fri May 12 19:32:08 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 12 May 2006 12:32:08 -0700 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <1147458726.2643.8.camel@bureau.maison> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> <1147458726.2643.8.camel@bureau.maison> Message-ID: <1147462329.3949.18.camel@localhost> On Fri, 2006-05-12 at 20:32 +0200, Eric Tanguy wrote: > > package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 > > unresolved deps: > > libguile.so.12 > > libguile-ltdl.so.1 > > libqthreads.so.12 > > > > package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 > > unresolved deps: > > libguile.so.12()(64bit) > > libguile-ltdl.so.1()(64bit) > > > > package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc > > unresolved deps: > > libguile.so.12 > > libguile-ltdl.so.1 > > Trying to rebuild it with mock give this error during building : > g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 > -mtune=generic -fasynchronous-unwind-tables -o drgeo drgenius_main.o > drgenius_mdi.o drgenius_config.o drgeo_adaptDialog.o drgenius_view.o > geo_view.o editor_view.o drgeo_init.o drgeo_printer.o > -Wl,--export-dynamic ./geo/libgeo.a -lglade-2.0 -lgtk-x11-2.0 > -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 > -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lxml2 -lz > -pthread /usr/lib/libguile.so -L/usr/lib -lgmp -lm -lltdl -lcrypt > /usr/bin/ld: cannot find -lltdl > collect2: ld returned 1 exit status > libltdl is from libtool. Seeing as one of the unresolved deps is libguile-ltdl something might have changed in the upstream guile that needs a change in the guile packaging for Core. Or it could be that your package depends on ltdl directly. In either case, a BuildRequires for libtool-ltdl-devel will probably get you past this error. If it is a problem with guile you should file a bug like "guile-devel should Require libtool-ltdl-devel". -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 nando at ccrma.Stanford.EDU Fri May 12 19:50:13 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Fri, 12 May 2006 12:50:13 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147348515.6598.14.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508213208.GB23374@devserv.devel.redhat.com> <445FD067.2010605@ajs.com> <1147139566.5758.14.camel@cmn3.stanford.edu> <1ed4a0130605082034y42e05c56y36094689bd5d2488@mail.gmail.com> <1147148220.27330.4.camel@atlantis.mpeters.local> <1147197099.22392.23.camel@cmn3.stanford.edu> <4460DD03.1030603@ieee.org> <1147348515.6598.14.camel@localhost.localdomain> Message-ID: <1147463413.2752.12.camel@cmn3.stanford.edu> On Thu, 2006-05-11 at 06:55 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-05-09 at 13:18 -0500, Quentin Spencer wrote: > > > Do I dare suggest that this might be a place where using an epoch might > > be justified? > > Actually, this would be one of the rare valid cases for epoch. Yeah, you guys are right, that would nicely solve the problem. Thanks! -- Fernando From j.w.r.degoede at hhs.nl Fri May 12 19:54:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 12 May 2006 21:54:03 +0200 Subject: License query In-Reply-To: <1147442487.6598.72.camel@localhost.localdomain> References: <44648AEE.40702@city-fan.org> <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> <1147442487.6598.72.camel@localhost.localdomain> Message-ID: <4464E7DB.3010203@hhs.nl> Tom 'spot' Callaway wrote: > On Fri, 2006-05-12 at 15:20 +0200, Nils Philippsen wrote: > >>> It looks quite free apart from the "as long as ... you do not ... try to >>> sell it" clause, which I think disqualifies it as free software despite >>> what the first sentence of the license terms states. Is this OK for >>> Extras or not? >> I don't think so. > > That counts as a use-restriction license. I say no. > > (See if you can get the author to remove the "as long as you do not try > to sell it" clause) > Exactly many authors unfortunatly come up with their own license, as a games SIG member I've got plenty of experience with those. Usually if the license already is 99.9% free a polite mail (exchange) is all it will take to get a 100% free license. OTOH if the license is restrictive (which this one isn't) your chances of changing the author's mind are less good. Regards, Hans From qspencer at ieee.org Fri May 12 20:03:03 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 12 May 2006 16:03:03 -0400 Subject: Buildsys stuck? Message-ID: <4464E9F7.7010003@ieee.org> job 9304 seems stuck, and I can't kill it or requeue it. Attempts to kill it give me: "connection to the server timed out". From dcbw at redhat.com Fri May 12 20:44:59 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 12 May 2006 16:44:59 -0400 Subject: Buildsys stuck? In-Reply-To: <4464E9F7.7010003@ieee.org> References: <4464E9F7.7010003@ieee.org> Message-ID: <1147466699.3679.3.camel@localhost.localdomain> On Fri, 2006-05-12 at 16:03 -0400, Quentin Spencer wrote: > job 9304 seems stuck, and I can't kill it or requeue it. Attempts to > kill it give me: "connection to the server timed out". Kicked, all better now. Dan From Christian.Iseli at licr.org Fri May 12 21:05:42 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 12 May 2006 23:05:42 +0200 Subject: FE Package Status of May 12, 2006 Message-ID: <200605122105.k4CL5hCU007871@mx1.redhat.com> Hi folks, The page has been updated. Thorsten asked if we could highlight a bit those folks who perform many reviews but are not yet sponsors, so I have added some coloring to the page. Actually, I kinda like colors :) Maybe other things could be colorized too... Another thing I was wondering: do you prefer people's names, or do you prefer the pseudo-email addresses in the various listings ? Visually, I tend to prefer just the name, but then it makes things a bit harder when trying to send an email to poke someone on an issue... But then again, I hope to automate the nagging emails at some point... so I'm kinda hesitating what to do. Cheers, Christian ---- FE Package Status of May 12, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1722 packages - 49 orphans - 43 packages not available in extras devel or release Axel dot Thimm at ATrpms dot net synaptic andreas at bawue dot net dd_rescue cgoorah at yahoo dot com dot au kadischi chris dot stone at gmail dot com pypoker-eval davidhart at tqmcube dot com leafnode dennis at ausil dot us cryptplug dreadyman at gmail dot com yakuake foolish at guezz dot net cowbell fredrik at dolda2000 dot com icmpdn gauret at free dot fr elmo gemi at bluewin dot ch inti gemi at bluewin dot ch drscheme ghenry at suretecsystems dot com gnome-applet-netmon ghenry at suretecsystems dot com rsnapshot ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jpo at di dot uminho dot pt perl-Devel-Cover jvdias at redhat dot com webmin matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache notting at redhat dot com comps oliver at linux-kernel dot at squidGuard paul at city-fan dot org perl-Authen-DigestMD5 rdieter at math dot unl dot edu gsview sgrubb at redhat dot com libsafe steve at silug dot org perl-Test-Portability-Files tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com stripesnoop tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox ville dot skytta at iki dot fi lirc-kmod-common ville dot skytta at iki dot fi lirc-kmod wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 3 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep jonathan dot underwood at gmail dot com muse - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 SquidGuard oliver at linux-kernel.at webmin jvdias at redhat.com - 3 packages present in the development repo which have no owners entry doctorj kchmviewer raidem-music - 12 orphaned packages, yet available in extras devel duplicity gtkglarea2 ks3switch lrmi ots perl-Chart perl-Net-Netmask perl-XML-XPath perl-XML-XQL s3switch tpb xosd - 37 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for FC5: tcallawa at redhat dot com check - 3 packages duplicated for devel: rdieter at math dot unl dot edu gtk+ rdieter at math dot unl dot edu glib tcallawa at redhat dot com check FE-ACCEPT packages stats: - 799 accepted, closed package reviews - 6 accepted, closed package reviews not in repo - 4 accepted, closed package reviews not in owners - 0 accepted, open package reviews older than 4 weeks; - 5 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 81 open tickets - 9 tickets with no activity in eight weeks - 5 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 195 open tickets - 11 tickets with no activity in eight weeks - 25 tickets with no activity in four weeks - 4 closed tickets FE-NEEDSPONSOR packages stats: - 37 open tickets - 1 tickets with no activity in eight weeks - 3 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 201 open tickets - 80 tickets with no activity in eight weeks - 69 tickets with no activity in four weeks CVS stats: - 1699 packages with a devel directory - 6 packages with no owners entry initng kchmviewer kile-i18n pcb perl-Maypole raidem-music - 5 packages in CVS devel *and* Core unifdef check libevent glib gtk+ Maintainers stats: - 186 maintainers - 2 inactive maintainers with open bugs Dropped FC packages: - 237 packages were dropped from core since FC 1 From jspaleta at gmail.com Fri May 12 21:12:11 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 12 May 2006 17:12:11 -0400 Subject: FE Package Status of May 12, 2006 In-Reply-To: <200605122105.k4CL5hCU007871@mx1.redhat.com> References: <200605122105.k4CL5hCU007871@mx1.redhat.com> Message-ID: <604aa7910605121412j2c31cae3p5c2b7f68a9e5106c@mail.gmail.com> On 5/12/06, Christian.Iseli at licr.org wrote: > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus Just a little FYI, I think you have an counting error in your script Look at the Inactivity notice section on the Package Status page. summary lists 0 packages but there is a specific package listed in the table underneath the summary. -jef"c'mon somebody else suck it up and do a few more reviews and knock me off the top 25 list..."spaleta From Christian.Iseli at licr.org Fri May 12 21:53:52 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 12 May 2006 23:53:52 +0200 Subject: FE Package Status of May 12, 2006 In-Reply-To: Your message of "Fri, 12 May 2006 17:12:11 EDT." <604aa7910605121412j2c31cae3p5c2b7f68a9e5106c@mail.gmail.com> Message-ID: <200605122153.k4CLrqoY002621@mx3.redhat.com> Hi Jef, jspaleta at gmail.com said: > I think you have an counting error in your script Look at the Inactivity > notice section on the Package Status page. summary lists 0 packages but there > is a specific package listed in the table underneath the summary. Ouch, one more. I have to confess another bug in the piece that says: "We have 2 maintainers with open bugs that have had no noticeable CVS..." where the 2 is obviously wrong too... I'll definitely try to squash those pesky bugs next time I get a chance... Thanks for spotting this one. Cheers, Christian From michael at knox.net.nz Fri May 12 22:10:58 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 13 May 2006 10:10:58 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <20060512131955.5d5055a4.bugs.michael@gmx.net> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> Message-ID: <446507F2.1060303@knox.net.nz> Hello Michael, Thanks for commenting... Michael Schwendt wrote: > On Fri, 12 May 2006 14:48:47 +1200, Michael J. Knox wrote: > >> This is a request for comment and perhaps an informal proposal for how >> to handle packages with AWOL owners. >> >> I have spent sometime discussing this process with a work college, a >> debian developer, on how best practice and the appropriate etiquette >> could be shown to the current owner of a said package. He suggested that >> debian's NMU or Non-Maintainer Upload, processed worked well within the >> debian development community. >> >> I have read through this policy of debian's and think that it addresses >> the issues nicely of ensuring that packages are not left to become stale >> and not offend packager owners. >> >> I am proposing we (Fedora Extras) adopt the same process. It would need >> to be made Fedora relevant and I would hope that people will see the >> plus in such a process. >> >> The over all aim is to avoid "stale" packages in Extras, more swiftly >> pick up on unmaintained packages and hopefully encourage people to work >> on these packages by providing a process in which people can fix them. > > First of all, I think you mix a few things. Specifically, the NMU talks > about "fixes", "bugs" and "serious problems", while you talk about > "stale", "unmaintained" packages and "the take over of a package". Not > sure whether you want to merge all that into a single policy. Possibly, I sort of see them one in the same. The "fixes, bugs and serious problems" can only apply if the package owner has been contacted and had no response. I see it as more of a taking small steps to ownership on a package where the original owner is no longer contactable. > > The main reason why NMUs are done is when a developer needs to fix > another developer's packages in order to address serious problems or > crippling bugs or when the package maintainer is unable to release a > fix in a timely fashion. > > I find that description poor. It is not clear when and why "another > developer's packages" are touched without the package maintainer doing > it. Because as soon as developers talk to eachother (e.g. in bugzilla), > collaborative package development becomes possible without additional > bureaucracy. Packagers at FE have done this multiple times before for > rebuilds, fixes and even version upgrades. If the NMU is only about > unreachable maintainers, the Debian folk has added a lot of bureaucracy > and complexity with questionable benefit and increased requirements for > tracking (e.g. that applied changes are not reverted the next time the > maintainer returns and imports his own package). Yes, debian has added too much bureaucracy... but I wont start on that. This is not intended to impact active packagers. If people have issues with an active packagers package, then file a bug ;) > > Noticably, the NMU is independent from what the security team does. > > When a security bug is detected, the security team may do an NMU, > using their own rules. Please refer to Handling security-related bugs, > Section 5.8.5 for more information. As is QA from security in FE (independent) > Here are the sections on dealing with MIA/AWOL maintainers: > > Orphaning a package > http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-orphaning > > Adopting a package (!) > http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-adopting > > Dealing with inactive and/or unreachable maintainers > http://www.debian.org/doc/manuals/developers-reference/ch-beyond-pkging.en.html#s-mia-qa > > Collaborative maintenance > http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-collaborative-maint > > What we most certainly don't want is that arbitrary developers use a > procedure like the NMU to do version upgrades without good reason. I like > that the NMU requires developers to file bug reports (including unified > diffs) for the changes they plan to apply. Version updated should not be allowed unless no other means of fixing a bug is possible. There *has* to be a BZ trail from the person wanting to do the NMU. As Glenn, my work college, told me, it is expected that a NMU is announced on debian's mailing list before it happens. This creates peer review and helps prevent "sneaky" upgrades and hi-jack attempts. > And if a package maintainer is believed to be MIA/AWOL, we don't want that > arbitrary developers use this opportunity to do upgrades without the > package getting a new maintainer. The NMU requires developers to watch > incoming bug reports, since their changes may cause new problems. This > adds quite some complexity to the package maintainership model. The NMU process I am proposing is to allow someone to take over that package (slowly and proven) not to run wild over CVS and the buildsys hap hazardly. AWOL owner --> Bob starts a BZ trail --> files patches --> announces NMU --> NMU pushed out ---> Bob requests ownership --> FESCo gives thumbs up. That's how I see the process. >> An example would be: >> >> http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01763.html > > Start tracking the date and number of contact attempts inside the bugzilla > ticket. Mention whether your email bounced. Announce that you plan to take > over the package next week. See below. Agree. the BZ trail is the up most importance in a process like this. >> This also allows people to demonstrate that they have a willingness to >> maintain a package and are capable of doing so. >> >> You can review debian's process here: >> >> http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu >> >> Some items that would need clarifying, would be the time needed to be >> considered "reasonable" in the time of contact and delay. Also, there >> would need to be persons responsible for "approving" the take over of a >> package. >> >> Please note, this is not to address or replace the orphan process, but >> to help in cases where the package has not been orphaned and the >> maintainer is not contactable. > > Too much at once. If a maintainer has not responded for more than six > weeks (as in the given example where a build is missing!), it should be in > the maintainers best interest that somebody else takes over package > development. And we ought to start tracking maintainers, which are > believed to be MIA/AWOL. Ok, but this process is missing and sometimes best intentions with out process lend to offending developers and standing on toes. Also, no one has told this person they could do that. Well, not that I have seen. >> If a process like this is received well, then I am happy to draft it for >> FESCo to ponder. > > What I don't like at all is the uncertain package status and ownership. Likewise, I wanted feed back (which you have given :) ) to help close the loop holes and define the process > Packages without a maintainer, but which are touched occasionally by > arbitrary people. With the next big problems inside the package and nobody > interested in contributing maintenance, we would be back at the drawing > board, since the package is still without maintainer/owner. This isn't a silver bullet proposal, merely a proposal on up to handle the situation when it arises. Its not going to provide a catch up for all state/unmaintained/AWOL developers, but it will allow those who see a package go stale and are willing to take it on with a defined process to do so. > I would appreciate if we started bottom-up with a procedure for "Adoption > of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then > we enhance the procedure in order to permit certain actions (like > requesting (re-)builds, fixing grave bugs) while it is still being waited > for a response by the maintainer. It will probably, except for security > issues, look like: > > - notify maintainer > - wait X days > - notify maintainer about planned take-over and > planned actions [e.g. (re-)builds, fixes] > - wait another X-Y days > - touch the package > - maybe wait another Z days > - take over the package in owners.list > Thats exactly what I was meaning. But its important that the "X, Y, Z" time frames are well known and defined. Michael From gemi at bluewin.ch Fri May 12 22:21:08 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 13 May 2006 00:21:08 +0200 Subject: Drop inti package Message-ID: <1147472469.15570.2.camel@scriabin.tannenrauch.ch> I would like to drop the package inti (http://inti.sourceforge.net/contact.html). It has not been updated since 2003. I will add it to the list of orphaned packages. Maybe someone has still interest in it. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From steve at silug.org Fri May 12 22:36:25 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 12 May 2006 17:36:25 -0500 Subject: rpms/perl-Module-Build/devel .cvsignore, 1.9, 1.10 perl-Module-Build.spec, 1.15, 1.16 sources, 1.9, 1.10 In-Reply-To: <4464C502.4090000@city-fan.org> References: <200605121708.k4CH8CZu002604@cvs-int.fedora.redhat.com> <4464C502.4090000@city-fan.org> Message-ID: <20060512223625.GA32247@osiris.silug.org> On Fri, May 12, 2006 at 06:25:22PM +0100, Paul Howarth wrote: > A bit OT, but have you managed to get Module::Build 0.28 to run the test > suite successfully on anything older than FC4? The "compat" test seems > to fail in various ways on FC3 and RHL9 here. I haven't tried to build it anywhere other than FC5 so far. Oh, and on a related note, one of the new dependencies for the new Module::Build BuildRequires Module::Build, which won't install in devel because of the new YAML I pushed out the other day. I guess the perl-YAML package needs to be removed from the repository long enough for me to rebuild perl-Module-Build (and build the new dependencies). Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From wart at kobold.org Fri May 12 23:30:39 2006 From: wart at kobold.org (Michael Thomas) Date: Fri, 12 May 2006 16:30:39 -0700 Subject: Maelstrom license clause Message-ID: <44651A9F.80605@kobold.org> I found the following clause in the Maelstrom package which is under re-review after being moved from core to extras. The package is mostly GPL, but there is the following extra clause in a README file: "The artwork and sounds used by Maelstrom are copyright Ambrosia Software (http://www.ambrosiasw.com) and may not be redistributed separately from the Maelstrom public GPL release." I seem to recall that there was a similar issue with uqm, but I don't recall the conclusion. Is this something that makes incompatible with Fedora's licensing requirements? --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Sat May 13 00:04:01 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 13 May 2006 12:04:01 +1200 Subject: FE Package Status of May 12, 2006 In-Reply-To: <200605122105.k4CL5hCU007871@mx1.redhat.com> References: <200605122105.k4CL5hCU007871@mx1.redhat.com> Message-ID: <44652271.2090802@knox.net.nz> Christian.Iseli at licr.org wrote: > Hi folks, > > The page has been updated. Thorsten asked if we could highlight a bit those > folks who perform many reviews but are not yet sponsors, so I have added some > coloring to the page. > > Actually, I kinda like colors :) Maybe other things could be colorized too... > > Another thing I was wondering: do you prefer people's names, or do you prefer > the pseudo-email addresses in the various listings ? > > Visually, I tend to prefer just the name, but then it makes things a bit > harder when trying to send an email to poke someone on an issue... > But then again, I hope to automate the nagging emails at some point... so I'm > kinda hesitating what to do. pseudo-email address works for me :) I am wondering why it keeps reporting doctorj as an orphan: [monkey at localhost owners]$ cat owners.list | grep doctorj Fedora Extras|doctorj|Java source code analyzer|michael at knox.net.nz|extras-qa at fedoraproject.org| [monkey at localhost owners]$ From buildsys at fedoraproject.org Fri May 12 23:59:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 12 May 2006 19:59:26 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060512235926.88E1715216D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 18 TeXmacs-1.0.6.1-2.fc4 bzflag-2.0.6-1.fc4 fig2ps-1.3.5-2.fc4 glpk-4.10-1.fc4 gpa-0.7.3-2.fc4 gpgme-1.1.2-4.fc4 ncftp-3.1.9-4.fc4 netcdf-3.6.1-2.fc4 octave-2.9.5-1.fc4 octave-forge-2006.03.17-3.fc4 par2cmdline-0.4-10.fc4 perl-Authen-DigestMD5-0.04-1.fc4 perl-SOAP-Lite-0.67-2.1.fc4 pypoker-eval-131.0-3.fc4 python-clientform-0.2.2-4.fc4 qof-0.6.4-4.fc4 torque-2.1.0p0-1.fc4 ufsparse-1.2-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 12 23:59:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 12 May 2006 19:59:26 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060512235926.93E7E15216E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 torque-2.1.0p0-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 12 23:59:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 12 May 2006 19:59:26 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060512235926.7FEB115216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 21 TeXmacs-1.0.6.1-2.fc5 abiword-2.4.4-4.fc5 bzflag-2.0.6-1.fc5 childsplay-0.81.8-3.fc5 childsplay_plugins-0.80.7-3.fc5 fig2ps-1.3.5-2.fc5 glpk-4.10-1.fc5 gpgme-1.1.2-4.fc5 ncftp-3.1.9-4.fc5 netcdf-3.6.1-2.fc5 par2cmdline-0.4-10.fc5 perl-Authen-DigestMD5-0.04-1.fc5 perl-Devel-Cover-0.55-2.fc5 perl-Module-Signature-0.54-1.fc5 perl-SOAP-Lite-0.67-2.fc5 perl-Test-SubCalls-1.06-1.fc5 pypoker-eval-131.0-3.fc5 python-clientform-0.2.2-4.fc5 qof-0.6.4-4.fc5 torque-2.1.0p0-1.fc5 xemacs-sumo-20060510-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 12 23:59:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 12 May 2006 19:59:26 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060512235926.741F0152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 19 Terminal-0.2.4-8.fc6 azureus-2.4.0.3-0.20060328cvs_5.fc6 cfengine-2.1.20-3.fc6 fig2ps-1.3.5-2.fc6 glpk-4.10-1.fc6 grip-3.2.0-11.fc6 gtkterm-0.99.5-2.fc6 mercurial-0.9-1.fc6 ncftp-3.1.9-4.fc6 netcdf-3.6.1-2.fc6 par2cmdline-0.4-10.fc6 perl-Authen-DigestMD5-0.04-1.fc6 perl-Devel-Cover-0.55-2.fc6 perl-Module-Signature-0.54-1.fc6 perl-Test-SubCalls-1.06-1.fc6 pypoker-eval-131.0-3.fc6 qof-0.6.4-4.fc6 torque-2.1.0p0-1.fc6 xbindkeys-1.7.2-5.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 13 00:31:41 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 13 May 2006 00:31:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-12 Message-ID: <20060513003141.32340.59000@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 From buildsys at fedoraproject.org Sat May 13 00:31:41 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 13 May 2006 00:31:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-12 Message-ID: <20060513003141.32350.19507@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 From buildsys at fedoraproject.org Sat May 13 00:31:41 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 13 May 2006 00:31:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-12 Message-ID: <20060513003141.32346.83419@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From Axel.Thimm at ATrpms.net Sat May 13 01:21:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 13 May 2006 03:21:43 +0200 Subject: Maelstrom license clause In-Reply-To: <44651A9F.80605@kobold.org> References: <44651A9F.80605@kobold.org> Message-ID: <20060513012143.GB28903@neu.nirvana> On Fri, May 12, 2006 at 04:30:39PM -0700, Michael Thomas wrote: > I found the following clause in the Maelstrom package which is under > re-review after being moved from core to extras. The package is mostly > GPL, but there is the following extra clause in a README file: > > "The artwork and sounds used by Maelstrom are copyright Ambrosia > Software (http://www.ambrosiasw.com) and may not be redistributed > separately from the Maelstrom public GPL release." > > I seem to recall that there was a similar issue with uqm, but I don't > recall the conclusion. > > Is this something that makes incompatible with Fedora's licensing > requirements? It isn't consistent with the GPL which the total package is supposed to be under, so it's an invalid license add-on, or the total package is not GPL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Sat May 13 03:53:53 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 12 May 2006 22:53:53 -0500 (CDT) Subject: How do I know if someone is already working on a package? In-Reply-To: References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: On Fri, 12 May 2006, Christopher Stone wrote: > On 5/12/06, Peter Gordon wrote: >> >> Email this list? ;) > > Or you could just seach bugzilla. Maybe it's just me, but I'd lean toward emailing the list. I was about to put in the effort to roll a clean, FE-quality RPM for gpsdrive, but when I mentioned it on IRC, Andreas Thienemann told me he had one close to complete, but not yet submitted for review (so a search wouldn't have turned anything up). There could be a middle ground between a noisier list and duplicated efforts, I suppose -- maybe there could be a wiki page where people could list packages they're working on? I don't know. I just suspect I would've been rather irked to find out my work was for nothing. :P Jima From eric.tanguy at univ-nantes.fr Sat May 13 09:05:45 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sat, 13 May 2006 11:05:45 +0200 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <1147462329.3949.18.camel@localhost> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> <1147458726.2643.8.camel@bureau.maison> <1147462329.3949.18.camel@localhost> Message-ID: <1147511145.7558.3.camel@bureau.maison> Le vendredi 12 mai 2006 ? 12:32 -0700, Toshio Kuratomi a ?crit : > On Fri, 2006-05-12 at 20:32 +0200, Eric Tanguy wrote: > > > package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 > > > unresolved deps: > > > libguile.so.12 > > > libguile-ltdl.so.1 > > > libqthreads.so.12 > > > > > > package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 > > > unresolved deps: > > > libguile.so.12()(64bit) > > > libguile-ltdl.so.1()(64bit) > > > > > > package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc > > > unresolved deps: > > > libguile.so.12 > > > libguile-ltdl.so.1 > > > > Trying to rebuild it with mock give this error during building : > > g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 > > -mtune=generic -fasynchronous-unwind-tables -o drgeo drgenius_main.o > > drgenius_mdi.o drgenius_config.o drgeo_adaptDialog.o drgenius_view.o > > geo_view.o editor_view.o drgeo_init.o drgeo_printer.o > > -Wl,--export-dynamic ./geo/libgeo.a -lglade-2.0 -lgtk-x11-2.0 > > -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 > > -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lxml2 -lz > > -pthread /usr/lib/libguile.so -L/usr/lib -lgmp -lm -lltdl -lcrypt > > /usr/bin/ld: cannot find -lltdl > > collect2: ld returned 1 exit status > > > libltdl is from libtool. Seeing as one of the unresolved deps is > libguile-ltdl something might have changed in the upstream guile that > needs a change in the guile packaging for Core. Or it could be that > your package depends on ltdl directly. In either case, a BuildRequires > for libtool-ltdl-devel will probably get you past this error. > > If it is a problem with guile you should file a bug like "guile-devel > should Require libtool-ltdl-devel". > > -Toshio So adding BuildRequires for libtool-ltdl-devel solve the problem and now the package build fine in mock. My question is : guile have to require libtool-ltdl or my package have to require it ? Thanks Eric From buildsys at fedoraproject.org Sat May 13 09:46:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 13 May 2006 05:46:49 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060513094649.89C18152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 1 torque-2.1.0p0-2.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 13 09:46:55 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 13 May 2006 05:46:55 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060513094655.31B1D152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 1 torque-2.1.0p0-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 13 09:47:11 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 13 May 2006 05:47:11 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060513094711.4DEDA152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 2 torque-2.1.0p0-2.fc5 xemacs-sumo-20060510-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 13 09:47:18 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 13 May 2006 05:47:18 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060513094718.ECFD6152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 4 fedora-package-config-apt-5.89-3 perl-Pod-Readme-0.081-2.fc6 perl-Test-Portability-Files-0.05-2.fc6 torque-2.1.0p0-2.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at city-fan.org Sat May 13 13:06:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 13 May 2006 14:06:41 +0100 Subject: rpms/perl-Module-Build/devel .cvsignore, 1.9, 1.10 perl-Module-Build.spec, 1.15, 1.16 sources, 1.9, 1.10 In-Reply-To: <20060512223625.GA32247@osiris.silug.org> References: <200605121708.k4CH8CZu002604@cvs-int.fedora.redhat.com> <4464C502.4090000@city-fan.org> <20060512223625.GA32247@osiris.silug.org> Message-ID: <1147525602.3031.25.camel@laurel.intra.city-fan.org> On Fri, 2006-05-12 at 17:36 -0500, Steven Pritchard wrote: > On Fri, May 12, 2006 at 06:25:22PM +0100, Paul Howarth wrote: > > A bit OT, but have you managed to get Module::Build 0.28 to run the test > > suite successfully on anything older than FC4? The "compat" test seems > > to fail in various ways on FC3 and RHL9 here. > > I haven't tried to build it anywhere other than FC5 so far. > > Oh, and on a related note, one of the new dependencies for the new > Module::Build BuildRequires Module::Build, which won't install in > devel because of the new YAML I pushed out the other day. > > I guess the perl-YAML package needs to be removed from the repository > long enough for me to rebuild perl-Module-Build (and build the new > dependencies). I think a better solution would be to raise a bug on Module::Build upstream to get it to build against the new perl-YAML. Packages in a repository that depend on each other really can't be conflicting as well. Paul. From opensource at till.name Sat May 13 14:04:05 2006 From: opensource at till.name (Till Maas) Date: Sat, 13 May 2006 16:04:05 +0200 Subject: Claiming ownership for thinkpad related packages and pam_mount Message-ID: <200605131604.05348.opensource@till.name> Hiyas, some packages I like to use are orphaned so I tinker with the idea of claiming ownership of them. I am not an maintainer for anything at the moment so what do I have to do to claim ownership? I am interested in the following packages: xosd tpb tpctl thinkpad-kmod thinkpad-kmod-common configure-thinkpad pam_mount Regards, Till From opensource at till.name Sat May 13 14:33:19 2006 From: opensource at till.name (Till Maas) Date: Sat, 13 May 2006 16:33:19 +0200 Subject: Suggestion for new packages: avr-gcc, avr-binutils, avr-libc, avrdude, uisp, avra Message-ID: <200605131633.19606.opensource@till.name> Hello, I would like to include the following packages to extras: avr-gcc avr-binutils avr-libc - http://www.nongnu.org/avr-libc/ avrdude - http://savannah.nongnu.org/projects/avrdude uisp - http://savannah.nongnu.org/projects/uisp avra - http://avra.sourceforge.net/ Is anyone else already working on this? Are there any legal issues why this software could not be added to extras or can I start writing the SPEC files? Regards, Till From steve at silug.org Sat May 13 15:46:02 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 13 May 2006 10:46:02 -0500 Subject: rpms/perl-Module-Build/devel .cvsignore, 1.9, 1.10 perl-Module-Build.spec, 1.15, 1.16 sources, 1.9, 1.10 In-Reply-To: <1147525602.3031.25.camel@laurel.intra.city-fan.org> References: <200605121708.k4CH8CZu002604@cvs-int.fedora.redhat.com> <4464C502.4090000@city-fan.org> <20060512223625.GA32247@osiris.silug.org> <1147525602.3031.25.camel@laurel.intra.city-fan.org> Message-ID: <20060513154602.GA17613@osiris.silug.org> On Sat, May 13, 2006 at 02:06:41PM +0100, Paul Howarth wrote: > I think a better solution would be to raise a bug on Module::Build > upstream to get it to build against the new perl-YAML. Packages in a > repository that depend on each other really can't be conflicting as > well. The new version of Module::Build does build against the newer YAML. I should have updated Module::Build first though, because the old version won't install with a newer YAML. I think I nearly have a workaround though. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From steve at silug.org Sat May 13 15:57:04 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 13 May 2006 10:57:04 -0500 Subject: Squirrelmail plugin packaging naming In-Reply-To: <44606D5E.5040405@timj.co.uk> References: <44606D5E.5040405@timj.co.uk> Message-ID: <20060513155704.GB17613@osiris.silug.org> On Tue, May 09, 2006 at 11:22:22AM +0100, Tim Jackson wrote: > There are a couple of Squirrelmail plugins I'd like to package. I've > worked out things from the packaging side and been successfully using > them for a while, but I'm not sure about the naming. Let's take for > example the change_pass plugin. Here are some viable options for naming: > > 1. squirrelmail-plugin-change_pass That's what I went with when I packaged it a couple of years ago. http://apt.kspei.com/fedora/1/i386/SRPMS.kspei/squirrelmail-plugin-change_pass-2.6_1.4.x-0.fdr.0.1.src.rpm Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From jspaleta at gmail.com Sat May 13 16:23:11 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 13 May 2006 12:23:11 -0400 Subject: How do I know if someone is already working on a package? In-Reply-To: References: <38891.127.0.0.1.1147458016.squirrel@www.thecodergeek.com> Message-ID: <604aa7910605130923h762e9a78l27adf527b9b93a0b@mail.gmail.com> On 5/12/06, Jima wrote: > I don't know. I just suspect I would've been rather irked to find out my > work was for nothing. :P Clearly we need a bugzilla category for "packages I've started working on but haven't submitted". Which will of course then require a category for "packages I'm thinking real hard about working on, but haven't started". And of course that will most likely require a category for "packages that I may be interested in thinking about working on, but I haven't spent too much time thinking about thinking about it". -jef"then again... we do have a wiki... which seems to be a pretty good place to use as a centralized notepad about who is working on pre-submitted packages"spaleta From toshio at tiki-lounge.com Sat May 13 16:45:57 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 13 May 2006 09:45:57 -0700 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] In-Reply-To: <1147511145.7558.3.camel@bureau.maison> References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> <1147458726.2643.8.camel@bureau.maison> <1147462329.3949.18.camel@localhost> <1147511145.7558.3.camel@bureau.maison> Message-ID: <1147538757.3260.6.camel@localhost> On Sat, 2006-05-13 at 11:05 +0200, Eric Tanguy wrote: > Le vendredi 12 mai 2006 ? 12:32 -0700, Toshio Kuratomi a ?crit : > > libltdl is from libtool. Seeing as one of the unresolved deps is > > libguile-ltdl something might have changed in the upstream guile that > > needs a change in the guile packaging for Core. Or it could be that > > your package depends on ltdl directly. In either case, a BuildRequires > > for libtool-ltdl-devel will probably get you past this error. > > > > If it is a problem with guile you should file a bug like "guile-devel > > should Require libtool-ltdl-devel". > > > So adding BuildRequires for libtool-ltdl-devel solve the problem and now > the package build fine in mock. My question is : guile have to require > libtool-ltdl or my package have to require it ? > I strongly suspect that guile-devel needs to Requires: libtool-ltdl-devel but I haven't looked at either your package or guile's so I can't be certain. If you only bumped the release of your package (didn't take the opportunity to upgrade to a new upstream) I'd say file a bug against guile. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sat May 13 16:50:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 13 May 2006 18:50:03 +0200 Subject: Suggestion for new packages: avr-gcc, avr-binutils, avr-libc, avrdude, uisp, avra In-Reply-To: <200605131633.19606.opensource@till.name> References: <200605131633.19606.opensource@till.name> Message-ID: <20060513165003.GC1606@neu.nirvana> Hi Till, On Sat, May 13, 2006 at 04:33:19PM +0200, Till Maas wrote: > I would like to include the following packages to extras: > > avr-gcc > avr-binutils > avr-libc - http://www.nongnu.org/avr-libc/ > avrdude - http://savannah.nongnu.org/projects/avrdude > uisp - http://savannah.nongnu.org/projects/uisp > avra - http://avra.sourceforge.net/ > > Is anyone else already working on this? Are there any legal issues why this > software could not be added to extras or can I start writing the SPEC files? If it's accepted on savannah then it should be Free Software, but it's up to you (the packager) to check the explicit licenses that come with the downloaded bits or are displayed on any download pages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat May 13 18:05:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 13:05:00 -0500 Subject: [Fwd: Broken dependencies in Fedora Extras development - 2006-05-11] References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> <1147458726.2643.8.camel@bureau.maison> <1147462329.3949.18.camel@localhost> <1147511145.7558.3.camel@bureau.maison> <1147538757.3260.6.camel@localhost> Message-ID: Toshio Kuratomi wrote: > On Sat, 2006-05-13 at 11:05 +0200, Eric Tanguy wrote: >> Le vendredi 12 mai 2006 ? 12:32 -0700, Toshio Kuratomi a ?crit : > >> > libltdl is from libtool. Seeing as one of the unresolved deps is >> > libguile-ltdl something might have changed in the upstream guile that >> > needs a change in the guile packaging for Core. Or it could be that >> > your package depends on ltdl directly. In either case, a BuildRequires >> > for libtool-ltdl-devel will probably get you past this error. >> > >> > If it is a problem with guile you should file a bug like "guile-devel >> > should Require libtool-ltdl-devel". >> > >> So adding BuildRequires for libtool-ltdl-devel solve the problem and now >> the package build fine in mock. My question is : guile have to require >> libtool-ltdl or my package have to require it ? >> > I strongly suspect that guile-devel needs to > Requires: libtool-ltdl-devel guile is one of those guilty packages that include one (or more) dreaded .la files. I'll go file a bug. -- Rex From rdieter at math.unl.edu Sat May 13 18:12:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 13:12:02 -0500 Subject: development/guile-devel References: <46091.193.52.109.12.1147426778.squirrel@webmail.univ-nantes.fr> <1147458726.2643.8.camel@bureau.maison> <1147462329.3949.18.camel@localhost> <1147511145.7558.3.camel@bureau.maison> <1147538757.3260.6.camel@localhost> Message-ID: Rex Dieter wrote: > Toshio Kuratomi wrote: > >> On Sat, 2006-05-13 at 11:05 +0200, Eric Tanguy wrote: >>> Le vendredi 12 mai 2006 ? 12:32 -0700, Toshio Kuratomi a ?crit : >> >>> > libltdl is from libtool. Seeing as one of the unresolved deps is >>> > libguile-ltdl something might have changed in the upstream guile that >>> > needs a change in the guile packaging for Core. Or it could be that >>> > your package depends on ltdl directly. In either case, a >>> > BuildRequires for libtool-ltdl-devel will probably get you past this >>> > error. >>> > >>> > If it is a problem with guile you should file a bug like "guile-devel >>> > should Require libtool-ltdl-devel". >>> > >>> So adding BuildRequires for libtool-ltdl-devel solve the problem and now >>> the package build fine in mock. My question is : guile have to require >>> libtool-ltdl or my package have to require it ? >>> >> I strongly suspect that guile-devel needs to >> Requires: libtool-ltdl-devel > > guile is one of those guilty packages that include one (or more) dreaded > .la files. > > I'll go file a bug. See "guile-devel deps missing" http://bugzilla.redhat.com/191595 -- Rex From rdieter at math.unl.edu Sat May 13 18:20:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 13:20:05 -0500 Subject: FE/development builds failing, missing deps Message-ID: I'm seeinh some FE/development builds failing today, assuming usual development repo breakage (libX11/libXt mostly), but thought I'd post anyway in case it's just me: ---------------------------------------------------- ... /usr/sbin/mock-helper yum --installroot ... install 'zlib-devel' 'tetex-latex' 'aspell-devel' 'qt-devel' 'xforms-devel' 'python' 'tetex-fonts' 'desktop-file-utils' 'aiksaurus-devel' Error: Missing Dependency: libXt-devel is needed by package qt-devel Error: Missing Dependency: libX11.so.6 is needed by package tetex-fonts Error: Missing Dependency: libX11-devel is needed by package xforms-devel Error: Missing Dependency: libX11-devel is needed by package qt-devel Error: Missing Dependency: libX11.so.6 is needed by package xforms-devel Error: Missing Dependency: libXt.so.6 is needed by package tetex-fonts Error: Missing Dependency: libX11.so.6 is needed by package qt-devel Error: Missing Dependency: libX11.so.6 is needed by package qt Error: Missing Dependency: libX11.so.6 is needed by package libXft Error: Missing Dependency: libX11.so.6 is needed by package libXpm-devel Error: Missing Dependency: libX11.so.6 is needed by package libXrandr Error: Missing Dependency: libX11.so.6 is needed by package libXcursor Error: Missing Dependency: libX11.so.6 is needed by package libXrender Error: Missing Dependency: libX11-devel is needed by package libXpm-devel Error: Missing Dependency: libXau.so.6 is needed by package libXext Error: Missing Dependency: libX11.so.6 is needed by package libXpm Error: Missing Dependency: libX11.so.6 is needed by package libXinerama Error: Missing Dependency: libX11.so.6 is needed by package libXext Error: Missing Dependency: libX11.so.6 is needed by package xforms Error: Missing Dependency: libXt.so.6 is needed by package libXpm-devel Error: Missing Dependency: libX11-devel is needed by package libXext-devel Error: Missing Dependency: libX11.so.6 is needed by package mesa-libGL Error: Missing Dependency: libX11.so.6 is needed by package gd Error: Missing Dependency: libX11.so.6 is needed by package libXfixes Error: Missing Dependency: libX11-devel is needed by package mesa-libGL-devel Error: Missing Dependency: libX11.so.6 is needed by package libXxf86vm Cleaning up... Done. From bugs.michael at gmx.net Sat May 13 18:42:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 13 May 2006 20:42:01 +0200 Subject: AWOL owners and stale packages. In-Reply-To: <446507F2.1060303@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> Message-ID: <20060513204201.b6fdcc5e.bugs.michael@gmx.net> On Sat, 13 May 2006 10:10:58 +1200, Michael J Knox wrote: > >> The over all aim is to avoid "stale" packages in Extras, more swiftly > >> pick up on unmaintained packages and hopefully encourage people to work > >> on these packages by providing a process in which people can fix them. > > > > First of all, I think you mix a few things. Specifically, the NMU talks > > about "fixes", "bugs" and "serious problems", while you talk about > > "stale", "unmaintained" packages and "the take over of a package". Not > > sure whether you want to merge all that into a single policy. > > Possibly, I sort of see them one in the same. The "fixes, bugs and > serious problems" can only apply if the package owner has been contacted > and had no response. Okay. That, of course, is quite different from [and more detailed than] "avoiding stale packages". I just wanted to make sure that the reason for NMU-activity is given in _actual problems_ with a package and not just due to some contributors preferring to engage in a release-race with upstream. Those tickets like "version 1.2.3 is available, please upgrade", which are easily forgotten by packagers, who didn't like a new release when they evaluated/tried it. "Unmaintained packages" was another vague term you used above, which I didn't comment on. _Packages without a maintainer_ (= orphans) can be taken over very "swiftly", because there is no maintainer you need to try to contact. Hence no need for complicated policies in that area. > I see it as more of a taking small steps to ownership on a package where > the original owner is no longer contactable. Right, and where a package is broken. That's exactly where we should start. > > I would appreciate if we started bottom-up with a procedure for "Adoption > > of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then > > we enhance the procedure in order to permit certain actions (like > > requesting (re-)builds, fixing grave bugs) while it is still being waited > > for a response by the maintainer. It will probably, except for security > > issues, look like: > > > > - notify maintainer > > - wait X days > > - notify maintainer about planned take-over and > > planned actions [e.g. (re-)builds, fixes] > > - wait another X-Y days > > - touch the package > > - maybe wait another Z days > > - take over the package in owners.list > > > > Thats exactly what I was meaning. But its important that the "X, Y, Z" > time frames are well known and defined. Let's start with X, maximum packager response time for a bugzilla ticket, in which a serious (or normal) bug was reported. Would X=14 days be too short? X+Y would cover at least two weekends. I mean, if a packager is on a long vacation (several weeks or more) and is neglecting package maintenance knowingly, the package would be suitable for shared maintainership anyway. And in cases where a packager has had an accident or is facing temporary illness (and similar things), we're back at what I've written before -- that it should be in the packager's best interest that other contributors help. From ville.skytta at iki.fi Sat May 13 18:44:48 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 13 May 2006 21:44:48 +0300 Subject: Incoming: directfb soname problems In-Reply-To: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> Message-ID: <1147545888.2746.102.camel@localhost.localdomain> On Sat, 2006-05-13 at 10:35 -0700, Thomas Vander Stichele wrote: > Log Message: > new upstream release ...which due to the soname change in it, will break stuff and leave yum users without all updates until they figure out what repo they need to temporarily disable in case they're using ones that have dependent packages. libdirect-0.9.so.24 -> libdirect-0.9.so.25 libdirectfb-0.9.so.24 -> libdirectfb-0.9.so.25 libfusion-0.9.so.24 -> libfusion-0.9.so.25 This is the second consecutive update to directfb which will cause these problems. I've seen no mail about the change on lists that I follow. The packages are built for all repos all the way down to FC-3 (an "EOL"d release). Looks like nothing was learned from the previous directfb mess. *sigh* I'm inclined to move the FE-[345] packages at least temporarily away from the needsign queue so that it can be discussed/explained why the pain is necessary, and if it is, it can be properly announced and people (both packagers and users) can prepare. Objections? From bdpepple at ameritech.net Sat May 13 18:53:17 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 13 May 2006 14:53:17 -0400 Subject: FE/development builds failing, missing deps In-Reply-To: References: Message-ID: <1147546397.4718.1.camel@shuttle.piedmont.com> On Sat, 2006-05-13 at 13:20 -0500, Rex Dieter wrote: > I'm seeinh some FE/development builds failing today, assuming usual > development repo breakage (libX11/libXt mostly), but thought I'd post > anyway in case it's just me: > > ---------------------------------------------------- > ... > /usr/sbin/mock-helper yum --installroot ... > install 'zlib-devel' 'tetex-latex' 'aspell-devel' 'qt-devel' 'xforms-devel' 'python' 'tetex-fonts' 'desktop-file-utils' 'aiksaurus-devel' > Error: Missing Dependency: libXt-devel is needed by package qt-devel > Error: Missing Dependency: libX11.so.6 is needed by package tetex-fonts > Error: Missing Dependency: libX11-devel is needed by package xforms-devel > Error: Missing Dependency: libX11-devel is needed by package qt-devel > Error: Missing Dependency: libX11.so.6 is needed by package xforms-devel > Error: Missing Dependency: libXt.so.6 is needed by package tetex-fonts > Error: Missing Dependency: libX11.so.6 is needed by package qt-devel > Error: Missing Dependency: libX11.so.6 is needed by package qt > Error: Missing Dependency: libX11.so.6 is needed by package libXft > Error: Missing Dependency: libX11.so.6 is needed by package libXpm-devel > Error: Missing Dependency: libX11.so.6 is needed by package libXrandr > Error: Missing Dependency: libX11.so.6 is needed by package libXcursor > Error: Missing Dependency: libX11.so.6 is needed by package libXrender > Error: Missing Dependency: libX11-devel is needed by package libXpm-devel > Error: Missing Dependency: libXau.so.6 is needed by package libXext > Error: Missing Dependency: libX11.so.6 is needed by package libXpm > Error: Missing Dependency: libX11.so.6 is needed by package libXinerama > Error: Missing Dependency: libX11.so.6 is needed by package libXext > Error: Missing Dependency: libX11.so.6 is needed by package xforms > Error: Missing Dependency: libXt.so.6 is needed by package libXpm-devel > Error: Missing Dependency: libX11-devel is needed by package libXext-devel > Error: Missing Dependency: libX11.so.6 is needed by package mesa-libGL > Error: Missing Dependency: libX11.so.6 is needed by package gd > Error: Missing Dependency: libX11.so.6 is needed by package libXfixes > Error: Missing Dependency: libX11-devel is needed by package > mesa-libGL-devel > Error: Missing Dependency: libX11.so.6 is needed by package libXxf86vm > Cleaning up... > Done. > Yeah, looks like Rawhide is broken. I was experiencing the same problems this morning. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rtlm10 at gmail.com Sat May 13 19:29:50 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Sat, 13 May 2006 15:29:50 -0400 Subject: mock builds broken on FC5 machines Message-ID: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> Some of you may already be aware that doing a mock build on a FC5 machine doesn't pull in all of the packages you need to properly setup your build env. yum removed support for groupreq tags in the group definitions for version 2.6+ which prevents "yum groupinstall build" from pulling in its required groups. To fix mock builds on a machine with yum 2.6+ find the line "config_opts['buildgroup'] = 'build'" in each of your /etc/mock/*.cfg files and change it to "config_opts['buildgroup'] = 'build build-minimal build-base'". Those are all of the groups (that I know about) currently required by the group build. Everything should be happy again! There is a conversation going on in the yum-devel list about how to handle groupreq going forward. As is common in open source projects people are using features in ways that the developers didn't expect. I trust that Seth and crew will find us a good solution. Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Sat May 13 19:44:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 13 May 2006 21:44:20 +0200 Subject: Suggestion for new packages: avr-gcc, avr-binutils, avr-libc, avrdude, uisp, avra In-Reply-To: <200605131633.19606.opensource@till.name> References: <200605131633.19606.opensource@till.name> Message-ID: <44663714.9090704@hhs.nl> Till Maas wrote: > Hello, > > I would like to include the following packages to extras: > > avr-gcc > avr-binutils > avr-libc - http://www.nongnu.org/avr-libc/ > avrdude - http://savannah.nongnu.org/projects/avrdude > uisp - http://savannah.nongnu.org/projects/uisp > avra - http://avra.sourceforge.net/ > > Is anyone else already working on this? Are there any legal issues why this > software could not be added to extras or can I start writing the SPEC files? > > Regards, > Till > > AFAIK no one is working on these, and their licenses are fine (dunno about avra, and better check the others to make sure). I would love to see these packaged, put me in the CC field after filing the review requests and I'll review them ASAP (which may not be that soon though) Regards, Hans From j.w.r.degoede at hhs.nl Sat May 13 19:48:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 13 May 2006 21:48:14 +0200 Subject: Incoming: directfb soname problems In-Reply-To: <1147545888.2746.102.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> Message-ID: <446637FE.3080305@hhs.nl> Ville Skytt? wrote: > On Sat, 2006-05-13 at 10:35 -0700, Thomas Vander Stichele wrote: > >> Log Message: >> new upstream release > > ...which due to the soname change in it, will break stuff and leave yum > users without all updates until they figure out what repo they need to > temporarily disable in case they're using ones that have dependent > packages. > > libdirect-0.9.so.24 -> libdirect-0.9.so.25 > libdirectfb-0.9.so.24 -> libdirectfb-0.9.so.25 > libfusion-0.9.so.24 -> libfusion-0.9.so.25 > > This is the second consecutive update to directfb which will cause these > problems. I've seen no mail about the change on lists that I follow. > The packages are built for all repos all the way down to FC-3 (an "EOL"d > release). Looks like nothing was learned from the previous directfb > mess. *sigh* > > I'm inclined to move the FE-[345] packages at least temporarily away > from the needsign queue so that it can be discussed/explained why the > pain is necessary, and if it is, it can be properly announced and people > (both packagers and users) can prepare. Objections? > Being the one who caused the directfb disaster the last time *, I say remove them from the need sign queue for now and contact the maintainer about this. This will avoid us all a lot of pain. Not many people actually use directfb, but many have packages installed which can optionally use it and thus depend on it. * A new upstream version was needed to get it to build on devel, there was no package for devel available breaking devel and the maintainer wasn't responding so I jumped the gun (oops). Regards, Hans From thomas at apestaart.org Sat May 13 20:02:40 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 13 May 2006 22:02:40 +0200 Subject: Incoming: directfb soname problems In-Reply-To: <1147545888.2746.102.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> Message-ID: <1147550560.26066.21.camel@otto.amantes> On Sat, 2006-05-13 at 21:44 +0300, Ville Skytt? wrote: > On Sat, 2006-05-13 at 10:35 -0700, Thomas Vander Stichele wrote: > > > Log Message: > > new upstream release > > ...which due to the soname change in it, will break stuff and leave yum > users without all updates until they figure out what repo they need to > temporarily disable in case they're using ones that have dependent > packages. I hate that too, but it's a design choice in the package installer to have nothing be upgraded in the case of one problem in the repo. I've been told the reasons, so I'm not going to argue over that particular bit. > This is the second consecutive update to directfb which will cause these > problems. I've seen no mail about the change on lists that I follow. I think Hans did the previous push. I mailed the maintainers of the relevant packages (evas and ecore in extras, xine and mplayer somewhere else) This is always going to be a problem with directfb - I've requested a change in their way of maintaining and releasing before but they choose to keep doing it this way for now. > The packages are built for all repos all the way down to FC-3 (an "EOL"d > release). Looks like nothing was learned from the previous directfb > mess. *sigh* I thought packages that were already in FE3 had a policy of updates being at the discretion of the packager. If I'm wrong, then I apologize, and feel free to pull the package. > I'm inclined to move the FE-[345] packages at least temporarily away > from the needsign queue so that it can be discussed/explained why the > pain is necessary, and if it is, it can be properly announced and people > (both packagers and users) can prepare. Objections? We don't have many packages like directfb afaik that chose to have a different so name for each release. AFAIK we don't have a real policy for a case like this, and when I asked on IRC, people felt it was enough to warn the affected maintainers. Which is what I did. I'm happy to follow any other guidelines if there are others. Thomas From rdieter at math.unl.edu Sat May 13 21:16:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 16:16:10 -0500 Subject: Incoming: directfb soname problems References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147550560.26066.21.camel@otto.amantes> Message-ID: Thomas Vander Stichele wrote: > On Sat, 2006-05-13 at 21:44 +0300, Ville Skytt? wrote: >> The packages are built for all repos all the way down to FC-3 (an "EOL"d >> release). Looks like nothing was learned from the previous directfb >> mess. *sigh* > I thought packages that were already in FE3 had a policy of updates > being at the discretion of the packager. As it stands now, yes, but... not if it's going to cause pain for other maintainers who don't support FC3. -- Rex From Axel.Thimm at ATrpms.net Sat May 13 22:25:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 14 May 2006 00:25:08 +0200 Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <1147545888.2746.102.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> Message-ID: <20060513222508.GG1606@neu.nirvana> On Sat, May 13, 2006 at 09:44:48PM +0300, Ville Skytt? wrote: > On Sat, 2006-05-13 at 10:35 -0700, Thomas Vander Stichele wrote: > > > Log Message: > > new upstream release > > ...which due to the soname change in it, will break stuff and leave yum > users without all updates until they figure out what repo they need to > temporarily disable in case they're using ones that have dependent > packages. > > libdirect-0.9.so.24 -> libdirect-0.9.so.25 > libdirectfb-0.9.so.24 -> libdirectfb-0.9.so.25 > libfusion-0.9.so.24 -> libfusion-0.9.so.25 Maybe it's time to think about packaging so into their separate libfoo subpackages like Debian/Mandrake/ATrpms are doing? This always ensures forward and backward compatibility at the cost of dead libfoo packages lying around. But unused libfoo packages can be auto-cleaned should that be the only issue against them. And the management overhead can also be nicely reduced. If there is interest to look into that route I can elaborate more on this. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Sat May 13 21:15:01 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 13 May 2006 16:15:01 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-12 In-Reply-To: <20060513003141.32350.19507@extras64.linux.duke.edu> References: <20060513003141.32350.19507@extras64.linux.duke.edu> Message-ID: <1147554901.2512.146.camel@vader.jdub.homelinux.org> On Sat, 2006-05-13 at 00:31 +0000, Fedora Extras repoclosure wrote: > > package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 > unresolved deps: > libvte.so.4 Bugging the package owner about this. There's no spec file in the devel branch in CVS, and no log as to why it was removed. Filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191614 for it. josh From mpeters at mac.com Sun May 14 05:13:52 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 13 May 2006 22:13:52 -0700 Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <20060513222508.GG1606@neu.nirvana> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <20060513222508.GG1606@neu.nirvana> Message-ID: <1147583632.6910.58.camel@atlantis.mpeters.local> On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote: > > Maybe it's time to think about packaging so into their separate > libfoo subpackages like Debian/Mandrake/ATrpms are doing? This > always ensures forward and backward compatibility at the cost of dead > libfoo packages lying around. I semi agree. If a package containing shared libraries is updated, it should not be too hard to make a compat package, even if it *just* has the older shared libraries, so that things don't break. From ville.skytta at iki.fi Sun May 14 09:11:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 14 May 2006 12:11:19 +0300 Subject: Incoming: directfb soname problems In-Reply-To: <1147550560.26066.21.camel@otto.amantes> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147550560.26066.21.camel@otto.amantes> Message-ID: <1147597879.2746.151.camel@localhost.localdomain> On Sat, 2006-05-13 at 22:02 +0200, Thomas Vander Stichele wrote: > We don't have many packages like directfb afaik that chose to have a > different so name for each release. That's not really relevant. > when I asked on IRC, people felt it was enough > to warn the affected maintainers. Which is what I did. I strongly disagree with that. The fundamental problem is that one can't possibly reach the whole target audience. Have the maintainers ack'd that they will be able to ship updated packages shortly (or at all) after your update hits the repos, for all affected distro versions? Are you sure you mailed the correct individuals? Rhetorical: If not, have all end users been notified what they need to do in the meantime? If the answer to any of these is "no", this is a potential security issue, which you're essentially willingly inflicting on users. I didn't see immediate commits following the directfb one to affected FE packages in the commits list, which already proves that as implemented, this update was a failure even within FE. > I'm happy to follow any other guidelines if there are others. A real policy in FESCO's TODO list. Some members were skeptical whether a policy is needed, but this reoccurring example probably serves as a good case in point. (My personal opinions follow.) The absolute minimum one can do is to think hard whether it makes sense to inflict the pain in the first place. If the conclusion is yes, in addition to poking chosen maintainers, announce it (along with the reasoning why it's going to be done!) prominently in public well (I'd say minimum 3 working days) before queuing the builds. The fedora-maintainers list has been used for these announcements in the past and should be used in the future. It won't hurt to send it to other lists as well, such as this list and 3rd party repo lists. I've temporarily moved the packages out of the needsign queue so the update can be reconsidered (as a whole or partially), and if still wanted, properly communicated before done. From ville.skytta at iki.fi Sun May 14 09:12:48 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 14 May 2006 12:12:48 +0300 Subject: Claiming ownership for thinkpad related packages and pam_mount In-Reply-To: <200605131604.05348.opensource@till.name> References: <200605131604.05348.opensource@till.name> Message-ID: <1147597968.2746.153.camel@localhost.localdomain> On Sat, 2006-05-13 at 16:04 +0200, Till Maas wrote: > some packages I like to use are orphaned so I tinker with the idea of claiming > ownership of them. I am not an maintainer for anything at the moment so what > do I have to do to claim ownership? IIRC you were considering submitting some other packages for review; when some of those are in and you have an account and a sponsor, just grab 'em. From fedora at leemhuis.info Sun May 14 09:45:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 11:45:46 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147545888.2746.102.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> Message-ID: <1147599946.2924.25.camel@localhost.localdomain> Seems scop said all the important things about the problems with this directfb update already so I like to use this opportunity to comment on something related. Am Samstag, den 13.05.2006, 21:44 +0300 schrieb Ville Skytt?: > [...] > The packages are built for all repos all the way down to FC-3 (an "EOL"d > release). > [...] This (e.g. pushing a [major] version update to FE4, FE5 and devel at the same time) is something I more and more dislike. Even if soname's don't change -- every update bears a risk of breaking stuff (especially updates to a new [major] version). Yes, often it works without problems, but our experience and mails like https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00332.html show that sometimes things simply break now and then. We should do our best to avoid that our users run into such problems. That's one of the reasons why I still would like to have a testing repo where all (or at least the major package updates) hang out some days until they get pushed to the proper repo. And/or a policy (or make it a strong suggestion to packagers) that "[major] version updates should be build for devel first; builds for stable releases shouldn't be done sooner than five days after the devel packages was published". Security-updates of course are outside this scope and should of course be pushed as fast as possible. Just my 2 cent. Other opinions? CU thl -- Thorsten Leemhuis From bugs.michael at gmx.net Sun May 14 11:13:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 14 May 2006 13:13:24 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147599946.2924.25.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> Message-ID: <20060514131324.79e11d67.bugs.michael@gmx.net> On Sun, 14 May 2006 11:45:46 +0200, Thorsten Leemhuis wrote: > Seems scop said all the important things about the problems with this > directfb update already so I like to use this opportunity to comment on > something related. > > Am Samstag, den 13.05.2006, 21:44 +0300 schrieb Ville Skytt?: > > [...] > > The packages are built for all repos all the way down to FC-3 (an "EOL"d > > release). > > [...] > > This (e.g. pushing a [major] version update to FE4, FE5 and devel at the > same time) is something I more and more dislike. Even if soname's don't > change -- every update bears a risk of breaking stuff (especially > updates to a new [major] version). Yes, often it works without problems, > but our experience and mails like > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00332.html > show that sometimes things simply break now and then. We should do our > best to avoid that our users run into such problems. > > That's one of the reasons why I still would like to have a testing repo > where all (or at least the major package updates) hang out some days > until they get pushed to the proper repo. And/or a policy (or make it a > strong suggestion to packagers) that "[major] version updates should be > build for devel first; builds for stable releases shouldn't be done > sooner than five days after the devel packages was published". > > Security-updates of course are outside this scope and should of course > be pushed as fast as possible. > > Just my 2 cent. Other opinions? It makes upgrades even more complicated. Remember a few things: 1) A regular [updates-]testing repository exposes only some users to package releases which may or may not become official. This adds another upgrade path. Do we work around bugs introduced in these updates? Do enough active users enable such an optional repository, so that it would become really helpful? I think Fedora Core Test Updates suffer from quite some desinterest. Lack of feedback--also success reports--about test updates doesn't help you to decide whether an update is good. 2) Will the build system build against the test updates or only against official updates in the main repository? In case it builds against test updates, what do we do if they are broken? And how are test updates pushed or withdrawn when dependencies have or have not been built against them? How does an additional repo solve the problem of insufficient communication about upgrades and rebuilds of complete dependency chains? From fedora at leemhuis.info Sun May 14 11:50:13 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 13:50:13 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <20060514131324.79e11d67.bugs.michael@gmx.net> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> Message-ID: <1147607413.18635.24.camel@localhost.localdomain> Am Sonntag, den 14.05.2006, 13:13 +0200 schrieb Michael Schwendt: > On Sun, 14 May 2006 11:45:46 +0200, Thorsten Leemhuis wrote: > > Am Samstag, den 13.05.2006, 21:44 +0300 schrieb Ville Skytt?: > > > [...] > > > The packages are built for all repos all the way down to FC-3 (an "EOL"d > > > release). > > > [...] > > > > This (e.g. pushing a [major] version update to FE4, FE5 and devel at the > > same time) is something I more and more dislike. Even if soname's don't > > change -- every update bears a risk of breaking stuff (especially > > updates to a new [major] version). Yes, often it works without problems, > > but our experience and mails like > > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00332.html > > show that sometimes things simply break now and then. We should do our > > best to avoid that our users run into such problems. > > > > That's one of the reasons why I still would like to have a testing repo > > where all (or at least the major package updates) hang out some days > > until they get pushed to the proper repo. And/or a policy (or make it a > > strong suggestion to packagers) that "[major] version updates should be > > build for devel first; builds for stable releases shouldn't be done > > sooner than five days after the devel packages was published". > > > > Security-updates of course are outside this scope and should of course > > be pushed as fast as possible. > > > > Just my 2 cent. Other opinions? > > It makes upgrades even more complicated. Yes, I know. > Remember a few things: > > 1) A regular [updates-]testing repository exposes only some users to > package releases which may or may not become official. This adds another > upgrade path. Do we work around bugs introduced in these updates? What kind of bugs do you mean exactly? How does core handle it? > Do > enough active users enable such an optional repository, so that it would > become really helpful? That's always problematic. But that's not a reason not to do it. It IMHO would be helpful enough if only all the Extras packagers would enable it and test their own packages falling out plague. (they can do that with the needsign-repo, too, but I doubt that a lot of people do that) > I think Fedora Core Test Updates suffer from quite > some desinterest. Well, it's not perfect, but I think it works good enough. > Lack of feedback--also success reports--about test > updates doesn't help you to decide whether an update is good. Well, currently there is no testing or decision if a update is good at all (besides the checking from the packager himself). As a ordinary user I'd much more prefer a package that was in extras-testing for some days (without feedback) over one that got no testing at all. > 2) Will the build system build against the test updates or only against > official updates in the main repository? That's the biggest problem. > In case it builds against test > updates, what do we do if they are broken? The same what we do now when a broken package hits the repo. And to make it sure (in case it wasn't already): No, I don't want a explicit testing repo where stuff could be published and tested that is not ready yet. I only want a testing repo where all updates hang out some days before they hit the proper repo. First in and First out (if there is no major breakage). > And how are test updates pushed Fifo. Example: Package foo is pushed to testing today (Sunday) and bar on Monday. foo will be pushed to the proper repo on Friday and bar on Saturday. > or withdrawn when dependencies have or have not been built against them? good question. But that shouldn't normally be the case. Another example (in case a problem showed up): Package foo is pushed to testing today (Sunday) and bar on Monday (bar depends on the new foo). foo makes problems. foo is fixed quickly on Tuesday. foo and bar get pushed to the proper repo on Saturday. > How does an additional repo solve the problem of insufficient > communication about upgrades and rebuilds of complete dependency chains? Not at all. That's not it's purpose. /me feels misunderstood CU thl /me sometimes doesn't understand the Open-Source-World -- a lot of people (see the achieves of the fedora mailinglists) scream when Fedora Core updates a package directly without letting it linger around in updates-testing for some days. But proposing the same concept for Extras only get criticism. Why should Extras be different? *Especially* because Extras has major version updates that are avoided in Core. -- Thorsten Leemhuis From giallu at gmail.com Sun May 14 13:29:37 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 14 May 2006 15:29:37 +0200 Subject: mock builds broken on FC5 machines In-Reply-To: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> References: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> Message-ID: On 5/13/06, Russell Harrison wrote: > To fix mock builds on a machine with yum 2.6+ find the line > "config_opts['buildgroup'] = 'build'" in each of your /etc/mock/*.cfg files > and change it to "config_opts['buildgroup'] = 'build build-minimal > build-base'". Those are all of the groups (that I know about) currently > required by the group build. Everything should be happy again! Thanks for the info... I was just wondering what was wrong with my mock... on a side note, is that normal that /etc/mock/fedora-5-i386-core.cfg is set to install from the development repo? i.e: [core] name=core baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 [groups] name=groups baseurl=http://fedoraproject.org/buildgroups/development/i386/ [extras] name=extras baseurl=http://fedoraproject.org/extras/development/i386 [local] name=local baseurl=http://extras64.linux.duke.edu/plague-results/development/ From bugs.michael at gmx.net Sun May 14 14:19:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 14 May 2006 16:19:19 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147607413.18635.24.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> Message-ID: <20060514161919.3ab454cf.bugs.michael@gmx.net> On Sun, 14 May 2006 13:50:13 +0200, Thorsten Leemhuis wrote: > > Remember a few things: > > > > 1) A regular [updates-]testing repository exposes only some users to > > package releases which may or may not become official. This adds another > > upgrade path. Do we work around bugs introduced in these updates? > > What kind of bugs do you mean exactly? How does core handle it? For instance: A bug in a package scriptlet, which touches some files and damages them. Will the final update try to repair the damage? Or: Accidentally dropped features, which are missing because a configure script failed to detect upgraded build requirements and hence disabled some pieces. In several applications, related configuration settings are lost when features are removed (a concrete example is Sylpheed). One thing for sure, both are scenarios which can happen. However, from a user's perspective it must be clear in which ways another extras-testing repository differs from the normal extras repository. Increased risk -> possibly increased requirement to recover from broken test updates -> the smell of guinea pigs -> the optional testing repository does not become popular -> doubtful benefit. > > Do > > enough active users enable such an optional repository, so that it would > > become really helpful? > > That's always problematic. But that's not a reason not to do it. It IMHO > would be helpful enough if only all the Extras packagers would enable it > and test their own packages falling out plague. (they can do that with > the needsign-repo, too, but I doubt that a lot of people do that) Most likely because there is no convenient way to pull a package from the needsign-repo [and any deps built against it]. And no way to put a lock on a set of packages in the needsign queue in order to release the complete set as a whole. How about picking up the old idea of a "scratch target" instead? > > I think Fedora Core Test Updates suffer from quite > > some desinterest. > > Well, it's not perfect, but I think it works good enough. As a counter-example, createrepo for FC4 and FC3 has still not been updated to fix the broken deps in Extras' "plague". If the Test Update repository were popular and helpful and if the developers believed in it, the errata for FC4/FC3 would have happened already long ago. > > Lack of feedback--also success reports--about test > > updates doesn't help you to decide whether an update is good. > > Well, currently there is no testing or decision if a update is good at > all (besides the checking from the packager himself). As a ordinary user > I'd much more prefer a package that was in extras-testing for some days > (without feedback) over one that got no testing at all. ? Is a package in extras/5, which is four weeks old, more safe to use than a package in extras/5, which is two hours old? The age of a package is irrelevant. The number of competent (!) testers who actually tested it and report success or failure, is the interesting bit. > And to make it sure (in case it wasn't already): No, I don't want a > explicit testing repo where stuff could be published and tested that is > not ready yet. I only want a testing repo where all updates hang out > some days before they hit the proper repo. First in and First out (if > there is no major breakage). And *if* there is major breakage? Which pieces would you want to hold up? And how? > > And how are test updates pushed > > Fifo. Example: Package foo is pushed to testing today (Sunday) and bar > on Monday. foo will be pushed to the proper repo on Friday and bar on > Saturday. Before that becomes possible we will need a way to mark packages which depend on eachother, so they are only pushed together. Plus a way to prioritise build jobs and releases (not just with security fixes in mind). > > or withdrawn when dependencies have or have not been built against them? > > good question. But that shouldn't normally be the case. > > Another example (in case a problem showed up): Package foo is pushed to > testing today (Sunday) and bar on Monday (bar depends on the new foo). > foo makes problems. foo is fixed quickly on Tuesday. foo and bar get > pushed to the proper repo on Saturday. Automatically? So, Extras packagers must watch another moving target? > > How does an additional repo solve the problem of insufficient > > communication about upgrades and rebuilds of complete dependency chains? > > Not at all. That's not it's purpose. /me feels misunderstood Then I must admit I don't understand the purpose of an extras-testing repository (in the context of how we've been doing builds/releases for quite some time). > CU > thl > > /me sometimes doesn't understand the Open-Source-World -- a lot of > people (see the achieves of the fedora mailinglists) scream when Fedora > Core updates a package directly without letting it linger around in > updates-testing for some days. ? Well, I see no users who scream and demand an extras-testing repository. We must improve in the area of _Package Upgrade Guidelines/Policies_, not create extra burden and artificial hurdles for the packagers. > But proposing the same concept for Extras > only get criticism. Why should Extras be different? *Especially* because > Extras has major version updates that are avoided in Core. From laurent.rineau__fc_extra at normalesup.org Sun May 14 15:12:28 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Sun, 14 May 2006 17:12:28 +0200 Subject: Packages guidelines: documentation subpackages name Message-ID: <200605141712.28690@rineau.schtroumpfette> At http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation we can read "it is recommended to use *-doc as the subpackage name", whereas in http://fedoraproject.org/wiki/Packaging/ReviewGuidelines we can read "-?MUST:?Large documentation files should go in a -docs subpackage." So, could we agree on one policy? FC and FE seem to mix the two styles of naming. Looking at /var/cache/yum/{core,extras}/primary.xml.gz, if found in fe5: 30 "-doc" 19 "-docs" and in fc5: 16 "-doc" 5 "-docs" From fedora at leemhuis.info Sun May 14 15:21:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 17:21:00 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <20060514161919.3ab454cf.bugs.michael@gmx.net> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> Message-ID: <1147620060.18635.71.camel@localhost.localdomain> Am Sonntag, den 14.05.2006, 16:19 +0200 schrieb Michael Schwendt: > On Sun, 14 May 2006 13:50:13 +0200, Thorsten Leemhuis wrote: > > > > Remember a few things: > > > > > > 1) A regular [updates-]testing repository exposes only some users to > > > package releases which may or may not become official. This adds another > > > upgrade path. Do we work around bugs introduced in these updates? > > What kind of bugs do you mean exactly? How does core handle it? > For instance: A bug in a package scriptlet, which touches some files and > damages them. Will the final update try to repair the damage? Good question -- I think that needs to be handled in a case by case decision. And it nothing that hopefully happens really that often. > Or: Accidentally dropped features, which are missing because a configure > script failed to detect upgraded build requirements and hence disabled > some pieces. In several applications, related configuration settings are > lost when features are removed (a concrete example is Sylpheed). > > One thing for sure, both are scenarios which can happen. Agreed. And that's why it we IMHO should have a testing repo to protect the users a bit more than we do now ;-) > However, from a > user's perspective it must be clear in which ways another extras-testing > repository differs from the normal extras repository. No real difference -- just a "they hang out there some days before they hit the usual repo". > Increased risk -> possibly increased requirement to recover from broken > test updates -> the smell of guinea pigs -> the optional testing > repository does not become popular -> doubtful benefit. Depends on how it is used. There shouldn't be and increased risk with my planed way to run it (just a repo where updated packages Fifo before they hit the proper repo) > > > Do > > > enough active users enable such an optional repository, so that it would > > > become really helpful? > > That's always problematic. But that's not a reason not to do it. It IMHO > > would be helpful enough if only all the Extras packagers would enable it > > and test their own packages falling out plague. (they can do that with > > the needsign-repo, too, but I doubt that a lot of people do that) > Most likely because there is no convenient way to pull a package from the > needsign-repo [and any deps built against it]. And no way to put a lock on > a set of packages in the needsign queue in order to release the complete > set as a whole. Yes, that could lead to problems -- did we hit such cases yet? (that's not meant as a rhetoric question -- more it "if the answer is 'yes, often' then we might need to do something to avoid this in the future) > How about picking up the old idea of a "scratch target" instead? The idea is still around -- I think there are mainly two things blocking it - update to new plague - someone that's works out the details how it actually works and that drives the whole idea forward > > > I think Fedora Core Test Updates suffer from quite > > > some desinterest. > > Well, it's not perfect, but I think it works good enough. > As a counter-example, createrepo for FC4 and FC3 has still not been > updated to fix the broken deps in Extras' "plague". If the Test Update > repository were popular and helpful and if the developers believed in it, > the errata for FC4/FC3 would have happened already long ago. The Core testing suffers IMHO from this: updates are posted there for testing and get forgotten. That's why I proposed a time-based scheme. > > > Lack of feedback--also success reports--about test > > > updates doesn't help you to decide whether an update is good. > > Well, currently there is no testing or decision if a update is good at > > all (besides the checking from the packager himself). As a ordinary user > > I'd much more prefer a package that was in extras-testing for some days > > (without feedback) over one that got no testing at all. > ? Is a package in extras/5, which is four weeks old, more safe to use > than a package in extras/5, which is two hours old? Partly -- because the older package probably is in use on several machines already; if it would have major problems people would have filed bug-reports and we would have removed or fixed the package in between. For the one that is two hours old it is likely that I'm one of its first users -- I'm the tester then, if I want or not. Example: A package which is in extras/5 for two hours after it was in extras/testing/5 for a weeks IMHO is more safe to use then a package that is build three hours ago and was published directly to the repo (even the package maintainer might be sleeping and couldn't test the package due to that yet) > The age of a package > is irrelevant. The number of competent (!) testers who actually tested it > and report success or failure, is the interesting bit. Sure. But currently we have no tester's at all. I'd like to have testers. > > And to make it sure (in case it wasn't already): No, I don't want a > > explicit testing repo where stuff could be published and tested that is > > not ready yet. I only want a testing repo where all updates hang out > > some days before they hit the proper repo. First in and First out (if > > there is no major breakage). > And *if* there is major breakage? Which pieces would you want to hold up? > And how? That is outside the scope of this particular discussion afaics -- sure, the questions need answers. But a "major breakage" can happen any time -- with or without testing repo is mostly irrelevant. But a testing repo might limit the impact because only those that have testing enabled will be affected and not everyone. > > > And how are test updates pushed > > Fifo. Example: Package foo is pushed to testing today (Sunday) and bar > > on Monday. foo will be pushed to the proper repo on Friday and bar on > > Saturday. > Before that becomes possible we will need a way to mark packages which > depend on eachother, so they are only pushed together. We probably need that, yes. But we simply could use the current scheme until then: packages foo1 and foo2 are build and a particular point in time and pushed to the testing repo together and another point of time. bar1 and bar2 get build some days later and also pushed to testing together. Five days after foo1 and foo2 were pushed both pacakgers are moved from testing to the proper repo. bar1 and bar2 would follow together five days after their push. > Plus a way to > prioritise build jobs and releases (not just with security fixes in mind). Well, we need that in any case. > > > or withdrawn when dependencies have or have not been built against them? > > good question. But that shouldn't normally be the case. > > Another example (in case a problem showed up): Package foo is pushed to > > testing today (Sunday) and bar on Monday (bar depends on the new foo). > > foo makes problems. foo is fixed quickly on Tuesday. foo and bar get > > pushed to the proper repo on Saturday. > Automatically? Unsure. But yeah, why not. > So, Extras packagers must watch another moving target? What do they have to watch precisely? I only seem problems when some packages are pushed directly to the repo. That should only happen for security issues -- we IMHo should be able to handle that. > > > How does an additional repo solve the problem of insufficient > > > communication about upgrades and rebuilds of complete dependency chains? > > Not at all. That's not it's purpose. /me feels misunderstood > Then I must admit I don't understand the purpose of an extras-testing > repository (in the context of how we've been doing builds/releases for > quite some time). Seems so. > > /me sometimes doesn't understand the Open-Source-World -- a lot of > > people (see the achieves of the fedora mailinglists) scream when Fedora > > Core updates a package directly without letting it linger around in > > updates-testing for some days. > > ? > > Well, I see no users who scream and demand an extras-testing repository. /me is one user and I'd like to have one ;-) Others around? But it really seems I'm in the minority in Extras land. So I'll be quiet for another while again and will probably stay away from this discussion. > We must improve in the area of _Package Upgrade Guidelines/Policies_, Agreed. > not create extra burden and artificial hurdles for the packagers. I don't see any new burden for the packagers. CU thl -- Thorsten Leemhuis From ville.skytta at iki.fi Sun May 14 15:33:23 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 14 May 2006 18:33:23 +0300 Subject: Packages guidelines: documentation subpackages name In-Reply-To: <200605141712.28690@rineau.schtroumpfette> References: <200605141712.28690@rineau.schtroumpfette> Message-ID: <1147620803.2746.158.camel@localhost.localdomain> On Sun, 2006-05-14 at 17:12 +0200, Laurent Rineau wrote: > At http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation we > can read "it is recommended to use *-doc as the subpackage name", whereas in > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines we can read > "- MUST: Large documentation files should go in a -docs subpackage." > > So, could we agree on one policy? FC and FE seem to mix the two styles of > naming. Looking at /var/cache/yum/{core,extras}/primary.xml.gz, if found in > fe5: > 30 "-doc" > 19 "-docs" > and in fc5: > 16 "-doc" > 5 "-docs" +1 to -doc. There's also -manual which could fall into the same category and packaged just as -doc. Someone will probably argue that -doc should be reserved for subpackages and -manual for ones that are built from their own SRPM, I'll say in advance that I disagree and the user doesn't care :) From chris.stone at gmail.com Sun May 14 16:22:19 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 14 May 2006 09:22:19 -0700 Subject: Packages guidelines: documentation subpackages name In-Reply-To: <1147620803.2746.158.camel@localhost.localdomain> References: <200605141712.28690@rineau.schtroumpfette> <1147620803.2746.158.camel@localhost.localdomain> Message-ID: On 5/14/06, Ville Skytt? wrote: > On Sun, 2006-05-14 at 17:12 +0200, Laurent Rineau wrote: > > At http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation we > > can read "it is recommended to use *-doc as the subpackage name", whereas in > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines we can read > > "- MUST: Large documentation files should go in a -docs subpackage." > > > > So, could we agree on one policy? FC and FE seem to mix the two styles of > > naming. Looking at /var/cache/yum/{core,extras}/primary.xml.gz, if found in > > fe5: > > 30 "-doc" > > 19 "-docs" > > and in fc5: > > 16 "-doc" > > 5 "-docs" > > +1 to -doc. > > There's also -manual which could fall into the same category and > packaged just as -doc. Someone will probably argue that -doc should be > reserved for subpackages and -manual for ones that are built from their > own SRPM, I'll say in advance that I disagree and the user doesn't > care :) According to the Package Review guidelines it should be "docs". - MUST: Large documentation files should go in a -docs subpackage. From chris.stone at gmail.com Sun May 14 16:27:08 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 14 May 2006 09:27:08 -0700 Subject: Packages guidelines: documentation subpackages name In-Reply-To: References: <200605141712.28690@rineau.schtroumpfette> <1147620803.2746.158.camel@localhost.localdomain> Message-ID: On 5/14/06, Christopher Stone wrote: > On 5/14/06, Ville Skytt? wrote: > > On Sun, 2006-05-14 at 17:12 +0200, Laurent Rineau wrote: > > > At http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation we > > > can read "it is recommended to use *-doc as the subpackage name", whereas in > > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines we can read > > > "- MUST: Large documentation files should go in a -docs subpackage." > > > > > > So, could we agree on one policy? FC and FE seem to mix the two styles of > > > naming. Looking at /var/cache/yum/{core,extras}/primary.xml.gz, if found in > > > fe5: > > > 30 "-doc" > > > 19 "-docs" > > > and in fc5: > > > 16 "-doc" > > > 5 "-docs" > > > > +1 to -doc. > > > > There's also -manual which could fall into the same category and > > packaged just as -doc. Someone will probably argue that -doc should be > > reserved for subpackages and -manual for ones that are built from their > > own SRPM, I'll say in advance that I disagree and the user doesn't > > care :) > > > According to the Package Review guidelines it should be "docs". > > - MUST: Large documentation files should go in a -docs subpackage. > Whoops didn't read the whole thread, you can ignore my last message, or just count it as +1 for docs ;-) From triad at df.lth.se Sun May 14 16:54:57 2006 From: triad at df.lth.se (Linus Walleij) Date: Sun, 14 May 2006 18:54:57 +0200 (CEST) Subject: License query In-Reply-To: <44648AEE.40702@city-fan.org> References: <44648AEE.40702@city-fan.org> Message-ID: On Fri, 12 May 2006, Paul Howarth wrote: > It looks quite free apart from the "as long as ... you do not ... try to sell > it" clause, which I think disqualifies it as free software despite what the > first sentence of the license terms states. Is this OK for Extras or not? It is not. It is one of those nasty cases when a package pretends to be free but is not. Linus From triad at df.lth.se Sun May 14 17:21:14 2006 From: triad at df.lth.se (Linus Walleij) Date: Sun, 14 May 2006 19:21:14 +0200 (CEST) Subject: Maelstrom license clause In-Reply-To: <20060513012143.GB28903@neu.nirvana> References: <44651A9F.80605@kobold.org> <20060513012143.GB28903@neu.nirvana> Message-ID: On Sat, 13 May 2006, Axel Thimm wrote: > On Fri, May 12, 2006 at 04:30:39PM -0700, Michael Thomas wrote: >> there is the following extra clause in a README file: >> >> "The artwork and sounds used by Maelstrom are copyright Ambrosia >> Software (http://www.ambrosiasw.com) and may not be redistributed >> separately from the Maelstrom public GPL release." >> >> Is this something that makes incompatible with Fedora's licensing >> requirements? > > It isn't consistent with the GPL which the total package is supposed > to be under, so it's an invalid license add-on, or the total package > is not GPL. I doubt it. It may be clumsy wording but I read it as "look, Maelstrom is GPL, this also goes for the graphics and stuff" i.e. just a clarification, not a license clause at all. The GPL already forbids you to remove the license from a package, so I don't think it's GPL incompatible. It actually says you may redistribute the artwork and sound separately as long as you send a copy of GPL with it, which is exactly what the GPL already mandates. Linus From Axel.Thimm at ATrpms.net Sun May 14 17:43:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 14 May 2006 19:43:57 +0200 Subject: Maelstrom license clause In-Reply-To: References: <44651A9F.80605@kobold.org> <20060513012143.GB28903@neu.nirvana> Message-ID: <20060514174357.GA22432@neu.nirvana> On Sun, May 14, 2006 at 07:21:14PM +0200, Linus Walleij wrote: > On Sat, 13 May 2006, Axel Thimm wrote: > > >On Fri, May 12, 2006 at 04:30:39PM -0700, Michael Thomas wrote: > > >>there is the following extra clause in a README file: > >> > >>"The artwork and sounds used by Maelstrom are copyright Ambrosia > >>Software (http://www.ambrosiasw.com) and may not be redistributed > >>separately from the Maelstrom public GPL release." > >> > >>Is this something that makes incompatible with Fedora's licensing > >>requirements? > > > >It isn't consistent with the GPL which the total package is supposed > >to be under, so it's an invalid license add-on, or the total package > >is not GPL. > > I doubt it. It may be clumsy wording but I read it as "look, Maelstrom is > GPL, this also goes for the graphics and stuff" i.e. just a clarification, > not a license clause at all. The GPL already forbids you to remove the > license from a package, so I don't think it's GPL incompatible. > > It actually says you may redistribute the artwork and sound separately as > long as you send a copy of GPL with it, which is exactly what the GPL > already mandates. No, I don't think that this is what they mean. It doesn't refer to the GPL license, but to the GPL release (implying that there is another non-GPL'd product). So you are not allowed to redistribute a modified version of the work, which may just happen to be the original work stripped by everything but the artwork/sounds. This of course is in conflict with the GPL. Anyway, the best thing is if the original poster or any other interested party brings this to the vendor's attention and asks for a correction of the license text or otherwise clarifies the situation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sun May 14 18:09:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 14 May 2006 20:09:15 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147620060.18635.71.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> <1147620060.18635.71.camel@localhost.localdomain> Message-ID: <20060514200915.8d63f6ab.bugs.michael@gmx.net> On Sun, 14 May 2006 17:21:00 +0200, Thorsten Leemhuis wrote: > But we simply could use the current scheme > until then: packages foo1 and foo2 are build and a particular point in > time and pushed to the testing repo together and another point of time. > bar1 and bar2 get build some days later and also pushed to testing > together. Five days after foo1 and foo2 were pushed both pacakgers are > moved from testing to the proper repo. bar1 and bar2 would follow > together five days after their push. foo1 and foo2 break dependencies in extras-testing. :) Let's assume extras-testing is covered by a repoclosure report. Still, only after 2-3 days a real user gets nervous and reports the breakage. A day later another packager, who receives the reports, rebuilds his packages bar1 and bar2 to fix the broken deps and pushes the builds into extras-testing. So, how do you forward the entire set into extras finally? If it's done automatically, foo1 and foo2 are pushed several days before bar1 and bar2. (yes, it needs somebody to push all four packages at once, something that has failed several times before for Core, btw) (Or Possibly you want to resolve all deps automatically, but in that case it might happen that foo1 is 7 days old, while baz2 has just been built, and then you might wait to give the set some longer testing) Conclusively, what we need to shield our users from broken updates is more careful packagers, more communication and coordination of upgrades which affect dependencies, and convenient access to a scratch target in the buildsys, so not every packager must set up mock and local mirrors of multiple distribution releases. And of course guidelines and hints on how to avoid common upgrade mistakes (like SONAME changes). > > So, Extras packagers must watch another moving target? > > What do they have to watch precisely? I only seem problems when some > packages are pushed directly to the repo. That should only happen for > security issues -- we IMHo should be able to handle that. As soon as any package, which has dependencies in Extras (whether at build-time or run-time, doesn't matter), is pushed into extras-testing, the affected Extras packagers must do their own preparations and testing against the new stuff in _extras-testing_. And unfortunately, they have the choice between two build targets now, "extras" and "extras-testing", which gets particularly funny when security fixes join the show. I smell chaos and extra burden. Think fedora.us unstable/testing/stable. At first we liked it, and possibly considered the classification of new packages as helpful. It was less easy for version upgrades, cvs snapshots and added packages to reduce the total number of installable/usable packages in the main repository through breakage. And we had to fill the repository with more and more packages without being confronted with breakage too often. But what has happened later? At least "testing" became quite crowded and made it more difficult to concentrate on the packages we wanted to see in use by our users. To decide whether test packages were good enough, developers and users needed to run "stable" and "testing", getting the entire mix of packages. And that is ugly. At the current pace updates are pushed out at Fedora Extras, extras-testing would be filled with packages constantly. From fedora at leemhuis.info Sun May 14 18:38:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 20:38:17 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <20060514200915.8d63f6ab.bugs.michael@gmx.net> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> <1147620060.18635.71.camel@localhost.localdomain> <20060514200915.8d63f6ab.bugs.michael@gmx.net> Message-ID: <1147631898.18635.96.camel@localhost.localdomain> Am Sonntag, den 14.05.2006, 20:09 +0200 schrieb Michael Schwendt: > On Sun, 14 May 2006 17:21:00 +0200, Thorsten Leemhuis wrote: > > > But we simply could use the current scheme > > until then: packages foo1 and foo2 are build and a particular point in > > time and pushed to the testing repo together and another point of time. > > bar1 and bar2 get build some days later and also pushed to testing > > together. Five days after foo1 and foo2 were pushed both pacakgers are > > moved from testing to the proper repo. bar1 and bar2 would follow > > together five days after their push. > > foo1 and foo2 break dependencies in extras-testing. :) You mean as a example? Okay. > Let's assume extras-testing is covered by a repoclosure report. It of course should. > Still, > only after 2-3 days a real user gets nervous and reports the breakage. A > day later another packager, who receives the reports, rebuilds his > packages bar1 and bar2 to fix the broken deps and pushes the builds into > extras-testing. So, how do you forward the entire set into extras finally? Well, that a case where manual interaction might be required for now. But it's still better then now where the breakage would immediately would have hit the proper repo. > If it's done automatically, foo1 and foo2 are pushed several days before > bar1 and bar2. (yes, it needs somebody to push all four packages at once, > something that has failed several times before for Core, btw) > (Or Possibly you want to resolve all deps automatically, but > in that case it might happen that foo1 is 7 days old, while baz2 has > just been built, and then you might wait to give the set some longer > testing) Still a lot better than the current situation. > Conclusively, what we need to shield our users from broken updates You seem to always center around broken updates with deps -- I mainly think about new version from upstream or newly introduced bugs in out packages that are buggy in general or on Fedora. > is more > careful packagers, more communication and coordination of upgrades which > affect dependencies, and convenient access to a scratch target in the > buildsys, so not every packager must set up mock and local mirrors of > multiple distribution releases. And of course guidelines and hints on how > to avoid common upgrade mistakes (like SONAME changes). Sure. > > > So, Extras packagers must watch another moving target? > > What do they have to watch precisely? I only seem problems when some > > packages are pushed directly to the repo. That should only happen for > > security issues -- we IMHo should be able to handle that. > > As soon as any package, which has dependencies in Extras (whether at > build-time or run-time, doesn't matter), is pushed into extras-testing, > the affected Extras packagers must do their own preparations and testing > against the new stuff in _extras-testing_. And unfortunately, they have > the choice between two build targets now, "extras" and "extras-testing", > which gets particularly funny when security fixes join the show. No. Fifo into testing for *all packages* except security fixes. No build target "extras". I never proposed that. And that's the point where we missunderstood each other afaics. > I smell chaos and extra burden. Yeah, that would be correct if we would have a build target "extras" -- but that's not what I propose. It might make a bit chaos when security updates get to the extras repo directly. But that's IMHO a acceptable and not that big problem. > Think fedora.us unstable/testing/stable. [...] Yeah, that really wasn't that ideal. CU thl -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Sun May 14 18:37:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 14 May 2006 20:37:15 +0200 (CEST) Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <1147583632.6910.58.camel@atlantis.mpeters.local> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <20060513222508.GG1606@neu.nirvana> <1147583632.6910.58.camel@atlantis.mpeters.local> Message-ID: <59853.81.64.156.253.1147631835.squirrel@rousalka.dyndns.org> Le Dim 14 mai 2006 07:13, Michael A. Peters a ?crit : > On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote: > >> >> Maybe it's time to think about packaging so into their separate >> libfoo subpackages like Debian/Mandrake/ATrpms are doing? This >> always ensures forward and backward compatibility at the cost of dead >> libfoo packages lying around. > > I semi agree. And I semi disagree. libfoomajor is a great way to hide the problem under the carpet and removes any incentive to app authors to resync on a common lib version. All the FC packages that went through a libfoomajor period where a hell to administrate and never seemed to disappear (ie other packagers felt since they were there they didn't have to fix their packages) In this particular case my personal opinion (of no particular worth) is : 1. the change should have been announced loudly beforehand 2. the breakage should have been initialy limited to FE devel, and only propagated to other versions after some sort of grace period 3. WTF is such a change doing in fc3 ? 4. the way yum balks at the first repo problem is not always helpful OTOH it may result in improved FE policies, so all is not black Regards, -- Nicolas Mailhot From fedora at leemhuis.info Sun May 14 18:44:56 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 20:44:56 +0200 Subject: Kernel modules in Fedora Extras Message-ID: <1147632296.18635.102.camel@localhost.localdomain> Hi All! Just FYI, I took the old kernel-module proposal and reworked the document a bit and put it in the proper place at: http://www.fedoraproject.org/wiki/Packaging/KernelModules Might sill be a bit rough and the standard and the page still needs some finetuning. But it's probably a lot better than before. HTH CU thl -- Thorsten Leemhuis From sean.bruno at dsl-only.net Sun May 14 18:51:04 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 14 May 2006 11:51:04 -0700 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147632296.18635.102.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> Message-ID: <1147632664.3033.6.camel@home-desk> On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > Hi All! > > Just FYI, I took the old kernel-module proposal and reworked the > document a bit and put it in the proper place at: > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > Might sill be a bit rough and the standard and the page still needs some > finetuning. But it's probably a lot better than before. > > HTH > > CU > thl > -- > Thorsten Leemhuis > You must have been reading my mind. I was getting ready to start a kmod rpm for two usb webcam modules(spca5xx and uvc video). I'll start a spec and source package based on this page and give you some feedback on it's practicality this week. Sean Bruno From mpeters at mac.com Sun May 14 19:01:58 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 14 May 2006 12:01:58 -0700 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147599946.2924.25.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> Message-ID: <1147633319.6910.76.camel@atlantis.mpeters.local> On Sun, 2006-05-14 at 11:45 +0200, Thorsten Leemhuis wrote: > > Just my 2 cent. Other opinions? Sure - along the lines of what Axel suggested. If you are going to upgrade a shared library in Extras, you have to provide a compatibility shared library for the older version - which can be removed from the repository after a period of time when no packages are using it any longer. devel package for the compatibility library need not be provided. If not the above, then at least a wiki page where the update must be announced - so that an announcement can go to appropriate list when such an update is planned. From fedora at leemhuis.info Sun May 14 19:12:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 May 2006 21:12:18 +0200 Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <59853.81.64.156.253.1147631835.squirrel@rousalka.dyndns.org> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <20060513222508.GG1606@neu.nirvana> <1147583632.6910.58.camel@atlantis.mpeters.local> <59853.81.64.156.253.1147631835.squirrel@rousalka.dyndns.org> Message-ID: <1147633939.18635.124.camel@localhost.localdomain> Am Sonntag, den 14.05.2006, 20:37 +0200 schrieb Nicolas Mailhot: > Le Dim 14 mai 2006 07:13, Michael A. Peters a ?crit : > > On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote: > >> Maybe it's time to think about packaging so into their separate > >> libfoo subpackages like Debian/Mandrake/ATrpms are doing? This > >> always ensures forward and backward compatibility at the cost of dead > >> libfoo packages lying around. > > I semi agree. > And I semi disagree. How about a policy like this: --- Package updates in Fedora Extras to new upstream version are allowed for stable Core versions as long as the soname of the provided libs doesn't change. Updates with soname changes are okay if the packager takes care of one of the following steps: a) you create and provide a compat-package with the old lib in it. The compat-package of course needs to be parallel-installable with the new version. b) A slightly painful procedure: - you prepare a update locally - you test if all other Extras packages that were build against the new version still build - you announce the planed update to the lists and give 3rd party repos some time (one week) to prepare; in parallel: - you ask all the maintainers of the packages depending on yours if it's okay if either -- you bump the release of their packages and request a rebuild -- or if they want to do it on their own at the right moment (that's crucial) - when all the other maintainers agreed so the update probably is going to be smooth you announce a specific date when you plan to rebuild you package and those depending on it. This announcement needs to have a list with all the packages that need a rebuild (to make sure that the extras signers don't push the packages from needsign to the proper repo while everything rebuilds) - you run a repoclosure after all the builds were done to make sure everything has worked properly --- Options? Did I miss anything? > In this particular case my personal opinion (of no particular worth) is : > 1. the change should have been announced loudly beforehand +1 > 2. the breakage should have been initialy limited to FE devel, +1 > and only > propagated to other versions after some sort of grace period See "b)" above -- does that cover everything? > 3. WTF is such a change doing in fc3 ? Exactly. [...] CU thl -- Thorsten Leemhuis From ndbecker2 at gmail.com Sun May 14 19:12:20 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 14 May 2006 15:12:20 -0400 Subject: twinkle? Message-ID: Anyone working on packaging twinkle? It built fine here, and looks pretty cool From bugs.michael at gmx.net Sun May 14 19:13:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 14 May 2006 21:13:44 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <1147631898.18635.96.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> <1147620060.18635.71.camel@localhost.localdomain> <20060514200915.8d63f6ab.bugs.michael@gmx.net> <1147631898.18635.96.camel@localhost.localdomain> Message-ID: <20060514211344.e6f51451.bugs.michael@gmx.net> On Sun, 14 May 2006 20:38:17 +0200, Thorsten Leemhuis wrote: > You seem to always center around broken updates with deps -- I mainly > think about new version from upstream or newly introduced bugs in out > packages that are buggy in general or on Fedora. No, no, I refer to all kinds of bugs: build-time, install-time, run-time, whatever. I see that new builds are pushed into extras-testing, and all subsequent builds (including security fixes) are done against the contents of extras-testing, too. What I fail to see is what is done with packages in extras-testing when bugs in a sub-set of extras-testing become known. From ndbecker2 at gmail.com Sun May 14 19:13:03 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 14 May 2006 15:13:03 -0400 Subject: democracy tv? Message-ID: Anyone working on democracy tv? Built fine here, even has Fedora srpm. From Jochen at herr-schmitt.de Sun May 14 19:28:10 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 14 May 2006 21:28:10 +0200 Subject: Trouble with incomplete Binary RPMs Message-ID: <0ML2xA-1FfMGC1Zj1-0000Ys@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191456 several users complaints, that the FC-4 package of stellarium-0.8.0-2 was malform. To solve this problem, I have reinitiate a rebuild of this package for FC-4. Becouse, that was not the first time where a incomplete RPM was put into the repository, I want to ask for the reason why this may be happen. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBRGeE009gByurcX4MEQLM3wCeNdxhQnxcJ1UGEKWPe/a4JULzc/cAoIVE NNu3USJjl28nUpBprehhicxZ =Jv/Q -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sun May 14 20:01:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 14 May 2006 22:01:36 +0200 Subject: Trouble with incomplete Binary RPMs In-Reply-To: <0ML2xA-1FfMGC1Zj1-0000Ys@mrelayeu.kundenserver.de> References: <0ML2xA-1FfMGC1Zj1-0000Ys@mrelayeu.kundenserver.de> Message-ID: <20060514220136.f4eb379b.bugs.michael@gmx.net> On Sun, 14 May 2006 21:28:10 +0200, Jochen Schmitt wrote: > On https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191456 > several users complaints, that the FC-4 package of > stellarium-0.8.0-2 was malform. > > To solve this problem, I have reinitiate a rebuild of this > package for FC-4. > > Becouse, that was not the first time where a incomplete RPM was > put into the repository, I want to ask for the reason why this > may be happen. I don't know when this happened for the first time. But since the rpm is truncated and from May 8th, it looks a bit as if it is a victim of an interrupted push of packages, which should not have been interrupted. From j.w.r.degoede at hhs.nl Sun May 14 20:41:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 14 May 2006 22:41:30 +0200 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <20060514161919.3ab454cf.bugs.michael@gmx.net> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> Message-ID: <446795FA.6050509@hhs.nl> Michael Schwendt wrote: Seeing the long list of mostly valid problems Michael brings up and combining this with my own gut feeling Which i had about this even before reading Michaels objections I say don't do it. Lets not add all these extra layers of complexity to the current well working FE "system" Yes sometimes someone screws up. We need to learn from these occasions and try to avoid them in the future. But adding a whole additional repo, which to make things even more complicated isn't really a whole new additional repo only make things complicated with little gain. Instead we need to educate packagers both when it comes to knowledge about the problems they may come as it comes to attitude. Above all we need more trust in our packagers! If we try to fix problems like this by adding layers of control and management and procedures instead of solving the problem at its roots: the packager*, then we will end up like the Dutch Public sector (healthcare, education) where 50% of all employees are overhead and even worse these overhead people create so much paperwork that the other 50% who tries to gets the job done looses at least 30% of its time filling in their paperwork. Regards, Hans * which is a human and will make mistakes, but no system is 100% failsafe From tcallawa at redhat.com Sun May 14 20:48:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 14 May 2006 15:48:24 -0500 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <20060512182751.c4a86e30.bugs.michael@gmx.net> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> <20060512182751.c4a86e30.bugs.michael@gmx.net> Message-ID: <1147639704.10616.90.camel@localhost.localdomain> On Fri, 2006-05-12 at 18:27 +0200, Michael Schwendt wrote: > On Fri, 12 May 2006 08:59:29 -0500, Tom 'spot' Callaway wrote: > > > On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > > > > > Even if it is for development, is it worth forcing it off into a > > > > -devel package for just one file? > > > > If the .pc file is the ONLY file that would qualify for -devel (aka, no > > headers, no static libs, nothing to develop a program against), then > > there is no reason to force a -devel subpackage just for it. > > There is one good reason: The .pc file contains dependencies on other .pc > files, which are located in -devel packages. In this case, you would need > a dependency ("Requires") from your non-devel package to -devel packages. > Without that dependency, your package would break the pkgconfig dependency > chain and several pkgconfig query commands. > > To keep development files in -devel packages is the only clean solution. Somehow, this discussion spilled off the list, and I didn't notice that I wasn't replying here too. As Michael Schwendt pointed out above, pkgconfig files depend on other pkgconfig files (and in all released versions of FC, this is not automatically detected by RPM). This is a very good reason not to let .pc go into non -devel packages. If we permit .pc files in non-devel packages, then we'll have non-devel packages that depend on -devel packages, inflating the install needlessly. I'd rather have one .pc file in a -devel package than trigger a chain of -devel packages to be installed when the user just wants to run a mono app. So, to be clear, I am not planning on changing the guidelines to deal with this issue. All .pc files need to go in -devel packages, even if it is the only -devel worthy file (which is the exception rather than the norm). ~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 bdpepple at ameritech.net Sun May 14 20:52:29 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 14 May 2006 16:52:29 -0400 Subject: mono / ".pc files in -devel packges" guideline In-Reply-To: <1147639704.10616.90.camel@localhost.localdomain> References: <7dd7ab490605110916v29107641hee3f362d4b74d269@mail.gmail.com> <7dd7ab490605111130q4b034d0fgadf7642ab9f28460@mail.gmail.com> <1147374513.14342.8.camel@shuttle.piedmont.com> <1147442369.6598.69.camel@localhost.localdomain> <20060512182751.c4a86e30.bugs.michael@gmx.net> <1147639704.10616.90.camel@localhost.localdomain> Message-ID: <1147639949.13466.1.camel@shuttle.piedmont.com> On Sun, 2006-05-14 at 15:48 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-05-12 at 18:27 +0200, Michael Schwendt wrote: > > On Fri, 12 May 2006 08:59:29 -0500, Tom 'spot' Callaway wrote: > > > > > On Thu, 2006-05-11 at 15:08 -0400, Brian Pepple wrote: > > > > > > > > Even if it is for development, is it worth forcing it off into a > > > > > -devel package for just one file? > > > > > > If the .pc file is the ONLY file that would qualify for -devel (aka, no > > > headers, no static libs, nothing to develop a program against), then > > > there is no reason to force a -devel subpackage just for it. > > > > There is one good reason: The .pc file contains dependencies on other .pc > > files, which are located in -devel packages. In this case, you would need > > a dependency ("Requires") from your non-devel package to -devel packages. > > Without that dependency, your package would break the pkgconfig dependency > > chain and several pkgconfig query commands. > > > > To keep development files in -devel packages is the only clean solution. > > Somehow, this discussion spilled off the list, and I didn't notice that > I wasn't replying here too. > > As Michael Schwendt pointed out above, pkgconfig files depend on other > pkgconfig files (and in all released versions of FC, this is not > automatically detected by RPM). This is a very good reason not to > let .pc go into non -devel packages. If we permit .pc files in non-devel > packages, then we'll have non-devel packages that depend on -devel > packages, inflating the install needlessly. > > I'd rather have one .pc file in a -devel package than trigger a chain of > -devel packages to be installed when the user just wants to run a mono > app. > > So, to be clear, I am not planning on changing the guidelines to deal > with this issue. All .pc files need to go in -devel packages, even if it > is the only -devel worthy file (which is the exception rather than the > norm). > I'll modify the Mono Packaging page also. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Sun May 14 20:53:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 14 May 2006 15:53:06 -0500 Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <1147633939.18635.124.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <20060513222508.GG1606@neu.nirvana> <1147583632.6910.58.camel@atlantis.mpeters.local> <59853.81.64.156.253.1147631835.squirrel@rousalka.dyndns.org> <1147633939.18635.124.camel@localhost.localdomain> Message-ID: <1147639986.10616.94.camel@localhost.localdomain> On Sun, 2006-05-14 at 21:12 +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 14.05.2006, 20:37 +0200 schrieb Nicolas Mailhot: > > Le Dim 14 mai 2006 07:13, Michael A. Peters a ?crit : > > > On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote: > > >> Maybe it's time to think about packaging so into their separate > > >> libfoo subpackages like Debian/Mandrake/ATrpms are doing? This > > >> always ensures forward and backward compatibility at the cost of dead > > >> libfoo packages lying around. > > > I semi agree. > > And I semi disagree. > > How about a policy like this: > > --- > Package updates in Fedora Extras to new upstream version are allowed for > stable Core versions as long as the soname of the provided libs doesn't > change. > > Updates with soname changes are okay if the packager takes care of one > of the following steps: > > a) you create and provide a compat-package with the old lib in it. The > compat-package of course needs to be parallel-installable with the new > version. Also, the new "compat" package needs to be reviewed as if it were a new package. We've already set precedent for this with wxGTK. Otherwise, I'm in total agreement here. ~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 tcallawa at redhat.com Sun May 14 20:55:35 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 14 May 2006 15:55:35 -0500 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <446795FA.6050509@hhs.nl> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> <446795FA.6050509@hhs.nl> Message-ID: <1147640136.10616.97.camel@localhost.localdomain> On Sun, 2006-05-14 at 22:41 +0200, Hans de Goede wrote: > Michael Schwendt wrote: > > > > Seeing the long list of mostly valid problems Michael brings up and > combining this with my own gut feeling Which i had about this even > before reading Michaels objections I say don't do it. Lets not add all > these extra layers of complexity to the current well working FE "system" +1. I don't feel that any of the supposed benefits of a required testing layer outweigh the pain it will cause. In addition, from my observations (and discussions with others), the testing repo is/was almost never used and even less "tested" by the userbase, in the places where it exists/existed. ~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 tcallawa at redhat.com Sun May 14 21:03:03 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 14 May 2006 16:03:03 -0500 Subject: Packages guidelines: documentation subpackages name In-Reply-To: References: <200605141712.28690@rineau.schtroumpfette> <1147620803.2746.158.camel@localhost.localdomain> Message-ID: <1147640583.10616.104.camel@localhost.localdomain> On Sun, 2006-05-14 at 09:27 -0700, Christopher Stone wrote: > > According to the Package Review guidelines it should be "docs". > > > > - MUST: Large documentation files should go in a -docs subpackage. Yeah, this is a typo. It should be -doc. My bad, sorry for not catching that one sooner. ~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 rtlm10 at gmail.com Sun May 14 21:56:43 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Sun, 14 May 2006 17:56:43 -0400 Subject: mock builds broken on FC5 machines In-Reply-To: References: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> Message-ID: <1ed4a0130605141456h592cfbc9k19c9463c25ef4a5f@mail.gmail.com> I thought that strange as well and edited all of mine to point to the actuall fc5 locations. Especially with the development trees getting hosed daily this early in the cycle. On 5/14/06, Gianluca Sforna wrote: > > On 5/13/06, Russell Harrison wrote: > > To fix mock builds on a machine with yum 2.6+ find the line > > "config_opts['buildgroup'] = 'build'" in each of your /etc/mock/*.cfg > files > > and change it to "config_opts['buildgroup'] = 'build build-minimal > > build-base'". Those are all of the groups (that I know about) currently > > required by the group build. Everything should be happy again! > > Thanks for the info... I was just wondering what was wrong with my mock... > > on a side note, is that normal that /etc/mock/fedora-5-i386-core.cfg > is set to install from the development repo? i.e: > > [core] > name=core > baseurl= > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > > [groups] > name=groups > baseurl=http://fedoraproject.org/buildgroups/development/i386/ > > [extras] > name=extras > baseurl=http://fedoraproject.org/extras/development/i386 > > [local] > name=local > baseurl=http://extras64.linux.duke.edu/plague-results/development/ > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Mon May 15 01:22:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 15 May 2006 03:22:17 +0200 Subject: libfoo (was: Incoming: directfb soname problems) In-Reply-To: <1147639986.10616.94.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <20060513222508.GG1606@neu.nirvana> <1147583632.6910.58.camel@atlantis.mpeters.local> <59853.81.64.156.253.1147631835.squirrel@rousalka.dyndns.org> <1147633939.18635.124.camel@localhost.localdomain> <1147639986.10616.94.camel@localhost.localdomain> Message-ID: <20060515012217.GA27235@neu.nirvana> On Sun, May 14, 2006 at 03:53:06PM -0500, Tom 'spot' Callaway wrote: > On Sun, 2006-05-14 at 21:12 +0200, Thorsten Leemhuis wrote: > > Am Sonntag, den 14.05.2006, 20:37 +0200 schrieb Nicolas Mailhot: > > > Le Dim 14 mai 2006 07:13, Michael A. Peters a ?crit : > > > > On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote: > > > >> Maybe it's time to think about packaging so into their separate > > > >> libfoo subpackages like Debian/Mandrake/ATrpms are doing? This > > > >> always ensures forward and backward compatibility at the cost of dead > > > >> libfoo packages lying around. > > > > I semi agree. > > > And I semi disagree. > > > > How about a policy like this: > > > > --- > > Package updates in Fedora Extras to new upstream version are allowed for > > stable Core versions as long as the soname of the provided libs doesn't > > change. Almost always the packager won't even notice, 99.9% of the specfiles have *.so.* in %files. > > Updates with soname changes are okay if the packager takes care of one > > of the following steps: Sometimes one might not even know what other packages depend on the lib's major. E.g. a packager would need to check all relevant repos for all relevant distros to see whether another package depends on his previous so version. > > a) you create and provide a compat-package with the old lib in it. The > > compat-package of course needs to be parallel-installable with the new > > version. > > Also, the new "compat" package needs to be reviewed as if it were a new > package. We've already set precedent for this with wxGTK. In the case of libfoo idioms you don't need the review: The "compat" package was in productive use all along. The larger Fedora package space becomes the more often one will be confronted with this kind of obstructions. Either a major bump will require a chain of rebuilds, or even worse some packages will really depend on the previous major version of the lib (after all the major bump should really indicate an API change). In the case of ATrpms the libfoo idiom even makes it possible to stay compatible with other repos (in fact that was the original motivation), as different repos build on different so versions or upgrade to new versions at different pace. Similar for Debian and Mandriva where the package space is too large to coordinate within one time unit. > Otherwise, I'm in total agreement here. > > ~spot -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Mon May 15 07:06:55 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 15 May 2006 09:06:55 +0200 Subject: mock builds broken on FC5 machines In-Reply-To: <1ed4a0130605141456h592cfbc9k19c9463c25ef4a5f@mail.gmail.com> References: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> <1ed4a0130605141456h592cfbc9k19c9463c25ef4a5f@mail.gmail.com> Message-ID: On 5/14/06, Russell Harrison wrote: > I thought that strange as well and edited all of mine to point to the > actuall fc5 locations. Especially with the development trees getting hosed > daily this early in the cycle. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186478 I should have checked earlier... From mpeters at mac.com Mon May 15 07:08:55 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 15 May 2006 00:08:55 -0700 Subject: GNOME packages that need review? Message-ID: <1147676936.26878.9.camel@atlantis.mpeters.local> I'm looking for some gnome packages that need review. I'd rather they not be mono packages, I want to watch some of them be reviewed first (feel free to put me on the cc list if you are submitting a mono package). I'm looking through the FE-NEW bugs trying to find some GNOME packages that need review, but it isn't always so easy to find. Note that I am not a sponsor, so I can't approve packages that need a sponsor - but I can comment on them. So - what gnome specific packages need some reviewer time? Maybe a page for gnome packages needing review should go in the gnome SIG. Should I just add a place for gnome packages that need review to http://fedoraproject.org/wiki/Extras/SIGs/GNOME (similar to games being packaged on the games SIG page)? From triad at df.lth.se Mon May 15 07:18:26 2006 From: triad at df.lth.se (Linus Walleij) Date: Mon, 15 May 2006 09:18:26 +0200 (CEST) Subject: Maelstrom license clause In-Reply-To: <20060514174357.GA22432@neu.nirvana> References: <44651A9F.80605@kobold.org> <20060513012143.GB28903@neu.nirvana> <20060514174357.GA22432@neu.nirvana> Message-ID: On Sun, 14 May 2006, Axel Thimm wrote: > Anyway, the best thing is if the original poster or any other > interested party brings this to the vendor's attention and asks for a > correction of the license text or otherwise clarifies the situation. I agree. Linus From paul at city-fan.org Mon May 15 08:02:58 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 09:02:58 +0100 Subject: License query In-Reply-To: <4464E7DB.3010203@hhs.nl> References: <44648AEE.40702@city-fan.org> <1147440032.3308.23.camel@gibraltar.stuttgart.redhat.com> <1147442487.6598.72.camel@localhost.localdomain> <4464E7DB.3010203@hhs.nl> Message-ID: <1147680179.3031.64.camel@laurel.intra.city-fan.org> On Fri, 2006-05-12 at 21:54 +0200, Hans de Goede wrote: > > Tom 'spot' Callaway wrote: > > On Fri, 2006-05-12 at 15:20 +0200, Nils Philippsen wrote: > > > >>> It looks quite free apart from the "as long as ... you do not ... try to > >>> sell it" clause, which I think disqualifies it as free software despite > >>> what the first sentence of the license terms states. Is this OK for > >>> Extras or not? > >> I don't think so. > > > > That counts as a use-restriction license. I say no. > > > > (See if you can get the author to remove the "as long as you do not try > > to sell it" clause) > > > > Exactly many authors unfortunatly come up with their own license, as a > games SIG member I've got plenty of experience with those. Usually if > the license already is 99.9% free a polite mail (exchange) is all it > will take to get a 100% free license. OTOH if the license is restrictive > (which this one isn't) your chances of changing the author's mind are > less good. Let's see what happens. http://rt.cpan.org/Public/Bug/Display.html?id=19256 Paul. From j.w.r.degoede at hhs.nl Mon May 15 08:43:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 15 May 2006 10:43:35 +0200 Subject: Some ftp space for SRPM for review wanted Message-ID: <44683F37.8050509@hhs.nl> Hi, I'm getting really tired of my ISP's 3Mb file size limit :( This makes me and my reviewers having to jump to all kinda hoops (no srpm, just a spec and a xxx-files.tgz with patches, .desktop etc. Then the reviewer has to download the main sources from upstream himself and assemble all the pieces). So can anyone help me with an account on a server somewhere? I can understand if you dislike ftp scp will do fine too. You can send me a gpg-coded mail wiht login credentials my public key is available from mit. I've some big packages which I plan on packaging soonish, so I will need a bit of diskspace (say upto 250 Mb) trafic will be low, as it will be used for posting SRPM's for review only. For me about me see: http://fedoraproject.org/wiki/HansdeGoede Thanks & Regards, Hans From tjikkun at xs4all.nl Mon May 15 09:05:06 2006 From: tjikkun at xs4all.nl (Sander Hoentjen) Date: Mon, 15 May 2006 11:05:06 +0200 Subject: Some ftp space for SRPM for review wanted In-Reply-To: <44683F37.8050509@hhs.nl> References: <44683F37.8050509@hhs.nl> Message-ID: <1147683907.3119.2.camel@tjikkun.hoentjen.eu> Hans, ik reply even off-list omdat ik wel een eigen ftp server draai, maar die zit achter mijn normale adsl lijn (+/- 40 kB/s up) verder heb ik op dit moment een hardware probleem en ga ik deze dus vervangen op korte termijn. Tot het moment van vervangen heb ik nogal eens problemen met uptime (random freezes). Als je niks anders kunt vinden is het misschien een optie, en als ik over een maand ongeveer genoeg geld heb om de hardware te vervangen dan ben ik in principe 24/7 online. Als je wel wat anders kan vinden dan is dat waarschijnlijk de betere oplossing, M.v.g. Sander On Mon, 2006-05-15 at 10:43 +0200, Hans de Goede wrote: > Hi, > > I'm getting really tired of my ISP's 3Mb file size limit :( This makes > me and my reviewers having to jump to all kinda hoops (no srpm, just a > spec and a xxx-files.tgz with patches, .desktop etc. Then the reviewer > has to download the main sources from upstream himself and assemble all > the pieces). > > So can anyone help me with an account on a server somewhere? I can > understand if you dislike ftp scp will do fine too. You can send me a > gpg-coded mail wiht login credentials my public key is available from mit. > > I've some big packages which I plan on packaging soonish, so I will need > a bit of diskspace (say upto 250 Mb) trafic will be low, as it will be > used for posting SRPM's for review only. > > For me about me see: > http://fedoraproject.org/wiki/HansdeGoede > > Thanks & Regards, > > Hans > From tjikkun at xs4all.nl Mon May 15 09:07:10 2006 From: tjikkun at xs4all.nl (Sander Hoentjen) Date: Mon, 15 May 2006 11:07:10 +0200 Subject: Some ftp space for SRPM for review wanted In-Reply-To: <1147683907.3119.2.camel@tjikkun.hoentjen.eu> References: <44683F37.8050509@hhs.nl> <1147683907.3119.2.camel@tjikkun.hoentjen.eu> Message-ID: <1147684030.3119.4.camel@tjikkun.hoentjen.eu> Humm ok, that was SUPPOSED to be off list :) On Mon, 2006-05-15 at 11:05 +0200, Sander Hoentjen wrote: > Hans, > > ik reply even off-list omdat ik wel een eigen ftp server draai, maar die > zit achter mijn normale adsl lijn (+/- 40 kB/s up) verder heb ik op dit > moment een hardware probleem en ga ik deze dus vervangen op korte > termijn. Tot het moment van vervangen heb ik nogal eens problemen met > uptime (random freezes). Als je niks anders kunt vinden is het misschien > een optie, en als ik over een maand ongeveer genoeg geld heb om de > hardware te vervangen dan ben ik in principe 24/7 online. > Als je wel wat anders kan vinden dan is dat waarschijnlijk de betere > oplossing, > > M.v.g. > Sander > > On Mon, 2006-05-15 at 10:43 +0200, Hans de Goede wrote: > > Hi, > > > > I'm getting really tired of my ISP's 3Mb file size limit :( This makes > > me and my reviewers having to jump to all kinda hoops (no srpm, just a > > spec and a xxx-files.tgz with patches, .desktop etc. Then the reviewer > > has to download the main sources from upstream himself and assemble all > > the pieces). > > > > So can anyone help me with an account on a server somewhere? I can > > understand if you dislike ftp scp will do fine too. You can send me a > > gpg-coded mail wiht login credentials my public key is available from mit. > > > > I've some big packages which I plan on packaging soonish, so I will need > > a bit of diskspace (say upto 250 Mb) trafic will be low, as it will be > > used for posting SRPM's for review only. > > > > For me about me see: > > http://fedoraproject.org/wiki/HansdeGoede > > > > Thanks & Regards, > > > > Hans > > > From laurent.rineau__fc_extra at normalesup.org Mon May 15 09:13:58 2006 From: laurent.rineau__fc_extra at normalesup.org (Laurent Rineau) Date: Mon, 15 May 2006 11:13:58 +0200 Subject: Some ftp space for SRPM for review wanted In-Reply-To: <1147684030.3119.4.camel@tjikkun.hoentjen.eu> References: <44683F37.8050509@hhs.nl> <1147683907.3119.2.camel@tjikkun.hoentjen.eu> <1147684030.3119.4.camel@tjikkun.hoentjen.eu> Message-ID: <200605151113.58817@rineau.schtroumpfette> On Monday 15 May 2006 11:07, Sander Hoentjen wrote: > Humm ok, that was SUPPOSED to be off list :) Actually, it seems it was cyphered. Do not worry! ;-) From mpeters at mac.com Mon May 15 09:55:32 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 15 May 2006 02:55:32 -0700 Subject: Some ftp space for SRPM for review wanted In-Reply-To: <200605151113.58817@rineau.schtroumpfette> References: <44683F37.8050509@hhs.nl> <1147683907.3119.2.camel@tjikkun.hoentjen.eu> <1147684030.3119.4.camel@tjikkun.hoentjen.eu> <200605151113.58817@rineau.schtroumpfette> Message-ID: <1147686933.26878.11.camel@atlantis.mpeters.local> On Mon, 2006-05-15 at 11:13 +0200, Laurent Rineau wrote: > On Monday 15 May 2006 11:07, Sander Hoentjen wrote: > > Humm ok, that was SUPPOSED to be off list :) > > Actually, it seems it was cyphered. Do not worry! ;-) > Naw - it was greek (to me) ;) From fedora at leemhuis.info Mon May 15 14:27:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 May 2006 16:27:22 +0200 Subject: Remove orphans in devel (Was: Re: atitvout + gai-pal : Orphaned dependencies!) In-Reply-To: <20060515124435.35771846.bugs.michael@gmx.net> References: <20060515124435.35771846.bugs.michael@gmx.net> Message-ID: <1147703242.2611.3.camel@localhost.localdomain> moving this to Fedora Extras list -- this seems like the better place for such discussions to me Am Montag, den 15.05.2006, 12:44 +0200 schrieb Michael Schwendt: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > The packages > > lrmi > xosd > > are on the list of orphaned packages. [...] Well, why don't we remove them from devel if the situation doesn't change in the next 5 days? Wasn't that the plan that was proposed shortly before FC5 was final when we tried to clean up everything a bit? CU thl -- Thorsten Leemhuis From paul at city-fan.org Mon May 15 14:28:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 15:28:06 +0100 Subject: mock builds broken on FC5 machines In-Reply-To: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> References: <1ed4a0130605131229n50e79ef9xe73c833966eca129@mail.gmail.com> Message-ID: <44688FF6.1060702@city-fan.org> Russell Harrison wrote: > Some of you may already be aware that doing a mock build on a FC5 machine > doesn't pull in all of the packages you need to properly setup your build > env. yum removed support for groupreq tags in the group definitions for > version 2.6+ which prevents "yum groupinstall build" from pulling in its > required groups. > > To fix mock builds on a machine with yum 2.6+ find the line > "config_opts['buildgroup'] = 'build'" in each of your /etc/mock/*.cfg files > and change it to "config_opts['buildgroup'] = 'build build-minimal > build-base'". Those are all of the groups (that I know about) currently > required by the group build. Everything should be happy again! I've documented this and some other mock issues here: http://fedoraproject.org/wiki/Extras/MockTricks Paul. From dcbw at redhat.com Mon May 15 14:45:24 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 May 2006 10:45:24 -0400 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147632296.18635.102.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> Message-ID: <1147704324.2193.53.camel@localhost.localdomain> On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > Hi All! > > Just FYI, I took the old kernel-module proposal and reworked the > document a bit and put it in the proper place at: > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > Might sill be a bit rough and the standard and the page still needs some > finetuning. But it's probably a lot better than before. Is there anything needed from the buildsystem for this? AFAIK you can already to i686, i586, ppc, and x86_64 kernel modules. ppc64iseries and ppc64 support isn't there yet though... Dan From bugs.michael at gmx.net Mon May 15 15:19:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 15 May 2006 17:19:03 +0200 Subject: Remove orphans in devel (Was: Re: atitvout + gai-pal : Orphaned dependencies!) In-Reply-To: <1147703242.2611.3.camel@localhost.localdomain> References: <20060515124435.35771846.bugs.michael@gmx.net> <1147703242.2611.3.camel@localhost.localdomain> Message-ID: <20060515171903.51700e88.bugs.michael@gmx.net> On Mon, 15 May 2006 16:27:22 +0200, Thorsten Leemhuis wrote: > moving this to Fedora Extras list -- this seems like the better place > for such discussions to me My message was a notification (also see its Cc line), not the start of a discussion. > Am Montag, den 15.05.2006, 12:44 +0200 schrieb Michael Schwendt: > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > > > The packages > > > > lrmi > > xosd > > > > are on the list of orphaned packages. [...] > > Well, why don't we remove them from devel if the situation doesn't > change in the next 5 days? That would be unnecessarily rude if done deliberately. These two orphans are requirements of maintained packages. So, now that it is known that they are orphaned, there is the opportunity to pick them up. > Wasn't that the plan that was proposed > shortly before FC5 was final when we tried to clean up everything a bit? See CVS commit traffic. Some more packages have been orphaned and have gone unnoticed. Even more packages have been orphaned in April. From buildsys at fedoraproject.org Mon May 15 15:25:52 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 15 May 2006 15:25:52 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-15 Message-ID: <20060515152552.4018.57603@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: redhat AT flyn.org package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 ====================================================================== New report for: wtogami AT redhat.com package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) ====================================================================== package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 From fedora at leemhuis.info Mon May 15 15:59:31 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 May 2006 17:59:31 +0200 Subject: Remove orphans in devel (Was: Re: atitvout + gai-pal : Orphaned dependencies!) In-Reply-To: <20060515171903.51700e88.bugs.michael@gmx.net> References: <20060515124435.35771846.bugs.michael@gmx.net> <1147703242.2611.3.camel@localhost.localdomain> <20060515171903.51700e88.bugs.michael@gmx.net> Message-ID: <1147708771.5969.13.camel@localhost.localdomain> Am Montag, den 15.05.2006, 17:19 +0200 schrieb Michael Schwendt: > On Mon, 15 May 2006 16:27:22 +0200, Thorsten Leemhuis wrote: > > > moving this to Fedora Extras list -- this seems like the better place > > for such discussions to me > My message was a notification (also see its Cc line), not the start of a > discussion. Exactly -- my message was meant as start of a discussion and that's why I move it to this list, that seemed like the better place. > > Am Montag, den 15.05.2006, 12:44 +0200 schrieb Michael Schwendt: > > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > > > > > The packages > > > > > > lrmi > > > xosd > > > > > > are on the list of orphaned packages. [...] > > > > Well, why don't we remove them from devel if the situation doesn't > > change in the next 5 days? > > That would be unnecessarily rude if done deliberately. These two orphans > are requirements of maintained packages. So, now that it is known that > they are orphaned, there is the opportunity to pick them up. Well, we can extend the timeframe a bit to (for example) two or four weeks. But IMHO removing them after that timeframe is better then removing them shortly before FC6 is launched. > > Wasn't that the plan that was proposed > > shortly before FC5 was final when we tried to clean up everything a bit? > See CVS commit traffic. Some more packages have been orphaned and have > gone unnoticed. Even more packages have been orphaned in April. Well, maintaining two lists manually (e.g. one in the wiki and one in owners.list) seems problematic to me in the longer term. We should try to find a unified solution. And btw, it seems we need a proper "orphan policy". Anyone interested in working one out? -- Thorsten Leemhuis From fedora at leemhuis.info Mon May 15 16:15:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 May 2006 18:15:37 +0200 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147704324.2193.53.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> Message-ID: <1147709737.6151.3.camel@localhost.localdomain> Am Montag, den 15.05.2006, 10:45 -0400 schrieb Dan Williams: > On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > > Hi All! > > > > Just FYI, I took the old kernel-module proposal and reworked the > > document a bit and put it in the proper place at: > > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > > > Might sill be a bit rough and the standard and the page still needs some > > finetuning. But it's probably a lot better than before. > > Is there anything needed from the buildsystem for this? AFAIK you can > already to i686, i586, ppc, and x86_64 kernel modules. Well, in and ideal world plague, mock or something else would pass the - version of the latest kernel to the rpmbuild-call via "--define kversion foo" - all variants (smp, "", xen0, xenU, ...) via "--define kvariants bar baz" when building the package. That would avoid the hardcoding of those vars in the spec file. > ppc64iseries and > ppc64 support isn't there yet though... ppc64 would probably require a special builder afaik where *.ppc64 isn't excluded? I tried that once -- worked fine. CU thl -- Thorsten Leemhuis From dcbw at redhat.com Mon May 15 16:47:53 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 May 2006 12:47:53 -0400 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147709737.6151.3.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> <1147709737.6151.3.camel@localhost.localdomain> Message-ID: <1147711673.32123.1.camel@localhost.localdomain> On Mon, 2006-05-15 at 18:15 +0200, Thorsten Leemhuis wrote: > Am Montag, den 15.05.2006, 10:45 -0400 schrieb Dan Williams: > > On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > > > Hi All! > > > > > > Just FYI, I took the old kernel-module proposal and reworked the > > > document a bit and put it in the proper place at: > > > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > > > > > Might sill be a bit rough and the standard and the page still needs some > > > finetuning. But it's probably a lot better than before. > > > > Is there anything needed from the buildsystem for this? AFAIK you can > > already to i686, i586, ppc, and x86_64 kernel modules. > > Well, in and ideal world plague, mock or something else would pass the > > - version of the latest kernel to the rpmbuild-call via "--define > kversion foo" > - all variants (smp, "", xen0, xenU, ...) via "--define kvariants bar > baz" > > when building the package. That would avoid the hardcoding of those vars > in the spec file. I think we can do that in a sane way, yes. > > ppc64iseries and > > ppc64 support isn't there yet though... > > ppc64 would probably require a special builder afaik where *.ppc64 isn't > excluded? I tried that once -- worked fine. Well, AFAIK Fedora runs 32-bit on ppc64 except for the kernel and possibly glibc (?) just like sparc64, so usually we'd exclude all *.ppc64 from the pull anyway. Dan From paul at city-fan.org Mon May 15 17:03:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 18:03:20 +0100 Subject: FE Package Status of May 12, 2006 In-Reply-To: <200605122105.k4CL5hCU007871@mx1.redhat.com> References: <200605122105.k4CL5hCU007871@mx1.redhat.com> Message-ID: <4468B458.90603@city-fan.org> Christian.Iseli at licr.org wrote: > Hi folks, > > The page has been updated. Thorsten asked if we could highlight a bit those > folks who perform many reviews but are not yet sponsors, so I have added some > coloring to the page. > > Actually, I kinda like colors :) Maybe other things could be colorized too... > > Another thing I was wondering: do you prefer people's names, or do you prefer > the pseudo-email addresses in the various listings ? > > Visually, I tend to prefer just the name, but then it makes things a bit > harder when trying to send an email to poke someone on an issue... > But then again, I hope to automate the nagging emails at some point... so I'm > kinda hesitating what to do. > > Cheers, > Christian > > ---- > > FE Package Status of May 12, 2006 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus The full report includes: > Packages appearing in Core but still present in CVS devel > > We have 5 packages in CVS devel which appear to have moved to Core: > > unifdef > check > libevent > glib > gtk+ At least for glib and gtk+, the packages have actually moved from Core to Extras, not the other way around. Paul. From jpo at lsd.di.uminho.pt Mon May 15 17:09:31 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 15 May 2006 18:09:31 +0100 Subject: FE Package Status of May 12, 2006 In-Reply-To: <4468B458.90603@city-fan.org> References: <200605122105.k4CL5hCU007871@mx1.redhat.com> <4468B458.90603@city-fan.org> Message-ID: <4468B5CB.3060903@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Christian.Iseli at licr.org wrote: >> Hi folks, >> >> The page has been updated. Thorsten asked if we could highlight a bit >> those folks who perform many reviews but are not yet sponsors, so I >> have added some coloring to the page. >> >> Actually, I kinda like colors :) Maybe other things could be >> colorized too... >> >> Another thing I was wondering: do you prefer people's names, or do you >> prefer the pseudo-email addresses in the various listings ? >> >> Visually, I tend to prefer just the name, but then it makes things a >> bit harder when trying to send an email to poke someone on an issue... >> But then again, I hope to automate the nagging emails at some point... >> so I'm kinda hesitating what to do. >> >> Cheers, >> Christian >> >> ---- >> >> FE Package Status of May 12, 2006 >> >> The full report can be found here: >> http://fedoraproject.org/wiki/Extras/PackageStatus > > The full report includes: > >> Packages appearing in Core but still present in CVS devel >> >> We have 5 packages in CVS devel which appear to have moved to Core: >> >> unifdef >> check >> libevent >> glib >> gtk+ > > At least for glib and gtk+, the packages have actually moved from Core > to Extras, not the other way around. > unifdef - ------- Appeared first in rawhide then it was submitted to Extras for FC-4 and FC-5 (see ticket #190362). 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEaLXKl0metZG9hRsRAlz6AJ9Z6n8RHuDMI96daKzCMFNfKL5dBQCgtpdC /OqdYzX3i9LLhPaoKR0ZaII= =UeZC -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From Christian.Iseli at licr.org Mon May 15 17:12:42 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 15 May 2006 19:12:42 +0200 Subject: FE Package Status of May 12, 2006 In-Reply-To: Your message of "Mon, 15 May 2006 18:03:20 BST." <4468B458.90603@city-fan.org> Message-ID: <200605151712.k4FHCgcb019468@ludwig-alpha.unil.ch> paul at city-fan.org said: > At least for glib and gtk+, the packages have actually moved from Core to > Extras, not the other way around. That's true, but the script is not smart enough to tell... I guess I should rephrase the message a bit. The message should go away when the packages actually disappear from the core repo. Cheers, Christian From Christian.Iseli at licr.org Mon May 15 17:15:28 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 15 May 2006 19:15:28 +0200 Subject: FE Package Status of May 12, 2006 In-Reply-To: Your message of "Mon, 15 May 2006 18:09:31 BST." <4468B5CB.3060903@lsd.di.uminho.pt> Message-ID: <200605151715.k4FHFSv4019542@ludwig-alpha.unil.ch> jpo at lsd.di.uminho.pt said: > unifdef > ------- > Appeared first in rawhide then it was submitted to Extras for > FC-4 and FC-5 (see ticket #190362). Yes, but I think in this case the files in the CVS devel branch should be removed, lest they land in FE 6 inadvertently... Christian From orion at cora.nwra.com Mon May 15 17:19:03 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 15 May 2006 11:19:03 -0600 Subject: epydoc -> noarch transition problems Message-ID: <4468B807.7060203@cora.nwra.com> Looks like epydoc went from an arch specific to a noarch package: /data/sw1/fedora/extras/5/i386/epydoc-2.1-4.noarch.rpm /data/sw1/fedora/extras/5/i386/epydoc-2.1-2.i386.rpm /data/sw1/fedora/extras/5/ppc/epydoc-2.1-4.noarch.rpm /data/sw1/fedora/extras/5/x86_64/epydoc-2.1-4.noarch.rpm However, it looks like the arch specific packages are still being picked up by yum on FC5 (and maybe others). It gets the noarch on devel. What needs to get cleaned up? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From kevin-fedora-extras at scrye.com Mon May 15 17:20:47 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 15 May 2006 11:20:47 -0600 (MDT) Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE References: <1147123014.2910.248.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> Message-ID: <20060515.112047.166116122.kevin@scrye.com> >>>>> "Jonathan" == Jonathan Underwood writes: Jonathan> On 12/05/06, Thorsten Leemhuis wrote: >> I'm not an emacs users, but from all I can see I'll vote for the >> solution spot suggested (e.g. emacs-common-foo). Jonathan> I much prefer emacsen-foo. As do I, but if everyone else prefers the 'emacs-common' thats ok with me too. :) Jonathan> Why do we need the word "common" in a package name? It makes Jonathan> sense in a subpackage name, but in a package name, it's Jonathan> confusing. I would agree. I guess we just need to have FECSO vote and settle it once and for all. :) Thorsten: Can you add that to the next meeting agenda? After that, both 'mew' and 'emacs-autex' probibly will need to change names to conform to whatever is decided. Jonathan> J Jonathan> -- fedora-extras-list mailing list Jonathan> fedora-extras-list at redhat.com Jonathan> https://www.redhat.com/mailman/listinfo/fedora-extras-list kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin-fedora-extras at scrye.com Mon May 15 17:25:31 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 15 May 2006 11:25:31 -0600 (MDT) Subject: Claiming ownership for thinkpad related packages and pam_mount References: <200605131604.05348.opensource@till.name> Message-ID: <20060515.112531.81086309.kevin@scrye.com> >>>>> "Till" == Till Maas writes: Till> Hiyas, some packages I like to use are orphaned so I tinker with Till> the idea of claiming ownership of them. I am not an maintainer Till> for anything at the moment so what do I have to do to claim Till> ownership? As far as I know we don't have a method to get someone sponsored/maintainer status without them having submitted a package for review. Is there some package you would like to submit for review? This would show that you know how packages work and the extras guidelines, etc. Till> I am interested in the following packages: Till> xosd tpb tpctl thinkpad-kmod thinkpad-kmod-common Till> configure-thinkpad pam_mount I use xosd and tpb a lot here. I will probibly take them over for now since no one else is stepping up, but if you do get a package reviewed and go through the process I would be happy to hand them off to you down the road. Till> Regards, Till kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin-fedora-extras at scrye.com Mon May 15 17:32:49 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 15 May 2006 11:32:49 -0600 (MDT) Subject: xosd, lrmi, and tpb Message-ID: <20060515.113249.379647983.kevin@scrye.com> Since no one else is interested, I am planning on taking over xosd, lrmi and tpb. I will take over a bit later today. If someone else would like to do so, let me know... I might take over the other thinkpad orphans as well, need to look at the kmod stuff to see how it works first. :) I'd be happy to hand these off later to interested parties... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon May 15 17:45:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 May 2006 19:45:04 +0200 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147711673.32123.1.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> <1147709737.6151.3.camel@localhost.localdomain> <1147711673.32123.1.camel@localhost.localdomain> Message-ID: <1147715104.6151.15.camel@localhost.localdomain> Am Montag, den 15.05.2006, 12:47 -0400 schrieb Dan Williams: > On Mon, 2006-05-15 at 18:15 +0200, Thorsten Leemhuis wrote: > > Am Montag, den 15.05.2006, 10:45 -0400 schrieb Dan Williams: > > > On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > > > > Just FYI, I took the old kernel-module proposal and reworked the > > > > document a bit and put it in the proper place at: > > > > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > > > Might sill be a bit rough and the standard and the page still needs some > > > > finetuning. But it's probably a lot better than before. > > > Is there anything needed from the buildsystem for this? AFAIK you can > > > already to i686, i586, ppc, and x86_64 kernel modules. > > Well, in and ideal world plague, mock or something else would pass the > > - version of the latest kernel to the rpmbuild-call via "--define > > kversion foo" > > - all variants (smp, "", xen0, xenU, ...) via "--define kvariants bar > > baz" > > when building the package. That would avoid the hardcoding of those vars > > in the spec file. > I think we can do that in a sane way, yes. Great :) Ohh, I forgot -- we currently use something like ExclusiveArch: i586, i686, x86_64, ppc to specify the target archs to build for. Some people don't like that -- it would be good if the buildsys could handle this, too (but of course the buildsys should not try to build for i386 -- that will fail). > > > ppc64iseries and > > > ppc64 support isn't there yet though... > > ppc64 would probably require a special builder afaik where *.ppc64 isn't > > excluded? I tried that once -- worked fine. > Well, AFAIK Fedora runs 32-bit on ppc64 except for the kernel and > possibly glibc (?) yes, glibc and some other ppc64 packages where 64 bit might be an advantage. > , so usually we'd exclude all > *.ppc64 from the pull anyway. Yeah, I know. For ppc-build that's okay and the best solution, but to build ppc64 kmod's we need to include at least kernel-devel*.ppc64 and probably some other crucial packages, too (glibc.ppc64 libgcc.ppc64 ? maybe others ). I tried to build a kmod for ppc64 with mock once -- worked just fine after removing the Exclude = *.ppc64 from the mock-conf for the target and putting ppc64-redhat-linux into /etc/rpm/platform on the host. So it shouldn't be a big deal to set a plague-builder up for ppc64 somewhere. But how to we make sure that only kmod's are build for ppc64 (and not everything). Can plague handle that? -- Thorsten Leemhuis From fedora at leemhuis.info Mon May 15 17:54:13 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 May 2006 19:54:13 +0200 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060515.112047.166116122.kevin@scrye.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060508.162036.833082439.kevin@scrye.com> <645d17210605100842rad0dc7ch8e1f31651599a05f@mail.gmail.com> <645d17210605110926g4494a41g867f68283e8f8b6@mail.gmail.com> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> Message-ID: <1147715653.6151.18.camel@localhost.localdomain> Am Montag, den 15.05.2006, 11:20 -0600 schrieb Kevin Fenzi: > >>>>> "Jonathan" == Jonathan Underwood writes: > Jonathan> On 12/05/06, Thorsten Leemhuis wrote: > >> I'm not an emacs users, but from all I can see I'll vote for the > >> solution spot suggested (e.g. emacs-common-foo). > Jonathan> I much prefer emacsen-foo. > As do I, but if everyone else prefers the 'emacs-common' thats ok with > me too. :) [...] > I guess we just need to have FECSO vote and settle it once and for > all. :) > > Thorsten: Can you add that to the next meeting agenda? Done. Currently we have this suggestions as far as I can see: emacs-muse (and have also xemacs-muse in bugzilla to avoid confusion) emacs-common-muse emacsen-muse Did I miss one? CU thl -- Thorsten Leemhuis From tibbs at math.uh.edu Mon May 15 18:14:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 15 May 2006 13:14:27 -0500 Subject: Claiming ownership for thinkpad related packages and pam_mount In-Reply-To: <20060515.112531.81086309.kevin@scrye.com> (Kevin Fenzi's message of "Mon, 15 May 2006 11:25:31 -0600 (MDT)") References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: KF> As far as I know we don't have a method to get someone KF> sponsored/maintainer status without them having submitted a KF> package for review. I don't think we have a policy, but the procedure is clear. They can just sign up for an account as normal, and the sponsor (assuming someone is willing to be one, of course) can upgrade the status as normal. I think the committee should take up the idea of sponsorship for package adoption without package submission. KF> Is there some package you would like to submit for review? This KF> would show that you know how packages work and the extras KF> guidelines, etc. He could also just review packages (but not be able to approve them, as usual) , help users, etc. - J< From kevin-fedora-extras at scrye.com Mon May 15 19:06:46 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 15 May 2006 13:06:46 -0600 (MDT) Subject: Claiming ownership for thinkpad related packages and pam_mount References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> Message-ID: <20060515.130646.925618500.kevin@scrye.com> >>>>> "Jason" == Jason L Tibbitts, writes: >>>>> "KF" == Kevin Fenzi writes: KF> As far as I know we don't have a method to get someone KF> sponsored/maintainer status without them having submitted a KF> package for review. Jason> I don't think we have a policy, but the procedure is clear. Jason> They can just sign up for an account as normal, and the sponsor Jason> (assuming someone is willing to be one, of course) can upgrade Jason> the status as normal. Jason> I think the committee should take up the idea of sponsorship Jason> for package adoption without package submission. Yeah, I think it should be possible too, but it will likely be much harder for sponsors to tell if someone is ready to be sponsored. KF> Is there some package you would like to submit for review? This KF> would show that you know how packages work and the extras KF> guidelines, etc. Jason> He could also just review packages (but not be able to approve Jason> them, as usual) , help users, etc. Sure. I guess it's currently subjectively up to sponsors to determine if someone is ready to be sponsored and maintain packages. Without concrete information it's impossible to tell if someone knows enough to be a good maintainer. :( One thing that might have helped in the dim past was when people did introductions explaining their background and skills... Jason> - J< kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Mon May 15 19:11:26 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 May 2006 15:11:26 -0400 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147715104.6151.15.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> <1147709737.6151.3.camel@localhost.localdomain> <1147711673.32123.1.camel@localhost.localdomain> <1147715104.6151.15.camel@localhost.localdomain> Message-ID: <1147720286.3067.12.camel@localhost.localdomain> On Mon, 2006-05-15 at 19:45 +0200, Thorsten Leemhuis wrote: > Am Montag, den 15.05.2006, 12:47 -0400 schrieb Dan Williams: > > On Mon, 2006-05-15 at 18:15 +0200, Thorsten Leemhuis wrote: > > > Am Montag, den 15.05.2006, 10:45 -0400 schrieb Dan Williams: > > > > On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote: > > > > > > Just FYI, I took the old kernel-module proposal and reworked the > > > > > document a bit and put it in the proper place at: > > > > > http://www.fedoraproject.org/wiki/Packaging/KernelModules > > > > > Might sill be a bit rough and the standard and the page still needs some > > > > > finetuning. But it's probably a lot better than before. > > > > Is there anything needed from the buildsystem for this? AFAIK you can > > > > already to i686, i586, ppc, and x86_64 kernel modules. > > > Well, in and ideal world plague, mock or something else would pass the > > > - version of the latest kernel to the rpmbuild-call via "--define > > > kversion foo" > > > - all variants (smp, "", xen0, xenU, ...) via "--define kvariants bar > > > baz" > > > when building the package. That would avoid the hardcoding of those vars > > > in the spec file. > > I think we can do that in a sane way, yes. > > Great :) > > Ohh, I forgot -- we currently use something like > > ExclusiveArch: i586, i686, x86_64, ppc > > to specify the target archs to build for. Some people don't like that -- > it would be good if the buildsys could handle this, too (but of course > the buildsys should not try to build for i386 -- that will fail). Out of curiosity, what _do_ they want to do? Do they just want to put nothing in the specfile and have it work magically? If we're talking a clear & simple approach, people have one option: ExclusiveArch: i586 i686 ... If we want to "assume" what the user wants, then we do all the magic in the build system and it's completely unclear _outside_ the buildsystem what architectures the kernel module actually builds on. Assuming isn't necessarily a bad thing, but if you take it too far stuff gets really unclear and you start not doing things people expect. The situation here would be that the package would build everywhere by default, and if the user doesn't want a specific architecture, they have to ExcludeArch that particular one. So we're right back to having to put that stuff back into the spec. It's a tradeoff: you either make expectations quite clear upfront, or you run around answering questions about why the buildsys does what it does because things are less clear. I guess we can just extend the additional package arches stuff in the buildsys config to do something like "!i386 !i486" and exclude those arches automatically, but build on all the rest. The problem is that this config option is a "you can build these if you want to", not a "these will be built unless you exclude them". I can look into expanding the syntax here to account for everything. > I tried to build a kmod for ppc64 with mock once -- worked just fine > after removing the > Exclude = *.ppc64 > from the mock-conf for the target and putting > ppc64-redhat-linux > into /etc/rpm/platform on the host. So it shouldn't be a big deal to set > a plague-builder up for ppc64 somewhere. But how to we make sure that > only kmod's are build for ppc64 (and not everything). Can plague handle > that? Yeah, I can look into this, though we've had issues with some stuff in RPM recently (RH Bug #171391). Dan From steve at silug.org Mon May 15 19:23:07 2006 From: steve at silug.org (Steven Pritchard) Date: Mon, 15 May 2006 14:23:07 -0500 Subject: help with build error Message-ID: <20060515192307.GA25121@osiris.silug.org> I sent this to fedora-perl-devel-list a couple of days ago, but since I haven't seen an answer there yet (and I need to get this resolved), I thought I should try here... I recently updated perl-YAML in devel, which broke perl-Module-Build. I'm trying to fix that by building the latest perl-Module-Build, but it looks like the old version is getting pulled in, causing a build failure. /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-ppc-core-558ea75def852d85a4d60009e86eb3328d806610/root install 'perl(ExtUtils::ParseXS) >= 1.02' 'perl(ExtUtils::CBuilder) >= 0.15' 'perl(Archive::Tar) >= 1.08' 'perl(Pod::Readme) >= 0.04' 'perl(YAML)' Error: Missing Dependency: perl(YAML) < 0.49 is needed by package perl-Module-Build In case anyone wants to see the full messages: Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/9342-perl-Module-Build-0.28-2.fc6/ I really don't see why the older version of Module::Build is getting pulled in by yum. As far as I can tell, it isn't a dependency of anything that Module::Build lists as a BuildRequires. So far the only solutions I can think of are to either remove the newer perl-YAML from the repository temporarily, or removing the older perl-Module-Build. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From rdieter at math.unl.edu Mon May 15 20:09:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 15 May 2006 15:09:17 -0500 Subject: upstream renamed app, simple update, or new review required? Message-ID: I'm maintaining kimdaba in Extras, and discoverred today that upstream renamed itself to kphotoalbum. I'm guessing I already know the answer.. but... can I just update the pkg using the new name of course and update owners.list), or ought a situation like this require a new review? -- Rex From peter at thecodergeek.com Mon May 15 20:13:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 15 May 2006 13:13:27 -0700 (PDT) Subject: upstream renamed app, simple update, or new review required? In-Reply-To: References: Message-ID: <37639.127.0.0.1.1147724007.squirrel@www.thecodergeek.com> Rex Dieter wrote: > I'm guessing I already know the answer.. but... can I just update the > pkg using the new name of course and update owners.list), or ought a > situation like this require a new review? The Wiki page has some good information about renaming packages: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-581c3fb3ff1c6ef7404e8b288b59cd5280d75ad6 Hope that helps. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From buildsys at fedoraproject.org Mon May 15 20:19:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 15 May 2006 16:19:37 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060515201937.D67C2152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 5 dnsmasq-2.31-1.fc3.1 mod_security-1.9.4-1.fc3 phpldapadmin-0.9.8.3-1.fc3 spamass-milter-0.3.1-3.fc3 wine-docs-0.9.13-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 15 20:20:11 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 15 May 2006 16:20:11 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060515202011.26B2B152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 12 abiword-2.4.4-4.fc4 fedora-package-config-smart-4-5 hspell-1.0-3.fc4 lyx-1.4.1-3.fc4 mftrace-1.2.4-1.fc4 mod_security-1.9.4-1.fc4 perl-Sub-Uplevel-0.12-1.fc4 perl-Test-Differences-0.47-2.fc4 phpldapadmin-0.9.8.3-1.fc4 shorewall-3.0.7-1.fc4 spamass-milter-0.3.1-3.fc4 wine-docs-0.9.13-0.1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 15 20:21:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 15 May 2006 16:21:05 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060515202105.8D5D8152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 19 NetworkManager-vpnc-0.6.2-1.fc5 aspell-he-1.0-1.fc5 childsplay_plugins-0.80.8-1.fc5 cowbell-0.2.7.1-2.fc5 fedora-package-config-smart-5-6 hspell-1.0-2.fc5 lyx-1.4.1-3.fc5 mftrace-1.2.4-1.fc5 mod_security-1.9.4-1.fc5 perl-Sub-Uplevel-0.12-1.fc5 perl-Test-Differences-0.47-2.fc5 phpldapadmin-0.9.8.3-1.fc5 pure-ftpd-1.0.21-5.fc5 python-adns-1.1.0-3.fc5 python-matplotlib-0.87.2-2.fc5 shorewall-3.0.7-1.fc5 spamass-milter-0.3.1-3.fc5 sylpheed-claws-2.2.0-1.fc5 wine-docs-0.9.13-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 15 20:21:56 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 15 May 2006 16:21:56 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060515202156.786C7152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 33 GeoIP-1.3.17-1.fc6 NetworkManager-vpnc-0.6.2-1.fc6 adns-1.2-3.fc6 apt-0.5.15lorg3-2.1.fc6 aspell-he-1.0-1.fc6 childsplay_plugins-0.80.8-1.fc6 dejavu-fonts-2.6.0-1.fc6 fedora-package-config-smart-5.89-7 gauche-gtk-0.4.1-7.fc6 gpgme-1.1.2-4.fc6 gprolog-1.2.19-5.fc6 gtk2hs-0.9.10-1.fc6 hspell-1.0-2.fc6 liblo-0.23-4.fc6 liblrdf-0.4.0-6.fc6 libnetfilter_conntrack-0.0.30-2.fc6 mod_security-1.9.4-1.fc6 pan-0.97-1.fc6 perl-CSS-Tiny-1.11-1.fc6 perl-PPI-HTML-1.07-1.fc6 perl-Test-Differences-0.47-2.fc6 phpldapadmin-0.9.8.3-1.fc6 pure-ftpd-1.0.21-5.fc6 python-adns-1.1.0-3.fc6 python-matplotlib-0.87.2-2.fc6 python-mechanize-0.1.1a-2.fc6 shorewall-3.2.0-0.1.Beta7.fc6 spamass-milter-0.3.1-3.fc6 swaks-20050709.1-5.fc6 sylpheed-claws-2.2.0-1.fc6 wine-docs-0.9.13-1.fc6 xarchon-0.50-2.fc6 xemacs-sumo-20060510-2.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From lmacken at redhat.com Mon May 15 20:34:26 2006 From: lmacken at redhat.com (Luke Macken) Date: Mon, 15 May 2006 16:34:26 -0400 Subject: new pork maintainer Message-ID: <20060515203426.GB31258@tomservo.boston.redhat.com> Ryan McCabe, the author of pork, will be taking over maintainership of his aim client. Thanks Ryan :) luke From ville.skytta at iki.fi Mon May 15 20:41:58 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 15 May 2006 23:41:58 +0300 Subject: Claiming ownership for thinkpad related packages and pam_mount In-Reply-To: References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> Message-ID: <1147725718.2760.25.camel@localhost.localdomain> On Mon, 2006-05-15 at 13:14 -0500, Jason L Tibbitts III wrote: > >>>>> "KF" == Kevin Fenzi writes: > > KF> As far as I know we don't have a method to get someone > KF> sponsored/maintainer status without them having submitted a > KF> package for review. > > I don't think we have a policy, but the procedure is clear. They can > just sign up for an account as normal, and the sponsor (assuming > someone is willing to be one, of course) can upgrade the status as > normal. > > I think the committee should take up the idea of sponsorship for > package adoption without package submission. Been there, done that. I'm not saying all cases will be the same, but the whole thinkpad software stack being orphaned at the moment is a direct consequence of one such experiment which failed pretty badly. From kevin-fedora-extras at scrye.com Mon May 15 20:48:43 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 15 May 2006 14:48:43 -0600 (MDT) Subject: xosd, lrmi, and tpb References: <20060515.113249.379647983.kevin@scrye.com> Message-ID: <20060515.144843.547156426.kevin@scrye.com> >>>>> "Kevin" == Kevin Fenzi writes: Kevin> Since no one else is interested, I am planning on taking over Kevin> xosd, lrmi and tpb. I will take over a bit later today. If Kevin> someone else would like to do so, let me know... ok. I have taken over: xosd lrmi tpb I have assigned the two tpb bugs to myself. None of the other packages have open bugs against them. I have removed them from the wiki orphan page. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at cypherpunks.ca Mon May 15 20:57:54 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 15 May 2006 22:57:54 +0200 (CEST) Subject: Remove orphans in devel (Was: Re: atitvout + gai-pal : Orphaned dependencies!) In-Reply-To: <1147708771.5969.13.camel@localhost.localdomain> References: <20060515124435.35771846.bugs.michael@gmx.net> <1147703242.2611.3.camel@localhost.localdomain> <20060515171903.51700e88.bugs.michael@gmx.net> <1147708771.5969.13.camel@localhost.localdomain> Message-ID: On Mon, 15 May 2006, Thorsten Leemhuis wrote: > > > moving this to Fedora Extras list -- this seems like the better place > > > for such discussions to me > > My message was a notification (also see its Cc line), not the start of a > > discussion. > > Exactly -- my message was meant as start of a discussion and that's why > I move it to this list, that seemed like the better place. > > > > lrmi > > > > xosd > > > > > > > > are on the list of orphaned packages. [...] I guess I can take on the packages needed for s3switch, since I need that utility on my old Vaio. So, I prefer someone else to take them, but if it no one else has an interested, I'll take: lrmi s3switch ks3switch If no one claims these in the next week or so, I'll take them. Paul From ville.skytta at iki.fi Mon May 15 21:12:31 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 16 May 2006 00:12:31 +0300 Subject: Kernel modules in Fedora Extras In-Reply-To: <1147720286.3067.12.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> <1147709737.6151.3.camel@localhost.localdomain> <1147711673.32123.1.camel@localhost.localdomain> <1147715104.6151.15.camel@localhost.localdomain> <1147720286.3067.12.camel@localhost.localdomain> Message-ID: <1147727551.2760.51.camel@localhost.localdomain> On Mon, 2006-05-15 at 15:11 -0400, Dan Williams wrote: > On Mon, 2006-05-15 at 19:45 +0200, Thorsten Leemhuis wrote: > > > > Ohh, I forgot -- we currently use something like > > > > ExclusiveArch: i586, i686, x86_64, ppc > > > > to specify the target archs to build for. Some people don't like that -- > > it would be good if the buildsys could handle this, too (but of course > > the buildsys should not try to build for i386 -- that will fail). > > Out of curiosity, what _do_ they want to do? Do they just want to put > nothing in the specfile Yes, if it is not known that something in the packaged modules *themselves* prevents them from working or makes them useless on some architectures (ExcludeArch), or if it is not known that the modules work or are useful only on a known set of architectures (ExclusiveArch). Consider someone running a custom kernel built for an architecture that is not shipped in FE (for example sparc or ia64 or pentium4 or whatever, these are just examples so ignore specifics and (non-)availability of the rest of the distro for the moment) and modules which per se are very much usable on that architecture. The rebuild of the module packages will fail because of the pesky hardcoded ExclusiveArch which is not there because the modules would actually need it nor to describe constraints of the modules, but because ExclusiveArch is being (ab)used for something else. > and have it work magically? If the buildsys knows the EVR of the latest kernel that modules should be built for and its variants, surely it's also capable of knowing what archs are they available for in FC and knows what archs it can build stuff for, and can pass the appropriate --target rpmbuild switches to the build, no? Why would that be any more magical or cause more assumptions or be somehow bad when it's (sometime going to be, I gather) already passing --define 'kversion ...' and --define 'kvariants ...'? Note: this is not really that big a deal nor would it cause unacceptable practical problems even for distro rebuilders IMO, it's just me (and others who dislike ExclusiveArch being used for the purpose of *adding* non-default archs to build for) being pedantic. From bugzilla at redhat.com Mon May 15 21:23:16 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 15 May 2006 17:23:16 -0400 Subject: [Bug 185606] Template file for libraries In-Reply-To: Message-ID: <200605152123.k4FLNGkF015369@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Template file for libraries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185606 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com Severity|enhancement |normal Keywords| |FutureFeature ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Keywords| |FutureFeature Resolution| |ERRATA Fixed In Version| |1.6-1 ------- Additional Comments From ville.skytta at iki.fi 2006-05-15 17:23 EST ------- Included in 1.6-1, which will soon hit the repos. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jonathan.underwood at gmail.com Mon May 15 21:34:51 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 15 May 2006 22:34:51 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147715653.6151.18.camel@localhost.localdomain> References: <1147123014.2910.248.camel@localhost.localdomain> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> Message-ID: <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> On 15/05/06, Thorsten Leemhuis wrote: > Am Montag, den 15.05.2006, 11:20 -0600 schrieb Kevin Fenzi: > > >>>>> "Jonathan" == Jonathan Underwood writes: > > Jonathan> On 12/05/06, Thorsten Leemhuis wrote: > > >> I'm not an emacs users, but from all I can see I'll vote for the > > >> solution spot suggested (e.g. emacs-common-foo). > > Jonathan> I much prefer emacsen-foo. > > As do I, but if everyone else prefers the 'emacs-common' thats ok with > > me too. :) > [...] > > I guess we just need to have FECSO vote and settle it once and for > > all. :) > > > > Thorsten: Can you add that to the next meeting agenda? > > Done. > > Currently we have this suggestions as far as I can see: > > emacs-muse (and have also xemacs-muse in bugzilla to avoid confusion) > emacs-common-muse > emacsen-muse > > Did I miss one? This also raises the meta question - is it ok for subpackages to have their own bugzilla entry? I think the answer has to be yes. For example, emacs-auctex really should have a subpackage for the preview latex style files and friends, called tetex-preview, such that functionality of the latex preview style files is made available for eg. LyX. This approach is recommended by upstream AUCTeX maintainers. Clearly, no user could be expected to know that bugs with tetex-preview should be filed against emacs-auctex. :) j. From mpeters at mac.com Mon May 15 21:47:52 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 15 May 2006 14:47:52 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060511.120202.170164697.kevin@scrye.com> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> Message-ID: <1147729672.4124.2.camel@atlantis.mpeters.local> On Mon, 2006-05-15 at 22:34 +0100, Jonathan Underwood wrote: > > This also raises the meta question - is it ok for subpackages to have > their own bugzilla entry? I think the answer has to be yes. > > For example, emacs-auctex really should have a subpackage for the > preview latex style files and friends, called tetex-preview, such that > functionality of the latex preview style files is made available for > eg. LyX. This approach is recommended by upstream AUCTeX maintainers. > Clearly, no user could be expected to know that bugs with > tetex-preview should be filed against emacs-auctex. :) While that is a problem - the proper bugzilla entry can be found by looking at the rpm info (which shows the src.rpm that spawned it). There are a boatload of packages with sub packages, and when I asked about this before (components for sub packages) I was very bluntly told "not gonna happen". From jamatos at fc.up.pt Mon May 15 22:30:08 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 15 May 2006 23:30:08 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> Message-ID: <200605152330.09838.jamatos@fc.up.pt> On Monday 15 May 2006 22:34, Jonathan Underwood wrote: > > For example, emacs-auctex really should have a subpackage for the > preview latex style files and friends, called tetex-preview, such that > functionality of the latex preview style files is made available for > eg. LyX. This approach is recommended by upstream AUCTeX maintainers. > Clearly, no user could be expected to know that bugs with > tetex-preview should be filed against emacs-auctex. :) Almost OT but what is missing for this subpackage to be available? I am using lyx and it would be a nice addition to lyx spec file: Require(hint): tetex-preview I am also willing to help with testing. :-) > j. -- Jos? Ab?lio From jonathan.underwood at gmail.com Mon May 15 22:48:35 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 15 May 2006 23:48:35 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <200605152330.09838.jamatos@fc.up.pt> References: <1147123014.2910.248.camel@localhost.localdomain> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <200605152330.09838.jamatos@fc.up.pt> Message-ID: <645d17210605151548k71bcb08el8a4f3a1c647aee8e@mail.gmail.com> On 15/05/06, Jose' Matos wrote: > Almost OT but what is missing for this subpackage to be available? > I am using lyx and it would be a nice addition to lyx spec file: > > Require(hint): tetex-preview > > I am also willing to help with testing. :-) Well, for a while it was waiting for the tetex packager to remove the preview latex documentation spuriosly packaged with tetex. He's kindly done that now. All it now requires is for me to submit builds of emacs-auctex which build the tetex-preview subpackage , and, importantly for the package naming issues to be cleared up, although, hopefully, if FESCO chose the right package naming (i.e. emacs-foo), we won't have to change auctex. :) J. I'll do it by this weekend, all being well. From buildsys at fedoraproject.org Mon May 15 23:01:31 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 15 May 2006 23:01:31 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-15 Message-ID: <20060515230131.18421.28719@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 From buildsys at fedoraproject.org Mon May 15 23:01:31 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 15 May 2006 23:01:31 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-15 Message-ID: <20060515230131.18430.29343@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From buildsys at fedoraproject.org Mon May 15 23:01:31 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 15 May 2006 23:01:31 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-15 Message-ID: <20060515230131.18435.45955@extras64.linux.duke.edu> ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Tue May 16 00:22:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 16 May 2006 00:22:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-15 Message-ID: <20060516002239.20557.79587@extras64.linux.duke.edu> ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm ERROR: swaks not in owners.list ERROR: source rpm is swaks-20050709.1-5.fc6.src.rpm Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: UNKNOWN OWNER package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(Authen:DigestMD5) package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Authen:DigestMD5) package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(Authen:DigestMD5) ====================================================================== package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From seg at haxxed.com Tue May 16 00:31:28 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 15 May 2006 19:31:28 -0500 Subject: SSL certificate of https://admin.fedora.redhat.com/ In-Reply-To: <200605111524.44065@rineau.schtroumpfette> References: <200605110904.41317@rineau.schtroumpfette> <200605111524.44065@rineau.schtroumpfette> Message-ID: <1147739489.31467.7.camel@localhost.localdomain> On Thu, 2006-05-11 at 15:24 +0200, Laurent Rineau wrote: > If I cannot specify several SSH keys, I will create a special key for my CVS > account, that I will transport on all my unix accounts, as you suggest. On a similar topic, the automated CLA signing thingy doesn't seem to work with signing subkeys. gpg of course doesn't help, I couldn't find any way to tell it to sign with the primary key, I ended up having to back up my keys, nuke all the subkeys, then sign, then restore the subkeys... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 16 00:35:13 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 15 May 2006 19:35:13 -0500 Subject: SSL certificate of https://admin.fedora.redhat.com/ In-Reply-To: References: <200605110904.41317@rineau.schtroumpfette> <200605111524.44065@rineau.schtroumpfette> Message-ID: <1147739715.31467.11.camel@localhost.localdomain> On Thu, 2006-05-11 at 08:32 -0500, Jima wrote: > Funny, I guess after you submit a comment, the resulting page has broken > links. Cute. Yeah, this is incredibly irritatingly bad web app design. If Galeon or X or my entire system crashes/hangs/power outage, and recovers the session later, I just end up with a bunch of error pages. Makes it hard to bookmark it as well. -------------- 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 jima at beer.tclug.org Tue May 16 02:24:27 2006 From: jima at beer.tclug.org (Jima) Date: Mon, 15 May 2006 21:24:27 -0500 (CDT) Subject: Kernel modules in Fedora Extras In-Reply-To: <1147727551.2760.51.camel@localhost.localdomain> References: <1147632296.18635.102.camel@localhost.localdomain> <1147704324.2193.53.camel@localhost.localdomain> <1147709737.6151.3.camel@localhost.localdomain> <1147711673.32123.1.camel@localhost.localdomain> <1147715104.6151.15.camel@localhost.localdomain> <1147720286.3067.12.camel@localhost.localdomain> <1147727551.2760.51.camel@localhost.localdomain> Message-ID: On Tue, 16 May 2006, Ville Skytt? wrote: > Yes, if it is not known that something in the packaged modules > *themselves* prevents them from working or makes them useless on some > architectures (ExcludeArch), or if it is not known that the modules work > or are useful only on a known set of architectures (ExclusiveArch). I agree on this. ExclusiveArch is more of a hindrance to me; I always end up having to add sparc/sparc64 to the list when updating packages to Aurora. > Consider someone running a custom kernel built for an architecture that > is not shipped in FE (for example sparc or ia64 or pentium4 or whatever, > these are just examples so ignore specifics and (non-)availability of > the rest of the distro for the moment) and modules which per se are very > much usable on that architecture. Actually, sparc isn't even a totally hypothetical example. Our own Dennis Gilmore maintains a sparc port of Extras for Aurora Linux, and is rather successful, from what I've seen. Jima From nando at ccrma.Stanford.EDU Tue May 16 05:11:17 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 15 May 2006 22:11:17 -0700 Subject: Suggestion for new packages: avr-gcc, avr-binutils, avr-libc, avrdude, uisp, avra In-Reply-To: <200605131633.19606.opensource@till.name> References: <200605131633.19606.opensource@till.name> Message-ID: <1147756277.14643.3.camel@cmn3.stanford.edu> On Sat, 2006-05-13 at 16:33 +0200, Till Maas wrote: > Hello, > > I would like to include the following packages to extras: > > avr-gcc > avr-binutils > avr-libc - http://www.nongnu.org/avr-libc/ > avrdude - http://savannah.nongnu.org/projects/avrdude > uisp - http://savannah.nongnu.org/projects/uisp > avra - http://avra.sourceforge.net/ > > Is anyone else already working on this? Are there any legal issues why this > software could not be added to extras or can I start writing the SPEC files? I have not submitted them but they are currently part of the Planet CCRMA repository, you may want to base your packages on them. The spec files were based on work by Yukio Mituiwa (I don't currently have avrdude or avra). -- Fernando From fedora at leemhuis.info Tue May 16 07:41:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 09:41:40 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> Message-ID: <1147765300.2469.2.camel@thl.ct.heise.de> Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: > >>>>> "KF" == Kevin Fenzi writes: > > KF> As far as I know we don't have a method to get someone > KF> sponsored/maintainer status without them having submitted a > KF> package for review. > > I don't think we have a policy, but the procedure is clear. They can > just sign up for an account as normal, and the sponsor (assuming > someone is willing to be one, of course) can upgrade the status as > normal. > > I think the committee should take up the idea of sponsorship for > package adoption without package submission. I send the following to the FESCo-List last week (it was in a similar context). --- I'll give a example of my currently thoughts: Package foo is orphaned. bar is interested in taking it over, but is no Extras contributor yet. Sponsor foobar steps up; he acts as proxy between bar and Extras cvs for some time (e.g. bar prepares patches, sends them to foobar who applies them and requests the build). If everything looks okay after some time bar get sponsored. Is this stupid? Biggest problem: How to find sponsors that like to act as proxy? --- That would mean (a lot of) extra work for the sponsors. And that's why this idea probably will fail. Does anyone have a better idea? CU thl From michael at knox.net.nz Tue May 16 07:45:24 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 16 May 2006 19:45:24 +1200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147765300.2469.2.camel@thl.ct.heise.de> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> Message-ID: <44698314.2060607@knox.net.nz> Thorsten Leemhuis wrote: > Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: >>>>>>> "KF" == Kevin Fenzi writes: >> KF> As far as I know we don't have a method to get someone >> KF> sponsored/maintainer status without them having submitted a >> KF> package for review. >> >> I don't think we have a policy, but the procedure is clear. They can >> just sign up for an account as normal, and the sponsor (assuming >> someone is willing to be one, of course) can upgrade the status as >> normal. >> >> I think the committee should take up the idea of sponsorship for >> package adoption without package submission. > > I send the following to the FESCo-List last week (it was in a similar > context). > > --- > I'll give a example of my currently thoughts: Package foo is orphaned. > bar is interested in taking it over, but is no Extras contributor yet. > Sponsor foobar steps up; he acts as proxy between bar and Extras cvs for > some time (e.g. bar prepares patches, sends them to foobar who applies > them and requests the build). If everything looks okay after some time > bar get sponsored. > > Is this stupid? Biggest problem: How to find sponsors that like to act > as proxy? > --- > > That would mean (a lot of) extra work for the sponsors. And that's why > this idea probably will fail. Does anyone have a better idea? The normal review request process? Potential owners can state that its an orphaned package and edit the orphan wiki page to include the BZ # of the review request. Simple enough? Michael From fedora at leemhuis.info Tue May 16 07:53:31 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 09:53:31 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <44698314.2060607@knox.net.nz> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> Message-ID: <1147766011.2469.6.camel@thl.ct.heise.de> Am Dienstag, den 16.05.2006, 19:45 +1200 schrieb Michael J Knox: > Thorsten Leemhuis wrote: > > Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: > >>>>>>> "KF" == Kevin Fenzi writes: > >> KF> As far as I know we don't have a method to get someone > >> KF> sponsored/maintainer status without them having submitted a > >> KF> package for review. > >> > >> I don't think we have a policy, but the procedure is clear. They can > >> just sign up for an account as normal, and the sponsor (assuming > >> someone is willing to be one, of course) can upgrade the status as > >> normal. > >> > >> I think the committee should take up the idea of sponsorship for > >> package adoption without package submission. > > > > I send the following to the FESCo-List last week (it was in a similar > > context). > > > > --- > > I'll give a example of my currently thoughts: Package foo is orphaned. > > bar is interested in taking it over, but is no Extras contributor yet. > > Sponsor foobar steps up; he acts as proxy between bar and Extras cvs for > > some time (e.g. bar prepares patches, sends them to foobar who applies > > them and requests the build). If everything looks okay after some time > > bar get sponsored. > > > > Is this stupid? Biggest problem: How to find sponsors that like to act > > as proxy? > > --- > > > > That would mean (a lot of) extra work for the sponsors. And that's why > > this idea probably will fail. Does anyone have a better idea? > > The normal review request process? Potential owners can state that its > an orphaned package and edit the orphan wiki page to include the BZ # of > the review request. > > Simple enough? Sorry, I'm not sure I correctly understood what you meant. You mean that a new contributor just files a new review request with an updated version of the old package? That's probably to easy if the old package is in a good shape. CU thl From michael at knox.net.nz Tue May 16 08:04:13 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 16 May 2006 20:04:13 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <20060513204201.b6fdcc5e.bugs.michael@gmx.net> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> Message-ID: <4469877D.8030505@knox.net.nz> Michael Schwendt wrote: > On Sat, 13 May 2006 10:10:58 +1200, Michael J Knox wrote: > >>>> The over all aim is to avoid "stale" packages in Extras, more swiftly >>>> pick up on unmaintained packages and hopefully encourage people to work >>>> on these packages by providing a process in which people can fix them. >>> First of all, I think you mix a few things. Specifically, the NMU talks >>> about "fixes", "bugs" and "serious problems", while you talk about >>> "stale", "unmaintained" packages and "the take over of a package". Not >>> sure whether you want to merge all that into a single policy. >> Possibly, I sort of see them one in the same. The "fixes, bugs and >> serious problems" can only apply if the package owner has been contacted >> and had no response. > > Okay. That, of course, is quite different from [and more detailed than] > "avoiding stale packages". Ok, sorry... sometimes I assume everyone is on the same page as me and neglect to make sure that I am understood :) > I just wanted to make sure that the reason for NMU-activity is given in > _actual problems_ with a package and not just due to some contributors > preferring to engage in a release-race with upstream. Those tickets like > "version 1.2.3 is available, please upgrade", which are easily forgotten > by packagers, who didn't like a new release when they evaluated/tried it. No way. This isn't about version bumps. The "version 1.2.3 is available, please upgrade" doesn't or shouldn't apply here. This is only about the process of handling packagers when an owner gives zero response and is not seen to be active. Avoiding the need for yourself and others to orphan them and disable their builds. > "Unmaintained packages" was another vague term you used above, which I > didn't comment on. _Packages without a maintainer_ (= orphans) can be > taken over very "swiftly", because there is no maintainer you need to try > to contact. Hence no need for complicated policies in that area. Thats only if the previous owner has announced as an orphan and noted that on the wiki or someone, like yourself, has figured out that no one is maintaining and orphaned it. >> I see it as more of a taking small steps to ownership on a package where >> the original owner is no longer contactable. > > Right, and where a package is broken. That's exactly where we should > start. agreed >>> I would appreciate if we started bottom-up with a procedure for "Adoption >>> of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then >>> we enhance the procedure in order to permit certain actions (like >>> requesting (re-)builds, fixing grave bugs) while it is still being waited >>> for a response by the maintainer. It will probably, except for security >>> issues, look like: >>> >>> - notify maintainer >>> - wait X days >>> - notify maintainer about planned take-over and >>> planned actions [e.g. (re-)builds, fixes] >>> - wait another X-Y days >>> - touch the package >>> - maybe wait another Z days >>> - take over the package in owners.list >>> >> Thats exactly what I was meaning. But its important that the "X, Y, Z" >> time frames are well known and defined. > > Let's start with X, maximum packager response time for a bugzilla ticket, > in which a serious (or normal) bug was reported. Would X=14 days be too > short? X+Y would cover at least two weekends. I mean, if a packager is on > a long vacation (several weeks or more) and is neglecting package > maintenance knowingly, the package would be suitable for shared > maintainership anyway. And in cases where a packager has had an accident > or is facing temporary illness (and similar things), we're back at what > I've written before -- that it should be in the packager's best interest > that other contributors help. > I feel, that if an owner is considered "active" then he/she should be able to at the very least, acknowledge a form of contact, direct email or BZ, within a 3 week time frame. However, I think it needs to be more than one attempt over that time frame. The person attempting the NMU must provide "proof" IMHO in the form of BZ reports etc of these attempts. A formal accounacment of intent on the extras list would be required, in case someone on the list knows the current owner where abouts. Michael From michael at knox.net.nz Tue May 16 08:05:01 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 16 May 2006 20:05:01 +1200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147766011.2469.6.camel@thl.ct.heise.de> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> <1147766011.2469.6.camel@thl.ct.heise.de> Message-ID: <446987AD.9080700@knox.net.nz> Thorsten Leemhuis wrote: > Am Dienstag, den 16.05.2006, 19:45 +1200 schrieb Michael J Knox: >> Thorsten Leemhuis wrote: >>> Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: >>>>>>>>> "KF" == Kevin Fenzi writes: >>>> KF> As far as I know we don't have a method to get someone >>>> KF> sponsored/maintainer status without them having submitted a >>>> KF> package for review. >>>> >>>> I don't think we have a policy, but the procedure is clear. They can >>>> just sign up for an account as normal, and the sponsor (assuming >>>> someone is willing to be one, of course) can upgrade the status as >>>> normal. >>>> >>>> I think the committee should take up the idea of sponsorship for >>>> package adoption without package submission. >>> I send the following to the FESCo-List last week (it was in a similar >>> context). >>> >>> --- >>> I'll give a example of my currently thoughts: Package foo is orphaned. >>> bar is interested in taking it over, but is no Extras contributor yet. >>> Sponsor foobar steps up; he acts as proxy between bar and Extras cvs for >>> some time (e.g. bar prepares patches, sends them to foobar who applies >>> them and requests the build). If everything looks okay after some time >>> bar get sponsored. >>> >>> Is this stupid? Biggest problem: How to find sponsors that like to act >>> as proxy? >>> --- >>> >>> That would mean (a lot of) extra work for the sponsors. And that's why >>> this idea probably will fail. Does anyone have a better idea? >> The normal review request process? Potential owners can state that its >> an orphaned package and edit the orphan wiki page to include the BZ # of >> the review request. >> >> Simple enough? > > Sorry, I'm not sure I correctly understood what you meant. You mean that > a new contributor just files a new review request with an updated > version of the old package? That's probably to easy if the old package > is in a good shape. hrmm.. good point. Perhaps it should just be avoided? Recommend new contributors take packages from the wish list or alike? Michael From mpeters at mac.com Tue May 16 08:23:55 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 16 May 2006 01:23:55 -0700 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <446987AD.9080700@knox.net.nz> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> <1147766011.2469.6.camel@thl.ct.heise.de> <446987AD.9080700@knox.net.nz> Message-ID: <1147767835.4124.10.camel@atlantis.mpeters.local> On Tue, 2006-05-16 at 20:05 +1200, Michael J Knox wrote: > > hrmm.. good point. Perhaps it should just be avoided? Recommend new > contributors take packages from the wish list or alike? A new contributor should write at least one spec file that meets Fedora packaging guidelines. There are from time to time packages submitted that are obviously taken from somewhere else, say upstream or SuSE or wherever - often they don't even build, let alone build in mock or meet the guidelines. The contributor needs to demonstrate that they understand the guidelines well enough to write a spec file that is at least close to the guidelines - starting with the provided templates referenced in the wiki. -=- With the thinkpad packages - I believe one (or more) of them is a kernel module, which should not be undertaken lightly, and probably should be undertaken by someone who really knows what they are doing. Maybe this person does. I have a thinkpad - I was contemplating offering to import and maintain until he gets sponsored, but I really don't want to be stuck with kernel modules if he ends up not getting sponsored (it would end up orphaned again were that to happen). From fedora at leemhuis.info Tue May 16 08:28:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 10:28:03 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <446987AD.9080700@knox.net.nz> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> <1147766011.2469.6.camel@thl.ct.heise.de> <446987AD.9080700@knox.net.nz> Message-ID: <1147768083.2469.11.camel@thl.ct.heise.de> Am Dienstag, den 16.05.2006, 20:05 +1200 schrieb Michael J Knox: > Thorsten Leemhuis wrote: > > Am Dienstag, den 16.05.2006, 19:45 +1200 schrieb Michael J Knox: > >> Thorsten Leemhuis wrote: > >>> Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: > >>>>>>>>> "KF" == Kevin Fenzi writes: > >>>> KF> As far as I know we don't have a method to get someone > >>>> KF> sponsored/maintainer status without them having submitted a > >>>> KF> package for review. > >>>> > >>>> I don't think we have a policy, but the procedure is clear. They can > >>>> just sign up for an account as normal, and the sponsor (assuming > >>>> someone is willing to be one, of course) can upgrade the status as > >>>> normal. > >>>> > >>>> I think the committee should take up the idea of sponsorship for > >>>> package adoption without package submission. > >>> I send the following to the FESCo-List last week (it was in a similar > >>> context). > >>> > >>> --- > >>> I'll give a example of my currently thoughts: Package foo is orphaned. > >>> bar is interested in taking it over, but is no Extras contributor yet. > >>> Sponsor foobar steps up; he acts as proxy between bar and Extras cvs for > >>> some time (e.g. bar prepares patches, sends them to foobar who applies > >>> them and requests the build). If everything looks okay after some time > >>> bar get sponsored. > >>> > >>> Is this stupid? Biggest problem: How to find sponsors that like to act > >>> as proxy? > >>> --- > >>> > >>> That would mean (a lot of) extra work for the sponsors. And that's why > >>> this idea probably will fail. Does anyone have a better idea? > >> The normal review request process? Potential owners can state that its > >> an orphaned package and edit the orphan wiki page to include the BZ # of > >> the review request. > >> > >> Simple enough? > > > > Sorry, I'm not sure I correctly understood what you meant. You mean that > > a new contributor just files a new review request with an updated > > version of the old package? That's probably to easy if the old package > > is in a good shape. > > hrmm.. good point. Perhaps it should just be avoided? Recommend new > contributors take packages from the wish list or alike? Well, we get closer to the point where most interesting free apps are packaged. So this will get more and more problematic. And letting new contributors package apps that the don't use or even are uninterested in is also likely not the best solution. CU thl From jamatos at fc.up.pt Tue May 16 08:32:07 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 16 May 2006 09:32:07 +0100 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount ) In-Reply-To: <1147768083.2469.11.camel@thl.ct.heise.de> References: <200605131604.05348.opensource@till.name> <446987AD.9080700@knox.net.nz> <1147768083.2469.11.camel@thl.ct.heise.de> Message-ID: <200605160932.08178.jamatos@fc.up.pt> On Tuesday 16 May 2006 09:28, Thorsten Leemhuis wrote: > Well, we get closer to the point where most interesting free apps are > packaged. So this will get more and more problematic. Famous last words. ;-) You really need to define "interesting". :-) -- Jos? Ab?lio From giallu at gmail.com Tue May 16 10:02:02 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 16 May 2006 12:02:02 +0200 Subject: Some ftp space for SRPM for review wanted In-Reply-To: <44683F37.8050509@hhs.nl> References: <44683F37.8050509@hhs.nl> Message-ID: On 5/15/06, Hans de Goede wrote: > I've some big packages which I plan on packaging soonish, so I will need > a bit of diskspace (say upto 250 Mb) trafic will be low, as it will be > used for posting SRPM's for review only. I am using intefree.it just because of this. Their (free) accounts used to have unlimited http space (uploads via ftp only, but I handle them gracefully with curl) though I am not really sure about their bw. Just contact me if you would like to apply for an account and need help for understanding the registration form (italian only) Gianluca From bugs.michael at gmx.net Tue May 16 11:09:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 16 May 2006 13:09:13 +0200 Subject: FESCo Elections 2006 In-Reply-To: <1147248642.4011.34.camel@localhost> References: <1146496913.2830.33.camel@localhost.localdomain> <1147134783.20987.0.camel@atlantis.mpeters.local> <1147248642.4011.34.camel@localhost> Message-ID: <20060516130913.c1fc5ca1.bugs.michael@gmx.net> On Wed, 10 May 2006 01:10:41 -0700, Toshio Kuratomi wrote: > On Mon, 2006-05-08 at 17:33 -0700, Michael A. Peters wrote: > > On Mon, 2006-05-01 at 17:21 +0200, Thorsten Leemhuis wrote: > > > Hi All! > > > > > > As discussed on this list and during the last two FESCo meetings > we're > > > going to have a election of the members for the next FESCo. > > > > I would like to nominate Toshio Kuratomi - but I'm not going to put > him > > on the wiki page, just encouraging him to self nominate if he wants > the > > commitment ... > Thanks Michael, > > I've been pretty busy lately but democracy doesn't work if there's no > one to vote for (or against). I'm willing to self-nominate and have put > my information on the wiki. > > I noticed there are a lot of other people who haven't self nominated but > have commitment and ideas for Fedora. In the same spirit as Michael I'd > like to encourage a few of them: > > Ignacio Vazquez -- I know you were thinking about this and some of the > potential projects on your blog looked very interesting. > > Josh Boyer -- You have intelligent comments and you're present for all > the meetings anyway :-) > > Michael Schwendt, I see Seth nominated you but there's no indication > you've accepted. If you're not burnt out, it would be good to see you > back. Haven't noticed the Wiki page before. Now I've linked it from the Extras main page in the FESCO section and have put it into CategoryExtras, too. I've marked myself as "contingent" for now, which is a comment I've seen also behind the names of other current FESCO members. (and I won't take the time to count my reviews in bugzilla.fedora.us, btw) I would really like to see many new members in FESCO, to gain experience whether they would do things differently. When I take a look at the Wiki page, which lists the current FESCO members, I see 17 names, but hardly 50% of them come to the meetings. I haven't made it to all meetings either. This is mainly because historically and repeatedly several items on the FESCO schedule page have not been about Fedora Extras, and only a very few members (I call them the "usual suspects") have been able to take action items anyway, like infrastructure tasks. The decision finding process is not accompanied with proper communication and discussion in email at all and is not considering community feedback either. So, not seldomly, when a topic is brought up in a meeting, we are without a quorum, and the initiated discussion doesn't lead to a quick decision either. The topic is put back on schedule and is usually not picked up before the next meeting. We don't even try to reach quorum outside the meetings. The decision finding process should not result in endless discussions (I hate that). But it should be possible to come up with an official FESCO statement, which would be a chance to test FESCO's community acceptance. Which in turn would be very important. In several parts I am not sure how FESCO works. Along the same lines, I'm still not sure what sponsor's obligations are. From jonathan.underwood at gmail.com Tue May 16 11:54:06 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 16 May 2006 12:54:06 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147729672.4124.2.camel@atlantis.mpeters.local> References: <1147123014.2910.248.camel@localhost.localdomain> <645d17210605111256v2a4ddb7dme239df7ff4b16bd0@mail.gmail.com> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> Message-ID: <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> On 15/05/06, Michael A. Peters wrote: > On Mon, 2006-05-15 at 22:34 +0100, Jonathan Underwood wrote: > > This also raises the meta question - is it ok for subpackages to have > > their own bugzilla entry? I think the answer has to be yes. [snip] > While that is a problem - the proper bugzilla entry can be found by > looking at the rpm info (which shows the src.rpm that spawned it). > Fair point. > There are a boatload of packages with sub packages, and when I asked > about this before (components for sub packages) I was very bluntly told > "not gonna happen". Yes, now you mention it, I can see that it would lead to an unmanagable inflation of bugzilla., forget I mentioned it. [I wonder how many users submitting bugs to bugzilla realize they need to find the module name from the rpm database in this way. I also wonder how many people are discouraged from submitting bugzillas because they can't find the relevant module. I then wonder if bugzillas from those people would be useful anyway. I should probably stop wondering.] Anyway to stay on topic - the emacs-foo proposal isn't reliant on a separate bugzilla entry for the xemacs-foo subpackage - it just would've been nice. But the disadvantages of having subpackage entries in bugzilla outweight the advantages, it seems to me. From mpeters at mac.com Tue May 16 12:01:05 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 16 May 2006 05:01:05 -0700 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147768083.2469.11.camel@thl.ct.heise.de> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> <1147766011.2469.6.camel@thl.ct.heise.de> <446987AD.9080700@knox.net.nz> <1147768083.2469.11.camel@thl.ct.heise.de> Message-ID: <1147780865.4124.16.camel@atlantis.mpeters.local> On Tue, 2006-05-16 at 10:28 +0200, Thorsten Leemhuis wrote: > > Well, we get closer to the point where most interesting free apps are > packaged. So this will get more and more problematic. with mono and java and ruby coming together now, there may be quite a few more "non interesting" apps coming down the pipeline. From fedora at leemhuis.info Tue May 16 12:22:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 14:22:26 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147780865.4124.16.camel@atlantis.mpeters.local> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <44698314.2060607@knox.net.nz> <1147766011.2469.6.camel@thl.ct.heise.de> <446987AD.9080700@knox.net.nz> <1147768083.2469.11.camel@thl.ct.heise.de> <1147780865.4124.16.camel@atlantis.mpeters.local> Message-ID: <1147782146.2469.29.camel@thl.ct.heise.de> Am Dienstag, den 16.05.2006, 05:01 -0700 schrieb Michael A. Peters: > On Tue, 2006-05-16 at 10:28 +0200, Thorsten Leemhuis wrote: > > Well, we get closer to the point where most interesting free apps are > > packaged. So this will get more and more problematic. > > with mono and java and ruby coming together now, there may be quite a > few more "non interesting" apps coming down the pipeline. Maybe for some people, yes. But for others, no. To give an example from my personal point of view: All free apps that I'm interested in are packaged already in Extras. So I would simply not know what to package if I'd like to become a Extras contributor now if I wasn't one already. And that's a problem we should solve sooner or later to get more people with fresh ideas involved in Fedora Extras. Just my 2 cent. CU thl From fedora at leemhuis.info Tue May 16 16:02:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 18:02:37 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147765300.2469.2.camel@thl.ct.heise.de> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> Message-ID: <1147795358.2270.8.camel@localhost.localdomain> Am Dienstag, den 16.05.2006, 09:41 +0200 schrieb Thorsten Leemhuis: > Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: > > I think the committee should take up the idea of sponsorship for > > package adoption without package submission. > I send the following to the FESCo-List last week (it was in a similar > context). >[...] > That would mean (a lot of) extra work for the sponsors. And that's why > this idea probably will fail. Does anyone have a better idea? Well, maybe a slightly different approach might be easier: Package foo is orphaned. Bar is interested in taking it over, but he is no Extras contributor yet. Sponsor foobar steps up and sponsors bar for Extras cvs access (only cvs, bar gets *no* permissions to requests builds in plague). Bar updates packages and sends foobar a note when everything is ready. Foobar reviews the committed stuff and requests build if everything is fine. If that worked fine for some update cycles and some time in general bar gets fully sponsored and gets permissions to requests builds. Opinions? CU thl -- Thorsten Leemhuis From mpeters at mac.com Tue May 16 16:21:56 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 16 May 2006 09:21:56 -0700 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147795358.2270.8.camel@localhost.localdomain> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <1147795358.2270.8.camel@localhost.localdomain> Message-ID: <1147796516.4124.25.camel@atlantis.mpeters.local> On Tue, 2006-05-16 at 18:02 +0200, Thorsten Leemhuis wrote: > > Well, maybe a slightly different approach might be easier: > > Package foo is orphaned. Bar is interested in taking it over, but he is > no Extras contributor yet. Sponsor foobar steps up and sponsors bar for > Extras cvs access (only cvs, bar gets *no* permissions to requests > builds in plague). Bar updates packages and sends foobar a note when > everything is ready. Foobar reviews the committed stuff and requests > build if everything is fine. If that worked fine for some update cycles > and some time in general bar gets fully sponsored and gets permissions > to requests builds. > > Opinions? That sounds like it would work just dandy. From shahms at shahms.com Tue May 16 17:16:28 2006 From: shahms at shahms.com (Shahms King) Date: Tue, 16 May 2006 10:16:28 -0700 Subject: epydoc -> noarch transition problems In-Reply-To: <4468B807.7060203@cora.nwra.com> References: <4468B807.7060203@cora.nwra.com> Message-ID: <446A08EC.7040908@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Orion Poplawski wrote: > Looks like epydoc went from an arch specific to a noarch package: > > /data/sw1/fedora/extras/5/i386/epydoc-2.1-4.noarch.rpm > /data/sw1/fedora/extras/5/i386/epydoc-2.1-2.i386.rpm > /data/sw1/fedora/extras/5/ppc/epydoc-2.1-4.noarch.rpm > /data/sw1/fedora/extras/5/x86_64/epydoc-2.1-4.noarch.rpm > > However, it looks like the arch specific packages are still being picked > up by yum on FC5 (and maybe others). It gets the noarch on devel. What > needs to get cleaned up? > On top of that, the arch specific version is built for python 2.3 and as such, gets installed into entirely the wrong location. The epydoc-2.1-2.i386.rpm package really needs to be removed. What needs to be done to make this happen? - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEagjs/qs2NkWy11sRAugwAKDFmzocjVVqzCphYkk99FqXxu3zkwCfYpXI lIcSY08Q81WPKxrp6qDYC5Y= =H5HE -----END PGP SIGNATURE----- From paul at city-fan.org Tue May 16 17:23:34 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 18:23:34 +0100 Subject: epydoc -> noarch transition problems In-Reply-To: <446A08EC.7040908@shahms.com> References: <4468B807.7060203@cora.nwra.com> <446A08EC.7040908@shahms.com> Message-ID: <446A0A96.7070908@city-fan.org> Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Orion Poplawski wrote: >> Looks like epydoc went from an arch specific to a noarch package: >> >> /data/sw1/fedora/extras/5/i386/epydoc-2.1-4.noarch.rpm >> /data/sw1/fedora/extras/5/i386/epydoc-2.1-2.i386.rpm >> /data/sw1/fedora/extras/5/ppc/epydoc-2.1-4.noarch.rpm >> /data/sw1/fedora/extras/5/x86_64/epydoc-2.1-4.noarch.rpm >> >> However, it looks like the arch specific packages are still being picked >> up by yum on FC5 (and maybe others). It gets the noarch on devel. What >> needs to get cleaned up? >> > > On top of that, the arch specific version is built for python 2.3 and as > such, gets installed into entirely the wrong location. The > epydoc-2.1-2.i386.rpm package really needs to be removed. What needs to > be done to make this happen? http://fedoraproject.org/wiki/Extras/FC5Status Paul. From j.w.r.degoede at hhs.nl Tue May 16 17:24:24 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 16 May 2006 19:24:24 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147795358.2270.8.camel@localhost.localdomain> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <1147795358.2270.8.camel@localhost.localdomain> Message-ID: <446A0AC8.2080601@hhs.nl> Thorsten Leemhuis wrote: > Am Dienstag, den 16.05.2006, 09:41 +0200 schrieb Thorsten Leemhuis: >> Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: >>> I think the committee should take up the idea of sponsorship for >>> package adoption without package submission. >> I send the following to the FESCo-List last week (it was in a similar >> context). >> [...] >> That would mean (a lot of) extra work for the sponsors. And that's why >> this idea probably will fail. Does anyone have a better idea? > > Well, maybe a slightly different approach might be easier: > > Package foo is orphaned. Bar is interested in taking it over, but he is > no Extras contributor yet. Sponsor foobar steps up and sponsors bar for > Extras cvs access (only cvs, bar gets *no* permissions to requests > builds in plague). Bar updates packages and sends foobar a note when > everything is ready. Foobar reviews the committed stuff and requests > build if everything is fine. If that worked fine for some update cycles > and some time in general bar gets fully sponsored and gets permissions > to requests builds. > Sounds like a good plan, except for one thing: -Assume I'm an evil bastard who wants to inject bad code into FE cvs -I say I want to unorphan a (few) package(s) and get sponsered -I update them (I've choosen easy ones) and request builds, sponsor is happy -In the mean time I also use my CVS access to inject some malwhere in a couple of much used often released packages. I circumvent the CVS change mails (yes thats possible, just hit ctrl-C at the right moment) -After some time the packages get build for one reason or another by their actual owner with my malware included. Then again I even have worries about this happening oneday with the current process. Thus what I do when I sponsor (sofar 2 people only) is look for other opensource contributions. If they have got CVS access to a couple of other projects they already have plenty chance to inject malware and thus probably wont (erm does that make sense?) But accept for the anove worries I like the idea in general. Actually I had the same idea before reading your mail :) Regards, Hans From j.w.r.degoede at hhs.nl Tue May 16 17:27:45 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 16 May 2006 19:27:45 +0200 Subject: Some ftp space for SRPM for review wanted In-Reply-To: References: <44683F37.8050509@hhs.nl> Message-ID: <446A0B91.9080505@hhs.nl> Gianluca Sforna wrote: > On 5/15/06, Hans de Goede wrote: >> I've some big packages which I plan on packaging soonish, so I will need >> a bit of diskspace (say upto 250 Mb) trafic will be low, as it will be >> used for posting SRPM's for review only. > > I am using intefree.it just because of this. Their (free) accounts > used to have unlimited http space (uploads via ftp only, but I handle > them gracefully with curl) though I am not really sure about their bw. > > Just contact me if you would like to apply for an account and need > help for understanding the registration form (italian only) > > Gianluca > Thanks for the offer and many thanks to all the others for their offers to. I have an account at atrpms now, which works well. Thanks again Axel, Hans From fedora at leemhuis.info Tue May 16 17:51:39 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 19:51:39 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <446A0AC8.2080601@hhs.nl> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <1147795358.2270.8.camel@localhost.localdomain> <446A0AC8.2080601@hhs.nl> Message-ID: <1147801899.2270.24.camel@localhost.localdomain> Am Dienstag, den 16.05.2006, 19:24 +0200 schrieb Hans de Goede: > > Thorsten Leemhuis wrote: > > Am Dienstag, den 16.05.2006, 09:41 +0200 schrieb Thorsten Leemhuis: > >> Am Montag, den 15.05.2006, 13:14 -0500 schrieb Jason L Tibbitts III: > Sounds like a good plan, except for one thing: > -Assume I'm an evil bastard who wants to inject bad code into FE cvs > -I say I want to unorphan a (few) package(s) and get sponsered > -I update them (I've choosen easy ones) and request builds, sponsor is > happy > -In the mean time I also use my CVS access to inject some malwhere in a > couple of much used often released packages. I circumvent the CVS > change mails (yes thats possible, just hit ctrl-C at the right moment) > -After some time the packages get build for one reason or another by > their actual owner with my malware included. > But why use orphan package as the entry point to get CVS access to Extras to "inject some malwhere"? You can have CVS access already nearly just as easy: Just package something, get it approved and get yourself sponsored. That not that more difficult. > Then again I even have worries about this happening oneday with the > current process. [...] Yeah, we might have grown so far that we need to limit access in CVS a bit more. We probably need to "add layers of control and management and procedures" to make everything more safe. CU thl -- Thorsten Leemhuis From ndbecker2 at gmail.com Tue May 16 19:05:18 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 16 May 2006 15:05:18 -0400 Subject: question on Individual Contributor License Agreement (CLA) Message-ID: I am about to send in CLA. I have cleared verbally with my employer legal, but I'm a bit stuck on one clause: 5. You represent that each of your Contributions is your original creation (see section 7 for submissions on behalf of others). You represent that your Contribution submission(s) include complete details of any third-party license or other restriction (including, but not limited to, related copyright, atents and trademarks) of which you are personally aware and which are associated with any part of your Contribution. In most cases, the work I submit will just be repackaging of other's work that is available from the net. (Actually I believe the vast majority of Fedora packages are in that category). So, it is not my 'original' work. For example, suppose there was a new browser, mudzilla, that is released under GPL. If I make an rpm package and submit it, I don't think section 5 applies, as it's not my creation. From jima at beer.tclug.org Tue May 16 19:09:50 2006 From: jima at beer.tclug.org (Jima) Date: Tue, 16 May 2006 14:09:50 -0500 (CDT) Subject: question on Individual Contributor License Agreement (CLA) In-Reply-To: References: Message-ID: On Tue, 16 May 2006, Neal Becker wrote: > In most cases, the work I submit will just be repackaging of other's work that > is available from the net. (Actually I believe the vast majority of Fedora > packages are in that category). So, it is not my 'original' work. > > For example, suppose there was a new browser, mudzilla, that is released under > GPL. If I make an rpm package and submit it, I don't think section 5 > applies, as it's not my creation. If repackaging other people's (legitimately open sourced) work violates Section 5 of the CLA, then I think most of our CLAs have been violated. Unless I'm entirely mistaken, MOST OF US just package other people's work. Jima From nicolas.mailhot at laposte.net Tue May 16 19:41:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 16 May 2006 21:41:14 +0200 Subject: question on Individual Contributor License Agreement (CLA) In-Reply-To: References: Message-ID: <1147808482.2440.75.camel@rousalka.dyndns.org> Le mardi 16 mai 2006 ? 14:09 -0500, Jima a ?crit : > On Tue, 16 May 2006, Neal Becker wrote: > > In most cases, the work I submit will just be repackaging of other's work that > > is available from the net. (Actually I believe the vast majority of Fedora > > packages are in that category). So, it is not my 'original' work. > > > > For example, suppose there was a new browser, mudzilla, that is released under > > GPL. If I make an rpm package and submit it, I don't think section 5 > > applies, as it's not my creation. > > If repackaging other people's (legitimately open sourced) work violates > Section 5 of the CLA, then I think most of our CLAs have been violated. > Unless I'm entirely mistaken, MOST OF US just package other people's work. What the CLA means is you take responsability for checking what you submit is legal. ie : 1. check licensing of source files 2. check licensing of any other material (spec example, scripts, images) you reuse in your package 3. agree to license whatever you provide yourself on top of this in a FE-compatible way -- 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 opensource at till.name Tue May 16 21:13:18 2006 From: opensource at till.name (Till Maas) Date: Tue, 16 May 2006 23:13:18 +0200 Subject: BuildRequires - flex and bison Message-ID: <200605162313.18593.opensource@till.name> Hiyas, do I need to add flex and bison as BuildRequires in a spec-file? http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not mention both as exceptions but the suggested configuration on http://fedoraproject.org/wiki/Extras/MockTricks includes both. Regards, Till From andreas.bierfert at lowlatency.de Tue May 16 21:24:46 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 16 May 2006 23:24:46 +0200 Subject: FESCo Nomination In-Reply-To: <1146763558.2859.17.camel@localhost.localdomain> References: <1145818390.2767.34.camel@localhost.localdomain> <1146763558.2859.17.camel@localhost.localdomain> Message-ID: <20060516232446.488e5aed@alkaid.a.lan> On Thu, 04 May 2006 12:25:57 -0500 "Tom 'spot' Callaway" wrote: > Well, let me throw my hat into the ring. Ok, here is my hat as well :)... take a look at the wiki page and read about me and if you have questions just go ahead an ask. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Tue May 16 21:32:43 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 16 May 2006 16:32:43 -0500 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147801899.2270.24.camel@localhost.localdomain> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <1147795358.2270.8.camel@localhost.localdomain> <446A0AC8.2080601@hhs.nl> <1147801899.2270.24.camel@localhost.localdomain> Message-ID: <1147815164.31467.18.camel@localhost.localdomain> On Tue, 2006-05-16 at 19:51 +0200, Thorsten Leemhuis wrote: > Yeah, we might have grown so far that we need to limit access in CVS a > bit more. We probably need to "add layers of control and management and > procedures" to make everything more safe. Err, careful. Personally I'd like to encourage more collective ownership in Extras. Locking things off would put a damper on this. What really needs to happen is simply make it impossible to bypass the commit emails. (Though something more along the lines of "Package Stewardship" seems more appropriate) http://c2.com/cgi/wiki?CodeStewardship -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 16 21:58:52 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 16 May 2006 16:58:52 -0500 Subject: package updates for in all repos at the same time (Was: Incoming: directfb soname problems) In-Reply-To: <20060514161919.3ab454cf.bugs.michael@gmx.net> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147599946.2924.25.camel@localhost.localdomain> <20060514131324.79e11d67.bugs.michael@gmx.net> <1147607413.18635.24.camel@localhost.localdomain> <20060514161919.3ab454cf.bugs.michael@gmx.net> Message-ID: <1147816734.31467.32.camel@localhost.localdomain> On Sun, 2006-05-14 at 16:19 +0200, Michael Schwendt wrote: > Before that becomes possible we will need a way to mark packages which > depend on eachother, so they are only pushed together. Plus a way to > prioritise build jobs and releases (not just with security fixes in mind). What could happen, is before moving packages out of needsign, repoclosure should be tested. Packages that break repo closure don't get let out. Once a full set of packages that don't break deps are sitting in needsign, they can be let out. Probably tricky to implement, but this would at least help prevent dep breakage in the repo. As signing packages is manual anyway, perhaps a repoclosure test could be run, and the packages to hold back are selected manually. (Or is this already done?) This still doesn't help when core breaks a dep though. (Galeon breaking everything when Mozilla is updated, for example. This is partially yum's fault, as the yum developers insist on making yum fail unless all repos are 100% perfect. Bleh.) Which is another reason to merge Extras and Core's build infrastructure... And does nothing about obscure new upstream bugs, but unless you can find an automatic way to detect them, you can't automatically prevent them anyway. (Unit tests) -------------- 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 Matt_Domsch at dell.com Tue May 16 22:01:10 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 16 May 2006 17:01:10 -0500 Subject: BuildRequires - flex and bison In-Reply-To: <200605162313.18593.opensource@till.name> References: <200605162313.18593.opensource@till.name> Message-ID: <20060516220110.GA6653@lists.us.dell.com> On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > Hiyas, > > do I need to add flex and bison as BuildRequires in a spec-file? > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > mention both as exceptions but the suggested configuration on > http://fedoraproject.org/wiki/Extras/MockTricks includes both. Both flex and bison are in the standard buildgroups, so they should not be listed as explicit BuildRequires in your spec file. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bugs.michael at gmx.net Tue May 16 23:26:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 17 May 2006 01:26:15 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <20060516220110.GA6653@lists.us.dell.com> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> Message-ID: <20060517012615.e5b3f5e3.bugs.michael@gmx.net> On Tue, 16 May 2006 17:01:10 -0500, Matt Domsch wrote: > On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > > Hiyas, > > > > do I need to add flex and bison as BuildRequires in a spec-file? > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > > mention both as exceptions but the suggested configuration on > > http://fedoraproject.org/wiki/Extras/MockTricks includes both. > > Both flex and bison are in the standard buildgroups, so they should > not be listed as explicit BuildRequires in your spec file. To be precise, they _need not_ be listed explicitly (see PackageReviewGuidelines). But it makes sense to list them. From j.w.r.degoede at hhs.nl Wed May 17 06:58:49 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 17 May 2006 08:58:49 +0200 Subject: sponsorship for package adoption without package submission (was Re: Claiming ownership for thinkpad related packages and pam_mount) In-Reply-To: <1147815164.31467.18.camel@localhost.localdomain> References: <200605131604.05348.opensource@till.name> <20060515.112531.81086309.kevin@scrye.com> <1147765300.2469.2.camel@thl.ct.heise.de> <1147795358.2270.8.camel@localhost.localdomain> <446A0AC8.2080601@hhs.nl> <1147801899.2270.24.camel@localhost.localdomain> <1147815164.31467.18.camel@localhost.localdomain> Message-ID: <446AC9A9.8080506@hhs.nl> Callum Lerwick wrote: > On Tue, 2006-05-16 at 19:51 +0200, Thorsten Leemhuis wrote: >> Yeah, we might have grown so far that we need to limit access in CVS a >> bit more. We probably need to "add layers of control and management and >> procedures" to make everything more safe. > > Err, careful. Personally I'd like to encourage more collective ownership > in Extras. Locking things off would put a damper on this. > > What really needs to happen is simply make it impossible to bypass the > commit emails. > +1 (+10 actually) As a sponsor I use the commit emails to monitor people I sponsored both for mistakes and unfortunatly also for bad intent. Unless my memory fails me I've sometime ago ctrl-C'd a cvs activity because I made a mistake. The changes however had already hit CVS, but due to the CTRl-C a commit mail never got send, thats bad! Regards, Hans From mpeters at mac.com Wed May 17 07:24:57 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 00:24:57 -0700 Subject: BuildRequires - flex and bison In-Reply-To: <20060517012615.e5b3f5e3.bugs.michael@gmx.net> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> Message-ID: <1147850698.20963.7.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 01:26 +0200, Michael Schwendt wrote: > On Tue, 16 May 2006 17:01:10 -0500, Matt Domsch wrote: > > > On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > > > Hiyas, > > > > > > do I need to add flex and bison as BuildRequires in a spec-file? > > > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > > > mention both as exceptions but the suggested configuration on > > > http://fedoraproject.org/wiki/Extras/MockTricks includes both. > > > > Both flex and bison are in the standard buildgroups, so they should > > not be listed as explicit BuildRequires in your spec file. > > To be precise, they _need not_ be listed explicitly (see > PackageReviewGuidelines). But it makes sense to list them. > It's certainly kinder to end users to list them, if the end user wants to rebuild the src.rpm with a custom patch or configure option. From rc040203 at freenet.de Wed May 17 07:27:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 17 May 2006 09:27:56 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <20060517012615.e5b3f5e3.bugs.michael@gmx.net> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> Message-ID: <1147850876.5280.70.camel@mccallum.corsepiu.local> On Wed, 2006-05-17 at 01:26 +0200, Michael Schwendt wrote: > On Tue, 16 May 2006 17:01:10 -0500, Matt Domsch wrote: > > > On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > > > Hiyas, > > > > > > do I need to add flex and bison as BuildRequires in a spec-file? > > > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > > > mention both as exceptions but the suggested configuration on > > > http://fedoraproject.org/wiki/Extras/MockTricks includes both. > > > > Both flex and bison are in the standard buildgroups, so they should > > not be listed as explicit BuildRequires in your spec file. > > To be precise, they _need not_ be listed explicitly (see > PackageReviewGuidelines). But it makes sense to list them. Facts, I consider to be defects of PackageReviewGuidelines. IMO, the only correct approach is to make explicitly listing them as BuildRequires mandatory, because having them in the defaults only adds bloat to mock, while only very few packages really use flex/bison. Ralf From michael at knox.net.nz Wed May 17 07:40:58 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 17 May 2006 19:40:58 +1200 Subject: unorphan... Message-ID: <446AD38A.6070108@knox.net.nz> I am going to unorphan the following unless there is any objection: duplicity gnofract4d Michael From paul at city-fan.org Wed May 17 07:45:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 17 May 2006 08:45:06 +0100 Subject: BuildRequires - flex and bison In-Reply-To: <1147850876.5280.70.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> Message-ID: <1147851906.1390.12.camel@laurel.intra.city-fan.org> On Wed, 2006-05-17 at 09:27 +0200, Ralf Corsepius wrote: > On Wed, 2006-05-17 at 01:26 +0200, Michael Schwendt wrote: > > On Tue, 16 May 2006 17:01:10 -0500, Matt Domsch wrote: > > > > > On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > > > > Hiyas, > > > > > > > > do I need to add flex and bison as BuildRequires in a spec-file? > > > > > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > > > > mention both as exceptions but the suggested configuration on > > > > http://fedoraproject.org/wiki/Extras/MockTricks includes both. > > > > > > Both flex and bison are in the standard buildgroups, so they should > > > not be listed as explicit BuildRequires in your spec file. > > > > To be precise, they _need not_ be listed explicitly (see > > PackageReviewGuidelines). But it makes sense to list them. > Facts, I consider to be defects of PackageReviewGuidelines. > > IMO, the only correct approach is to make explicitly listing them as > BuildRequires mandatory, because having them in the defaults only adds > bloat to mock, while only very few packages really use flex/bison. +1 The new buildsys-build package, which replaces the use of comps groups in the forthcoming version of mock from cvs, still has dependencies on flex and bison and will hence pull them in to the default buildroot. http://www.redhat.com/archives/fedora-extras-commits/2006-April/msg00850.html Any other packages in the list that shouldn't be? Paul. From fedora at leemhuis.info Wed May 17 08:11:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 17 May 2006 10:11:58 +0200 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <1147851906.1390.12.camel@laurel.intra.city-fan.org> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> Message-ID: <1147853518.2445.17.camel@thl.ct.heise.de> Am Mittwoch, den 17.05.2006, 08:45 +0100 schrieb Paul Howarth: > On Wed, 2006-05-17 at 09:27 +0200, Ralf Corsepius wrote: > +1 > > The new buildsys-build package, which replaces the use of comps groups > in the forthcoming version of mock from cvs, still has dependencies on > flex and bison and will hence pull them in to the default buildroot. > > http://www.redhat.com/archives/fedora-extras-commits/2006-April/msg00850.html > > Any other packages in the list that shouldn't be? /me looks at http://cvs.fedora.redhat.com/viewcvs/mock/buildsys-build.spec?root=fedora&view=markup -- no changes since the import Okay, I'd like to propose that we also remove the following packages from the list: automake15, automake, automake16, automake14, libtool, autoconf They shouldn't normally be needed for building and there are even some people that even say "you shall not use autoconf in spec files -- patch the sources instead". In any case, having them in the default buildroot sounds unnecessary to me. Or are there any good reason I'm not aware of? And I'm wondering why we need those (hints why we might need them appreciated): openssh-server doxygen indent byacc ctags gettext gdb createrepo perl-XML-* And we probably should synchronize it with the list we maintain at http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions For example: python and intltool (probably others) are in the default mock install, but not in the list from the wiki. perl on the other hand is. Is there a good reason for that behavior? CU thl /me is wondering if he should put this onto the agenda for the next FESCo meeting From rc040203 at freenet.de Wed May 17 08:28:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 17 May 2006 10:28:32 +0200 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <1147853518.2445.17.camel@thl.ct.heise.de> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> <1147853518.2445.17.camel@thl.ct.heise.de> Message-ID: <1147854512.5280.79.camel@mccallum.corsepiu.local> On Wed, 2006-05-17 at 10:11 +0200, Thorsten Leemhuis wrote: > Am Mittwoch, den 17.05.2006, 08:45 +0100 schrieb Paul Howarth: > > On Wed, 2006-05-17 at 09:27 +0200, Ralf Corsepius wrote: > > +1 > > > > The new buildsys-build package, which replaces the use of comps groups > > in the forthcoming version of mock from cvs, still has dependencies on > > flex and bison and will hence pull them in to the default buildroot. > > > > http://www.redhat.com/archives/fedora-extras-commits/2006-April/msg00850.html > > > > Any other packages in the list that shouldn't be? > > /me looks at > http://cvs.fedora.redhat.com/viewcvs/mock/buildsys-build.spec?root=fedora&view=markup > -- no changes since the import > > Okay, I'd like to propose that we also remove the following packages > from the list: > > automake15, automake, automake16, automake14, libtool, autoconf > > They shouldn't normally be needed for building and there are even some > people that even say "you shall not use autoconf in spec files -- patch > the sources instead". As I am amongst those, I fully agree with your proprosal above. > In any case, having them in the default buildroot > sounds unnecessary to me. Or are there any good reason I'm not aware of? There are some subtile dependencies between rpm/rpmbuild (read: packaging bugs in rpmbuild) and some other packages. One would have to check if these have still exist. > And I'm wondering why we need those (hints why we might need them > appreciated): > > openssh-server > doxygen > indent > byacc > ctags > gettext > gdb > createrepo > perl-XML-* Without having checked details, they are all superflous, IMO. Also cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183872 the responsible persons have preferred to ignore for many weeks. > And we probably should synchronize it with the list we maintain at > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > For example: python and intltool (probably others) are in the default > mock install, but not in the list from the wiki. perl on the other hand > is. Is there a good reason for that behavior? None that I am aware about. Neither python, perl nor intltool should be in there, unless they are rpm-required by some other tools. Ralf From jonathan.underwood at gmail.com Wed May 17 08:54:07 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 17 May 2006 09:54:07 +0100 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <1147853518.2445.17.camel@thl.ct.heise.de> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> <1147853518.2445.17.camel@thl.ct.heise.de> Message-ID: <645d17210605170154w3ff03271ob340d69a009be83f@mail.gmail.com> Thorsten - I notice over on fedora-devel-list that there's a cleanup of core packages going on based in the first phase upon getting all packages buildable in mock, with a longer term view of having core packages comply with the Extras guidelines: https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00308.html I suspect these proposed removals from the buildroot would be significant to these efforts (I could be wrong) - it might be worth discussing with those involved in the core cleanup? just a thought, apologies if it's way off beam, Jonathan From paul at city-fan.org Wed May 17 09:01:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 17 May 2006 10:01:06 +0100 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <1147854512.5280.79.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> <1147853518.2445.17.camel@thl.ct.heise.de> <1147854512.5280.79.camel@mccallum.corsepiu.local> Message-ID: <446AE652.8080607@city-fan.org> Ralf Corsepius wrote: > Neither python, perl nor intltool should be > in there, unless they are rpm-required by some other tools. perl is required by rpm-build, probably because the perl.prov/perl.req perl-dep-finding scripts are written in perl. WHilst it could be argued that these could be split off in to a subpackage to avoid the perl dep, that would break the (pretty good) auto-deps that rpm does for perl packages. The same doesn't yet apply to python but I could imagine it happening. Paul. From fedora at leemhuis.info Wed May 17 09:11:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 17 May 2006 11:11:32 +0200 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <645d17210605170154w3ff03271ob340d69a009be83f@mail.gmail.com> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> <1147853518.2445.17.camel@thl.ct.heise.de> <645d17210605170154w3ff03271ob340d69a009be83f@mail.gmail.com> Message-ID: <1147857093.3549.34.camel@thl.ct.heise.de> Am Mittwoch, den 17.05.2006, 09:54 +0100 schrieb Jonathan Underwood: > Thorsten - I notice over on fedora-devel-list that there's a cleanup > of core packages going on based in the first phase upon getting all > packages buildable in mock, with a longer term view of having core > packages comply with the Extras guidelines: > > https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00308.html > > I suspect these proposed removals from the buildroot would be > significant to these efforts (I could be wrong) - it might be worth > discussing with those involved in the core cleanup? Two of those involved are in FESCo, so they should notice. But I send all three involved a mail just to make sure that they do :) BTW, I added a item about this discussion to the FESCo schedule. We'll look at it in the next meeting. But we should continue to discuss it on the list until then. CU thl From bugzilla at redhat.com Wed May 17 10:52:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 17 May 2006 06:52:45 -0400 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200605171052.k4HAqjTL005319@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com Bug 180066 depends on bug 184199, which changed state. Bug 184199 Summary: It is not possible to build noarch ruby packages https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184199 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |RAWHIDE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From buildsys at fedoraproject.org Wed May 17 12:44:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 12:44:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-17 Message-ID: <20060517124409.16559.34868@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From buildsys at fedoraproject.org Wed May 17 12:44:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 12:44:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-17 Message-ID: <20060517124409.16564.444@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Wed May 17 12:44:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 12:44:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-17 Message-ID: <20060517124409.16551.9207@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 From buildsys at fedoraproject.org Wed May 17 12:44:10 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 12:44:10 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-17 Message-ID: <20060517124410.16565.19296@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 TeXmacs 1.0.6-6.fc6.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc TeXmacs 1.0.6-6.fc6.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 TeXmacs 1.0.6-6.fc6.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch pop-before-smtp 1.36-2.noarch swaks 20050709.1-5.fc6.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: tibbs AT math.uh.edu package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(Authen:DigestMD5) package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Authen:DigestMD5) package: swaks - 20050709.1-5.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(Authen:DigestMD5) ====================================================================== New report for: redhat AT flyn.org package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 ====================================================================== New report for: wtogami AT redhat.com package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) ====================================================================== New report for: tcallawa AT redhat.com package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 ====================================================================== New report for: matthias AT rpmforge.net package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 ====================================================================== package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: TeXmacs - 1.0.6-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) < 0:0.49 package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: TeXmacs - 1.0.6-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: TeXmacs - 1.0.6-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) < 0:0.49 From jkeating at redhat.com Wed May 17 14:46:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 May 2006 10:46:07 -0400 Subject: buildsys-build (Was Re: BuildRequires - flex and bison) In-Reply-To: <1147853518.2445.17.camel@thl.ct.heise.de> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147851906.1390.12.camel@laurel.intra.city-fan.org> <1147853518.2445.17.camel@thl.ct.heise.de> Message-ID: <1147877167.5295.3.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-05-17 at 10:11 +0200, Thorsten Leemhuis wrote: > > /me is wondering if he should put this onto the agenda for the next > FESCo meeting > Since this effects the packaging guidelines, which are not just Extras specific anymore, this really should be handled by more than just FESCO. I had hoped that yesterday's Fedora Board meeting would produce a governing body to handle package guidelines and such, and they would be responsible for acking or nacking this. /me will ping the board. -- 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 tcallawa at redhat.com Wed May 17 15:18:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 17 May 2006 10:18:06 -0500 Subject: BuildRequires - flex and bison In-Reply-To: <1147850876.5280.70.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> Message-ID: <1147879086.18341.10.camel@localhost.localdomain> On Wed, 2006-05-17 at 09:27 +0200, Ralf Corsepius wrote: > On Wed, 2006-05-17 at 01:26 +0200, Michael Schwendt wrote: > > On Tue, 16 May 2006 17:01:10 -0500, Matt Domsch wrote: > > > > > On Tue, May 16, 2006 at 11:13:18PM +0200, Till Maas wrote: > > > > Hiyas, > > > > > > > > do I need to add flex and bison as BuildRequires in a spec-file? > > > > > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires does not > > > > mention both as exceptions but the suggested configuration on > > > > http://fedoraproject.org/wiki/Extras/MockTricks includes both. > > > > > > Both flex and bison are in the standard buildgroups, so they should > > > not be listed as explicit BuildRequires in your spec file. > > > > To be precise, they _need not_ be listed explicitly (see > > PackageReviewGuidelines). But it makes sense to list them. > Facts, I consider to be defects of PackageReviewGuidelines. Err... looking at what PackageReviewGuidelines actually says: MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines; inclusion of those as BuildRequires is optional. Apply common sense. The only packages in the exceptions section are: bash bzip2 coreutils cpio diffutils fedora-release (and/or redhat-release) gcc gcc-c++ gzip make patch perl rpm-build redhat-rpm-config sed tar unzip Note the absense of bison or flex in that list. Thus, the Guidelines state that you should have BR: bison/flex if you need it to build. ~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 tibbs at math.uh.edu Wed May 17 15:35:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 17 May 2006 10:35:23 -0500 Subject: BuildRequires - flex and bison In-Reply-To: <1147879086.18341.10.camel@localhost.localdomain> (Tom Callaway's message of "Wed, 17 May 2006 10:18:06 -0500") References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: TC> Note the absense of bison or flex in that list. Thus, the TC> Guidelines state that you should have BR: bison/flex if you need TC> it to build. The fact that the default build group contains more than is in the exception list indicates that all of this testing currently happening on the Core packages is almost certainly missing a ton of BR:s that need to be there. - J< From orion at cora.nwra.com Wed May 17 15:41:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 17 May 2006 09:41:16 -0600 Subject: epydoc -> noarch transition problems In-Reply-To: <446A0A96.7070908@city-fan.org> References: <4468B807.7060203@cora.nwra.com> <446A08EC.7040908@shahms.com> <446A0A96.7070908@city-fan.org> Message-ID: <446B441C.80805@cora.nwra.com> Paul Howarth wrote: > Shahms King wrote: >> On top of that, the arch specific version is built for python 2.3 and as >> such, gets installed into entirely the wrong location. The >> epydoc-2.1-2.i386.rpm package really needs to be removed. What needs to >> be done to make this happen? > > http://fedoraproject.org/wiki/Extras/FC5Status > > Paul. > Was tried once to no apparent effect. Trying again. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rc040203 at freenet.de Wed May 17 16:02:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 17 May 2006 18:02:39 +0200 Subject: BuildRequires - flex and bison In-Reply-To: References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> Message-ID: <1147881759.5280.121.camel@mccallum.corsepiu.local> On Wed, 2006-05-17 at 10:35 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway writes: > > TC> Note the absense of bison or flex in that list. Thus, the > TC> Guidelines state that you should have BR: bison/flex if you need > TC> it to build. > > The fact that the default build group contains more than is in the > exception list indicates that all of this testing currently happening > on the Core packages is almost certainly missing a ton of BR:s that > need to be there. Not only Core, Extras also is suffering from the same defects: c.f. http://fedoraproject.org/buildgroups/5/i386/buildroots.xml [This is the default mock config] Ralf From splinux at fedoraproject.org Wed May 17 16:03:22 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Wed, 17 May 2006 18:03:22 +0200 Subject: Remove goupil in the FE system build Message-ID: Hello, I've made a bad package in the devel repos, i didn't want to do this :( Could you remove goupil of build system and extras cvs? Thanks in advance. Damien -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Wed May 17 16:42:30 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 17 May 2006 18:42:30 +0200 Subject: epydoc -> noarch transition problems In-Reply-To: <446B441C.80805@cora.nwra.com> References: <4468B807.7060203@cora.nwra.com> <446A08EC.7040908@shahms.com> <446A0A96.7070908@city-fan.org> <446B441C.80805@cora.nwra.com> Message-ID: <20060517184230.6142f931.bugs.michael@gmx.net> On Wed, 17 May 2006 09:41:16 -0600, Orion Poplawski wrote: > Paul Howarth wrote: > > Shahms King wrote: > >> On top of that, the arch specific version is built for python 2.3 and as > >> such, gets installed into entirely the wrong location. The > >> epydoc-2.1-2.i386.rpm package really needs to be removed. What needs to > >> be done to make this happen? > > > > http://fedoraproject.org/wiki/Extras/FC5Status > > > > Paul. > > > > Was tried once to no apparent effect. Trying again. Please don't. We're not stupid. http://fedoraproject.org/wiki/Extras/FC5Status?action=info http://fedoraproject.org/wiki/Extras/FC5Status?action=diff&rev2=142&rev1=141 From ville.skytta at iki.fi Wed May 17 17:05:59 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 17 May 2006 20:05:59 +0300 Subject: BuildRequires - flex and bison In-Reply-To: <1147881759.5280.121.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> Message-ID: <1147885560.2760.138.camel@localhost.localdomain> On Wed, 2006-05-17 at 18:02 +0200, Ralf Corsepius wrote: > Not only Core, Extras also is suffering from the same defects: > c.f. http://fedoraproject.org/buildgroups/5/i386/buildroots.xml > > [This is the default mock config] I wonder how those extra packages have crept there, the minimal set of packages assumed present in build roots has been documented and unchanged for years. From orion at cora.nwra.com Wed May 17 17:44:13 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 17 May 2006 11:44:13 -0600 Subject: epydoc -> noarch transition problems In-Reply-To: <20060517184230.6142f931.bugs.michael@gmx.net> References: <4468B807.7060203@cora.nwra.com> <446A08EC.7040908@shahms.com> <446A0A96.7070908@city-fan.org> <446B441C.80805@cora.nwra.com> <20060517184230.6142f931.bugs.michael@gmx.net> Message-ID: <446B60ED.1070608@cora.nwra.com> Michael Schwendt wrote: > Please don't. We're not stupid. > > http://fedoraproject.org/wiki/Extras/FC5Status?action=info > http://fedoraproject.org/wiki/Extras/FC5Status?action=diff&rev2=142&rev1=141 > Very sorry, just assumed that a push would have occurred already as they used to be very frequent. Will try to stop assuming... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From buildsys at fedoraproject.org Wed May 17 18:58:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 17 May 2006 14:58:04 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060517185804.D72FC152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 66 GeoIP-1.3.17-1.fc6 NetworkManager-vpnc-0.6.2-1.fc6 TeXmacs-1.0.6.1-4.fc6 adns-1.2-3.fc6 adplug-2.0-2.fc6 apt-0.5.15lorg3-2.1.fc6 aspell-he-1.0-1.fc6 bzflag-2.0.8-1.fc6 ccache-2.4-5.fc6 cernlib-2005-20.fc6 childsplay_plugins-0.80.8-1.fc6 contact-lookup-applet-0.14-3.fc6 cowbell-0.2.7.1-2.fc6 crossfire-1.9.0-4.fc6 crossfire-client-1.9.0-2 crossfire-maps-1.9.0-1.fc6 darcs-1.0.7-1.fc6 dejavu-fonts-2.6.0-1.fc6 fedora-package-config-smart-5.89-7 fedora-rpmdevtools-1.6-1.fc6 gaim-gaym-0.96-2.fc6 gauche-gtk-0.4.1-7.fc6 git-1.3.3-1.fc6 gpgme-1.1.2-4.fc6 gprolog-1.2.19-5.fc6 gtk2hs-0.9.10-1.fc6 gtklp-1.2.1-2.fc6 hspell-1.0-2.fc6 kchmviewer-2.0-4.fc6 liblo-0.23-4.fc6 liblrdf-0.4.0-6.fc6 libnasl-2.2.7-1.fc6 libnetfilter_conntrack-0.0.30-2.fc6 lyx-1.4.1-4.fc6 mftrace-1.2.4-1.fc6 mod_security-1.9.4-1.fc6 nagios-2.3.1-1.fc6 nessus-core-2.2.7-1.fc6 nessus-libraries-2.2.7-1.fc6 pan-0.97-2.fc6 pcsc-perl-1.4.3-1.fc6 perl-CSS-Tiny-1.11-1.fc6 perl-Expect-1.16-2.fc6 perl-Expect-Simple-0.02-1.fc6 perl-PPI-HTML-1.07-1.fc6 perl-Test-Differences-0.47-2.fc6 php-Smarty-2.6.13-1.fc6 phpldapadmin-0.9.8.3-1.fc6 pure-ftpd-1.0.21-5.fc6 python-adns-1.1.0-3.fc6 python-ctypes-0.9.9.6-1.fc6 python-matplotlib-0.87.2-2.fc6 python-mechanize-0.1.1a-2.fc6 rogue-5.4.2-6.fc6 shorewall-3.2.0-0.1.Beta7.fc6 spamass-milter-0.3.1-3.fc6 swaks-20050709.1-6.fc6 sylpheed-claws-2.2.0-1.fc6 torque-2.1.0p0-3.fc6 upx-2.00-2.fc6 wine-0.9.13-1.fc6 wine-docs-0.9.13-1.fc6 xarchon-0.50-2.fc6 xemacs-21.5.27-1.fc6 xemacs-sumo-20060510-2.fc6 xsp-1.1.15-1.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 17 18:58:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 17 May 2006 14:58:04 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060517185804.F0C3B15216D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 24 adplug-2.0-2.fc4 bzflag-2.0.8-1.fc4 fedora-rpmdevtools-1.6-1.fc4 gaim-gaym-0.96-2.fc4 gauche-gtk-0.4.1-7.fc4.1 git-1.3.3-1.fc4 gprolog-1.2.19-5.fc4 gtk2hs-0.9.10-1.fc4 gtklp-1.2.1-2.fc4 kchmviewer-2.0-4.fc4 libnasl-2.2.7-1.fc4 lyx-1.4.1-4.fc4 nagios-2.3.1-1.fc4 nessus-core-2.2.7-1.fc4 nessus-libraries-2.2.7-1.fc4 perl-Pod-Readme-0.081-2.fc4 perl-Test-Portability-Files-0.05-1.fc4 php-Smarty-2.6.13-1.fc4 python-ctypes-0.9.9.6-1.fc4 stellarium-0.8.0-3.fc4 swaks-20050709.1-5.fc4 swaks-20050709.1-6.fc4 vorbisgain-0.34-1.fc4 wine-0.9.13-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 17 18:58:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 17 May 2006 14:58:04 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060517185804.E715D15216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 33 adplug-2.0-2.fc5 bzflag-2.0.8-1.fc5 ccache-2.4-5.fc5 cernlib-2005-20.fc5 contact-lookup-applet-0.14-2.fc5 fedora-rpmdevtools-1.6-1.fc5 gaim-gaym-0.96-3.fc5 gauche-gtk-0.4.1-7.fc5 git-1.3.3-1.fc5 gprolog-1.2.19-5.fc5 gtk2hs-0.9.10-1.fc5 gtklp-1.2.1-2.fc5 kchmviewer-2.0-4.fc5 liblo-0.23-4.fc5 liblrdf-0.4.0-6.fc5 libnasl-2.2.7-1.fc5 lyx-1.4.1-4.fc5 nagios-2.3.1-1.fc5 nessus-core-2.2.7-1.fc5 nessus-libraries-2.2.7-1.fc5 pcsc-perl-1.4.3-1.fc5 perl-CSS-Tiny-1.11-1.fc5 perl-Expect-1.16-2.fc5 perl-Expect-Simple-0.02-1.fc5 perl-PPI-HTML-1.07-1.fc5 perl-Pod-Readme-0.081-2.fc5 perl-Test-Portability-Files-0.05-1.fc5 php-Smarty-2.6.13-1.fc5 python-ctypes-0.9.9.6-1.fc5 swaks-20050709.1-5.fc5 swaks-20050709.1-6.fc5 vorbisgain-0.34-2.fc5 wine-0.9.13-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 17 18:58:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 17 May 2006 14:58:05 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060517185805.0681115216E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 git-1.3.3-1.fc3 wine-0.9.13-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From notting at redhat.com Wed May 17 19:15:18 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 May 2006 15:15:18 -0400 Subject: Packaging guidelines: buildroot Message-ID: <20060517191518.GC24486@devserv.devel.redhat.com> So, in the guidelines, it states that all packages should use: %{_tmppath}/%{name}-%{version}-%{release}-%{%{__id_u} -n} What does this have to do with the package? Nothing. Why is this in the guidelines? Why are we putting this in spec files? All this does is give the developer a chance to manually enter information that they can get wrong. It's not like the build system will even use this value. Why isn't this the default for RPM, either patched into the default RPM package, or in redhat-rpm-config? Bill From skvidal at linux.duke.edu Wed May 17 19:29:02 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 May 2006 15:29:02 -0400 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: <1147894142.12565.4.camel@cutter> On Wed, 2006-05-17 at 15:15 -0400, Bill Nottingham wrote: > So, in the guidelines, it states that all packages should use: > > %{_tmppath}/%{name}-%{version}-%{release}-%{%{__id_u} -n} > > What does this have to do with the package? Nothing. > > Why is this in the guidelines? Why are we putting this in spec > files? All this does is give the developer a chance to manually > enter information that they can get wrong. It's not like the build > system will even use this value. > > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? we could also put it in the default .rpmmacros in mock. -sv From skvidal at linux.duke.edu Wed May 17 19:30:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 May 2006 15:30:46 -0400 Subject: BuildRequires - flex and bison In-Reply-To: <1147885560.2760.138.camel@localhost.localdomain> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> Message-ID: <1147894247.12565.6.camel@cutter> On Wed, 2006-05-17 at 20:05 +0300, Ville Skytt? wrote: > On Wed, 2006-05-17 at 18:02 +0200, Ralf Corsepius wrote: > > > Not only Core, Extras also is suffering from the same defects: > > c.f. http://fedoraproject.org/buildgroups/5/i386/buildroots.xml > > > > [This is the default mock config] > > I wonder how those extra packages have crept there, the minimal set of > packages assumed present in build roots has been documented and > unchanged for years. that's the set of packages I was given a while back for the default buildroot. Check the buildsys archives. I'm pretty sure it is from there. -sv From buildsys at fedoraproject.org Wed May 17 19:23:20 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 19:23:20 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-17 Message-ID: <20060517192320.30103.77621@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From buildsys at fedoraproject.org Wed May 17 19:23:20 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 19:23:20 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-17 Message-ID: <20060517192320.30105.64550@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Wed May 17 19:23:20 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 19:23:20 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-17 Message-ID: <20060517192320.30100.72870@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 From buildsys at fedoraproject.org Wed May 17 19:23:20 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 17 May 2006 19:23:20 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-17 Message-ID: <20060517192320.30108.63263@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 Sprog 0.14-11.fc5.noarch cpanspec 1.65-2.fc6.noarch diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 perl-Module-Build 0.2612-2.fc5.noarch perl-Module-Install 0.62-2.fc6.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc Sprog 0.14-11.fc5.noarch cpanspec 1.65-2.fc6.noarch diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc perl-Module-Build 0.2612-2.fc5.noarch perl-Module-Install 0.62-2.fc6.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 Sprog 0.14-11.fc5.noarch cpanspec 1.65-2.fc6.noarch diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 perl-Module-Build 0.2612-2.fc5.noarch perl-Module-Install 0.62-2.fc6.noarch pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: ghenry AT suretecsystems.com package: Sprog - 0.14-11.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) package: Sprog - 0.14-11.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) package: Sprog - 0.14-11.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) ====================================================================== New report for: tcallawa AT redhat.com package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 ====================================================================== New report for: steve AT silug.org package: perl-Module-Install - 0.62-2.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) >= 0:0.35 package: cpanspec - 1.65-2.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) package: perl-Module-Install - 0.62-2.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) >= 0:0.35 package: cpanspec - 1.65-2.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) package: cpanspec - 1.65-2.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) package: perl-Module-Install - 0.62-2.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) >= 0:0.35 ====================================================================== New report for: matthias AT rpmforge.net package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 ====================================================================== package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-i386 unresolved deps: perl(YAML) >= 0:0.35 perl(YAML) < 0:0.49 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-x86_64 unresolved deps: perl(YAML) >= 0:0.35 perl(YAML) < 0:0.49 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: perl-Module-Build - 0.2612-2.fc5.noarch from fedora-extras-development-ppc unresolved deps: perl(YAML) >= 0:0.35 perl(YAML) < 0:0.49 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 From peter at thecodergeek.com Wed May 17 19:33:38 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 17 May 2006 12:33:38 -0700 (PDT) Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: <48880.127.0.0.1.1147894418.squirrel@www.thecodergeek.com> Bill Nottingham wrote: > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? If you create your spec files from the fedora-newrpmspec tool (from the fedora-rpmdevtools package), then it automatically adds that as the BuildRoot. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From jkeating at redhat.com Wed May 17 19:44:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 May 2006 15:44:54 -0400 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: <1147895094.7823.20.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-05-17 at 15:15 -0400, Bill Nottingham wrote: > Why is this in the guidelines? Why are we putting this in spec > files? All this does is give the developer a chance to manually > enter information that they can get wrong. It's not like the build > system will even use this value. > > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? Perhaps because it is defined in just about every package I've ran across, and almost every different possible way. Should we instead say 'There should be no buildroot definition in the spec.' ? -- 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 paul at city-fan.org Wed May 17 19:45:58 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 17 May 2006 20:45:58 +0100 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: <1147895158.2403.1.camel@laurel.intra.city-fan.org> On Wed, 2006-05-17 at 15:15 -0400, Bill Nottingham wrote: > So, in the guidelines, it states that all packages should use: > > %{_tmppath}/%{name}-%{version}-%{release}-%{%{__id_u} -n} > > What does this have to do with the package? Nothing. > > Why is this in the guidelines? Why are we putting this in spec > files? All this does is give the developer a chance to manually > enter information that they can get wrong. It's not like the build > system will even use this value. > > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? If you take an SRPM with no BuildRoot: and try to build to build it as a regular user on just about any system it'll fail because nobody AFAIK currently ships an rpm package with a default buildroot. So even if it's fixed in rpm or mock, it'll be a while before it's safe to remove BuildRoot: tags if the packager wants any semblance of portability. Paul. From rdieter at math.unl.edu Wed May 17 19:46:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 May 2006 14:46:51 -0500 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: Bill Nottingham wrote: > So, in the guidelines, it states that all packages should use: > %{_tmppath}/%{name}-%{version}-%{release}-%{%{__id_u} -n} > > What does this have to do with the package? Nothing. ... > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? Setting a good/default %buildroot in redhat-rpm-config makes a lot of sense. -- Rex From mpeters at mac.com Wed May 17 20:02:27 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 13:02:27 -0700 Subject: Packaging guidelines: buildroot In-Reply-To: <48880.127.0.0.1.1147894418.squirrel@www.thecodergeek.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> <48880.127.0.0.1.1147894418.squirrel@www.thecodergeek.com> Message-ID: <1147896148.20963.17.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 12:33 -0700, Peter Gordon wrote: > Bill Nottingham wrote: > > Why isn't this the default for RPM, either patched into the default > > RPM package, or in redhat-rpm-config? > > If you create your spec files from the fedora-newrpmspec tool (from > the fedora-rpmdevtools package), then it automatically adds that as > the BuildRoot. I believe it does in emacs too - though I haven't created a virgin spec file in emacs in awhile (I just copy the templates from /usr/share/fedora/ ) From michael at knox.net.nz Wed May 17 20:03:20 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 18 May 2006 08:03:20 +1200 Subject: The "Summary - Broken dependencies" emails. Message-ID: <446B8188.8090008@knox.net.nz> Should bugs be filed against the packages with broken dependencies? I see the same packages appearing and wonder if a bug report or two would help get the package owners fixing the issues. Michael From mpeters at mac.com Wed May 17 20:04:30 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 13:04:30 -0700 Subject: Packaging guidelines: buildroot In-Reply-To: <1147895158.2403.1.camel@laurel.intra.city-fan.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> Message-ID: <1147896270.20963.20.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 20:45 +0100, Paul Howarth wrote: > > If you take an SRPM with no BuildRoot: and try to build to build it as a > regular user on just about any system it'll fail because nobody AFAIK > currently ships an rpm package with a default buildroot. So even if it's > fixed in rpm or mock, it'll be a while before it's safe to remove > BuildRoot: tags if the packager wants any semblance of portability. On the one hand, yes - on the other, the documentation isn't exactly difficult to find. From notting at redhat.com Wed May 17 20:06:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 May 2006 16:06:04 -0400 Subject: Packaging guidelines: buildroot In-Reply-To: <1147895158.2403.1.camel@laurel.intra.city-fan.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> Message-ID: <20060517200604.GA22917@devserv.devel.redhat.com> Paul Howarth (paul at city-fan.org) said: > > Why isn't this the default for RPM, either patched into the default > > RPM package, or in redhat-rpm-config? > > If you take an SRPM with no BuildRoot: and try to build to build it as a > regular user on just about any system it'll fail because nobody AFAIK > currently ships an rpm package with a default buildroot. So even if it's > fixed in rpm or mock, it'll be a while before it's safe to remove > BuildRoot: tags if the packager wants any semblance of portability. I see no reason why the default can't be pulled from the stock system RPM macros; in fact, that's the logical place for it, rather than per-package. Bill From paul at city-fan.org Wed May 17 20:10:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 17 May 2006 21:10:35 +0100 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517200604.GA22917@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> Message-ID: <1147896635.2403.8.camel@laurel.intra.city-fan.org> On Wed, 2006-05-17 at 16:06 -0400, Bill Nottingham wrote: > Paul Howarth (paul at city-fan.org) said: > > > Why isn't this the default for RPM, either patched into the default > > > RPM package, or in redhat-rpm-config? > > > > If you take an SRPM with no BuildRoot: and try to build to build it as a > > regular user on just about any system it'll fail because nobody AFAIK > > currently ships an rpm package with a default buildroot. So even if it's > > fixed in rpm or mock, it'll be a while before it's safe to remove > > BuildRoot: tags if the packager wants any semblance of portability. > > I see no reason why the default can't be pulled from the stock > system RPM macros; in fact, that's the logical place for it, > rather than per-package. Of course it is, but that doesn't help all the legacy/other distros that don't set the default in this way. If someone wants to rebuild a buildroot-less SRPM on such a system, they'll need to edit the spec file or their rpmmacros file, which in the case of end users trying to get a package working on their system is a whole extra layer of hassle. I'm all for setting a default buildroot in rpm but think that there should be a substantial grace period before the BuildRoot: tags are removed from packages en masse. Paul. From notting at redhat.com Wed May 17 20:17:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 May 2006 16:17:08 -0400 Subject: Packaging guidelines: buildroot In-Reply-To: <1147896635.2403.8.camel@laurel.intra.city-fan.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> <1147896635.2403.8.camel@laurel.intra.city-fan.org> Message-ID: <20060517201708.GC22917@devserv.devel.redhat.com> Paul Howarth (paul at city-fan.org) said: > Of course it is, but that doesn't help all the legacy/other distros that > don't set the default in this way. If someone wants to rebuild a > buildroot-less SRPM on such a system, they'll need to edit the spec file > or their rpmmacros file, which in the case of end users trying to get a > package working on their system is a whole extra layer of hassle. > > I'm all for setting a default buildroot in rpm but think that there > should be a substantial grace period before the BuildRoot: tags are > removed from packages en masse. So it could be something that's done in development going forward only; I don't see that as a big issue. You could argue that %clean is superfluous spec file noise as well. Bill From mpeters at mac.com Wed May 17 20:26:48 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 13:26:48 -0700 Subject: Packaging guidelines: buildroot In-Reply-To: <1147896635.2403.8.camel@laurel.intra.city-fan.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> <1147896635.2403.8.camel@laurel.intra.city-fan.org> Message-ID: <1147897609.20963.26.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 21:10 +0100, Paul Howarth wrote: > > Of course it is, but that doesn't help all the legacy/other distros that > don't set the default in this way. If someone wants to rebuild a > buildroot-less SRPM on such a system, they'll need to edit the spec file > or their rpmmacros file, which in the case of end users trying to get a > package working on their system is a whole extra layer of hassle. No one should ever build an RPM as root, so the end user should have either a clean buildsystem (ie mock/mach) or a ~/.rpmmacros file anyway. The shell script that sets it all up for the end user is fairly easy to find on the web if you do not already have it available in your distro. rebuilding an rpm is something that can always cause problems for those who do not know what they are doing (such as linking against libraries not in the rpm database, etc.) and for those having trouble, they _can_ rtfm. From mpeters at mac.com Wed May 17 20:33:10 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 13:33:10 -0700 Subject: The "Summary - Broken dependencies" emails. In-Reply-To: <446B8188.8090008@knox.net.nz> References: <446B8188.8090008@knox.net.nz> Message-ID: <1147897990.20963.34.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 08:03 +1200, Michael J. Knox wrote: > Should bugs be filed against the packages with broken dependencies? I > see the same packages appearing and wonder if a bug report or two would > help get the package owners fixing the issues. I believe they get an e-mail with each one. At least when I've had packages and the deps broke, I got an e-mail. In devel branch, sometimes fixing a package isn't so easy because devel branch has changed a version of a build dependency that breaks the build, or it doesn't build with the cflags, or it is broken on only one arch, and the packager is either waiting for upstream, or working on a patch themselves. Then again, sometimes all they need is a bump and rebuild. I wouldn't worry about broken devel branch packages too much unless it is needed by another package. Not until fc6 gets closer anyway. Broken fc3/4/5 packages should have bugs filed if they aren't already. From michael at knox.net.nz Wed May 17 20:44:57 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 18 May 2006 08:44:57 +1200 Subject: The "Summary - Broken dependencies" emails. In-Reply-To: <1147897990.20963.34.camel@atlantis.mpeters.local> References: <446B8188.8090008@knox.net.nz> <1147897990.20963.34.camel@atlantis.mpeters.local> Message-ID: <446B8B49.1020200@knox.net.nz> Michael A. Peters wrote: > On Thu, 2006-05-18 at 08:03 +1200, Michael J. Knox wrote: > >>Should bugs be filed against the packages with broken dependencies? I >>see the same packages appearing and wonder if a bug report or two would >>help get the package owners fixing the issues. > > > I believe they get an e-mail with each one. > At least when I've had packages and the deps broke, I got an e-mail. Good to know > In devel branch, sometimes fixing a package isn't so easy because devel > branch has changed a version of a build dependency that breaks the > build, or it doesn't build with the cflags, or it is broken on only one > arch, and the packager is either waiting for upstream, or working on a > patch themselves. Then again, sometimes all they need is a bump and > rebuild. > > I wouldn't worry about broken devel branch packages too much unless it > is needed by another package. Not until fc6 gets closer anyway. Sounds good to me. > Broken fc3/4/5 packages should have bugs filed if they aren't already. Ok, will do that (hopefully BZ will be in a better state today) Thanks! Michael From nicolas.mailhot at laposte.net Wed May 17 20:26:04 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 17 May 2006 22:26:04 +0200 Subject: Packaging guidelines: buildroot In-Reply-To: <1147896635.2403.8.camel@laurel.intra.city-fan.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> <1147896635.2403.8.camel@laurel.intra.city-fan.org> Message-ID: <1147897566.2244.15.camel@rousalka.dyndns.org> Le mercredi 17 mai 2006 ? 21:10 +0100, Paul Howarth a ?crit : > Of course it is, but that doesn't help all the legacy/other distros that > don't set the default in this way. If someone wants to rebuild a > buildroot-less SRPM on such a system, they'll need to edit the spec file > or their rpmmacros file, which in the case of end users trying to get a > package working on their system is a whole extra layer of hassle. You can solve this part easily by packaging the macro definition in a separate rpm for legacy distros (jpackage has been shipping its rpm macros in a separate package since before FC time) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Wed May 17 21:01:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 17 May 2006 23:01:18 +0200 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517191518.GC24486@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> Message-ID: <20060517210118.GB17312@neu.nirvana> On Wed, May 17, 2006 at 03:15:18PM -0400, Bill Nottingham wrote: > So, in the guidelines, it states that all packages should use: > > %{_tmppath}/%{name}-%{version}-%{release}-%{%{__id_u} -n} > > What does this have to do with the package? Nothing. > > Why is this in the guidelines? Why are we putting this in spec > files? All this does is give the developer a chance to manually > enter information that they can get wrong. It's not like the build > system will even use this value. > > Why isn't this the default for RPM, either patched into the default > RPM package, or in redhat-rpm-config? Makes sense, it will make an end to the fantasy of BuildRoot name inventes (like adding the uid ...). But what happens when a package has no BuildRoot and neither does a macro for it exist? Would it potentially eat the user's home? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed May 17 21:02:13 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 18 May 2006 00:02:13 +0300 Subject: Packaging guidelines: buildroot In-Reply-To: <1147897566.2244.15.camel@rousalka.dyndns.org> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> <1147896635.2403.8.camel@laurel.intra.city-fan.org> <1147897566.2244.15.camel@rousalka.dyndns.org> Message-ID: <1147899733.2760.157.camel@localhost.localdomain> On Wed, 2006-05-17 at 22:26 +0200, Nicolas Mailhot wrote: > You can solve this part easily by packaging the macro definition in a > separate rpm for legacy distros (jpackage has been shipping its rpm > macros in a separate package since before FC time) But the way those macros had to be injected into rpm's config so that they were actually visible anywhere was plain ugly [0], would have disappeared when the rpm or foo-rpm-config package was updated etc, so I don't think that's something that should be used as an example for anything but rather should be just forgotten. [0] In-place modification of non-%config rpmrc's here and there IIRC From notting at redhat.com Wed May 17 21:04:41 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 May 2006 17:04:41 -0400 Subject: Packaging guidelines: buildroot In-Reply-To: <20060517210118.GB17312@neu.nirvana> References: <20060517191518.GC24486@devserv.devel.redhat.com> <20060517210118.GB17312@neu.nirvana> Message-ID: <20060517210440.GC5289@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > Makes sense, it will make an end to the fantasy of BuildRoot name > inventes (like adding the uid ...). > > But what happens when a package has no BuildRoot and neither does a > macro for it exist? Would it potentially eat the user's home? rpmbuild: Fatal, no build root defined (I doubt it does this now...) Bill From pertusus at free.fr Wed May 17 22:24:25 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 18 May 2006 00:24:25 +0200 Subject: adding a page in wiki? Message-ID: <20060517222425.GA2399@free.fr> Hello, I would like to create a page similar with http://fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel but for core packages, to remove automatically from http://fedoraproject.org/wiki/Extras/PackageStatus?highlight=%28CategoryExtras%29#head-fc61f83902f24ae4168e91ba0f4017ddeccea83b the packages that have been obsoleted or merged in other packages. Maybe it could be called PackagesRemovedFromCore It should be also usefull for Core to document what happened to those packages, so I am not sure it should be in CategoryExtras wiki. Who should I contact, and also is there a coordination for the page names? -- Pat From Axel.Thimm at ATrpms.net Wed May 17 23:06:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 May 2006 01:06:10 +0200 Subject: Greedy install Message-ID: <20060517230610.GI17312@neu.nirvana> Hi, what's the best way to have as many packages as possible installed (given some special handling, e.g. no additional glibc/kernel)? E.g. how does on tell yum or any other tool "install fedora extras"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Wed May 17 23:14:27 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 17 May 2006 17:14:27 -0600 Subject: Greedy install In-Reply-To: <20060517230610.GI17312@neu.nirvana> References: <20060517230610.GI17312@neu.nirvana> Message-ID: <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> On 5/17/06, Axel Thimm wrote: > Hi, > > what's the best way to have as many packages as possible installed > (given some special handling, e.g. no additional glibc/kernel)? > E.g. how does on tell yum or any other tool "install fedora extras"? Does this do it? yum install ---disablerepo=\* --enablerepo=extras install \* > -- > Axel.Thimm at ATrpms.net > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From seg at haxxed.com Wed May 17 23:17:44 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 17 May 2006 18:17:44 -0500 Subject: Example mock config Message-ID: <1147907864.6731.5.camel@localhost> I figure this will be useful to others, I have documented my mock setup, oriented towards personal use and reviews, here: http://fedoraproject.org/wiki/CallumLerwick/MockHacking -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed May 17 23:26:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 May 2006 01:26:25 +0200 Subject: Greedy install In-Reply-To: <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> References: <20060517230610.GI17312@neu.nirvana> <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> Message-ID: <20060517232625.GJ17312@neu.nirvana> On Wed, May 17, 2006 at 05:14:27PM -0600, Stephen John Smoogen wrote: > On 5/17/06, Axel Thimm wrote: > >Hi, > > > >what's the best way to have as many packages as possible installed > >(given some special handling, e.g. no additional glibc/kernel)? > >E.g. how does on tell yum or any other tool "install fedora extras"? > > Does this do it? > yum install ---disablerepo=\* --enablerepo=extras install \* I guess in principle it should, but Error: oidentd conflicts with pidentd Error: Missing Dependency: php = 5.1.2 is needed by package syck-php Error: Missing Dependency: python < 0:2.4 is needed by package python-reportlab Error: Missing Dependency: xorg-x11-Xnest is needed by package sabayon-admin Error: compat-wxGTK2-devel conflicts with compat-wxGTK-devel Error: compat-wxGTK-devel conflicts with compat-wxGTK2-devel Error: Missing Dependency: php = 5.1.2 is needed by package php-eaccelerator Error: uw-imap-devel conflicts with libc-client-devel So one would not manually exclude the one and other package and get a maximum install (but it takes ages to compute, I'll do that tomorrow :). I wished yum had apt's auto-keeping-back feature when it comes to conflicts and other mismathces on the repo side. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Thu May 18 02:09:44 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 17 May 2006 19:09:44 -0700 Subject: comps comps-fe6.xml,1.2,1.3 In-Reply-To: <200605171526.k4HFQlsf028568@cvs-int.fedora.redhat.com> References: <200605171526.k4HFQlsf028568@cvs-int.fedora.redhat.com> Message-ID: <446BD768.5090805@thecodergeek.com> Michael Thomas (wart) wrote: > Modified Files: > comps-fe6.xml > Log Message: > Added crossfire client It was my understanding that we were supposed to add things to comps.xml.in, and not comps.xml (as it would be automagically be regenerated every so often or with a new package push). Is this the case or should we be also adding our packages to the .xml files too? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Thu May 18 03:00:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 May 2006 05:00:33 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <1147885560.2760.138.camel@localhost.localdomain> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> Message-ID: <1147921233.5280.129.camel@mccallum.corsepiu.local> On Wed, 2006-05-17 at 20:05 +0300, Ville Skytt? wrote: > On Wed, 2006-05-17 at 18:02 +0200, Ralf Corsepius wrote: > > > Not only Core, Extras also is suffering from the same defects: > > c.f. http://fedoraproject.org/buildgroups/5/i386/buildroots.xml > > > > [This is the default mock config] > > I wonder how those extra packages have crept there, the minimal set of > packages assumed present in build roots has been documented and > unchanged for years. I've always wondered why FE doesn't ship these files as local files inside of the mock rsp. as part of a "mock-fedora-config*.rpm" and instead forces users to pull them from the net. Also, I wonder, why FE5-mock/yum doesn't seem to process tags recursively anymore, which renders FE5-mock more or less nonfunctional ;) Ralf From skvidal at linux.duke.edu Thu May 18 04:52:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 May 2006 00:52:26 -0400 Subject: BuildRequires - flex and bison In-Reply-To: <1147921233.5280.129.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> Message-ID: <1147927946.14273.5.camel@cutter> On Thu, 2006-05-18 at 05:00 +0200, Ralf Corsepius wrote: > I've always wondered why FE doesn't ship these files as local files > inside of the mock rsp. as part of a "mock-fedora-config*.rpm" and > instead forces users to pull them from the net. so that they can be changed. to make sure people are building with something current. > Also, I wonder, why FE5-mock/yum doesn't seem to process > tags recursively anymore, which renders FE5-mock more or less > nonfunctional ;) read the buildsys-list, additionally russell harrison posted the explanation here earlier this week. -sv From pmatilai at laiskiainen.org Thu May 18 05:54:38 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 17 May 2006 22:54:38 -0700 (PDT) Subject: Packaging guidelines: buildroot In-Reply-To: <20060517210440.GC5289@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> <20060517210118.GB17312@neu.nirvana> <20060517210440.GC5289@devserv.devel.redhat.com> Message-ID: On Wed, 17 May 2006, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: >> Makes sense, it will make an end to the fantasy of BuildRoot name >> inventes (like adding the uid ...). >> >> But what happens when a package has no BuildRoot and neither does a >> macro for it exist? Would it potentially eat the user's home? > > rpmbuild: Fatal, no build root defined > > (I doubt it does this now...) IIRC it currently just tries to use / as buildroot if not defined anywhere, which is utterly nonsensible. It'd make perfect sense if it behaved like that: if no buildroot has been set in spec or macros, error out, and then specify a sane buildroot in the default macros. I requested this on rpm-list a few years ago but got shot down with "yes I agree but legacy "s. So yes, pretty please, my +10 for this. The current situation of people doing the right thing and using non / buildroot having to put in extra cruft in their specs is just silly. - Panu - From pmatilai at laiskiainen.org Thu May 18 06:06:23 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 17 May 2006 23:06:23 -0700 (PDT) Subject: Removing noise from specs Message-ID: Reminded by Bill's suggestion of putting the default buildroot into rpm default macro configuration instead of having to set in each and every spec, here's another long time wish of mine: Have rpm default to %defattr(-,root,root,-) in %files section(s). It's the right thing for most packages so it's really just noise in 90% of the specs, it's an endless source of silly packaging mistakes (forgetting to add it when splitting off a subpackage etc) and those who need special permissions can set them with their own %defattr/%attr use. Pretty please? - Panu - From notting at redhat.com Thu May 18 06:33:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 18 May 2006 02:33:52 -0400 Subject: Removing noise from specs In-Reply-To: References: Message-ID: <20060518063352.GA19240@devserv.devel.redhat.com> Panu Matilainen (pmatilai at laiskiainen.org) said: > > Reminded by Bill's suggestion of putting the default buildroot into rpm > default macro configuration instead of having to set in each and every > spec, here's another long time wish of mine: > > Have rpm default to %defattr(-,root,root,-) in %files section(s). It's the > right thing for most packages so it's really just noise in 90% of the > specs, it's an endless source of silly packaging mistakes (forgetting to > add it when splitting off a subpackage etc) and those who need special > permissions can set them with their own %defattr/%attr use. > > Pretty please? I'm all for it. Bill From rc040203 at freenet.de Thu May 18 06:55:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 May 2006 08:55:49 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <1147927946.14273.5.camel@cutter> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> Message-ID: <1147935349.5280.149.camel@mccallum.corsepiu.local> On Thu, 2006-05-18 at 00:52 -0400, seth vidal wrote: > On Thu, 2006-05-18 at 05:00 +0200, Ralf Corsepius wrote: > > > I've always wondered why FE doesn't ship these files as local files > > inside of the mock rsp. as part of a "mock-fedora-config*.rpm" and > > instead forces users to pull them from the net. > > so that they can be changed. to make sure people are building with > something current. If packaging them into the mock-rpm, yum/apt will keep them current. People with smaller bandwidth will appreciate this, because it will help avoid them having to download the stuff each time anew once they build a package. Also, I am not sure if the PackageGuideLines allow packages downloading documents from external sources. > > Also, I wonder, why FE5-mock/yum doesn't seem to process > > tags recursively anymore, which renders FE5-mock more or less > > nonfunctional ;) > > read the buildsys-list, additionally russell harrison posted the > explanation here earlier this week. I guess, you mean this: > To fix mock builds on a machine with yum 2.6+ find the line > "config_opts['buildgroup'] = 'build'" in each of your /etc/mock/*.cfg > files and change it to "config_opts['buildgroup'] = 'build > build-minimal build-base'". A very clear description of a work around on severe regression in mock/yum. I think it now should be your task to fix the bugs in the packages you maintain instead of pushing all users to work around the bugs. TIA. Ralf From jamatos at fc.up.pt Thu May 18 07:22:22 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 18 May 2006 08:22:22 +0100 Subject: Greedy install In-Reply-To: <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> References: <20060517230610.GI17312@neu.nirvana> <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> Message-ID: <200605180822.23314.jamatos@fc.up.pt> On Thursday 18 May 2006 00:14, Stephen John Smoogen wrote: > Does this do it? > yum install ---disablerepo=\* --enablerepo=extras install \* Since Extras depend on Core I am unsure if this will work. OTHO if you enable Core+Updates you will get all Fedora. :-) > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator -- Jos? Ab?lio From pmatilai at laiskiainen.org Thu May 18 08:18:30 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 18 May 2006 01:18:30 -0700 (PDT) Subject: Packaging guidelines: buildroot In-Reply-To: <20060517201708.GC22917@devserv.devel.redhat.com> References: <20060517191518.GC24486@devserv.devel.redhat.com> <1147895158.2403.1.camel@laurel.intra.city-fan.org> <20060517200604.GA22917@devserv.devel.redhat.com> <1147896635.2403.8.camel@laurel.intra.city-fan.org> <20060517201708.GC22917@devserv.devel.redhat.com> Message-ID: On Wed, 17 May 2006, Bill Nottingham wrote: > Paul Howarth (paul at city-fan.org) said: >> Of course it is, but that doesn't help all the legacy/other distros that >> don't set the default in this way. If someone wants to rebuild a >> buildroot-less SRPM on such a system, they'll need to edit the spec file >> or their rpmmacros file, which in the case of end users trying to get a >> package working on their system is a whole extra layer of hassle. >> >> I'm all for setting a default buildroot in rpm but think that there >> should be a substantial grace period before the BuildRoot: tags are >> removed from packages en masse. > > So it could be something that's done in development going forward only; > I don't see that as a big issue. > > You could argue that %clean is superfluous spec file noise as well. Ah yes, that - while we're at it lets get rid of that noise as well. A related item, although not quite that straightforward, is 'rm -rf $RPM_BUILD_ROOT' at beginning of %install. There are some special cases where package build is broken in the sense that it installs stuff on the build-stage, OOo being a notable example. But those could be handled with a special --no-clean flag to %install or something. - Panu - From Axel.Thimm at ATrpms.net Thu May 18 11:14:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 May 2006 13:14:19 +0200 Subject: Greedy install In-Reply-To: <200605180822.23314.jamatos@fc.up.pt> References: <20060517230610.GI17312@neu.nirvana> <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> <200605180822.23314.jamatos@fc.up.pt> Message-ID: <20060518111419.GA14899@neu.nirvana> On Thu, May 18, 2006 at 08:22:22AM +0100, Jose' Matos wrote: > On Thursday 18 May 2006 00:14, Stephen John Smoogen wrote: > > Does this do it? > > yum install ---disablerepo=\* --enablerepo=extras install \* > > Since Extras depend on Core I am unsure if this will work. > OTHO if you enable Core+Updates you will get all Fedora. :-) I already have all of core by the hidden @everything install option. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu May 18 11:32:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 07:32:32 -0400 Subject: Removing noise from specs In-Reply-To: References: Message-ID: <1147951952.2251.5.camel@ender> On Wed, 2006-05-17 at 23:06 -0700, Panu Matilainen wrote: > Have rpm default to %defattr(-,root,root,-) in %files section(s). It's > the > right thing for most packages so it's really just noise in 90% of the > specs, it's an endless source of silly packaging mistakes (forgetting > to > add it when splitting off a subpackage etc) and those who need > special > permissions can set them with their own %defattr/%attr use. > > Pretty please? +1 The more of this cryptic crap we can move into default macros the better. -- 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 rdieter at math.unl.edu Thu May 18 12:32:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 May 2006 07:32:20 -0500 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> Message-ID: Than Ngo (than) wrote: > Author: than > > Update of /cvs/extras/rpms/qt4/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22613/devel > > Modified Files: > .cvsignore sources > Added Files: > qt4.spec qtrc > Log Message: > auto-import qt4-4.1.2-1 on branch devel from qt4-4.1.2-1.src.rpm I call shenanigans! (: Extras import without Review is a no-no. Besides, review is currently underway: http://bugzilla.redhat.com/bugzilla/188180 (For which, btw, I've already put in a *lot* of work). -- Rex From paul at city-fan.org Thu May 18 12:37:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 13:37:01 +0100 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> Message-ID: <446C6A6D.7010100@city-fan.org> Rex Dieter wrote: > Than Ngo (than) wrote: >> Author: than >> >> Update of /cvs/extras/rpms/qt4/devel >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22613/devel >> >> Modified Files: >> .cvsignore sources Added Files: >> qt4.spec qtrc Log Message: >> auto-import qt4-4.1.2-1 on branch devel from qt4-4.1.2-1.src.rpm > > I call shenanigans! (: Extras import without Review is a no-no. > > Besides, review is currently underway: > http://bugzilla.redhat.com/bugzilla/188180 > (For which, btw, I've already put in a *lot* of work). +1 I think than's sponsor needs to have a quiet word about procedures. Paul. From rdieter at math.unl.edu Thu May 18 12:41:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 May 2006 07:41:01 -0500 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <446C6A6D.7010100@city-fan.org> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> Message-ID: Paul Howarth wrote: > Rex Dieter wrote: > >> Than Ngo (than) wrote: >> >>> Author: than >>> >>> Update of /cvs/extras/rpms/qt4/devel >>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22613/devel >>> >>> Modified Files: >>> .cvsignore sources Added Files: >>> qt4.spec qtrc Log Message: >>> auto-import qt4-4.1.2-1 on branch devel from qt4-4.1.2-1.src.rpm >> >> >> I call shenanigans! (: Extras import without Review is a no-no. >> >> Besides, review is currently underway: >> http://bugzilla.redhat.com/bugzilla/188180 >> (For which, btw, I've already put in a *lot* of work). > +1 > I think than's sponsor needs to have a quiet word about procedures. than at redhat.com is the kde-maintainer at redhat. Appears to be a simple mistake. No harm, no foul. -- Rex From dennis at ausil.us Thu May 18 13:17:46 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 18 May 2006 08:17:46 -0500 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> Message-ID: <200605180817.46646.dennis@ausil.us> On Thursday 18 May 2006 07:41, Rex Dieter wrote: > > than at redhat.com is the kde-maintainer at redhat. Appears to be a simple > mistake. No harm, no foul. Except this is not the first time than has done this. He did the same thing with koffice. I think that than needs a serious wrap over the knuckles on this he also needs to read http://fedoraproject.org/wiki/Extras/NewPackageProcess and make sure he is clear with the propper procedures. If he is not clear ask here. -- Dennis Gilmore, RHCE Proud Australian From nicolas.mailhot at laposte.net Thu May 18 13:23:10 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 18 May 2006 15:23:10 +0200 (CEST) Subject: Removing noise from specs In-Reply-To: References: Message-ID: <8421.192.54.193.51.1147958590.squirrel@rousalka.dyndns.org> Le Jeu 18 mai 2006 08:06, Panu Matilainen a ?crit : > > Reminded by Bill's suggestion of putting the default buildroot into rpm > default macro configuration instead of having to set in each and every > spec, here's another long time wish of mine: > > Have rpm default to %defattr(-,root,root,-) in %files section(s). It's the > right thing for most packages so it's really just noise in 90% of the > specs, it's an endless source of silly packaging mistakes (forgetting to > add it when splitting off a subpackage etc) and those who need special > permissions can set them with their own %defattr/%attr use. %defattr(0644,root,root,0755) would be less transparent but would force packagers to actually check the perms they need -- Nicolas Mailhot From jkeating at redhat.com Thu May 18 13:39:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 09:39:03 -0400 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200605180817.46646.dennis@ausil.us> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> <200605180817.46646.dennis@ausil.us> Message-ID: <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 08:17 -0500, Dennis Gilmore wrote: > Except this is not the first time than has done this. He did the same thing > with koffice. I think that than needs a serious wrap over the knuckles on > this he also needs to read > http://fedoraproject.org/wiki/Extras/NewPackageProcess and make sure he is > clear with the propper procedures. If he is not clear ask here. > As I was searching for this page, I realized, is this actually linked to from anywhere? Also, is there any way in MoinMoin to show what pages actually link to THIS page? -- 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 mpeters at mac.com Thu May 18 13:37:31 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 06:37:31 -0700 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200605180817.46646.dennis@ausil.us> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> <200605180817.46646.dennis@ausil.us> Message-ID: <1147959451.3186.18.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 08:17 -0500, Dennis Gilmore wrote: > On Thursday 18 May 2006 07:41, Rex Dieter wrote: > > > > than at redhat.com is the kde-maintainer at redhat. Appears to be a simple > > mistake. No harm, no foul. > Except this is not the first time than has done this. He did the same thing > with koffice. I think that than needs a serious wrap over the knuckles on > this he also needs to read > http://fedoraproject.org/wiki/Extras/NewPackageProcess and make sure he is > clear with the propper procedures. If he is not clear ask here. I don't know about qt4 - but I thought that at some point, there was a policy that allowed stuff moving from core to extras to be done without needing a proper review, which would be the case with koffice. From jamatos at fc.up.pt Thu May 18 13:38:33 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 18 May 2006 14:38:33 +0100 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <200605180817.46646.dennis@ausil.us> <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <200605181438.33578.jamatos@fc.up.pt> On Thursday 18 May 2006 14:39, Jesse Keating wrote: > On Thu, 2006-05-18 at 08:17 -0500, Dennis Gilmore wrote: > > Except this is not the first time than has done this. He did the same > > thing with koffice. I think that than needs a serious wrap over the > > knuckles on this he also needs to read > > http://fedoraproject.org/wiki/Extras/NewPackageProcess and make sure he > > is clear with the propper procedures. If he is not clear ask here. > > As I was searching for this page, I realized, is this actually linked to > from anywhere? 1) http://fedoraproject.org/ -> Extras 2) http://fedoraproject.org/wiki/Extras -> Extras/NewPackageProcess - How to get a new package into Extras 3) http://fedoraproject.org/wiki/Extras/NewPackageProcess > Also, is there any way in MoinMoin to show what pages > actually link to THIS page? I don't know. :-( -- Jos? Ab?lio From kevin.kofler at chello.at Thu May 18 13:39:45 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 18 May 2006 13:39:45 +0000 (UTC) Subject: BuildRequires - flex and bison References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > Also, I am not sure if the PackageGuideLines allow packages downloading > documents from external sources. Of course they do! >From the "Hey, let's remove Firefox, it 'downloads documents from external sources'!" dept., Kevin Kofler From jkeating at redhat.com Thu May 18 13:50:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 09:50:17 -0400 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200605181438.33578.jamatos@fc.up.pt> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <200605180817.46646.dennis@ausil.us> <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> <200605181438.33578.jamatos@fc.up.pt> Message-ID: <1147960217.14172.12.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 14:38 +0100, Jose' Matos wrote: > 1) http://fedoraproject.org/ -> Extras > 2) http://fedoraproject.org/wiki/Extras -> Extras/NewPackageProcess - > How to > get a new package into Extras > 3) http://fedoraproject.org/wiki/Extras/NewPackageProcess Ah, for some reason my eyes skipped over the larger text. *shrug* -- 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 jkeating at redhat.com Thu May 18 13:51:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 09:51:31 -0400 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1147959451.3186.18.camel@atlantis.mpeters.local> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> <200605180817.46646.dennis@ausil.us> <1147959451.3186.18.camel@atlantis.mpeters.local> Message-ID: <1147960291.14172.14.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 06:37 -0700, Michael A. Peters wrote: > I don't know about qt4 - but I thought that at some point, there was a > policy that allowed stuff moving from core to extras to be done without > needing a proper review, which would be the case with koffice. > Absolutely not. This was a common assumption that was flat wrong. Core package quality isn't even close to Extras in a lot of cases. ALL new packages to Extras (new as in never in Extras before) need to go through a review process. Said review process could be the same one that was done to get a new package into FC6+, just reference that review when filing the review bug. -- 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 fedora at camperquake.de Thu May 18 13:48:15 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 18 May 2006 15:48:15 +0200 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1147959451.3186.18.camel@atlantis.mpeters.local> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> <200605180817.46646.dennis@ausil.us> <1147959451.3186.18.camel@atlantis.mpeters.local> Message-ID: <20060518154815.7d833cf3@duras.int.addix.net> Hi. On Thu, 18 May 2006 06:37:31 -0700, Michael A. Peters wrote: > I don't know about qt4 - but I thought that at some point, there was a > policy that allowed stuff moving from core to extras to be done > without needing a proper review, which would be the case with koffice. This policy has been pulled, due to the sometimes less than stellar shape some core packages are in. From paul at city-fan.org Thu May 18 13:49:54 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 14:49:54 +0100 Subject: rpms/qt4/devel qt4.spec, NONE, 1.1 qtrc, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> References: <200605181133.k4IBXU1t022652@cvs-int.fedora.redhat.com> <446C6A6D.7010100@city-fan.org> <200605180817.46646.dennis@ausil.us> <1147959543.14172.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <446C7B82.1040704@city-fan.org> Jesse Keating wrote: > On Thu, 2006-05-18 at 08:17 -0500, Dennis Gilmore wrote: >> Except this is not the first time than has done this. He did the same thing >> with koffice. I think that than needs a serious wrap over the knuckles on >> this he also needs to read >> http://fedoraproject.org/wiki/Extras/NewPackageProcess and make sure he is >> clear with the propper procedures. If he is not clear ask here. >> > > As I was searching for this page, I realized, is this actually linked to > from anywhere? Also, is there any way in MoinMoin to show what pages > actually link to THIS page? Click on the "Extras/NewPackageProcess" link at the top of the page, just above the "This document is for existing Contributors only". It says that there are indeed no pages currently linking to that one. It's wrong though, because http://fedoraproject.org/wiki/Extras links to it quite prominently. Perhaps this is a manifestation of something like: http://moinmoin.wikiwikiweb.de/MoinMoinBugs/LinksWithTitlesNotIncludedInSearchResults Paul. From paul at city-fan.org Thu May 18 13:53:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 14:53:00 +0100 Subject: BuildRequires - flex and bison In-Reply-To: References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> Message-ID: <446C7C3C.5040701@city-fan.org> Kevin Kofler wrote: > Ralf Corsepius writes: >> Also, I am not sure if the PackageGuideLines allow packages downloading >> documents from external sources. > > Of course they do! >>From the "Hey, let's remove Firefox, it 'downloads documents from external > sources'!" dept., Methinks Ralf was referring to build-time downloading, not run-time downloading. Paul. From mpeters at mac.com Thu May 18 14:05:17 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 07:05:17 -0700 Subject: BuildRequires - flex and bison In-Reply-To: References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> Message-ID: <1147961118.3186.23.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 13:39 +0000, Kevin Kofler wrote: > Ralf Corsepius writes: > > Also, I am not sure if the PackageGuideLines allow packages downloading > > documents from external sources. > > Of course they do! > >From the "Hey, let's remove Firefox, it 'downloads documents from external > sources'!" dept., Since "content" isn't allowed, some apps must be allowed to do so. They should not do it as root, however. That's something to watch for with packages that use consolehelper. If they have a link to a website etc. from the menu, it launches the web browser as root - which is a bad thing. A really bad thing. firestarter was one such (since patched) package that did this. From rc040203 at freenet.de Thu May 18 14:10:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 May 2006 16:10:19 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <446C7C3C.5040701@city-fan.org> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> <446C7C3C.5040701@city-fan.org> Message-ID: <1147961419.5280.164.camel@mccallum.corsepiu.local> On Thu, 2006-05-18 at 14:53 +0100, Paul Howarth wrote: > Kevin Kofler wrote: > > Ralf Corsepius writes: > >> Also, I am not sure if the PackageGuideLines allow packages downloading > >> documents from external sources. > > > > Of course they do! > >>From the "Hey, let's remove Firefox, it 'downloads documents from external > > sources'!" dept., > > Methinks Ralf was referring to build-time downloading, not run-time > downloading. Me was referring to unattended background downloads of data files (configuration- files, data files, text files). Concerns along the lines "What puts mock into a special position" that it is allowed to automatically pull *config* files unsupervised from a remote location: Wrt. this, I don't see how mock is any different from * applications contacting a remote counter each time they start up. * games loading their game data from a remote file. * applications dynamically installing plug ins from remote. ... Another concern are usability (fedoraproject.org bottlenecking mock), and security. Ralf From skvidal at linux.duke.edu Thu May 18 14:16:38 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 May 2006 10:16:38 -0400 Subject: BuildRequires - flex and bison In-Reply-To: <1147961419.5280.164.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> <446C7C3C.5040701@city-fan.org> <1147961419.5280.164.camel@mccallum.corsepiu.local> Message-ID: <1147961798.3167.18.camel@cutter> On Thu, 2006-05-18 at 16:10 +0200, Ralf Corsepius wrote: > On Thu, 2006-05-18 at 14:53 +0100, Paul Howarth wrote: > > Kevin Kofler wrote: > > > Ralf Corsepius writes: > > >> Also, I am not sure if the PackageGuideLines allow packages downloading > > >> documents from external sources. > > > > > > Of course they do! > > >>From the "Hey, let's remove Firefox, it 'downloads documents from external > > > sources'!" dept., > > > > Methinks Ralf was referring to build-time downloading, not run-time > > downloading. > Me was referring to unattended background downloads of data files > (configuration- files, data files, text files). > > Concerns along the lines "What puts mock into a special position" that > it is allowed to automatically pull *config* files unsupervised from a > remote location: > > Wrt. this, I don't see how mock is any different from > * applications contacting a remote counter each time they start up. > * games loading their game data from a remote file. > * applications dynamically installing plug ins from remote. > ... > > Another concern are usability (fedoraproject.org bottlenecking mock), > and security. That's like saying that yum should ship with all the metadata it will ever need b/c it shouldn't be allowed to download files from the network. mock isn't downloading anything special, yum, being used by mock, is. -sv From rc040203 at freenet.de Thu May 18 14:29:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 May 2006 16:29:45 +0200 Subject: BuildRequires - flex and bison In-Reply-To: <1147961798.3167.18.camel@cutter> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> <446C7C3C.5040701@city-fan.org> <1147961419.5280.164.camel@mccallum.corsepiu.local> <1147961798.3167.18.camel@cutter> Message-ID: <1147962585.5280.171.camel@mccallum.corsepiu.local> On Thu, 2006-05-18 at 10:16 -0400, seth vidal wrote: > On Thu, 2006-05-18 at 16:10 +0200, Ralf Corsepius wrote: > > On Thu, 2006-05-18 at 14:53 +0100, Paul Howarth wrote: > > > Kevin Kofler wrote: > > > > Ralf Corsepius writes: > > > >> Also, I am not sure if the PackageGuideLines allow packages downloading > > > >> documents from external sources. > > > > > > > > Of course they do! > > > >>From the "Hey, let's remove Firefox, it 'downloads documents from external > > > > sources'!" dept., > > > > > > Methinks Ralf was referring to build-time downloading, not run-time > > > downloading. > > Me was referring to unattended background downloads of data files > > (configuration- files, data files, text files). > > > > Concerns along the lines "What puts mock into a special position" that > > it is allowed to automatically pull *config* files unsupervised from a > > remote location: > > > > Wrt. this, I don't see how mock is any different from > > * applications contacting a remote counter each time they start up. > > * games loading their game data from a remote file. > > * applications dynamically installing plug ins from remote. > > ... > > > > Another concern are usability (fedoraproject.org bottlenecking mock), > > and security. > > That's like saying that yum should ship with all the metadata it will > ever need b/c it shouldn't be allowed to download files from the > network. Yum is *SPECIAL* > mock isn't downloading anything special, yum, being used by mock, is. mock is an arbitrary application. Ralf From skvidal at linux.duke.edu Thu May 18 14:42:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 May 2006 10:42:43 -0400 Subject: BuildRequires - flex and bison In-Reply-To: <1147962585.5280.171.camel@mccallum.corsepiu.local> References: <200605162313.18593.opensource@till.name> <20060516220110.GA6653@lists.us.dell.com> <20060517012615.e5b3f5e3.bugs.michael@gmx.net> <1147850876.5280.70.camel@mccallum.corsepiu.local> <1147879086.18341.10.camel@localhost.localdomain> <1147881759.5280.121.camel@mccallum.corsepiu.local> <1147885560.2760.138.camel@localhost.localdomain> <1147921233.5280.129.camel@mccallum.corsepiu.local> <1147927946.14273.5.camel@cutter> <1147935349.5280.149.camel@mccallum.corsepiu.local> <446C7C3C.5040701@city-fan.org> <1147961419.5280.164.camel@mccallum.corsepiu.local> <1147961798.3167.18.camel@cutter> <1147962585.5280.171.camel@mccallum.corsepiu.local> Message-ID: <1147963364.3167.23.camel@cutter> On Thu, 2006-05-18 at 16:29 +0200, Ralf Corsepius wrote: > On Thu, 2006-05-18 at 10:16 -0400, seth vidal wrote: > > On Thu, 2006-05-18 at 16:10 +0200, Ralf Corsepius wrote: > > > On Thu, 2006-05-18 at 14:53 +0100, Paul Howarth wrote: > > > > Kevin Kofler wrote: > > > > > Ralf Corsepius writes: > > > > >> Also, I am not sure if the PackageGuideLines allow packages downloading > > > > >> documents from external sources. > > > > > > > > > > Of course they do! > > > > >>From the "Hey, let's remove Firefox, it 'downloads documents from external > > > > > sources'!" dept., > > > > > > > > Methinks Ralf was referring to build-time downloading, not run-time > > > > downloading. > > > Me was referring to unattended background downloads of data files > > > (configuration- files, data files, text files). > > > > > > Concerns along the lines "What puts mock into a special position" that > > > it is allowed to automatically pull *config* files unsupervised from a > > > remote location: > > > > > > Wrt. this, I don't see how mock is any different from > > > * applications contacting a remote counter each time they start up. > > > * games loading their game data from a remote file. > > > * applications dynamically installing plug ins from remote. > > > ... > > > > > > Another concern are usability (fedoraproject.org bottlenecking mock), > > > and security. > > > > That's like saying that yum should ship with all the metadata it will > > ever need b/c it shouldn't be allowed to download files from the > > network. > Yum is *SPECIAL* > > > mock isn't downloading anything special, yum, being used by mock, is. > mock is an arbitrary application. mock is an arbitrary application which is specifically calling yum. yum is downloading the files. so if yum is special then there's no problem here. -sv From wart at kobold.org Thu May 18 15:10:04 2006 From: wart at kobold.org (Wart) Date: Thu, 18 May 2006 08:10:04 -0700 Subject: comps comps-fe6.xml,1.2,1.3 In-Reply-To: <446BD768.5090805@thecodergeek.com> References: <200605171526.k4HFQlsf028568@cvs-int.fedora.redhat.com> <446BD768.5090805@thecodergeek.com> Message-ID: <446C8E4C.6010101@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Gordon wrote: > Michael Thomas (wart) wrote: > >> Modified Files: >> comps-fe6.xml Log Message: >> Added crossfire client > > > It was my understanding that we were supposed to add things to > comps.xml.in, and not comps.xml (as it would be automagically be > regenerated every so often or with a new package push). > > Is this the case or should we be also adding our packages to the .xml > files too? No, you should be adding them to the .in file only. I wasn't being careful when I made this change... - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEbI5IDeYlPfs40g8RAqFXAJ40tWfTij+J7WofNHLBc+GerPNe2gCbBIaJ RcUY9uwFdzGJKwvItm5CPsA= =Nwz2 -----END PGP SIGNATURE----- From paul at city-fan.org Thu May 18 15:12:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 16:12:04 +0100 Subject: Virtuals for webserver and fastcgi Message-ID: <446C8EC4.5010807@city-fan.org> I'm preparing a package for mod_fcgid, which is a GPL-ed mod_fastcgi replacement for Apache httpd. There is also an existing review request for fcgi (#182440), which provides a server-agnostic FastCGI capability. I can envisage, at some point in the future, that people might want to package up FastCGI applications and might want to add a suitable dependency for a FastCGI-capable server, akin to the existing "webserver" provide. Any suggestions for what, if any, that should be? Some possibilities: Provides: webserver(fastcgi) Provides: webserver-fastcgi Provides: fastcgi Any others? Any preferences? Paul. From fedora at leemhuis.info Thu May 18 15:40:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 May 2006 17:40:01 +0200 Subject: Summary from the last weeks FESCo meeting Message-ID: <1147966802.2264.4.camel@localhost.localdomain> == Summary == Present from FESco -- scop, warren, mschwendt, skvidal, jpo, skvidal * Weekly sponsorship nomination * we need more reviewers. * "Education" is key to getting more reviewers. * tibbs and warren will improve the docs in the wiki * Incompatible package upgrade policy * that's a old item in the schedule -- we didn't talk about this for months. See full log for details (19:21 - 19:47). But the problem isn't that big, so we don't need to hurry (this was before the directfb update happened) * Define rules how SIGs should work * also on the schedule for a long time already. It was agreed on that we don't want to define anything ATM. Just let them work as they like. We can revisit this later if we want/have to. * other discussions (see full log for details): * 19:02 permissions problems with the extras-push scripts should be fixed (mostly) * 19:51 what do people think about multiple maintainers for a single package?; lack of a proposal how to do it exactly * 19:52 emacsen/muse * 19:58 it is not possible to CC the fedora-security mailing list from bugzilla * 20:00 jwb> | thl, as far as the voting system goes... i have yet to hear anything back from Sopwith == Full log == {{{ 19:00 --- | thl has changed the topic to: FESCo meeting in progress 19:00 * | thl looks around 19:00 * | jima scurries away again 19:00 --- | Users 70 nicks 19:00 < mschwendt> | Note to all: FE repodata for 3|4|5|development has been recreated on the master server. Sync happening right now. -- The next push will break again, though, unless the remaining permission problems get fixed. ;) 19:01 < jpo> | thanks Michael 19:01 * | jima applauds mschwendt 19:01 * | thl sees scop, warren, mschwendt, skvidal, jpo -- anyone else from FESCo around? 19:02 < thl> | seems not 19:02 --- | thl has changed the topic to: FESCo meeting in progress - Broken deps report 19:02 < thl> | mschwendt, skvidal that's the status? does it run on buigl64 already? 19:03 < mschwendt> | no 19:03 < warren> | mschwendt, remaining permission problems? 19:03 < thl> | well, is there anything new that needs to be discussed? 19:04 < mschwendt> | warren: not for repoclosure script, but for the extras-push scripts 19:04 < thl> | mschwendt, or do we simply wait until you and skvidal find time for it 19:04 * | warren looks at extras64 19:05 < warren> | mschwendt, I fixed this again 2 days ago, who owned files that had wrong permissions today? 19:05 < mschwendt> | you and scop 19:05 < warren> | 644 and 755 permission? 19:05 < mschwendt> | extras-repobuild.py terminates with a bad shell exit code, which is not recognised by the push script 19:06 < mschwendt> | I've fixed this in CVS already and up'ped the scripts on the server 19:06 < mschwendt> | warren: see /tmp/repomd-cache 19:06 < warren> | mschwendt, btw, what do you use to upload scripts to the server? 19:06 < warren> | mschwendt, do you sync it from cvs, or just upload manually 19:06 < mschwendt> | I sync them 19:06 < warren> | how? 19:06 < scop> | FWIW, my last login to buildsys was two days ago, and IIRC I didn't even do a push back then 19:06 < mschwendt> | warren: cvs up from within extras_signers group 19:07 < warren> | ah 19:07 < mschwendt> | scop: these files are from May 7th and older! 19:07 < mschwendt> | repodata has NOT been created since then 19:09 < thl> | do you guys want to dicuss this further? 19:09 < thl> | or can we move on? 19:09 < mschwendt> | let's move 19:09 < mschwendt> | we have a separate list for this 19:09 < thl> | k 19:09 --- | thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination 19:09 < thl> | any new nominations? 19:09 < thl> | while on the topic: 19:10 < thl> | did evereyone notice the fedora-music-list and the plans to get lots of stuiff from Planet CCRMA into extras? 19:10 < thl> | that will probably a lot of reviewing work 19:10 < che> | thl, awesome though 19:11 < tibbs> | Yes, we need more reviewers. 19:11 < warren> | did we have any resolution on the alternative kernel thing? 19:11 < thl> | warren, that's more on the fab list currently 19:11 < warren> | And is he submitting everything through the review process like normal? 19:11 < noa> | thl, yup.. I'm wondering.. how is that intitiative related to what monty talked about over at fudcon? 19:11 < thl> | warren, it seems jack currently is the bottleneck 19:11 < warren> | who is jack? 19:12 * | skvidal just got back 19:12 < mschwendt> | a package in the queue 19:12 < noa> | jack is a real time audio pipeline 19:12 < thl> | jack-audio-connction-foo 19:12 < warren> | oh 19:12 < warren> | noa, Noa Resare? 19:12 < tibbs> | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183912 19:12 < noa> | warren, yup :) 19:12 < noa> | warren, long time 19:12 < warren> | noa, welcome back! You were one of our original contributors. 19:12 * | noa remembers setting up a bugzilla for fedora in the early days :) 19:13 < warren> | noa, still running with no security updates! =) 19:13 < thl> | noa, btw, I don't know "what monty talked about over at fudcon" 19:13 < noa> | unfortunatly I was sucked up in work and family life for a months 19:13 < thl> | noa, did I miss anything important? 19:14 < noa> | thl, it was one of the videos, it seems like he has gotten the task to design an audio daemon that will try to fix many of the problems with audio on linux 19:14 < warren> | noa, you came to Boston? 19:14 < warren> | thl, noa: I suspect this has nothing to do with what monty talked about. 19:14 < noa> | warren, no, i saw the videos over here in sweden 19:14 < warren> | ah 19:15 < thl> | noa, k 19:15 < thl> | anyway, back to the topic 19:15 < noa> | sorry :) 19:15 < thl> | tibbs> | Yes, we need more reviewers. 19:15 < thl> | that's IMHO one crucial point 19:15 < tibbs> | I'm trying to do at least two a day, but lately the list has been growing. 19:15 < che> | thl, what are the requirements for a reviewer? 19:15 < mschwendt> | thl: the problem with jack is not that we need more reviewers, but that it is not ready. Fernando has commented on the package already. 19:15 < thl> | and related to " Encourage Extras reviews " -- that's still on the schedule 19:16 < warren> | thl, adn again I say, "Education" is key to getting more reviewers. 19:16 < bpepple> | warren: +1 19:16 < thl> | warren, that's why I brought " Encourage Extras reviews " onto the table 19:16 < thl> | that's assigned to you warren 19:16 < thl> | you had plans to update the docs in the wiki 19:16 < tibbs> | che: you need cvsextras membership, which means package maintainership, which means sponsorship. 19:17 < warren> | unfortunately I've been unable to prioritize the necessary work to rewrite that entirely myself 19:17 < tibbs> | Well, fedorabugs membership, but cvsextras is the prerequisite for that. 19:17 < mschwendt> | tibbs: in short "you need a sponsor" -- package maintainership is not needed 19:17 < cweyl> | well, "anyone can review", if I recall correctly... it's the _approving_ part that requires cvsextras 19:17 < thl> | warren, any timeframe when to get this done? 19:17 < thl> | or is anyone else interested in improving our docs? 19:18 < warren> | I think it will be an incremental process, and I will need help. 19:19 < thl> | warren, could you find time to lay down a small and rough plan and ask for help on f-extrs-list? 19:19 < tibbs> | I'd like to help 19:19 < warren> | How about I work with tibbs. 19:19 < thl> | tibbs, can you take care of that together with warren? 19:19 < warren> | and we create a plan, and ask the list 19:19 < thl> | warren, tibbs, thx 19:20 < tibbs> | Sure. Email OK? 19:20 < warren> | okk 19:20 < thl> | k, then let's move on 19:20 < thl> | we'll see if we later if we need more reviews and/or sponsors for the stuff from Planet CCRMA 19:21 --- | thl has changed the topic to: FESCO Meeting -- Incompatible package upgrade policy 19:21 < thl> | warren, that's still on the schedule and assigned to you 19:21 < warren> | Have we really had problems with this? 19:21 < scop> | yes 19:22 < scop> | not recently AFAIK, though 19:22 < tibbs> | One came up last week. Let me think... 19:22 < warren> | I think "do the right thing" and improved tools to tell us when things break gives us a nice balance between freedom and control. 19:22 < thl> | improved tools sound like a good idea 19:22 < tibbs> | I think it was "pan", the newsreader. 19:23 * | mschwendt must leave for a few mins 19:23 < warren> | We need the ability to upgrade stuff, because that is the easiest way to fix problems sometimes. At the same time we need the tools to support this, and enforce rebuilding deps when you make such changes. 19:23 < thl> | I also dislike the plague part in each of the broken deps report for FC3 19:23 < scop> | tools tend to help within FE only 19:23 < scop> | thl, so poke the maintainer to do something about it? 19:23 < thl> | dcbw build plague for FC3 but the dep "createrepo >= foo" is not resolvable 19:24 < thl> | scop, such packages probably shouldn't even hit the repo 19:24 < thl> | (in an ideal world) 19:24 < scop> | right, but if something's broken, it needs to be fixed 19:25 < warren> | Idea 19:25 < scop> | "not liking" seeing someting in breakage reports doesn't help alone ;) 19:25 < thl> | scop, in the case of plague it would require a updated createrepo released as update from core 19:25 < thl> | scop, sure ;-) 19:25 < scop> | thl, I know, https://bugzilla.redhat.com/170531 19:25 < warren> | Should the package sign & push process resolve deps and exclude things that break deps? 19:25 < thl> | warren, yeah, maybe 19:27 < thl> | scop, thx, didn#t know there was a bug for it open 19:27 < thl> | warren, would that be possible and easy to do? 19:27 < noa> | warren, if there is a good mechanism for notifying the affected maintainers I think that would be good 19:28 < skvidal> | thl: no, it wouldn't be 19:28 < warren> | per-package CC lists that people can subscribe to would help 19:28 * | warren files that idea... 19:28 < scop> | but that's no substitute for a policy 19:29 < mschwendt> | thl: there is no way to withdraw a built package as it was made available to the build system already 19:29 < thl> | mschwendt, also true 19:30 < thl> | maye plague could check if all deps are resolved before pushing a package to the needsign repo 19:30 < thl> | or does that sound completely silly ? 19:30 < skvidal> | how about make the pkg owner check for closure before they push out a package 19:30 < tibbs> | You couldn't rebuild a dependency chain that way, could you? 19:31 < thl> | and is the problem big enough to discuss it? 19:31 < scop> | not completely silly, but something that could cause problems in complex build dependency chains 19:31 < thl> | scop, true 19:31 < mschwendt> | sounds like we need a QA Checklist again :) 19:32 < thl> | anyway, back to the original topic: Incompatible package upgrade policy 19:32 < scop> | no, we need that policy :) 19:32 < thl> | that what is written in the wiki: 19:32 < thl> | Seems like we need tools that will allows packagers to 1. notify others when the packager breaks something that others depend on; 2. notify the packager when he's about to break somwthing that others depend on. Warren is working on a proposal. 19:32 < thl> | anyone any idea how this could be done? 19:33 * | scop brb 19:33 < mschwendt> | if you are aware of your package's deps, why not mail the other package owners? 19:33 < warren> | Combination of written process and automated detection 19:34 < thl> | "automated detection" seems crucial 19:34 < jima> | mschwendt: i thought the problem was more not being aware of the dependency problem. 19:34 < jima> | thl: exactly. 19:34 < skvidal> | the problem will be two people submitting at the same time 19:34 < warren> | although skvidal has a good point 19:34 < skvidal> | you could make them both check for closure 19:35 < skvidal> | but due to their two pkgs coming out at the same time 19:35 < skvidal> | they'd have no way of knowing about new deps 19:35 < skvidal> | or the removal, thereof 19:36 < thl> | :-/ 19:36 < thl> | so what do we do? we ignored it for months already 19:36 < thl> | do we want to continue so? 19:37 < thl> | and try to fix the things one by one when they show up the next time? 19:37 < warren> | it hasn't been as much of a problem lately 19:37 < thl> | agreed 19:37 < tibbs> | Is it possible to track dependencies and alert maintainers when something new depends on their packages? 19:37 < jima> | oooo. 19:37 < mschwendt> | probably with a front-end for repoquery 19:38 < XulChris> | heya tibbs got your comments on my package, thanks 19:38 < warren> | basic building blocks like: per package CC list would allow otehr infrastructure to build on top of it. 19:38 < skvidal> | tibbs: and display it where? 19:38 < tibbs> | Email? Or just a command-line tool to list stuff that depends on me. 19:38 < tibbs> | It would at least tell me who I need to keep updated. 19:38 < skvidal> | tibbs: just add a command to the makefile system to look for what depends on their package 19:38 < jima> | i'd think email; there's probably no incentive/reminder to run the command. 19:39 < skvidal> | then they maybe could do: make whatrequires 19:39 < skvidal> | jima: right, b/c MORE email makes people pay attention 19:39 < skvidal> | 19:39 < tibbs> | Imagine you're Rex. All kinds of stuff is going to depend on Qt4 once it gets in, plus he has like 50 other packages. 19:39 < XulChris> | tibbs: your comments said my package didnt have a %check section, but it does 19:40 < tibbs> | XulChris: I'm prone to idiocy. Shoot me the bug #. 19:40 < thl> | well, I'll mention this discussion in the summary 19:40 < thl> | maybe some other people have an idea 19:40 < mschwendt> | Does repoquery have an option to examine _all_ dependencies? 19:41 < thl> | I'll leave it on the schedule for now 19:41 < |Jef|> | mschwendt: --alldeps 19:41 < mschwendt> | And this doesn't suffice? 19:41 < mschwendt> | Sure, one could evaluate owners.list, too, but why? 19:43 * | thl waits 15 more seconds for further input and will move on if nothing shows up 19:43 < |Jef|> | mschwendt: hmmm alldeps might not be what you want... "check non-explicit dependencies as well" may not mean "walk the dep tree" 19:43 --> | Eva42 (Unknown) has joined #fedora-extras 19:43 * | thl waits 20 seconds before moving on 19:43 < mschwendt> | Walking the entire dep tree is not needed 19:44 < mschwendt> | Just a beautified display of "my package is used by: A B C D" possibly with owners' email addr in brackets 19:44 < thl> | mschwendt, maybe we can have that in the planed web-interface 19:44 * | scop wants to note that no tool the packager can run will help with locally installed stuff or unconfigured 3rd party repos 19:44 < jima> | no, because the non-explicit deps should be handled when checking the explicit deps' dependencies. 19:44 < jima> | 12:43 < mschwendt> Walking the entire dep tree is not needed 19:44 < thl> | awjb had plans for one but didn#t work on it yet (afaik) 19:44 < jima> | irt that 19:45 < thl> | k, guys, let's forget about this topic for today and let's move on 19:46 < jima> | forget about what topic? 19:46 < thl> | jima, the "Incompatible package upgrade policy" 19:46 < jima> | thl: _what topic?_ (sorry...) 19:46 < warren> | It is a bit more complicated and difficult to fix than we can figure out during this meeting. 19:46 < thl> | warren, exactly 19:47 --- | thl has changed the topic to: FESCO meeting -- Define how SIGs should work 19:47 < thl> | that's still on the schedule 19:47 < tibbs> | The games SIG is running nicely. 19:47 < XulChris> | what does that mean? 19:47 < thl> | do we still want do to that or do we just proceed as currrently? 19:47 < XulChris> | ya i was just gonna say.. 19:48 < warren> | Aren't SIG's working fine now? 19:48 * | _wart_ thinks so 19:48 < XulChris> | well there is some confusion between the music SIG and "sound" SIG 19:48 < thl> | warren, they are, but we have no real "rules" how they should wroks 19:48 < thl> | work 19:48 < jima> | isn't "how do we start up a new SIG?" more the issue? :| 19:48 < thl> | the question is: do we need such rules? 19:49 < tibbs> | SIGs may start to overlap or conflict as more of them appear. 19:49 < _wart_> | thl: I don't think rules are necessary at this point. Things seem to be working fine without strict rules for now. 19:49 < warren> | thl, I've kind of been handling that. I've been demanding that each group write their Wiki page with goals and such before they get their mailing list. Games went through this. 19:49 < warren> | thl, so I could just write that down on the wiki. 19:49 < jima> | s/rules/guidelines/ ? 19:49 < tibbs> | FESCO may be asked to step in for conflicts, but without rules any decision will be treated as arbitrary. 19:50 * | thl needs to leave soon 19:50 < jima> | the process should probably be listed someplace (as warren said) 19:50 < warren> | I'll just write it down. 19:50 < thl> | warren, thx 19:50 < warren> | It is pretty clear to me, and it worked more than once. 19:50 * | jima stops interfering with the swift passage of the meeting. 19:50 --- | thl has changed the topic to: FESCO meeting -- Free discussion 19:50 <-- | Foolish has quit (Read error: 104 (Connection reset by peer)) 19:51 < thl> | anything else the needs to be discussed? 19:51 < jima> | thl: crap. now you're never gonna get out of here. ;) 19:51 < nirik> | anyone have thoughts on the muse/emacs namespace issues? 19:51 < XulChris> | when can we vote for fesco members? 19:51 < XulChris> | sorry if this was already discussed 19:51 < skvidal> | what do people think about multiple maintainers for a single package? 19:51 < skvidal> | either per-branch or just in general? 19:51 < thl> | XulChris, when the voting system is ready 19:51 < thl> | skvidal, we need co-maintainership 19:51 < skvidal> | ie: maintainer1 takes care of fc4 and f3, maintainer2 takes care of fc5 19:51 < che> | skvidal, good idea 19:51 < skvidal> | thl: is there anything stopping it? 19:52 < skvidal> | thl: any roadblocks we need to clear? 19:52 < thl> | skvidal, lack of a proposal how to do it exactly 19:52 < thl> | and support in owners.list 19:52 < thl> | guys, sorry, I have to leave now 19:52 < scop> | just use initial cc in owners.list 19:52 < nirik> | in reguards to emacsen/muse, proposal from jonathan: http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00297.html 19:52 < thl> | warren, can you handle the rest of the meeting please? 19:52 < che> | skvidal, id even say that it should be mandatory to have atleast 2 19:52 < tibbs> | Sponsorship needed for co-maintainers? 19:52 < skvidal> | okay so we need a mutliple-maintainers porposal and owner's list needs to be less crappy 19:52 < jwb> | skvidal, scop and i are already doing it 19:52 < che> | skvidal, what if one goes on holidays? 19:52 < jpo> | warren: can we still access the fedora.us tickets? 19:52 < skvidal> | che: I like holidays 19:53 < jima> | tibbs: err, they're contributors, so i'd think they'd need to be sponsored. 19:53 < che> | skvidal, me too... but what about updates/security patches etc 19:53 < skvidal> | I like holidays 19:53 < jima> | thl: have fun/good luck/whatever. :) 19:53 < jima> | i think everyone likes holidays. 19:53 < warren> | jpo, I'm wanting to archive the fedora.us tickets in static pages at the same URL, I need some help to do this. 19:53 < warren> | hoping noa will help, because he originally setup fedora.us bugzilla =) 19:53 < che> | skvidal, also you got a 4 eyes principle then for new builds 19:53 < che> | skvidal, cant hurt either 19:54 < jpo> | I was trying to find a couple of perl-Net-SSLeay tickets 19:54 * | thl afk now 19:54 < noa> | warren, I'll have a look at that that in a few days 19:54 < ixs> | warren: the bugzilla system is still running? small shellscript with wget and sed should be able to mirror that. Friend of mine did this many months back... 19:54 < jpo> | Help needed? 19:55 < skvidal> | che: I don't disagree - but I think requiring it for every package would be onerous 19:56 < che> | skvidal, well for every small packaged script it would be overhead probably. 19:56 < ixs> | skvidal: not to mention that it would probably mean too much work. 19:56 < che> | skvidal, for complex things -> defnitely. 19:57 < jpo> | warren: mail me if you need help to export the tickets 19:57 < che> | skvidal, also what if someone stops maintaining it... because of time reasons e.g. 19:57 --> | cwickert (Christoph Wickert) has joined #fedora-extras 19:57 < skvidal> | che: then they orphan it 19:57 < warren> | jpo, ok, I'll mail you and noa 19:57 < che> | skvidal, it would take some time for someone else to get into it etc... it would take time to find a new maintainer etc. 19:57 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras 19:57 < che> | skvidal, yeah... means its hanging around without updates and still gets built... 19:57 < che> | skvidal, dont think thats a really good approach though 19:57 < skvidal> | che: but nevertheless - I'd like to work to remove the roadblocks to multiple pkg owners 19:57 < skvidal> | so I'll see what I can do to get us a proposal and layout for owners.list 19:58 < scop> | can anyone identify those roadblocks? 19:58 < jpo> | warren: another problem 19:58 < jpo> | it is not possible to CC the fedora-security mailing list from bugzilla 19:58 < jwb> | skvidal, scop and i are already doing it 19:58 < che> | skvidal, good luck on it. i basically only see "pro" 19:58 < jwb> | skvidal, so what roadblocks? 19:58 < skvidal> | jwb: making it official 19:58 < warren> | jpo, who has admin access to the list? 19:59 < tibbs> | jpo: I asked about that yesterday on fedora-security-list but haven't seen a response yet. 19:59 < warren> | jpo, the list admin can create a bugzilla account without that admin mail hitting the list. He can read it in the moderation queue. 19:59 < warren> | jpo, only after the account is created can the list be added CC. 19:59 < jpo> | tibbs: I saw the archives a couple of minutes ago 19:59 < jpo> | warren: thks 20:00 < jwb> | thl, as far as the voting system goes... i have yet to hear anything back from Sopwith 20:00 < tibbs> | Anyone interested in writing PHP/PEAR packaging guidelines? 20:00 < jwb> | step 1) don't do it 20:00 * | jwb kids 20:01 < scop> | :) 20:01 < tibbs> | Several modules up for review, but lack of guidelines makes it tough to do a reasonable review. 20:01 * | jima doesn't volunteer 20:01 < XulChris> | php-pear > perl-* ;-) 20:01 < jima> | mainly because i don't especially care for php. :P 20:01 <-- | Anvil has quit (Remote closed the connection) 20:01 < XulChris> | maybe send an email to f-e-l about it? 20:01 < warren> | I move that we close this meeting. 20:01 < jwb> | seconded 20:01 < tibbs> | Nothing for me to add. 20:01 < ixs> | tibbs: php-review is a bitch. I tried doing a review of php-pear-mailparse but gave up as there are way too many different opinions of "ho to do it right"(tm) 20:02 --> | Anvil (Dona Nobis Pacem E Dona Eis Requiem) has joined #fedora-extras 20:02 < abadger1999> | (10:52:27) nirik: in reguards to emacsen/muse, proposal from jonathan: http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00297.html 20:02 < RemiFedora> | hi tibbs, i'm the "remi.collet" who submit this php-pear*.rpm 20:02 < abadger1999> | Did anyone have any comments on this? 20:02 < warren> | Meeting End. 20:02 < nirik> | abadger1999: we can possibly get it on the adgenda for next week? 20:02 < ixs> | tibbs: there are several possible ways of packaging the php stuff, I'd volunteer to work on guidelines if I'm supported by some other people. 20:02 < abadger1999> | nirik: Sounds god. 20:02 < tibbs> | emacsen-* seems distasteful, but I don't see how any proposal could be much better. 20:03 < jima> | ...and so Typo Hour in #fedora-extras begins. 20:03 < tibbs> | ixs: I'm willing to help a bit, but I'm no PHP expert. 20:03 < nirik> | yeah, I think emacsen is the best we can do... 20:03 < cweyl> | ixs: I'll be happy to lend a hand 20:03 < abadger1999> | tibbs: yeah... Debian has an emacsen-common for files shared between xemacs and emacs.... 20:03 < XulChris> | is there a php SIG? 20:03 < ixs> | tibbs: Great. Then I'll just put on the php-expert hat. ;-D 20:03 < ixs> | tibbs: anyone else? 20:03 < jpo> | scop: if you have a couple of minutes could you browse ticket #191351 20:04 < nirik> | of course that doesn't solve the muse issue... since there are potentially 2 other projects called that that could be packaged. 20:04 < nirik> | but it gets the emacsen one out of the way at least. :) 20:04 < scop> | jpo, will take a look tonight 20:04 < ixs> | XulChris: no php sig yet. 20:04 < jpo> | scop: thanks 20:04 --> | blippie (Noa Resare) has joined #fedora-extras 20:05 < scop> | I wonder if the bugzilla component name == srpm name rule is carved in stone 20:05 < ixs> | scop: it's been that way in the past. changing it sounds like a bad idea. 20:05 < ixs> | how else is one supposed to gather the component name from the rpm? 20:06 < ixs> | rpm -qi foo gives you the souce rpm name aka the component. 20:06 < scop> | I was more like thinking there could be both emacs-muse and xemacs-muse components in bugzilla 20:07 < scop> | if people are worried that xemacs-muse users can't find the emacs-muse component 20:07 < |Jef|> | scop: ill let you do that.. if we also have a component for each -devel subpackage too! 20:07 < warren> | We had talked about sub-package names being components in Bugzilla before. 20:07 < warren> | But I don't think it is a good idea. 20:07 < scop> | |Jef|, *I* am not worried about that 20:08 < warren> | |Jef|, each debuginfo package too =) 20:08 < |Jef|> | warren: sweet 20:08 < |Jef|> | warren: i wonder what bugzilla's limit is for component list length? 20:09 < |Jef|> | scop: i think its pretty silly to break that rule for xemacs subpackages... if it doesn't make sense to break that rule more generally 20:09 < scop> | what I find odd is that "emacs-muse" wouldn't work just fine as the component (and SRPM) name, but yet another one, emacsen-muse has to be invented 20:09 < scop> | |Jef|, I agree 20:09 < warren> | |Jef|, I'm not sure we want to make bugzilla go slower than it already does =) 20:10 < |Jef|> | warren: can it? 20:10 < blippie> | no, the low speed limit has been reached 20:10 < warren> | scop, I supported emacs-muse personally. 20:10 < nirik> | the name 'emacs' is kinda overloaded tho... most people think of gnu-emacs then... or at least I do... not the generic emacs term... 20:10 < ixs> | personally, I think emacsen sounds stupid. 20:10 < ixs> | why not name it foomacsfoo-muse. ;-D 20:11 <-- | has quit (Remote closed the connection) 20:13 < tibbs> | ixs: we can just start a wiki page for packaging guidelines. 20:13 < ixs> | tibbs: wiki/extras/PHPPackagingGuidelines 20:14 < ixs> | something like that? 20:14 < tibbs> | Probably wiki/Packaging/PHP to match Packaging/Perl and Packaging/Python 20:15 < ixs> | hmmm. sounds reasonable. 20:17 < ixs> | http://fedoraproject.org/wiki/Packaging/PHP done 20:17 < RemiFedora> | if i can. I think a great job have already be done on php-* rpm 20:17 --> | che_ (Che Guevara) has joined #fedora-extras 20:18 <-- | che has quit (Nick collision from services.) 20:18 < ixs> | RemiFedora: Your input would be greatly appreciated. Problem is, as I said above, there are way too many opinions on packaging php stuff, as can be seen on your review bugs. 20:18 --- | che_ is now known as che 20:18 < RemiFedora> | On bug 19066, 190252, 183359, 185423 20:19 < RemiFedora> | yes, i agree for the need of a guidelines. Buf for example, the use of /usr/share/pear/.pkgxml is now in the "core" php-pear. 20:22 < scop> | jpo, still here? 20:22 < jpo> | yes 20:22 < scop> | I'm wondering what kind of input are you looking for for the Net-SSLeay issue? 20:23 < dgilmore> | jpo i was wondering that also 20:23 < jpo> | A second opinion 20:24 < jpo> | if I should apply the patch to 1.26 20:24 < tibbs> | Is the patch destabilizing in some way, or does it break compatibility? 20:24 < jpo> | I don't think so (but have to look again) 20:25 < dgilmore> | jpo: do you have a bug# or the patch somewhere? 20:25 < scop> | https://bugzilla.redhat.com/191351 20:25 < jpo> | in the FC-5 and devel SRPM 20:27 < dgilmore> | jpo: cool i had only seen the email posted about it to fedora-security 20:28 < jpo> | I will try to ping the current module maintainer about it 20:28 < scop> | so the issue is that if $EGD_PATH is not defined in the environment, SSLeay reads some "entropy" from /tmp/entropy 20:28 <-- | noa has quit ("Leaving") 20:28 --- | blippie is now known as noa 20:28 < scop> | ...which can be created by anyone, thus injecting some known data into the seeding process 20:29 < scop> | ...right? 20:29 < jpo> | yep 20:29 < dgilmore> | scop: thats what it looks like to me 20:30 < scop> | see man RAND_egd (if you have openssl installed) 20:30 --> | Belegdol (Julian Sikorski) has joined #fedora-extras 20:30 < scop> | "On systems without /dev/*random devices providing entropy from the kernel, the EGD entropy gathering daemon can be used to collect entropy." 20:30 < scop> | also openssl FAQ: 20:31 <-- | Belegdol has quit (Read error: 104 (Connection reset by peer)) 20:31 --> | Belegdol (Julian Sikorski) has joined #fedora-extras 20:31 < scop> | "On systems without /dev/urandom and /dev/random, it is a good idea to use the Entropy Gathering Demon (EGD) ..." 20:31 < scop> | so the patch looks innocent enough to me 20:34 < jpo> | I will try to apply it to the FC-3 and FC-4 branches 20:34 < Belegdol> | hi. what rpm targets can be installed in i386 fedora? 20:35 < Belegdol> | i was able to install i686, but unable to install pentium4 20:35 < jpo> | sould I worry about old fedora.us FC-1 and FC-2 branches? 20:35 < jpo> | s/sould/should/ 20:35 < che> | Belegdol, rpm --eval %configure 20:35 < dgilmore> | jpo: looks ok to me the only othere way to do it would be to start the egd daemon with its socket at /tmp/entropy 20:36 < che> | Belegdol, thats what happens if you dont specify a target 20:36 < dgilmore> | jpo: ask warren but i dont think there is anyway to build and get the updates out 20:36 < jpo> | ok 20:36 --> | homeas (Thomas Vander Stichele) has joined #fedora-extras 20:36 < dgilmore> | skvidal: does the extras build system handle fc1 and fc2? 20:37 < scop> | dgilmore, ne 20:37 < skvidal> | nope 20:37 < scop> | s/ne/no/ 20:37 < warren> | jpo, don't worry about FC-1 and FC-2 20:37 < jpo> | thanks. }}} -- Thorsten Leemhuis From buildsys at fedoraproject.org Thu May 18 17:42:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 18 May 2006 13:42:42 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060518174242.9476415218A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 3 cernlib-2005-20.fc3 docbook2X-0.8.7-1.fc3 utrac-0.3.0-7.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 18 17:42:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 18 May 2006 13:42:42 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060518174242.8C7D4152189@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 9 GeoIP-1.3.17-1.fc4 cernlib-2005-20.fc4 darcs-1.0.7-1.fc4 docbook2X-0.8.7-1.fc4 dvb-apps-1.1.1-2.fc4 kchmviewer-2.5-1.fc4 scrip-1.4-5.fc4 tin-1.8.1-1.fc4 utrac-0.3.0-6.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 18 17:42:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 18 May 2006 13:42:42 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060518174242.804D0152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 10 GeoIP-1.3.17-1.fc5 darcs-1.0.7-1.fc5 docbook2X-0.8.7-1.fc5 dvb-apps-1.1.1-2.fc5 kchmviewer-2.5-1.fc5 libgalago-0.5.0-1.fc5 perl-Test-Expect-0.30-1.fc5 scrip-1.4-5.fc5 utrac-0.3.0-6.fc5 xarchon-0.50-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu May 18 17:42:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 18 May 2006 13:42:42 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060518174242.76168152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 15 conntrack-1.0-0.1.beta1.fc6 docbook2X-0.8.7-1.fc6 dvb-apps-1.1.1-1.fc6 dvb-apps-1.1.1-2.fc6 kchmviewer-2.5-1.fc6 libgalago-0.5.0-2.fc6 naim-0.11.8.2-4.fc6 net6-1.3.0-2.rc2.fc6 perl-Net-SNMP-5.2.0-1.fc6 perl-YAML-0.39-2.fc6 php-pear-DB-1.7.6-5 python-mechanize-0.1.1a-3.fc6 rafkill-1.2.1-1.fc6 scrip-1.4-5.fc6 utrac-0.3.0-6.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From thomas at apestaart.org Thu May 18 17:56:40 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 18 May 2006 19:56:40 +0200 Subject: Incoming: directfb soname problems In-Reply-To: <1147597879.2746.151.camel@localhost.localdomain> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147550560.26066.21.camel@otto.amantes> <1147597879.2746.151.camel@localhost.localdomain> Message-ID: <1147975000.4065.49.camel@otto.amantes> > > We don't have many packages like directfb afaik that chose to have a > > different so name for each release. > > That's not really relevant. It's the heart of the discussion we're having. DirectFB will cause this problem for extras for every release they ever make. So it is different from everything else in Fedora Extras that can be upgraded easily for every new release. > > when I asked on IRC, people felt it was enough > > to warn the affected maintainers. Which is what I did. > > I strongly disagree with that. The fundamental problem is that one > can't possibly reach the whole target audience. It seems you're suggesting that since I can't know who's using directfb outside of extras, I can't reach them. If that is a consideration, basically that means that we should never accept any update in Extras that breaks ABI/so name/compatibility. That would be a fine rule, but afaik we don't have it yet. I don't know if I would be for or against; but if it was a rule, I'd probably stop packaging directfb because it would become pointless to have it in extras at all. > Have the maintainers > ack'd that they will be able to ship updated packages shortly (or at > all) after your update hits the repos, for all affected distro versions? I sent a mail to ivazquez (evas packages) and anvil (xine and mplayer), and to hans de goede (because he's interested in directfb). I did not get any feedback from ivazquez or hans, an anvil told me he would rebuild livna packages when the directfb update would hit extras. Yes, I agree with you that ivazquez should give his OK. > Are you sure you mailed the correct individuals? No, I allow for the possibility of me having made a mistake :) Here's what I did. I ran: repoquery --alldeps --whatrequires directfb That gave me evas and ecore, as well as xine and mplayer. For evas and ecore, I checked the last %changelog author, as well as the owners.list file, and mailed ivazquez. For xine and mplayer, I contacted anvil. > Rhetorical: If not, > have all end users been notified what they need to do in the meantime? I don't know how to contact all end users. > If the answer to any of these is "no", this is a potential security > issue, which you're essentially willingly inflicting on users. You caught me - I was hoping to set up a new bot net after my old one got found out :) I'm going to reiterate that the "potential security issue" is something that IMO should really be fixed in the package manager. I think it's wrong to blame individual package maintainers for creating a potential security problem that is left there to be abused by the package manager of choice. The reasons I've heard for this IMO do not weigh up against the problem that *any* repository can create this way. > I didn't see immediate commits following the directfb one to affected FE > packages in the commits list, which already proves that as implemented, > this update was a failure even within FE. It sounds like you're saying that in practice everyone affected by the change should be making their commits at the exact same time ? That's doable for this package I guess, since it's only two people if you agree that only extras should be taken into account. > A real policy in FESCO's TODO list. Some members were skeptical whether > a policy is needed, but this reoccurring example probably serves as a > good case in point. I think this is being blown out of proportion. In extras, there are two packages affected. Both packages are part of the same functionality - getting Enlightenment stuff running. They've been in extras for three months. I doubt there is a wide installed base of people that have *both* directfb and enlightenment running, but I could be wrong. Anvil was willing to update his livna packages as soon as the update came out (FWIW, there is no good way of coordinating updates between extras and livna except for poking anvil. So there will always be a window in which the typical user's yum setup is temporarily "broken".) Am I missing something ? > I've temporarily moved the packages out of the needsign queue so the > update can be reconsidered (as a whole or partially), and if still > wanted, properly communicated before done. Well, I doubt you will have a lot of people asking for directfb on this list. There is a lot of stuff being packaged in extras, and not every user is on this list. DirectFB is a niche project. But for what it's worth, here's my request to put it back, and I will communicate the update to whoever you think I should communicate it to. If it's going to remain blocked for reasons mentioned above, that's fine as well, but then I'm better off dropping the package from Extras, since that would mean Extras is not the place to have this package. If effectively directfb can't be upgraded, there's no point in shipping it from Extras. Thomas From jima at beer.tclug.org Thu May 18 18:05:25 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 18 May 2006 13:05:25 -0500 (CDT) Subject: Removing noise from specs In-Reply-To: <8421.192.54.193.51.1147958590.squirrel@rousalka.dyndns.org> References: <8421.192.54.193.51.1147958590.squirrel@rousalka.dyndns.org> Message-ID: On Thu, 18 May 2006, Nicolas Mailhot wrote: > Le Jeu 18 mai 2006 08:06, Panu Matilainen a ?crit : >> >> Have rpm default to %defattr(-,root,root,-) in %files section(s). It's the >> right thing for most packages so it's really just noise in 90% of the >> specs, it's an endless source of silly packaging mistakes (forgetting to >> add it when splitting off a subpackage etc) and those who need special >> permissions can set them with their own %defattr/%attr use. > > %defattr(0644,root,root,0755) would be less transparent but would force > packagers to actually check the perms they need How is that a "but?" I'd consider it more of an "and." Shouldn't we be paying attention to permissions? (Although knowing my luck I'd get burned at least once by that change...) Jima From buildsys at fedoraproject.org Thu May 18 17:59:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 18 May 2006 17:59:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-18 Message-ID: <20060518175957.31585.35834@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Thu May 18 17:59:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 18 May 2006 17:59:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-18 Message-ID: <20060518175957.31589.56606@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 drgeo 1.1.0-7.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gnotime 2.2.2-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc drgeo 1.1.0-7.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gnotime 2.2.2-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 drgeo 1.1.0-7.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gnotime 2.2.2-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnotime - 2.2.2-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile.so.12 libguile-ltdl.so.1 libqthreads.so.12 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: drgeo - 1.1.0-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libguile-ltdl.so.1 libguile.so.12 libqthreads.so.12 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: drgeo - 1.1.0-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: gnotime - 2.2.2-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libguile.so.12()(64bit) libguile-ltdl.so.1()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) package: gnotime - 2.2.2-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile.so.12 libguile-ltdl.so.1 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: drgeo - 1.1.0-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libguile-ltdl.so.1 libguile.so.12 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 From buildsys at fedoraproject.org Thu May 18 17:59:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 18 May 2006 17:59:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-18 Message-ID: <20060518175957.31587.78163@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Thu May 18 17:59:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 18 May 2006 17:59:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-18 Message-ID: <20060518175957.31576.32411@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 From grinnz at gmail.com Thu May 18 18:22:40 2006 From: grinnz at gmail.com (Dan) Date: Thu, 18 May 2006 14:22:40 -0400 Subject: Greedy install In-Reply-To: <20060517232625.GJ17312@neu.nirvana> References: <20060517230610.GI17312@neu.nirvana> <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> <20060517232625.GJ17312@neu.nirvana> Message-ID: <446CBB70.7040507@gmail.com> Axel Thimm wrote: > On Wed, May 17, 2006 at 05:14:27PM -0600, Stephen John Smoogen wrote: > >> On 5/17/06, Axel Thimm wrote: >> >>> Hi, >>> >>> what's the best way to have as many packages as possible installed >>> (given some special handling, e.g. no additional glibc/kernel)? >>> E.g. how does on tell yum or any other tool "install fedora extras"? >>> >> Does this do it? >> yum install ---disablerepo=\* --enablerepo=extras install \* >> > > I guess in principle it should, but > > Error: oidentd conflicts with pidentd > Error: Missing Dependency: php = 5.1.2 is needed by package syck-php > Error: Missing Dependency: python < 0:2.4 is needed by package python-reportlab > Error: Missing Dependency: xorg-x11-Xnest is needed by package sabayon-admin > Error: compat-wxGTK2-devel conflicts with compat-wxGTK-devel > Error: compat-wxGTK-devel conflicts with compat-wxGTK2-devel > Error: Missing Dependency: php = 5.1.2 is needed by package php-eaccelerator > Error: uw-imap-devel conflicts with libc-client-devel > > So one would not manually exclude the one and other package and get a > maximum install (but it takes ages to compute, I'll do that tomorrow :). > > I wished yum had apt's auto-keeping-back feature when it comes to > conflicts and other mismathces on the repo side. > From repoclosure: Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 syck-php 0.55-7.fc5.i386 And it looks like the compat-wxGTK doesn't like compat-wxGTK2. That explains about half of the issues. -Dan From grinnz at gmail.com Thu May 18 18:23:16 2006 From: grinnz at gmail.com (Dan) Date: Thu, 18 May 2006 14:23:16 -0400 Subject: Greedy install In-Reply-To: <20060517232625.GJ17312@neu.nirvana> References: <20060517230610.GI17312@neu.nirvana> <80d7e4090605171614g612890bw34033928622a826b@mail.gmail.com> <20060517232625.GJ17312@neu.nirvana> Message-ID: <446CBB94.4030508@gmail.com> Axel Thimm wrote: > On Wed, May 17, 2006 at 05:14:27PM -0600, Stephen John Smoogen wrote: > >> On 5/17/06, Axel Thimm wrote: >> >>> Hi, >>> >>> what's the best way to have as many packages as possible installed >>> (given some special handling, e.g. no additional glibc/kernel)? >>> E.g. how does on tell yum or any other tool "install fedora extras"? >>> >> Does this do it? >> yum install ---disablerepo=\* --enablerepo=extras install \* >> > > I guess in principle it should, but > > Error: oidentd conflicts with pidentd > Error: Missing Dependency: php = 5.1.2 is needed by package syck-php > Error: Missing Dependency: python < 0:2.4 is needed by package python-reportlab > Error: Missing Dependency: xorg-x11-Xnest is needed by package sabayon-admin > Error: compat-wxGTK2-devel conflicts with compat-wxGTK-devel > Error: compat-wxGTK-devel conflicts with compat-wxGTK2-devel > Error: Missing Dependency: php = 5.1.2 is needed by package php-eaccelerator > Error: uw-imap-devel conflicts with libc-client-devel > > So one would not manually exclude the one and other package and get a > maximum install (but it takes ages to compute, I'll do that tomorrow :). > > I wished yum had apt's auto-keeping-back feature when it comes to > conflicts and other mismathces on the repo side. > From repoclosure: Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 syck-php 0.55-7.fc5.i386 And it looks like the compat-wxGTK-devel doesn't like compat-wxGTK2-devel. That explains about half of the issues. -Dan From andreas at bawue.net Thu May 18 18:39:28 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 18 May 2006 20:39:28 +0200 (CEST) Subject: Virtuals for webserver and fastcgi In-Reply-To: <446C8EC4.5010807@city-fan.org> References: <446C8EC4.5010807@city-fan.org> Message-ID: On Thu, 18 May 2006, Paul Howarth wrote: > I can envisage, at some point in the future, that people might want to > package up FastCGI applications and might want to add a suitable > dependency for a FastCGI-capable server, akin to the existing > "webserver" provide. Any suggestions for what, if any, that should be? *Sigh*. I'd really love to see something a bit weaker than Requires. Suggested: or Optional: to indicate that the package would like to have fast_cgi, but doesn't need it. That would be nice for rpm. regards, andreas From qspencer at ieee.org Thu May 18 17:43:52 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 18 May 2006 13:43:52 -0400 Subject: Virtuals for webserver and fastcgi In-Reply-To: References: <446C8EC4.5010807@city-fan.org> Message-ID: <446CB258.4050901@ieee.org> Andreas Thienemann wrote: > On Thu, 18 May 2006, Paul Howarth wrote: > > >> I can envisage, at some point in the future, that people might want to >> package up FastCGI applications and might want to add a suitable >> dependency for a FastCGI-capable server, akin to the existing >> "webserver" provide. Any suggestions for what, if any, that should be? >> > *Sigh*. > > I'd really love to see something a bit weaker than Requires. Suggested: or > Optional: to indicate that the package would like to have fast_cgi, but > doesn't need it. > > That would be nice for rpm. > +1. Debian has this, and it makes a lot of sense for packages like atlas that provide performance-optimized versions of libraries that already exist in another package (blas and lapack, in this case). In many cases users don't know about these libraries, and having suggested dependencies would provide a way to make users aware of their options. -Quentin From mpeters at mac.com Thu May 18 18:46:32 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 11:46:32 -0700 Subject: Virtuals for webserver and fastcgi In-Reply-To: References: <446C8EC4.5010807@city-fan.org> Message-ID: <1147977993.3186.31.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 20:39 +0200, Andreas Thienemann wrote: > > I'd really love to see something a bit weaker than Requires. Suggested: or > Optional: to indicate that the package would like to have fast_cgi, but > doesn't need it. > > That would be nice for rpm. Suggests is in development version of RPM - so at some point, you will have it. From andreas at bawue.net Thu May 18 18:57:29 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 18 May 2006 20:57:29 +0200 (CEST) Subject: Virtuals for webserver and fastcgi In-Reply-To: <1147977993.3186.31.camel@atlantis.mpeters.local> References: <446C8EC4.5010807@city-fan.org> <1147977993.3186.31.camel@atlantis.mpeters.local> Message-ID: On Thu, 18 May 2006, Michael A. Peters wrote: > Suggests is in development version of RPM - so at some point, you will > have it. YAY! \o/ andreas From jonathan.underwood at gmail.com Thu May 18 19:33:59 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 20:33:59 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> Message-ID: <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> OK, FESCO unfortunatley didn't actually seem to reach any kind of decision on this. So, I have updated the spec to call the package emacs-muse, with subpackages of xemacs-muse, emacs-muse-common, emacs-muse-el and xemacs-muse-el. this is a bit unilateral, but I figured doing something is better than nothing. I have also added Obsoletes: muse and Provides: muse to the muse-common subpackage. I'm all ready to go, but I don't know what the best way to proceed is - shall I import this as a new package into cvs (since the package name is now different) and request the old package is deleted? (surely this won't have to go through the review process again?) Jonathan. From rdieter at math.unl.edu Thu May 18 19:41:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 May 2006 14:41:07 -0500 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > OK, FESCO unfortunatley didn't actually seem to reach any kind of > decision on this. So, I have updated the spec to call the package > emacs-muse, with subpackages of xemacs-muse, emacs-muse-common, > emacs-muse-el and xemacs-muse-el. this is a bit unilateral, but I > figured doing something is better than nothing. > > I have also added Obsoletes: muse and Provides: muse to the > muse-common subpackage. > > I'm all ready to go, but I don't know what the best way to proceed is > - shall I import this as a new package into cvs (since the package > name is now different) and request the old package is deleted? (surely > this won't have to go through the review process again?) Yep, no, respectively. Not sure of the wisdom of the Obsoltes/Provides: muse, since part of the point of this discussion was the name collision with something else named muse. -- Rex From jonathan.underwood at gmail.com Thu May 18 19:44:49 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 20:44:49 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: References: <1147123014.2910.248.camel@localhost.localdomain> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> Message-ID: <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> On 18/05/06, Rex Dieter wrote: > > Yep, no, respectively. > > Not sure of the wisdom of the Obsoltes/Provides: muse, since part of the > point of this discussion was the name collision with something else > named muse. Yeah, I was concerned about that - but I think this is the only way to deal with the upgrade path. And I thought that we had (more or less) settled on using an epoch for the other muse package to avoid problems. Am I missing something ? From kevin-fedora-extras at scrye.com Thu May 18 19:46:43 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 18 May 2006 13:46:43 -0600 (MDT) Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE References: <1147123014.2910.248.camel@localhost.localdomain> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> Message-ID: <20060518.134643.461780524.kevin@scrye.com> >>>>> "Jonathan" == Jonathan Underwood writes: Jonathan> OK, FESCO unfortunatley didn't actually seem to reach any Jonathan> kind of decision on this. Yes, they did in the meeting just this morning... The answer seems to be 'emacs-common-muse' May 18 11:02:33 --- thl has changed the topic to: FESCo Meeting in progess -- emacs-muse May 18 11:02:37 * bpepple lurking about. May 18 11:02:41 {x,}emacs-muse, emacs-comon-muse or emacsen-muse ? May 18 11:02:50 do we want to discuss this without spot? May 18 11:02:56 * spot is here May 18 11:03:00 +1 emacs-common-muse May 18 11:03:04 * nirik likes 'emacsen-muse', but it doesn't really matter that much I guess. May 18 11:03:12 +1 emacs-common-muse May 18 11:03:20 there is no precent for making up words like emacsen in the guidelines to date May 18 11:03:22 spot, what's you current solution? May 18 11:03:29 and i would prefer not to start anything. :) May 18 11:03:33 +1 emacs-common-muse May 18 11:03:41 spot: fair enough. May 18 11:03:42 emacs-common-foo is my vote May 18 11:03:50 +? emacs-common-muse May 18 11:03:51 +1 emacs-common-muse May 18 11:03:55 precedent May 18 11:04:13 k, seems this one one easy May 18 11:04:24 ok, so muse, mew, and emacs-autex have to change... Jonathan> So, I have updated the spec to Jonathan> call the package emacs-muse, with subpackages of Jonathan> xemacs-muse, emacs-muse-common, emacs-muse-el and Jonathan> xemacs-muse-el. this is a bit unilateral, but I figured Jonathan> doing something is better than nothing. Jonathan> I have also added Obsoletes: muse and Provides: muse to the Jonathan> muse-common subpackage. Make sure you have the versions right in there. Jonathan> I'm all ready to go, but I don't know what the best way to Jonathan> proceed is - shall I import this as a new package into cvs Jonathan> (since the package name is now different) and request the Jonathan> old package is deleted? (surely this won't have to go Jonathan> through the review process again?) Yeah, I would think importing the new package and requesting the old one be removed would be right. Jonathan> Jonathan. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Thu May 18 19:51:26 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 20:51:26 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> Message-ID: <1147981887.5504.6.camel@laurel.intra.city-fan.org> On Thu, 2006-05-18 at 20:44 +0100, Jonathan Underwood wrote: > On 18/05/06, Rex Dieter wrote: > > > > Yep, no, respectively. > > > > Not sure of the wisdom of the Obsoltes/Provides: muse, since part of the > > point of this discussion was the name collision with something else > > named muse. > > Yeah, I was concerned about that - but I think this is the only way to > deal with the upgrade path. And I thought that we had (more or less) > settled on using an epoch for the other muse package to avoid > problems. Am I missing something ? Epochs just trump version/release numbers, that's all. E.g. foo epoch 1 version 0.00001 is "later" as far as rpm is concerned than foo epoch 0 version 15.7. If you obsolete "muse" (unversioned), all packages of that name will go, regardless of their epoch. Paul. From jonathan.underwood at gmail.com Thu May 18 19:54:08 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 20:54:08 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <20060518.134643.461780524.kevin@scrye.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <20060518.134643.461780524.kevin@scrye.com> Message-ID: <645d17210605181254u7fb74b6dr7d17622aadc4313d@mail.gmail.com> On 18/05/06, Kevin Fenzi wrote: > >>>>> "Jonathan" == Jonathan Underwood writes: > > Jonathan> OK, FESCO unfortunatley didn't actually seem to reach any > Jonathan> kind of decision on this. > > Yes, they did in the meeting just this morning... > [snip of proceedings] OK, I looked at the time indicated at the top of Thorstens summary and missed the main part. However, you will notice that further down there are votes in favour of emacs-common. So I don't really think a decision was reached. > The answer seems to be 'emacs-common-muse' > I don't think people read the discussion properly. The "common" in there is superfluous. This will trigge renaming other packages to. BIG GROAN. *Bangs head on wall, goes to make cup of tea, and edits the spec again.* From jonathan.underwood at gmail.com Thu May 18 19:55:49 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 20:55:49 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147981887.5504.6.camel@laurel.intra.city-fan.org> References: <1147123014.2910.248.camel@localhost.localdomain> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> <1147981887.5504.6.camel@laurel.intra.city-fan.org> Message-ID: <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> On 18/05/06, Paul Howarth wrote: > Epochs just trump version/release numbers, that's all. > > E.g. foo epoch 1 version 0.00001 is "later" as far as rpm is concerned > than foo epoch 0 version 15.7. > > If you obsolete "muse" (unversioned), all packages of that name will go, > regardless of their epoch. Well, that's what I thought originally, but the discussion previously convinced me my understanding was wrong. Seems not. So what IS the best way to deal with this...? From mpeters at mac.com Thu May 18 20:02:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 13:02:45 -0700 Subject: Incoming: directfb soname problems In-Reply-To: <1147975000.4065.49.camel@otto.amantes> References: <200605131735.k4DHZPJh005005@cvs-int.fedora.redhat.com> <1147545888.2746.102.camel@localhost.localdomain> <1147550560.26066.21.camel@otto.amantes> <1147597879.2746.151.camel@localhost.localdomain> <1147975000.4065.49.camel@otto.amantes> Message-ID: <1147982566.3186.49.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 19:56 +0200, Thomas Vander Stichele wrote: *snip* > DirectFB will cause this > problem for extras for every release they ever make. So it is different > from everything else in Fedora Extras that can be upgraded easily for > every new release. > *snip* > If that is a consideration, > basically that means that we should never accept any update in Extras > that breaks ABI/so name/compatibility. > > That would be a fine rule, but afaik we don't have it yet. I don't know > if I would be for or against; but if it was a rule, I'd probably stop > packaging directfb because it would become pointless to have it in > extras at all. Given that this will always happen with Directfb - third party repositories that do not want to break should plan ahead and provide a compat package so that when directfb is updated, they can provide the needed shared libraries themselves. It should be the 3rd parties responsibility to keep compatible, at least in this case since it is known that updates change the library version. > > > No, I allow for the possibility of me having made a mistake :) > Here's what I did. I ran: > repoquery --alldeps --whatrequires directfb > > That gave me evas and ecore, as well as xine and mplayer. > > For evas and ecore, I checked the last %changelog author, as well as the > owners.list file, and mailed ivazquez. > For xine and mplayer, I contacted anvil. That seems sufficient to me personally. > > I'm going to reiterate that the "potential security issue" is something > that IMO should really be fixed in the package manager. I think it's > wrong to blame individual package maintainers for creating a potential > security problem that is left there to be abused by the package manager > of choice. The reasons I've heard for this IMO do not weigh up against > the problem that *any* repository can create this way. There is no security issue IMHO. If yum breaks because of a third party repo or rpm is installed, that is the users responsibility to take of since they are using unsupported packages. *snip* > > If it's going to remain blocked for reasons mentioned above, that's fine > as well, but then I'm better off dropping the package from Extras, since > that would mean Extras is not the place to have this package. If > effectively directfb can't be upgraded, there's no point in shipping it > from Extras. I hope it can stay in Extras. As far as a policy - coordination of rebuilding the packages that need to be rebuilt so that they get pushed in same yum push is sufficient IMHO. From mpeters at mac.com Thu May 18 20:11:57 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 13:11:57 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> <1147981887.5504.6.camel@laurel.intra.city-fan.org> <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> Message-ID: <1147983117.3186.57.camel@atlantis.mpeters.local> On Thu, 2006-05-18 at 20:55 +0100, Jonathan Underwood wrote: > > Well, that's what I thought originally, but the discussion previously > convinced me my understanding was wrong. Seems not. > > So what IS the best way to deal with this...? > What had been suggested - the emacs package in FC<6 would obsolete/provide muse, but NOT obsolete/provide in FC-6 and the music muse package wouldn't hit until FC6. Anybody who has run a yum update will have emacs-muse (or whatever) installed and not have the muse package anymore. In FC-6 since the emacs-muse package there will NOT obsolete/provide muse, the music muse will install just fine, but probably should have an epoch just in case someone installed FC-3/4/5 muse and never did a yum update after the namespace change. They will end up with music muse replacing the emacs package, which they may not want - but there's a lot of time between now and FC-6. Did the music muse need to get into FC5? If so, is it possible to obsolete muse < 1:n.n.n w/ no provides? I know that would give rpmlint errors, I don't know if you can limit an obsoletes to less than an epoch or not. From jonathan.underwood at gmail.com Thu May 18 20:19:39 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 21:19:39 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1147983117.3186.57.camel@atlantis.mpeters.local> References: <1147123014.2910.248.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> <1147981887.5504.6.camel@laurel.intra.city-fan.org> <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> <1147983117.3186.57.camel@atlantis.mpeters.local> Message-ID: <645d17210605181319o670a1ec7l92dce6644e3e18ec@mail.gmail.com> On 18/05/06, Michael A. Peters wrote: > On Thu, 2006-05-18 at 20:55 +0100, Jonathan Underwood wrote: > > > > > Well, that's what I thought originally, but the discussion previously > > convinced me my understanding was wrong. Seems not. > > > > So what IS the best way to deal with this...? > > > > What had been suggested - the emacs package in FC<6 would > obsolete/provide muse, but NOT obsolete/provide in FC-6 and the music > muse package wouldn't hit until FC6. I thought the PlanetCCRMA guys wanted the music muse package to hit before FC6 though? Even if not, this FE package will still conflict with PC muse package... since only one version of the emacs muse package ever hit FE (version 3.02.6b), would it not work to just do Obsolotes: muse = 3.02.6b in all packages? From nicolas.mailhot at laposte.net Thu May 18 19:42:03 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 18 May 2006 21:42:03 +0200 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> Message-ID: <1147981330.2244.36.camel@rousalka.dyndns.org> Le jeudi 18 mai 2006 ? 20:33 +0100, Jonathan Underwood a ?crit : > I have also added Obsoletes: muse and Provides: muse to the > muse-common subpackage. This bit will hurt you a lot if someone packages the other muse apps under the muse name -- 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 jonathan.underwood at gmail.com Thu May 18 20:54:28 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 18 May 2006 21:54:28 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181319o670a1ec7l92dce6644e3e18ec@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> <1147981887.5504.6.camel@laurel.intra.city-fan.org> <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> <1147983117.3186.57.camel@atlantis.mpeters.local> <645d17210605181319o670a1ec7l92dce6644e3e18ec@mail.gmail.com> Message-ID: <645d17210605181354l72e084c0h18752d83e2ba1101@mail.gmail.com> In case anyone wants to look at what I propose to import into CVS: http://physics.open.ac.uk/~ju83/emacs-muse.spec Cheers, Jonathan From toshio at tiki-lounge.com Thu May 18 23:24:37 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 18 May 2006 16:24:37 -0700 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181254u7fb74b6dr7d17622aadc4313d@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <20060518.134643.461780524.kevin@scrye.com> <645d17210605181254u7fb74b6dr7d17622aadc4313d@mail.gmail.com> Message-ID: <1147994677.3129.43.camel@localhost> On Thu, 2006-05-18 at 20:54 +0100, Jonathan Underwood wrote: > On 18/05/06, Kevin Fenzi wrote: > > >>>>> "Jonathan" == Jonathan Underwood writes: > > > > Jonathan> OK, FESCO unfortunatley didn't actually seem to reach any > > Jonathan> kind of decision on this. > > > > Yes, they did in the meeting just this morning... > > > > [snip of proceedings] > > OK, I looked at the time indicated at the top of Thorstens summary and > missed the main part. However, you will notice that further down there > are votes in favour of emacs-common. So I don't really think a > decision was reached. > If you're looking at the Summary email, you're looking at the minutes from last week's meeting. Emacs-muse was one of the first things discussed today. -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 kevin.kofler at chello.at Fri May 19 00:23:40 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 19 May 2006 00:23:40 +0000 (UTC) Subject: Removing noise from specs References: <8421.192.54.193.51.1147958590.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot writes: > %defattr(0644,root,root,0755) would be less transparent but would force > packagers to actually check the perms they need No, IMHO it would just lead them to systematically put %defattr(0755,root,root,0755) (or worse, 0777, you never know...) everywhere in specfiles, which means: * more files with executable permissions, not less, * more specfile noise, not less. Kevin Kofler From mpeters at mac.com Fri May 19 01:00:15 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 18 May 2006 18:00:15 -0700 Subject: Removing noise from specs In-Reply-To: References: <8421.192.54.193.51.1147958590.squirrel@rousalka.dyndns.org> Message-ID: <1148000415.3186.67.camel@atlantis.mpeters.local> On Fri, 2006-05-19 at 00:23 +0000, Kevin Kofler wrote: > Nicolas Mailhot writes: > > %defattr(0644,root,root,0755) would be less transparent but would force > > packagers to actually check the perms they need > > No, IMHO it would just lead them to systematically put > %defattr(0755,root,root,0755) (or worse, 0777, you never know...) everywhere in > specfiles, which means: It also means that RPMs will have incorrect ownership when built on systems that do not define the defattr outside of the spec file. It is better to have it it their. Not defining buildroot is one thing -it won't cause an incorrectly packaged rpm to be built on older systems, it will cause a build failure until the user defines a buildroot. But not having a %defattr means that on systems that don't define it, the package will build but have improper permissions - which is a severe security risk. It does not hurt to have %defattr there, and having it there prevents improper permissions. Well, prevents improper permissions that would be correct if it is defined there. From kevin-fedora-extras at scrye.com Fri May 19 01:22:47 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 18 May 2006 19:22:47 -0600 (MDT) Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE References: <1147123014.2910.248.camel@localhost.localdomain> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <645d17210605181244v33087f57i89cf225f38738d73@mail.gmail.com> <1147981887.5504.6.camel@laurel.intra.city-fan.org> <645d17210605181255q720d4b3dx17b18a983f7fba1d@mail.gmail.com> <1147983117.3186.57.camel@atlantis.mpeters.local> <645d17210605181319o670a1ec7l92dce6644e3e18ec@mail.gmail.com> <645d17210605181354l72e084c0h18752d83e2ba1101@mail.gmail.com> Message-ID: <20060518.192247.300476924.kevin@scrye.com> >>>>> "Jonathan" == Jonathan Underwood writes: Jonathan> In case anyone wants to look at what I propose to import Jonathan> into CVS: http://physics.open.ac.uk/~ju83/emacs-muse.spec Shouldn't that have the main package Name as 'emacs-common-muse' ? I thought it was decided that the base packages should be 'emacs-common-$name'. I guess we can see the package guidelines once they are updated... :) Jonathan> Cheers, Jonathan kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From petersen at redhat.com Fri May 19 02:28:57 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 19 May 2006 11:28:57 +0900 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-18 In-Reply-To: <20060518175957.31585.35834@extras64.linux.duke.edu> References: <20060518175957.31585.35834@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-4-i386: > ---------------------------------------------------------------------- > scim-tables-japanese 0.5.4-2.fc4.i386 > scim-tables-korean 0.5.4-2.fc4.i386 These should be obsoleted now by scim-tables-0.5.6-1.fc4 and ditto for fc3, or is there still a problem. Jens From rdieter at math.unl.edu Fri May 19 04:17:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 May 2006 23:17:48 -0500 Subject: Virtuals for webserver and fastcgi In-Reply-To: <1147977993.3186.31.camel@atlantis.mpeters.local> References: <446C8EC4.5010807@city-fan.org> <1147977993.3186.31.camel@atlantis.mpeters.local> Message-ID: Michael A. Peters wrote: > On Thu, 2006-05-18 at 20:39 +0200, Andreas Thienemann wrote: > >> I'd really love to see something a bit weaker than Requires. Suggested: or >> Optional: to indicate that the package would like to have fast_cgi, but >> doesn't need it. >> >> That would be nice for rpm. > > Suggests is in development version of RPM - so at some point, you will > have it. Suggests aka Requires(hint) -- Rex From rvinyard at cs.nmsu.edu Fri May 19 05:43:04 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Thu, 18 May 2006 23:43:04 -0600 Subject: GNOME packages that need review? In-Reply-To: <1147676936.26878.9.camel@atlantis.mpeters.local> References: <1147676936.26878.9.camel@atlantis.mpeters.local> Message-ID: <446D5AE8.9080903@cs.nmsu.edu> GNOME only? If you'll consider gtkmm I have a couple waiting... namely bit, bitgtkmm and papyrus (a GnomeCanvas C++ replacement for Gtkmm). Michael A. Peters wrote: > I'm looking for some gnome packages that need review. > I'd rather they not be mono packages, I want to watch some of them be > reviewed first (feel free to put me on the cc list if you are submitting > a mono package). > > I'm looking through the FE-NEW bugs trying to find some GNOME packages > that need review, but it isn't always so easy to find. > > Note that I am not a sponsor, so I can't approve packages that need a > sponsor - but I can comment on them. > > So - what gnome specific packages need some reviewer time? > > Maybe a page for gnome packages needing review should go in the gnome > SIG. Should I just add a place for gnome packages that need review to > http://fedoraproject.org/wiki/Extras/SIGs/GNOME (similar to games being > packaged on the games SIG page)? > From fedora at leemhuis.info Fri May 19 06:52:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 19 May 2006 08:52:38 +0200 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> References: <1147123014.2910.248.camel@localhost.localdomain> <1147442019.6598.63.camel@localhost.localdomain> <645d17210605120812h63aa7b81ga98d21f7216a8688@mail.gmail.com> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> Message-ID: <1148021558.12843.2.camel@thl.ct.heise.de> Am Donnerstag, den 18.05.2006, 20:33 +0100 schrieb Jonathan Underwood: > OK, FESCO unfortunatley didn't actually seem to reach any kind of > decision on this. Why do you think so? Here is the relevant part from yesterdays meeting (it was the first topic; the summary I send out yesterday was from *last* weeks meeting) > 19:02 --- | thl has changed the topic to: FESCo Meeting in progess -- emacs-muse > 19:02 * | bpepple lurking about. > 19:02 < thl> | {x,}emacs-muse, emacs-comon-muse or emacsen-muse ? > 19:02 < thl> | do we want to discuss this without spot? > 19:02 * | spot is here > 19:02 < XulChris> | +1 emacs-common-muse > 19:02 * | nirik likes 'emacsen-muse', but it doesn't really matter that much I guess. > 19:03 < thl> | +1 emacs-common-muse > 19:03 < spot> | there is no precent for making up words like emacsen in the guidelines to date > 19:03 < thl> | spot, what's you current solution? > 19:03 < spot> | and i would prefer not to start anything. :) > 19:03 < mschwendt> | +1 emacs-common-muse > 19:03 < nirik> | spot: fair enough. > 19:03 < spot> | emacs-common-foo is my vote > 19:03 < XulChris> | +? emacs-common-muse > 19:03 < bpepple> | +1 emacs-common-muse > 19:03 < spot> | precedent > 19:04 < thl> | k, seems this one one easy > 19:04 < nirik> | ok, so muse, mew, and emacs-autex have to change... > 19:04 < thl> | spot, can you mail that to the list and put it in the packaging guidelines please? > 19:04 < spot> | gladly. > 19:04 --> | thomasvs (Thomas Vander Stichele) [n=thomas at fedora/thomasvs] has joined #fedora-extras > 19:04 * | nirik can go review vm now too. ;) > 19:04 < thl> | spot, thx CU thl From jonathan.underwood at gmail.com Fri May 19 09:54:44 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 19 May 2006 10:54:44 +0100 Subject: [Fedora-music-list] Re: package naming question: muse -vs - MusE In-Reply-To: <1148021558.12843.2.camel@thl.ct.heise.de> References: <1147123014.2910.248.camel@localhost.localdomain> <1147448842.2300.2.camel@localhost.localdomain> <645d17210605120903g1e724bb2h9c145c9d10cf0530@mail.gmail.com> <20060515.112047.166116122.kevin@scrye.com> <1147715653.6151.18.camel@localhost.localdomain> <645d17210605151434l45d3a548g4b30e797d0263f4c@mail.gmail.com> <1147729672.4124.2.camel@atlantis.mpeters.local> <645d17210605160454v52617c28h35fb9f992a2c7acb@mail.gmail.com> <645d17210605181233k53f38385x2b4b5868c174cc8d@mail.gmail.com> <1148021558.12843.2.camel@thl.ct.heise.de> Message-ID: <645d17210605190254y54adf6aew14e990722cd74fa6@mail.gmail.com> On 19/05/06, Thorsten Leemhuis wrote: > Am Donnerstag, den 18.05.2006, 20:33 +0100 schrieb Jonathan Underwood: > > OK, FESCO unfortunatley didn't actually seem to reach any kind of > > decision on this. > > Why do you think so? Here is the relevant part from yesterdays meeting > (it was the first topic; the summary I send out yesterday was from > *last* weeks meeting) OK, sorry, I thought that was for this weeks meeting. I have to say, I just don't get why people think emacs-common-muse is a useful package name - the common in the package name is superfluous. The common files should be a subpackage of the main package, not the main package, surely? However, if you guys really want this to be the Guideline, I will push ahead with it - but it impacts all emacs packages. The alternative, which I have implemented sticks closer to current guidlines and packaging precedent... please do have a look at the URL I posted for the alternative implementation. Jonathan. From dan at danny.cz Fri May 19 10:03:45 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 19 May 2006 12:03:45 +0200 Subject: unifying of spec files for different Fedora releases Message-ID: <1148033025.3489.12.camel@eagle.danny.cz> Hello, I want to unify the spec files for TinyERP, because they are (only a bit) different between FC < 5 and FC >=5 due the change in Xorg packaging. Now I have in the spec for FC < 5 BuildRequires: xorg-x11-Xvfb and for FC >= 5 I need BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base and there is also a difference between calling the Xvfb server (/usr/X11/bin/Xvfb vs. /usr/bin/Xvfb). Should I check the value of "%fedora" so it would look like %if "%fedora" < 5 BuildRequires: xorg-x11-Xvfb %else BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base %endif or should I use "%dist" for the checks? I was probably already mentioned on this list, but I not able to find it. Dan -- TinyERP maintainer for Fedora Extras From bugs.michael at gmx.net Fri May 19 10:21:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 19 May 2006 12:21:32 +0200 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-18 In-Reply-To: References: <20060518175957.31585.35834@extras64.linux.duke.edu> Message-ID: <20060519122132.0a2b6697.bugs.michael@gmx.net> On Fri, 19 May 2006 11:28:57 +0900, Jens Petersen wrote: > Fedora Extras repoclosure wrote: > > Summary of broken packages in fedora-extras-4-i386: > > ---------------------------------------------------------------------- > > scim-tables-japanese 0.5.4-2.fc4.i386 > > scim-tables-korean 0.5.4-2.fc4.i386 > > These should be obsoleted now by scim-tables-0.5.6-1.fc4 and ditto for > fc3, or is there still a problem. The packages, however, are still offered for install: $ yum install scim-tables-japanese Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for scim-tables-japanese to pack into transaction set. scim-tables-japanese-0.5. 100% |=========================| 4.8 kB 00:00 ---> Package scim-tables-japanese.i386 0:0.5.4-2.fc3 set to be updated --> Running transaction check --> Processing Dependency: scim-tables = 0.5.4 for package: scim-tables-japanese --> Finished Dependency Resolution Error: Missing Dependency: scim-tables = 0.5.4 is needed by package scim-tables-japanese For requesting removal of these obsolete packages, see: http://fedoraproject.org/wiki/Extras/FC4Status http://fedoraproject.org/wiki/Extras/FC3Status Futher references: https://www.redhat.com/archives/fedora-maintainers/2006-May/msg00026.html https://bugzilla.redhat.com/190116 From mpeters at mac.com Fri May 19 10:22:20 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 19 May 2006 03:22:20 -0700 Subject: unifying of spec files for different Fedora releases In-Reply-To: <1148033025.3489.12.camel@eagle.danny.cz> References: <1148033025.3489.12.camel@eagle.danny.cz> Message-ID: <1148034140.3186.76.camel@atlantis.mpeters.local> On Fri, 2006-05-19 at 12:03 +0200, Dan Hor?k wrote: > > Should I check the value of "%fedora" so it would look like > > %if "%fedora" < 5 > BuildRequires: xorg-x11-Xvfb > %else > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > %endif > > or should I use "%dist" for the checks? I was probably already mentioned > on this list, but I not able to find it. Problem with both: [mpeters at atlantis ~]$ rpm -E %dist %dist [mpeters at atlantis ~]$ rpm -E %fedora %fedora [mpeters at atlantis ~]$ It would make the spec file unbuildable on a lot of systems. What you could do - something like %define mod_x %(eval "if [ -f /some/file ]; then echo 1; else echo 0; fi") where /some/file is the xorg-x11-server-Xvfb path to a file that is different from the References: <1148033025.3489.12.camel@eagle.danny.cz> Message-ID: <446D9D4A.2070603@city-fan.org> Dan Hor?k wrote: > Hello, > > I want to unify the spec files for TinyERP, because they are (only a > bit) different between FC < 5 and FC >=5 due the change in Xorg > packaging. > > Now I have in the spec for FC < 5 > > BuildRequires: xorg-x11-Xvfb > > and for FC >= 5 I need > > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > > and there is also a difference between calling the Xvfb server > (/usr/X11/bin/Xvfb vs. /usr/bin/Xvfb). > > Should I check the value of "%fedora" so it would look like > > %if "%fedora" < 5 > BuildRequires: xorg-x11-Xvfb > %else > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > %endif > > or should I use "%dist" for the checks? I was probably already mentioned > on this list, but I not able to find it. The wiki suggests to use %fedora for this: http://fedoraproject.org/wiki/DistTag Paul. From nphilipp at redhat.com Fri May 19 10:27:38 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 19 May 2006 12:27:38 +0200 Subject: unifying of spec files for different Fedora releases In-Reply-To: <1148034140.3186.76.camel@atlantis.mpeters.local> References: <1148033025.3489.12.camel@eagle.danny.cz> <1148034140.3186.76.camel@atlantis.mpeters.local> Message-ID: <1148034459.18119.2.camel@gibraltar.stuttgart.redhat.com> On Fri, 2006-05-19 at 03:22 -0700, Michael A. Peters wrote: > On Fri, 2006-05-19 at 12:03 +0200, Dan Hor?k wrote: > > > > > Should I check the value of "%fedora" so it would look like > > > > %if "%fedora" < 5 > > BuildRequires: xorg-x11-Xvfb > > %else > > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > > %endif > > > > or should I use "%dist" for the checks? I was probably already mentioned > > on this list, but I not able to find it. > > Problem with both: > > [mpeters at atlantis ~]$ rpm -E %dist > %dist > [mpeters at atlantis ~]$ rpm -E %fedora > %fedora > [mpeters at atlantis ~]$ > > It would make the spec file unbuildable on a lot of systems. > What you could do - something like > > %define mod_x %(eval "if [ -f /some/file ]; then echo 1; else echo 0; > fi") > > where /some/file is the xorg-x11-server-Xvfb path to a file that is > different from the References: <1148033025.3489.12.camel@eagle.danny.cz> <446D9D4A.2070603@city-fan.org> Message-ID: <200605191137.10448.jamatos@fc.up.pt> On Friday 19 May 2006 11:26, Paul Howarth wrote: > The wiki suggests to use %fedora for this: > > http://fedoraproject.org/wiki/DistTag For grace where I have a similar problem I have used %fedora. In my experience as long as the changes are self-contained, like in this case, it is easier to have a single spec. > Paul. -- Jos? Ab?lio From buildsys at fedoraproject.org Fri May 19 11:09:18 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 19 May 2006 07:09:18 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060519110918.EEE78152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 20 cpanspec-1.66-1.fc6 drgeo-1.1.0-8.fc6 dvb-apps-1.1.1-4.fc6 erlang-R11B-0.1.fc6 erlang-esdl-0.95.0630-6.fc6 exiv2-0.9.1-3.fc6 gnonlin-0.10.4-1 gnotime-2.2.2-5.fc6 kphone-4.2-10.fc6 kphotoalbum-2.2-2.fc6 liblo-0.23-6.fc6 liblrdf-0.4.0-7.fc6 obby-0.4.0-2.rc2.fc6 perl-GDGraph-1.4308-1.fc6 perl-Module-Build-0.2800-2.fc6 perl-Sub-Uplevel-0.12-1.fc6 perl-Test-Expect-0.30-1.fc6 wine-0.9.13-2.fc6 wings-0.98.32b-7.fc6 xfce4-appfinder-4.2.3-3.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 19 11:09:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 19 May 2006 07:09:19 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060519110919.03934152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 14 cpanspec-1.66-1.fc5 dvb-apps-1.1.1-3.fc5 erlang-R11B-0.1.fc5 erlang-esdl-0.95.0630-6.fc5 exiv2-0.9.1-3.fc5 kphone-4.2-10.fc5 kphotoalbum-2.2-2.fc5 liblo-0.23-6.fc5 liblrdf-0.4.0-7.fc5 perl-GDGraph-1.4308-1.fc5 perl-Net-SNMP-5.2.0-1.fc5 wine-0.9.13-2.fc5 wings-0.98.32b-7.fc5 xfce4-appfinder-4.2.3-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 19 11:09:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 19 May 2006 07:09:19 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060519110919.11EFB15218A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 erlang-R11B-0.1.fc3 kphone-4.2-10.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 19 11:09:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 19 May 2006 07:09:19 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060519110919.0A84C152189@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 10 cpanspec-1.66-1.fc4 dvb-apps-1.1.1-3.fc4 erlang-R11B-0.1.fc4 erlang-esdl-0.95.0630-6.fc4 exiv2-0.9.1-3.fc4 kphone-4.2-10.fc4 kphotoalbum-2.2-2.fc4 perl-GDGraph-1.4308-1.fc4 perl-Net-SNMP-5.2.0-1.fc4 wings-0.98.32b-7.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 19 11:32:17 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 19 May 2006 11:32:17 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-19 Message-ID: <20060519113217.30536.64408@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 ====================================================================== New report for: petersen AT redhat.com package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Fri May 19 11:32:17 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 19 May 2006 11:32:17 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-19 Message-ID: <20060519113217.30523.60935@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== New report for: ivazquez AT ivazquez.net package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 ====================================================================== New report for: tcallawa AT redhat.com package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 ====================================================================== New report for: petersen AT redhat.com package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Fri May 19 11:32:17 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 19 May 2006 11:32:17 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-19 Message-ID: <20060519113217.30541.36968@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 scim-skk 0.5.2-3.fc5.i386 scim-tomoe 0.2.0-3.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 scim-skk 0.5.2-3.fc5.x86_64 scim-tomoe 0.2.0-3.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: ryo-dairiki AT users.sourceforge.net package: scim-skk - 0.5.2-3.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-tomoe - 0.2.0-3.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-skk - 0.5.2-3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: scim-tomoe - 0.2.0-3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 ====================================================================== New report for: qshen AT redhat.com package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) ====================================================================== New report for: matthias AT rpmforge.net package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Fri May 19 11:32:17 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 19 May 2006 11:32:17 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-19 Message-ID: <20060519113217.30545.65693@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 pop-before-smtp 1.36-2.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-i386 unresolved deps: perl(Net::Netmask) package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Net::Netmask) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: pop-before-smtp - 1.36-2.noarch from fedora-extras-development-ppc unresolved deps: perl(Net::Netmask) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 From Christian.Iseli at licr.org Fri May 19 12:28:13 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 14:28:13 +0200 Subject: FE Package Status of May 19, 2006 Message-ID: <200605191228.k4JCSDP1001293@ludwig-alpha.unil.ch> Hi folks, Status updated. I have also colorized the top 25 review submitters... I tried to fix a couple bugs in the script... but there remains some. In particular, I have to apologize to Rex: it's not his fault if qt4 is already in CVS but my script gets the owner from the BZ ticket... so he's the one who appears in the report. Sorry. 36 accepted packages in a week. FE-NEW backlog is stable. Slight increase in FE-REVIEW. BTW, I think a page similar to Extras/PackagesNoLongerInDevel for Core is a good idea... Cheers, Christian --- FE Package Status of May 19, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1758 packages - 48 orphans - 43 packages not available in extras devel or release Axel dot Thimm at ATrpms dot net synaptic andreas at bawue dot net dd_rescue bdpepple at ameritech dot net galago-daemon cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode dennis at ausil dot us cryptplug fredrik at dolda2000 dot com icmpdn gauret at free dot fr tiger gauret at free dot fr elmo ghenry at suretecsystems dot com gnome-applet-netmon ghenry at suretecsystems dot com rsnapshot ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin matthias at rpmforge dot net php-pecl-pdo matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net php-pecl-pdo-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache notting at redhat dot com comps oliver at linux-kernel dot at squidGuard rdieter at math dot unl dot edu exiv2 rdieter at math dot unl dot edu kphotoalbum rdieter at math dot unl dot edu gsview sgrubb at redhat dot com libsafe splinux at fedoraproject dot org goupil tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com stripesnoop tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap than at redhat dot com qt4 toniw at iki dot fi silky toniw at iki dot fi libmatchbox ville dot skytta at iki dot fi lirc-kmod-common ville dot skytta at iki dot fi lirc-kmod wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 6 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep jonathan dot underwood at gmail dot com muse jpo at di dot uminho dot pt perl-Test-Expect kevin-redhat-bugzilla at tummy dot com tpb noa at resare dot com vorbisgain - 4 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=188180,191603 qt4 rdieter at math.unl.edu rsnapshot lists at forevermore.net https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 SquidGuard oliver at linux-kernel.at webmin jvdias at redhat.com - 1 packages present in the development repo which have no owners entry conntrack - 4 orphaned packages, yet available in extras devel gtkglarea2 ots perl-XML-XPath perl-XML-XQL - 37 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for FC5: tcallawa at redhat dot com check - 3 packages duplicated for devel: rdieter at math dot unl dot edu gtk+ rdieter at math dot unl dot edu glib tcallawa at redhat dot com check FE-ACCEPT packages stats: - 835 accepted, closed package reviews - 6 accepted, closed package reviews not in repo - 1 accepted, closed package reviews not in owners - 5 accepted, open package reviews older than 4 weeks; - 3 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 85 open tickets - 9 tickets with no activity in eight weeks - 26 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 195 open tickets - 12 tickets with no activity in eight weeks - 47 tickets with no activity in four weeks - 2 closed tickets FE-NEEDSPONSOR packages stats: - 42 open tickets - 1 tickets with no activity in eight weeks - 17 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 208 open tickets - 121 tickets with no activity in eight weeks - 30 tickets with no activity in four weeks CVS stats: - 1731 packages with a devel directory - 5 packages with no owners entry conntrack initng kile-i18n pcb perl-Maypole - 4 packages in CVS devel *and* Core check libevent glib gtk+ Maintainers stats: - 188 maintainers - 2 inactive maintainers with open bugs - 1 inactive maintainers Dropped FC packages: - 237 packages were dropped from core since FC 1 From dan at danny.cz Fri May 19 12:38:15 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 19 May 2006 14:38:15 +0200 Subject: unifying of spec files for different Fedora releases In-Reply-To: <1148034459.18119.2.camel@gibraltar.stuttgart.redhat.com> References: <1148033025.3489.12.camel@eagle.danny.cz> <1148034140.3186.76.camel@atlantis.mpeters.local> <1148034459.18119.2.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1148042295.3489.25.camel@eagle.danny.cz> Nils Philippsen p??e v P? 19. 05. 2006 v 12:27 +0200: > On Fri, 2006-05-19 at 03:22 -0700, Michael A. Peters wrote: > > On Fri, 2006-05-19 at 12:03 +0200, Dan Hor?k wrote: > > > > > > > > Should I check the value of "%fedora" so it would look like > > > > > > %if "%fedora" < 5 > > > BuildRequires: xorg-x11-Xvfb > > > %else > > > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > > > %endif > > > > > > or should I use "%dist" for the checks? I was probably already mentioned > > > on this list, but I not able to find it. > > > > Problem with both: > > > > [mpeters at atlantis ~]$ rpm -E %dist > > %dist > > [mpeters at atlantis ~]$ rpm -E %fedora > > %fedora > > [mpeters at atlantis ~]$ > > > > It would make the spec file unbuildable on a lot of systems. > > What you could do - something like > > > > %define mod_x %(eval "if [ -f /some/file ]; then echo 1; else echo 0; > > fi") > > > > where /some/file is the xorg-x11-server-Xvfb path to a file that is > > different from the > Well, this depends on the package in question being installed. You could > instead use the %fedora macros and if they don't exist, use defaults. > Check out the current bzflag spec file to see what I mean. Thanks to all. I will use the "bzflag" method because it uses the standard %fedora tag but is also buildable on other distros controlled by a command line option. Dan -- TinyERP maintainer for Fedora Extras From Christian.Iseli at licr.org Fri May 19 12:52:27 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 14:52:27 +0200 Subject: FE Package Status of May 12, 2006 In-Reply-To: Your message of "Fri, 12 May 2006 17:12:11 EDT." <604aa7910605121412j2c31cae3p5c2b7f68a9e5106c@mail.gmail.com> Message-ID: <200605191252.k4JCqSwx001925@ludwig-alpha.unil.ch> jspaleta at gmail.com said: > Just a little FYI, I think you have an counting error in your script Look at > the Inactivity notice section on the Package Status page. summary lists 0 > packages but there is a specific package listed in the table underneath the > summary. Should now be fixed. Christian From Christian.Iseli at licr.org Fri May 19 12:58:26 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 14:58:26 +0200 Subject: FE Package Status of May 12, 2006 In-Reply-To: Your message of "Sat, 13 May 2006 12:04:01 +1200." <44652271.2090802@knox.net.nz> Message-ID: <200605191258.k4JCwQwU002080@ludwig-alpha.unil.ch> michael at knox.net.nz said: > I am wondering why it keeps reporting doctorj as an orphan: Because doctorj was listed on the Extras/PackagesNoLongerInDevel page... I have now removed it from that page. Christian From fedora at leemhuis.info Fri May 19 13:42:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 19 May 2006 15:42:32 +0200 Subject: FE Package Status of May 19, 2006 In-Reply-To: <200605191228.k4JCSDP1001293@ludwig-alpha.unil.ch> References: <200605191228.k4JCSDP1001293@ludwig-alpha.unil.ch> Message-ID: <1148046152.2261.4.camel@localhost.localdomain> Christian, thanks for your work. Am Freitag, den 19.05.2006, 14:28 +0200 schrieb Christian.Iseli at licr.org: [...] > BTW, I think a page similar to Extras/PackagesNoLongerInDevel for Core is a > good idea... Actually I'd like to get rid of that page. I'd prefer if we could put files like "dead.package" (with a explanation why it is dead) into the devel branch of the package (and remove all others) in cvs. Christian, would that work for you? Maybe this could even be done in Core, too. CU thl -- Thorsten Leemhuis From Christian.Iseli at licr.org Fri May 19 13:52:01 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 15:52:01 +0200 Subject: FE Package Status of May 19, 2006 In-Reply-To: Your message of "Fri, 19 May 2006 15:42:32 +0200." <1148046152.2261.4.camel@localhost.localdomain> Message-ID: <200605191352.k4JDq1J7003489@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > Actually I'd like to get rid of that page. I'd prefer if we could put files > like "dead.package" (with a explanation why it is dead) into the devel branch > of the package (and remove all others) in cvs. Christian, would that work for > you? Yea, that'd work too. And I agree it's a better solution: less pages to maintain and the CVS repo is *the* data source. I notice some retired packages already have a dead.package file (e.g., elmo). I'll update the script and see what happens... > Maybe this could even be done in Core, too. Yes, I'd like that. Can I get a local copy of the Core repo ? Christian From bugs.michael at gmx.net Fri May 19 14:08:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 19 May 2006 16:08:51 +0200 Subject: FE Package Status of May 19, 2006 In-Reply-To: <200605191228.k4JCSDP1001293@ludwig-alpha.unil.ch> References: <200605191228.k4JCSDP1001293@ludwig-alpha.unil.ch> Message-ID: <20060519160851.af3e5c61.bugs.michael@gmx.net> On Fri, 19 May 2006 14:28:13 +0200, Christian.Iseli at licr.org wrote: > ghenry at suretecsystems dot com rsnapshot > - 4 packages which have not yet been FE-APPROVE'd... > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=188180,191603 > qt4 rdieter at math.unl.edu > rsnapshot lists at forevermore.net ? Where does this come from? rsnapshot predates the NewPackageProcess. https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00509.html > - 4 orphaned packages, yet available in extras devel > gtkglarea2 ots perl-XML-XPath perl-XML-XQL See mail to maintainers-list and owners of dependencies. From Christian.Iseli at licr.org Fri May 19 14:29:17 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 16:29:17 +0200 Subject: FE Package Status of May 19, 2006 In-Reply-To: Your message of "Fri, 19 May 2006 16:08:51 +0200." <20060519160851.af3e5c61.bugs.michael@gmx.net> Message-ID: <200605191429.k4JETH0E004387@ludwig-alpha.unil.ch> bugs.michael at gmx.net said: > On Fri, 19 May 2006 14:28:13 +0200, Christian.Iseli at licr.org wrote: > > - 4 packages which have not yet been FE-APPROVE'd... > > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=188180,191603 > > qt4 rdieter at math.unl.edu > > rsnapshot lists at forevermore.net > > ? Where does this come from? When there's an open BZ review ticket, the script assumes the mentioned package hasn't been approved yet... For qt4, Than Ngo imported in CVS apparently by mistake For rsnapshot, I dunno. Probably the new submitter didn't notice the package was already in FE, presumably because it has not been built in a long time. Christian From opensource at till.name Fri May 19 14:51:03 2006 From: opensource at till.name (Till Maas) Date: Fri, 19 May 2006 16:51:03 +0200 Subject: mock and proxy Message-ID: <200605191651.03862.opensource@till.name> Hiyas, the recommend way to use a proxy for mock on http://fedoraproject.org/wiki/Extras/MockTricks is to set http_proxy oder ftp_proxy variable for the user that runs mock. In this case mock seems not to use the proxy-definitions in /etc/mock/*.cfg for individual repositories. Example: ---- [local] name=local baseurl=http://localhost/localrepo proxy=_none_ ---- For this reason I suggest to add to the wiki page to configure proxies in the mock config files instead of using enviroment variables or at least to comment on this problem. Regards, Till From tibbs at math.uh.edu Fri May 19 16:46:33 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 19 May 2006 11:46:33 -0500 Subject: FE Package Status of May 19, 2006 In-Reply-To: <200605191429.k4JETH0E004387@ludwig-alpha.unil.ch> (Christian Iseli's message of "Fri, 19 May 2006 16:29:17 +0200") References: <200605191429.k4JETH0E004387@ludwig-alpha.unil.ch> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> For rsnapshot, I dunno. Probably the new submitter didn't notice CI> the package was already in FE, presumably because it has not been CI> built in a long time. It has never been built as far as I can tell, nor has it had any activity at all since what looks to be some sort of mass import. It really seems to be something of a phantom package. I've asked the submitter to ping the original package owner, but if anything qualifies for orphan status, rsnapshot does. - J< From Christian.Iseli at licr.org Fri May 19 17:19:58 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 19 May 2006 19:19:58 +0200 Subject: FE Package Status of May 19, 2006 In-Reply-To: Your message of "Fri, 19 May 2006 11:46:33 CDT." Message-ID: <200605191719.k4JHJwQh002935@mx3.redhat.com> tibbs at math.uh.edu said: > if anything qualifies for orphan status, rsnapshot does. Agreed :) From bugzilla at redhat.com Fri May 19 17:16:38 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 19 May 2006 13:16:38 -0400 Subject: [Bug 166960] Review Request: Fuse-emulator In-Reply-To: Message-ID: <200605191716.k4JHGcU1017789@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Fuse-emulator https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166960 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wtogami at redhat.com Fri May 19 18:51:49 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 19 May 2006 14:51:49 -0400 Subject: Taking Ownership of perl-Net-Netmask Message-ID: <446E13C5.2090401@redhat.com> I am taking ownership of perl-Net-Netmask in order to revive it so pop-before-smtp can be used again. Warren Togami wtogami at redhat.com From rdieter at math.unl.edu Fri May 19 19:58:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 19 May 2006 14:58:52 -0500 Subject: unifying of spec files for different Fedora releases In-Reply-To: <1148033025.3489.12.camel@eagle.danny.cz> References: <1148033025.3489.12.camel@eagle.danny.cz> Message-ID: Dan Hor?k wrote: > Hello, > > I want to unify the spec files for TinyERP, because they are (only a > bit) different between FC < 5 and FC >=5 due the change in Xorg > packaging. > > Now I have in the spec for FC < 5 > > BuildRequires: xorg-x11-Xvfb > > and for FC >= 5 I need > > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > > and there is also a difference between calling the Xvfb server > (/usr/X11/bin/Xvfb vs. /usr/bin/Xvfb). > > Should I check the value of "%fedora" so it would look like > > %if "%fedora" < 5 > BuildRequires: xorg-x11-Xvfb > %else > BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > %endif > > or should I use "%dist" for the checks? I was probably already mentioned > on this list, but I not able to find it. The former (use %%fedora). It's easier for less than, greater than checks. -- Rex From rdieter at math.unl.edu Fri May 19 19:59:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 19 May 2006 14:59:54 -0500 Subject: unifying of spec files for different Fedora releases In-Reply-To: <1148034140.3186.76.camel@atlantis.mpeters.local> References: <1148033025.3489.12.camel@eagle.danny.cz> <1148034140.3186.76.camel@atlantis.mpeters.local> Message-ID: Michael A. Peters wrote: > On Fri, 2006-05-19 at 12:03 +0200, Dan Hor?k wrote: > >> Should I check the value of "%fedora" so it would look like >> >> %if "%fedora" < 5 >> BuildRequires: xorg-x11-Xvfb >> %else >> BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base >> %endif >> >> or should I use "%dist" for the checks? I was probably already mentioned >> on this list, but I not able to find it. > > Problem with both: > > [mpeters at atlantis ~]$ rpm -E %dist > %dist > [mpeters at atlantis ~]$ rpm -E %fedora > %fedora > [mpeters at atlantis ~]$ > > It would make the spec file unbuildable on a lot of systems. FYI, we're speaking here only in the context of Fedora Extras and it's buildsystem. -- Rex From paul at city-fan.org Fri May 19 20:21:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 19 May 2006 21:21:04 +0100 Subject: unifying of spec files for different Fedora releases In-Reply-To: References: <1148033025.3489.12.camel@eagle.danny.cz> <1148034140.3186.76.camel@atlantis.mpeters.local> Message-ID: <1148070065.7586.14.camel@laurel.intra.city-fan.org> On Fri, 2006-05-19 at 14:59 -0500, Rex Dieter wrote: > Michael A. Peters wrote: > > On Fri, 2006-05-19 at 12:03 +0200, Dan Hor?k wrote: > > > >> Should I check the value of "%fedora" so it would look like > >> > >> %if "%fedora" < 5 > >> BuildRequires: xorg-x11-Xvfb > >> %else > >> BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base > >> %endif > >> > >> or should I use "%dist" for the checks? I was probably already mentioned > >> on this list, but I not able to find it. > > > > Problem with both: > > > > [mpeters at atlantis ~]$ rpm -E %dist > > %dist > > [mpeters at atlantis ~]$ rpm -E %fedora > > %fedora > > [mpeters at atlantis ~]$ > > > > It would make the spec file unbuildable on a lot of systems. > > FYI, we're speaking here only in the context of Fedora Extras and it's > buildsystem. If you care about being able to build elsewhere, one possibility would be to use a construct like: %if 0%{?fedora} < 5 BuildRequires: xorg-x11-Xvfb %else BuildRequires: xorg-x11-server-Xvfb, xorg-x11-fonts-base %endif Paul. From mpeters at mac.com Fri May 19 20:35:06 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 19 May 2006 13:35:06 -0700 Subject: unifying of spec files for different Fedora releases In-Reply-To: References: <1148033025.3489.12.camel@eagle.danny.cz> <1148034140.3186.76.camel@atlantis.mpeters.local> Message-ID: <1148070907.3186.100.camel@atlantis.mpeters.local> On Fri, 2006-05-19 at 14:59 -0500, Rex Dieter wrote: > > FYI, we're speaking here only in the context of Fedora Extras and it's > buildsystem. I understand that - but I remember when there was something I wanted that didn't ship with Red Hat - it was great when a src.rpm would "just build". From lists at forevermore.net Fri May 19 20:41:26 2006 From: lists at forevermore.net (Chris Petersen) Date: Fri, 19 May 2006 13:41:26 -0700 Subject: Thoughts about courier-mta packaging? Message-ID: <446E2D76.7020004@forevermore.net> I use courier as a mail server both at work and at home, and have often wondered why it wasn't included as part of fedora extras. Sam (the author) has built a wonderful multi-distro spec that works fine (except for one missing build-dep that's specific to a package split in fc4; an easy fix). I'd be more than happy to submit/maintain the package in extras if it didn't require maintaining the spec myself -- it's HUGE and complicated and there's no need to maintain a separate one when the upstream author does it already. I couldn't find any info about courier in bugzilla or the list archives, so I figured I'd toss it out here for a quick discussion before submitting the idea for package review. -Chris From jkeating at redhat.com Fri May 19 20:44:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 19 May 2006 16:44:28 -0400 Subject: Thoughts about courier-mta packaging? In-Reply-To: <446E2D76.7020004@forevermore.net> References: <446E2D76.7020004@forevermore.net> Message-ID: <1148071468.12055.7.camel@ender> On Fri, 2006-05-19 at 13:41 -0700, Chris Petersen wrote: > I couldn't find any info about courier in bugzilla or the list > archives, > so I figured I'd toss it out here for a quick discussion before > submitting the idea for package review. > IIRC Sam is already packaging some things for Extras, leading up to Courier perhaps. Sam? -- 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 michael at knox.net.nz Fri May 19 21:40:14 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 20 May 2006 09:40:14 +1200 Subject: taking owership.. Message-ID: <446E3B3E.1090408@knox.net.nz> of ots if there is no objections. Michael From lists at forevermore.net Fri May 19 23:38:50 2006 From: lists at forevermore.net (Chris Petersen) Date: Fri, 19 May 2006 16:38:50 -0700 Subject: claiming ownership of rsnapshot Message-ID: <446E570A.2010407@forevermore.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191603 Yay, my first package... - -Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEblcKrSbyO+OXkmERArVnAJ0Yxw1qLGIfNWbWV4o1NsurHHG1wACeILap lmBTcHivaHz/mPD+TOU0B2s= =IgMR -----END PGP SIGNATURE----- From gauret at free.fr Sat May 20 07:22:50 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 20 May 2006 09:22:50 +0200 Subject: Trouble with the new Amarok version Message-ID: I'm maintaining Amarok in Extras, and version 1.4 final is out. This version removes the gstreamer engine, because the devs judged it to be not ready yet (which is true, no streaming for example). That leaves amarok with two engines, Xine and Helix, and at least one of them has to be present. The problem is that Xine contains mp3 decoding code, and thus is not in Extras, and HelixPlayer is ExcludeArch'd ppc64 x86_64 s390 s390x ia64 As a consequence, since 1.4 final there is no engine available on x86_64. There is no clean way to reactivate the gstreamer engine (gone from the tarball), so I'm thinking about ExcludArch'ing Amarok in the same way as HelixPlayer. It's pretty sad because it means x86_64 users won't have it, even if they can get the xine engine plugin from /somewhere else/. Do you see any other option ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "L'adulte ne croit pas au P?re No?l. Il vote." -- Pierre Desproges From ville.skytta at iki.fi Sat May 20 07:40:27 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 20 May 2006 10:40:27 +0300 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: <1148110827.2765.55.camel@localhost.localdomain> On Sat, 2006-05-20 at 09:22 +0200, Aurelien Bompard wrote: > There is no clean way to reactivate the gstreamer engine (gone from the > tarball), so I'm thinking about ExcludArch'ing Amarok in the same way as > HelixPlayer. It's pretty sad because it means x86_64 users won't have it, > even if they can get the xine engine plugin from /somewhere else/. If that's the only way, I'd suggest making the change in devel only and leaving older distro versions (including FC-5) where they are now for all archs. From gajownik at fedora.pl Sat May 20 10:03:56 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 20 May 2006 12:03:56 +0200 Subject: Taking ownership of yakuake Message-ID: <446EE98C.6050301@fedora.pl> Hi! I'm taking ownership of yakuake if there is no objection :) Regards, Dawid -- ^_* From hugo at devin.com.br Sat May 20 10:13:30 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 20 May 2006 07:13:30 -0300 Subject: Taking ownership of yakuake In-Reply-To: <446EE98C.6050301@fedora.pl> References: <446EE98C.6050301@fedora.pl> Message-ID: <200605200713.35068.hugo@devin.com.br> On Saturday 20 May 2006 07:03, Dawid Gajownik wrote: > Hi! Hau! > I'm taking ownership of yakuake if there is no objection :) Do it! I'm really waiting for it to enter Extras... ;) > Regards, > Dawid -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From chitlesh at fedoraproject.org Sat May 20 12:20:27 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 20 May 2006 14:20:27 +0200 Subject: Taking ownership of yakuake In-Reply-To: <200605200713.35068.hugo@devin.com.br> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> Message-ID: <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> On 5/20/06, Hugo Cisneiros wrote: > On Saturday 20 May 2006 07:03, Dawid Gajownik wrote: > > Hi! > > Hau! > > > I'm taking ownership of yakuake if there is no objection :) > > Do it! I'm really waiting for it to enter Extras... ;) > > > Regards, > > Dawid I thought you Hugo you wanted to push yakuake into extras. Chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Sat May 20 12:57:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 20 May 2006 07:57:25 -0500 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: Aurelien Bompard wrote: > I'm maintaining Amarok in Extras, and version 1.4 final is out. This version > removes the gstreamer engine, because the devs judged it to be not ready > yet (which is true, no streaming for example). > That leaves amarok with two engines, Xine and Helix, and at least one of > them has to be present. We (someone) should probably try to get nmm into Extras, that would make 3. -- Rex From buildsys at fedoraproject.org Sat May 20 12:42:57 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 20 May 2006 08:42:57 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060520124257.D29B9152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 pop-before-smtp-1.41-1.fc3 tinyerp-3.3.0-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 20 12:43:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 20 May 2006 08:43:06 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060520124306.1B40C152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 10 htop-0.6.2-1.fc4 kismet-0.0.2006.04.R1-2.fc4 mercurial-0.9-1.fc4 mftrace-1.2.4-2.fc4 pop-before-smtp-1.41-1.fc4 python-kid-0.9.1-1.fc4 rogue-5.4.2-5.fc4 tinyerp-3.3.0-1.fc4 wmx-6pl1-8.fc4 ytalk-3.3.0-4.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 20 12:43:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 20 May 2006 08:43:34 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060520124334.B1C86152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 18 celestia-1.4.1-2.fc5 dia-0.95-2.fc5 galago-daemon-0.5.0-2.fc5 htop-0.6.2-1.fc5 kismet-0.0.2006.04.R1-2.fc5 libkexif-0.2.3-1.fc5 libkipi-0.1.4-1.fc5 mercurial-0.9-1.fc5 mftrace-1.2.4-2.fc5 pop-before-smtp-1.41-1.fc5 python-kid-0.9.1-1.fc5 rogue-5.4.2-5.fc5 scim-skk-0.5.2-4.fc5 scim-tomoe-0.2.0-5.fc5 tiger-3.2.1-4.fc5 tinyerp-3.3.0-1.fc5 wmx-6pl1-8.fc5 ytalk-3.3.0-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat May 20 12:44:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 20 May 2006 08:44:05 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060520124405.14F65152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 21 bmp-flac2-009-1.fc6 celestia-1.4.1-2.fc6 dia-0.95-2.fc6 galago-daemon-0.5.0-3.fc6 htop-0.6.2-1.fc6 isic-0.06-2.fc6 libapreq2-2.08-0.rc1.1.fc6 libkexif-0.2.3-1.fc6 libkipi-0.1.4-1.fc6 lilypond-2.8.3-1.fc6 mftrace-1.2.4-2.fc6 paps-0.6.6-1.fc6 perl-Net-Netmask-1.9012-2.fc6 perl-Socket6-0.19-2.fc6 pop-before-smtp-1.41-1.fc6 rsnapshot-1.2.3-2 tiger-3.2.1-4.fc6 tinyerp-3.3.0-1.fc6 tpb-0.6.4-4.fc6 wmx-6pl1-8.fc6 ytalk-3.3.0-4.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From gajownik at fedora.pl Sat May 20 13:46:21 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 20 May 2006 15:46:21 +0200 Subject: Taking ownership of yakuake In-Reply-To: <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> Message-ID: <446F1DAD.9050908@fedora.pl> Dnia 05/20/2006 02:27 PM, U?ytkownik Chitlesh GOORAH napisa?: >> Do it! I'm really waiting for it to enter Extras... ;) If I understand this page correctly ? http://fedoraproject.org/wiki/Extras/OrphanedPackages I must wait one week more :( > I thought you Hugo you wanted to push yakuake into extras. We have been discussing this issue here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471#c2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186283#c8 Regards, Dawid -- ^_* From bugs.michael at gmx.net Sat May 20 14:20:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 20 May 2006 16:20:35 +0200 Subject: Taking ownership of yakuake In-Reply-To: <446F1DAD.9050908@fedora.pl> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> <446F1DAD.9050908@fedora.pl> Message-ID: <20060520162035.6c2b59fb.bugs.michael@gmx.net> On Sat, 20 May 2006 15:46:21 +0200, Dawid Gajownik wrote: > Dnia 05/20/2006 02:27 PM, U?ytkownik Chitlesh GOORAH napisa?: > > >> Do it! I'm really waiting for it to enter Extras... ;) > > If I understand this page correctly ? > http://fedoraproject.org/wiki/Extras/OrphanedPackages I must wait one > week more :( No, just take _this one_. From fedora at liebchen-online.de Sat May 20 15:03:57 2006 From: fedora at liebchen-online.de (Jens Liebchen) Date: Sat, 20 May 2006 17:03:57 +0200 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: <446F2FDD.9070408@liebchen-online.de> Aurelien Bompard schrieb: > As a consequence, since 1.4 final there is no engine available on x86_64. > > There is no clean way to reactivate the gstreamer engine (gone from the > tarball), so I'm thinking about ExcludArch'ing Amarok in the same way as > HelixPlayer. It's pretty sad because it means x86_64 users won't have it, > even if they can get the xine engine plugin from /somewhere else/. > Do you see any other option ? No, this is the best temporary solution, until we have a engine for x86_64 that can ship with fedora. We really should update at least the other archs, as they currently ship with a 1.4beta3 version which has some really nasty bugs that are fixed in 1.4 final. So staying at 1.4beta3 and pushing 1.4 final only into devel like Ville suggested is a bad idea for the majority of people. In my opinion Aurelien should release the final packages for all possible architectures and stay at version 1.4beta3 in x86_64 until a solution is found for the missing sound engine. When there is one, we can release a new package for all archs including this solution. Doing so, we improve stability for the majority of users a lot and we do not lessen stability for x86_64 users. Cheers, Jens From buildsys at fedoraproject.org Sat May 20 15:18:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 20 May 2006 15:18:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-20 Message-ID: <20060520151839.6709.48171@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 sqlite-tcl 2.8.16-1.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 sqlite-tcl 2.8.16-1.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: sqlite-tcl - 2.8.16-1.i386 from fedora-extras-3-i386 unresolved deps: sqlite = 0:2.8.16-1 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sqlite-tcl - 2.8.16-1.x86_64 from fedora-extras-3-x86_64 unresolved deps: sqlite = 0:2.8.16-1 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Sat May 20 15:18:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 20 May 2006 15:18:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-20 Message-ID: <20060520151839.6721.95524@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Sat May 20 15:18:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 20 May 2006 15:18:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-20 Message-ID: <20060520151839.6723.82134@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gparted 0.2.4-2.fc6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 xchat-gnome 0.11-2.fc6.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gparted 0.2.4-2.fc6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc xchat-gnome 0.11-2.fc6.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gparted 0.2.4-2.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 xchat-gnome 0.11-2.fc6.x86_64 ====================================================================== New report for: dakingun AT gmail.com package: gparted - 0.2.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: gparted - 0.2.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: gparted - 0.2.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 ====================================================================== New report for: steve AT silug.org package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 ====================================================================== New report for: bdpepple AT ameritech.net package: xchat-gnome - 0.11-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnotify.so.0 package: xchat-gnome - 0.11-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnotify.so.0()(64bit) package: xchat-gnome - 0.11-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnotify.so.0 ====================================================================== package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Sat May 20 15:18:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 20 May 2006 15:18:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-20 Message-ID: <20060520151839.6718.82832@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From gauret at free.fr Sat May 20 15:28:19 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 20 May 2006 17:28:19 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Rex Dieter wrote: > We (someone) should probably try to get nmm into Extras, that would make > 3. Nope, either Xine or Helix are required to build Amarok. It's in the readme, and the configure script checks it. Of course I could patch the configure script to make NMM sufficient, as I did previously for gstreamer, but we still have to include NMM in extras, make sure it does not contain libmad code and that it builds and works fine on x86_64. That would take some time. Well, it still looks like the cleanest way, so I'll try packaging NMM. Rex, you don't happen to have a spec file for it available, do you ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr One of the universal rules of happiness is: "Always be wary of any helpful item that weighs less than its operating manual". From gauret at free.fr Sat May 20 15:30:16 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 20 May 2006 17:30:16 +0200 Subject: Trouble with the new Amarok version References: <446F2FDD.9070408@liebchen-online.de> Message-ID: Jens Liebchen wrote: > In my opinion Aurelien should release the final packages for all > possible architectures and stay at version 1.4beta3 in x86_64 until a > solution is found for the missing sound engine. That is not possible, there are only branches for distro versions, not archs IIRC. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Make everything as simple as possible, but not simpler." -- Albert Einstein From ville.skytta at iki.fi Sat May 20 16:25:22 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 20 May 2006 19:25:22 +0300 Subject: Trouble with the new Amarok version In-Reply-To: <446F2FDD.9070408@liebchen-online.de> References: <446F2FDD.9070408@liebchen-online.de> Message-ID: <1148142322.2765.87.camel@localhost.localdomain> On Sat, 2006-05-20 at 17:03 +0200, Jens Liebchen wrote: > We really should update at least the other archs, as they currently ship > with a 1.4beta3 version which has some really nasty bugs that are fixed > in 1.4 final. So staying at 1.4beta3 and pushing 1.4 final only into > devel like Ville suggested is a bad idea for the majority of people. Note that the if the new one is pushed, automatic cleanup scripts will at some point remove the SRPM that was sometime used to build the x86_64 package. The version skew will also probably cause problems for external engine packagers. And Like Aurelien already mentioned, where do you maintain the old package for x86_64? When a security issue is found that requires action for all architectures, how do you handle it? > In my opinion Aurelien should release the final packages for all > possible architectures -1 if it means introducing the version skew. From fedora at liebchen-online.de Sat May 20 16:45:01 2006 From: fedora at liebchen-online.de (Jens Liebchen) Date: Sat, 20 May 2006 18:45:01 +0200 Subject: Trouble with the new Amarok version In-Reply-To: <1148142322.2765.87.camel@localhost.localdomain> References: <446F2FDD.9070408@liebchen-online.de> <1148142322.2765.87.camel@localhost.localdomain> Message-ID: <446F478D.3070301@liebchen-online.de> Ville Skytt? schrieb: >> We really should update at least the other archs, as they currently ship >> with a 1.4beta3 version which has some really nasty bugs that are fixed >> in 1.4 final. So staying at 1.4beta3 and pushing 1.4 final only into >> devel like Ville suggested is a bad idea for the majority of people. > > Note that the if the new one is pushed, automatic cleanup scripts will > at some point remove the SRPM that was sometime used to build the x86_64 > package. The version skew will also probably cause problems for > external engine packagers. And Like Aurelien already mentioned, where > do you maintain the old package for x86_64? When a security issue is > found that requires action for all architectures, how do you handle it? > >> In my opinion Aurelien should release the final packages for all >> possible architectures > > -1 if it means introducing the version skew. I didn't saw the point that the old work will be lost then and we can't split the package easily. So, as you and Aurelien already pointed out, the only thing we can do is to try to fix the sound engine problem before releasing the packages (and thus fixing the bugs in 1.4beta3). Cu, Jens From rdieter at math.unl.edu Sat May 20 18:18:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 20 May 2006 13:18:45 -0500 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: Aurelien Bompard wrote: > Rex Dieter wrote: >> We (someone) should probably try to get nmm into Extras, that would make >> 3. > > Nope, either Xine or Helix are required to build Amarok. It's in the readme, > and the configure script checks it. > Of course I could patch the configure script to make NMM sufficient, My bad then. I had been under the impression that nmm could be used as the (only/default) output engine. I'm sure amarok's dev's have a good reason why not, right? In retrospect, I think they (amarok's devs) made a serious error in judgement(*) pulling *both* arts and gstreamer(08 or 10) support for this release. To me, that alienates quite a large population (ie, those like fedora who don't have xine). -- Rex (*) See? I refrained from calling them stupid. oops... From gauret at free.fr Sat May 20 18:27:18 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 20 May 2006 20:27:18 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Rex Dieter wrote: > I'm sure amarok's dev's have a good reason why not, right? Oh yeah, probably the same reason they dropped gst10. Anyway, we have to have at least one engine to ship Amarok for x86_64, so I don't have a choice here. And NMM looks like a PITA to package (dozens of build deps, half of them forbidden in Fedora) > In retrospect, I think they (amarok's devs) made a serious error in > judgement(*) pulling *both* arts and gstreamer(08 or 10) support for > this release. To me, that alienates quite a large population (ie, those > like fedora who don't have xine). Agreed wholeheartedly. I have read less politically correct comments from them about distros which don't ship patent-encumbered software such as mp3 decoding, and thus Xine. Anyway, that's not the point here. I'll let you know when the NMM package takes shape, if you're interested in reviewing it, or if you want it for kde-redhat. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Recursion: (n.) See "Recursion". From gajownik at fedora.pl Sat May 20 18:44:35 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 20 May 2006 20:44:35 +0200 Subject: Taking ownership of yakuake In-Reply-To: <20060520162035.6c2b59fb.bugs.michael@gmx.net> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> <446F1DAD.9050908@fedora.pl> <20060520162035.6c2b59fb.bugs.michael@gmx.net> Message-ID: <446F6393.7050900@fedora.pl> Dnia 05/20/2006 04:20 PM, U?ytkownik Michael Schwendt napisa?: > No, just take _this one_. Done. Regards, Dawid -- ^_* From triad at df.lth.se Sat May 20 18:57:44 2006 From: triad at df.lth.se (Linus Walleij) Date: Sat, 20 May 2006 20:57:44 +0200 (CEST) Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: On Sat, 20 May 2006, Aurelien Bompard wrote: > Do you see any other option ? Are the improvements in the new Amarok so important that it is impossible to live without them and simply stall the package at the current version until they adopt a more mature gStreamer and/or arts? Linus From hugo at devin.com.br Sat May 20 19:17:22 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 20 May 2006 16:17:22 -0300 Subject: Taking ownership of yakuake In-Reply-To: <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> Message-ID: <200605201617.22932.hugo@devin.com.br> On Saturday 20 May 2006 09:20, Chitlesh GOORAH wrote: > I thought you Hugo you wanted to push yakuake into extras. As the yakuake package was finally orphaned, and as this bugzilla entry[1] (and this one[2] too) shows, I gave up trying to maintain it to give place for other user ;-) [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186283 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190471 -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From fedora at liebchen-online.de Sat May 20 19:24:04 2006 From: fedora at liebchen-online.de (Jens Liebchen) Date: Sat, 20 May 2006 21:24:04 +0200 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: <446F6CD4.9060503@liebchen-online.de> Linus Walleij schrieb: > Are the improvements in the new Amarok so important that it is > impossible to live without them and simply stall the package at the > current version until they adopt a more mature gStreamer and/or arts? Imho: yeah. The actual version in extras is 1.4beta3, which is far from being really stable. Some of the bugs rendering this version unusable (for a stable distro release, not for the beta itself) are: Settings are lost sometimes after restarting (especially for podcasts) or copying to vfat players renames all tracks depending on the title, so all albums are getting sorted wrong on mobile vfat players (The last bug had 170 votes in KDE's bugzilla). 1.4 final should fix these and some more issues. At least I am not aware of any security issues, but as these usability issues are really nasty ones happening in the major features of amarok 1.4 namely podcasting and mobile player integration, we should not wait longer than necessary. Otherwise many users would be badly disappointed by the release and in the next step by fedora. Unfortunately, getting a usable sound engine doesn't look like an easy solvable problem :-( Anyway, I am voting against waiting. Cheers, Jens From bugzilla at redhat.com Sat May 20 20:35:03 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 20 May 2006 16:35:03 -0400 Subject: [Bug 174325] Review Request: mod_spin Apache module In-Reply-To: Message-ID: <200605202035.k4KKZ3TV022685@www.beta.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mod_spin Apache module https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174325 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com tibbs at math.uh.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 | nThis| | -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From gajownik at fedora.pl Sat May 20 21:00:33 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 20 May 2006 23:00:33 +0200 Subject: Taking ownership of yakuake In-Reply-To: <200605201617.22932.hugo@devin.com.br> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> <200605201617.22932.hugo@devin.com.br> Message-ID: <446F8371.7070503@fedora.pl> Dnia 05/20/2006 09:10 PM, U?ytkownik Hugo Cisneiros napisa?: > I gave up trying to maintain it to give place > for other user ;-) ...and I wanted to thank you for this once again :D -- ^_* From kevin.kofler at chello.at Sat May 20 20:56:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 20 May 2006 20:56:51 +0000 (UTC) Subject: Trouble with the new Amarok version References: Message-ID: Aurelien Bompard writes: > There is no clean way to reactivate the gstreamer engine (gone from the > tarball) What about just taking it from SVN (or failing that, from the Beta 3 tarball, but you should probably be able to get the latest version from KDE SVN) and add it as an extra Source1? While this may upset the amaroK developers, it's IMHO the cleanest solution from the users' perspective. Kevin Kofler From chitlesh at fedoraproject.org Sat May 20 21:32:55 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 20 May 2006 23:32:55 +0200 Subject: Taking ownership of yakuake In-Reply-To: <446F8371.7070503@fedora.pl> References: <446EE98C.6050301@fedora.pl> <200605200713.35068.hugo@devin.com.br> <13dbfe4f0605200520o42cf4736x2192e05094718962@mail.gmail.com> <200605201617.22932.hugo@devin.com.br> <446F8371.7070503@fedora.pl> Message-ID: <13dbfe4f0605201432w7d118270o31b23043babb51f@mail.gmail.com> Go on guys, push that great KDE app to Extras :) Chitlesh -- http://clunixchit.blogspot.com From mpeters at mac.com Sat May 20 22:34:36 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 20 May 2006 15:34:36 -0700 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: <1148164476.3189.2.camel@atlantis.mpeters.local> On Sat, 2006-05-20 at 20:56 +0000, Kevin Kofler wrote: > Aurelien Bompard writes: > > There is no clean way to reactivate the gstreamer engine (gone from the > > tarball) > > What about just taking it from SVN (or failing that, from the Beta 3 tarball, > but you should probably be able to get the latest version from KDE SVN) and add > it as an extra Source1? While this may upset the amaroK developers, it's IMHO > the cleanest solution from the users' perspective. ++ The only other option I see is to move it to livna and use xine until gstreamer backend is fixed. From lists at forevermore.net Sun May 21 03:31:22 2006 From: lists at forevermore.net (Chris Petersen) Date: Sat, 20 May 2006 20:31:22 -0700 Subject: dealing with "contrib" type directories Message-ID: <446FDF0A.2020907@forevermore.net> A couple of the things I package have "contrib" directories, and I'm wondering what the appropriate method is for dealing with them. Traditionally, I put them in %doc, which seems like a reasonable enough place. This brings me to my second problem: dependencies. rpm automatically extracts dependencies from all executable scripts in a package, including those listed in %doc. To get around this, I have to chmod all of the files in contrib directories to be non-executable. Is this the correct way to handle things? Is there a better way? -Chris From mpeters at mac.com Sun May 21 04:18:14 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 20 May 2006 21:18:14 -0700 Subject: dealing with "contrib" type directories In-Reply-To: <446FDF0A.2020907@forevermore.net> References: <446FDF0A.2020907@forevermore.net> Message-ID: <1148185094.4296.3.camel@atlantis.mpeters.local> On Sat, 2006-05-20 at 20:31 -0700, Chris Petersen wrote: > A couple of the things I package have "contrib" directories, and I'm > wondering what the appropriate method is for dealing with them. > > Traditionally, I put them in %doc, which seems like a reasonable enough > place. > > This brings me to my second problem: dependencies. rpm automatically > extracts dependencies from all executable scripts in a package, > including those listed in %doc. To get around this, I have to chmod all > of the files in contrib directories to be non-executable. > > Is this the correct way to handle things? Is there a better way? That is the correct way AFAIK. If they call /usr/local/bin/{perl,python,etc} it is kind to change them to /usr/bin/ but I'm not sure that is necessary if you are going to remove the execution bit. From kevin.kofler at chello.at Sun May 21 06:28:45 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 21 May 2006 06:28:45 +0000 (UTC) Subject: Trouble with the new Amarok version References: Message-ID: Aurelien Bompard writes: > I'm maintaining Amarok in Extras, and version 1.4 final is out. Oh, by the way, you need this patch: http://svntalk.pwsp.net/project/amaroK/revision/541986 or upgrades from versions older than Beta 3 (for example on FC4->FC5 upgrades) will delete the collection/playlist database. (This was mentioned on dot.kde.org.) Kevin Kofler From gauret at free.fr Sun May 21 07:39:24 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 21 May 2006 09:39:24 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Kevin Kofler wrote: > What about just taking it from SVN (or failing that, from the Beta 3 > tarball, but you should probably be able to get the latest version from > KDE SVN) and add it as an extra Source1? While this may upset the amaroK > developers, it's IMHO the cleanest solution from the users' perspective. Yes, since NMM won't build with GCC 4.1, I think I'll do that. Thanks for your input. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "L'adulte ne croit pas au P?re No?l. Il vote." -- Pierre Desproges From gauret at free.fr Sun May 21 07:45:54 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 21 May 2006 09:45:54 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Kevin Kofler wrote: > Oh, by the way, you need this patch: > http://svntalk.pwsp.net/project/amaroK/revision/541986 > or upgrades from versions older than Beta 3 (for example on FC4->FC5 > upgrades) will delete the collection/playlist database. (This was > mentioned on dot.kde.org.) They have released a new tarball to fix this issue, and it's the one I'm using. But thanks for the report. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr The only "intuitive" interface is the nipple. After that it's all learned. From fedora at leemhuis.info Sun May 21 09:33:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 May 2006 11:33:49 +0200 Subject: Summary from this weeks FESCo meeting Message-ID: <1148204030.2296.20.camel@localhost.localdomain> == Summary == Present from FESCo: thl, skvidal, jeremy, mschwendt, warren, spot, thomasvs, ensc, jpo * 19:02 {x,}emacs-muse, emacs-comon-muse or emacsen-muse ? * emacs-common-muse ! * 19:05 buildsys-build -- What packages shall be in the default buildroot? * spot> | we should keep this to the smallest possible set of packages * skvidal> | so whenever someone decides on what these things are, let me know of the list so I can edit the right files * spot > | ok, i just sent an email to fesco with the packages used by mock that are above/beyond the exceptions; i'm not against adding some of these to the Exceptions list with rationalizations * spot> | i'll work on the "new Exceptions" * 19:14 Deduping of needsign packages * mschwendt will lokk after this (it's on the schedule for a long time already) * 19:19 How to solve legal issues * thl put that on the schedule -- seems the communication between Extras and Legal isn't perfect and some things got stuck due to that * warren> | thl, generally legal tells me, "If in doubt, the answer is no." * spot> | legal issues wrt packaging should be decided by the packaging committee * 19:20 packaging committee * spot has a mandate for such a committee to exist and he has been appointed [by FAB] to make it go. :) * some discussion if FESCo or another Committee should handle that; the idea was to have a committee that spanned both core and extras defining packaging standards for both; we need something today, and the current plan seems to be to create a packaging committee (lead by spot); we'll probably revisit this issue after fc6; if at any point, it becomes irrelevant, we'll absorb it back in * Weekly sponsorship nomination * _wart_ (Michael Thomas) nominates himself; FESCo will get back to him you next week * 19:38 what do we do with MIA/AWOL maintainers? * See also https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00319.html * Just to make sure we all know what's meant: * AWOL=absent without leave * MIA=missing in action * some discussions; jwb, mschwendt and Michael J Knox seem to be interested in it. See full log for details * 19:48 co-maintainership is brought into the MIA/AWOL discussion * warren> | Yeah, co-maintainership is something we need too... (thl puts it on the schedule) * warren> | I suppose fedora account system is the proper place to track this in a database, and it can be * mschwendt> | warren: plus a tracker for contributors who are believed to be MIA/AWOL * warren> | Let's put together a design proposal for this packages database * warren> | I'll write something up initially for fedora-extras-list * 19:58 Incompatible package upgrade policy (directfb for example) * some discussion around https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00433.html * maybe there should be at most one compat-*package per case ? * spot> | thl: let me write something up and we'll hash it out later; i think i know what i want here * 20:07 Free discussion * 20:07 spot> | ruby guidelines; http://www.fedoraproject.org/wiki/Packaging/Ruby * some discussions if a "Ruby (abi) = foo" would make sense; rawhide might have something like that now. Spot will take a closer look if we can have something compatible for older distros * 20:11 php: /var/www/ vs. /usr/share * spot> | someone might just have to put their foot down and choose a side. * spot> | i think i vote for php code to go into /usr/share i dont want to step on userdata living in /var/www * ixs> | fine. I'll consider that settled then. * spot> | ixs: can you write up a little policy blurb for me to add to the guidelines == Full Log == In the wiki at http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060518 -- Thorsten Leemhuis From buildsys at fedoraproject.org Sun May 21 16:05:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 21 May 2006 12:05:31 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060521160531.8512B152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 20 bmp-flac2-009-1.fc5 dejavu-fonts-2.6.0-1.fc5 duplicity-0.4.2-1.fc5 gnofract4d-2.14-2.fc5 gnumeric-1.6.3-2.fc5 hspell-1.0-3.fc5 libnfnetlink-0.0.14-3.fc5 ots-0.4.2-9.fc5 perl-Class-Inspector-1.16-1.fc5 perl-File-Find-Rule-0.29-1.fc5 perl-Module-Build-0.2800-2.fc5 perl-Params-Util-0.14-1.fc5 perl-Params-Validate-0.82-1.fc5 python-kid-0.9.1-2.fc5 rafkill-1.2.1-1.fc5 rsnapshot-1.2.3-2.fc5 sylpheed-claws-plugins-2.2.0-1.fc5 xmms-alarm-0.3.7-4.fc5 yakuake-2.7.5-2.fc5 ytalk-3.3.0-5.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 21 16:05:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 21 May 2006 12:05:31 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060521160531.72AA1152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 27 MochiKit-1.3.1-1.fc6 acpitool-0.4.5-1.fc6 apt-0.5.15lorg3.1-3_rc2.fc6 cppunit-1.11.6-1.fc6 duplicity-0.4.2-1.fc6 fedora-package-config-apt-5.89-4 fuse-2.5.3-2.fc6 gnofract4d-2.14-2.fc6 gnumeric-1.6.3-2.fc6 gossip-0.11-4.fc6 gtkglextmm-1.2.0-2 hspell-1.0-3.fc6 lilypond-doc-2.8.3-1.fc6 orpie-1.4.3-4 ots-0.4.2-9.fc6 perl-Class-Inspector-1.16-1.fc6 perl-File-Find-Rule-0.29-1.fc6 perl-PadWalker-1.0-1.fc6 perl-Params-Util-0.14-1.fc6 perl-Params-Validate-0.82-1.fc6 perl-YAML-0.58-3.fc6 python-kid-0.9.1-2.fc6 rsnapshot-1.2.3-2.fc6 xchat-gnome-0.11-3.fc6 xmms-alarm-0.3.7-4.fc6 yakuake-2.7.5-2.fc6 ytalk-3.3.0-5.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 21 16:05:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 21 May 2006 12:05:31 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060521160531.8D3F2152189@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 15 celestia-1.4.1-0.2.fc4 dejavu-fonts-2.6.0-1.fc4 duplicity-0.4.2-1.fc4 gnofract4d-2.14-2.fc4 hspell-1.0-4.fc4 ots-0.4.2-9.fc4 perl-Class-Inspector-1.16-1.fc4 perl-File-Find-Rule-0.29-1.fc4 perl-Module-Build-0.2800-2.fc4 perl-Params-Util-0.14-1.fc4 perl-Params-Validate-0.82-1.fc4 python-kid-0.9.1-2.fc4 rsnapshot-1.2.3-2.fc4 yakuake-2.7.5-2.fc4 ytalk-3.3.0-5.fc4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 21 16:05:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 21 May 2006 12:05:31 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060521160531.9470A15218A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 2 acpitool-0.4.5-1.fc3 perl-File-Find-Rule-0.29-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 21 16:30:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 21 May 2006 16:30:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-21 Message-ID: <20060521163046.31100.26872@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Sun May 21 16:30:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 21 May 2006 16:30:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-21 Message-ID: <20060521163046.31097.46731@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Sun May 21 16:30:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 21 May 2006 16:30:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-21 Message-ID: <20060521163046.31102.9760@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gparted 0.2.4-2.fc6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gparted 0.2.4-2.fc6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gparted 0.2.4-2.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gparted - 0.2.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gparted - 0.2.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: gparted - 0.2.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 From buildsys at fedoraproject.org Sun May 21 16:30:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 21 May 2006 16:30:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-21 Message-ID: <20060521163046.31090.11563@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From gauret at free.fr Sun May 21 17:43:01 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 21 May 2006 19:43:01 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Kevin Kofler wrote: > What about just taking it from SVN (or failing that, from the Beta 3 > tarball, but you should probably be able to get the latest version from > KDE SVN) and add it as an extra Source1? While this may upset the amaroK > developers, it's IMHO the cleanest solution from the users' perspective. OK, so I finally did that. I took the gstreamer engine from beta3 (I tried and failed with SVN, because I couldn't get automake to generate the Makefile.in properly). I've added back the gstreamer 0.10 engine only for the archs where HelixPlayer is unavailable (mainly x86_64), so the amarok devs shouldn't be too upset. Thanks to all for your advice Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Programmer: A biological system designed to convert coffee and pizza into code. From rdieter at math.unl.edu Sun May 21 18:43:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 21 May 2006 13:43:07 -0500 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: Aurelien Bompard wrote: > Anyway, that's not the point here. I'll let you know when the NMM package > takes shape, if you're interested in reviewing it, or if you want it for > kde-redhat. Absolutely. I had only taken a passing look at it. I'm glad someone (else) is looking at packaging it. (: -- Rex From kevin.kofler at chello.at Sun May 21 19:48:13 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 21 May 2006 19:48:13 +0000 (UTC) Subject: Trouble with the new Amarok version References: Message-ID: Aurelien Bompard writes: > I've added back the gstreamer 0.10 engine only for the archs where > HelixPlayer is unavailable (mainly x86_64), so the amarok devs shouldn't be > too upset. The question is though: how useful is the HelixPlayer engine in practice? I understand that it technically supports more amaroK features (such as streaming), but that format support is lacking in Helix unless you have the proprietary RealPlayer GOLD installed. Kevin Kofler From gauret at free.fr Sun May 21 20:17:18 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 21 May 2006 22:17:18 +0200 Subject: Trouble with the new Amarok version References: Message-ID: Kevin Kofler wrote: > The question is though: how useful is the HelixPlayer engine in practice? It works pretty well here, reading ogg vorbis files. I don't know how to add mp3 support to Helix, but there is still the possibility to get the xine engine from /somewhere else/. Since without this additional repo you wouldn't be able to read mp3 files anyway, I think it's not a problem. If you suggest I should add back gst10 on all archs, I'd rather follow the dev's opinion on the maturity of this engine, unless I have no other choice (as on x86_64). Having no streaming support without warning with gst10 surprised me a lot, and will probably be the source of many bug reports. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin From lists at forevermore.net Sun May 21 20:25:10 2006 From: lists at forevermore.net (Chris Petersen) Date: Sun, 21 May 2006 13:25:10 -0700 Subject: claiming ownership of new package: lineakd Message-ID: <4470CCA6.70400@forevermore.net> Minor compile issue on ppc arch that will be resolved as soon as I hear back from upstream. Also, would be grateful if anyone is interested in reviewing the last 3 parts of this program (separate packages). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191605 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191606 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191607 -Chris From chris.stone at gmail.com Sun May 21 22:22:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 21 May 2006 15:22:53 -0700 Subject: Unorphan cksfv Message-ID: I wish to unorphan cksfv. Please speak up now if there are any objections, or forever hold your peace. From cweyl at alumni.drew.edu Mon May 22 03:28:16 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 21 May 2006 20:28:16 -0700 Subject: taking over perl-XML-XPath Message-ID: <7dd7ab490605212028w3d7c131wfc54fe8314668538@mail.gmail.com> If no one objects, I'll take over the orphaned package perl-XML-XPath... -Chris -- Chris Weyl Ex astris, scientia From jspaleta at gmail.com Mon May 22 13:51:28 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 22 May 2006 09:51:28 -0400 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both Message-ID: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> Good Morning, Anyone interested in taking over maintainership of glabels and istanbul? In just under a month I will be moving to Alaska and I will be without residential broadband for the foreseeable future. Whats worse is the new place of employment which does have band is currently an all windows shop (something I'll fix in a finite amount of time), making a tad more difficult to sneak in a few minutes of fedora related moonlighting, until I'm there long to resuscitate some decommissioned desktops into Linux machines. So both of these packages will be effectively orphaned unless someone else becomes the primary maintainer. glabels in fedora extras is currently tracking the stable glabels branch, and its pretty straight forward. Just get on the low traffic upstream glabels mailinglist and watch for any "stable" release announcements or upstream bugs. Istanbul will require more work at some point. Fedora's Istanbul is still using gstreamer08, and the version of Instanbul in cvs is ported to gstreamer-0.10. BUT the X display grabbing gstreamer module that cvs Istanbul relies on isn't in gstreamer-bad, which fedora isn't going to ship. Moving fedora-extras-development to the gst 0.10 based Istanbul, will have to wait for the module to move over to gstreamer-good and for that new release of gstreamer-good to be dropped into Core. You'll have to watch the gstreamer plugins release announcements and watch the changes in istanbul cvs to see when the pieces fall into place. This burned me leading up to fc5, I didn't realize that the required gst plugin was placed in the gstreamer-bad pile. There is also the chance to build the current gst08 based istanbul for FC4. Last time I checked the needed FC4 gsteamer-plugins package was in FC4 updates-testing. IF that has moved over to updates-released istanbul can be built for FE4. Istanbul is a very thin layer of python gui over gstreamer's inherent pipelining functionality. The real magic (or lack there of) is at the gstreamer plugin level. Any takers? -jef"I hope its not cold in Alaska"spaleta From thomas at apestaart.org Mon May 22 13:57:39 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 22 May 2006 15:57:39 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-21 In-Reply-To: <20060521163046.31102.9760@extras64.linux.duke.edu> References: <20060521163046.31102.9760@extras64.linux.duke.edu> Message-ID: <1148306259.2626.153.camel@otto.amantes> Hi, > gnonlin-devel 0.10.0.5-6.i386 This package should be removed from all repositories. Current gnonlin does not install or need to install any development files anymore. Maybe the gnonlin rpm could even obsoletes: it ? Thomas From thomas at apestaart.org Mon May 22 14:31:46 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 22 May 2006 16:31:46 +0200 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> Message-ID: <1148308306.2626.157.camel@otto.amantes> Hi, > Istanbul will require more work at some point. Fedora's Istanbul is > still using gstreamer08, and the version of Instanbul in cvs is ported > to gstreamer-0.10. BUT the X display grabbing gstreamer module that > cvs Istanbul relies on isn't in gstreamer-bad, which fedora isn't > going to ship. It was moved to -good in the 0.10.3 release of -good two weeks ago. Of course it would still need an update of the core package. Thomas From tcallawa at redhat.com Mon May 22 15:44:15 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 22 May 2006 10:44:15 -0500 Subject: Updates to Packaging Guidelines Message-ID: <1148312656.2295.89.camel@localhost.localdomain> Per FESCO, there was one major addition to the Packaging Guidelines: The naming scheme for addon emacs compatible components is: emacs-common-foo, where foo is the upstream name of the component. In addition, the kernel module naming was corrected to match the new guidelines for kernel module packaging (changed from kernel-module-foo to kmod-foo). ~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 buildsys at fedoraproject.org Mon May 22 16:03:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 22 May 2006 12:03:37 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060522160337.413DF152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 9 abcm2ps-4.12.18-1.fc3 awstats-6.5-3.fc3 bluefish-1.0.5-3.fc3 kipi-plugins-0.1.0-0.8.rc2.fc3 kmymoney2-0.8.4-1.fc3.1 metapixel-1.0.1-4.fc3 nagios-2.3.1-1.fc3 perl-Mail-Mbox-MessageParser-1.4003-1.fc3 videodog-0.31-3.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 22 16:03:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 22 May 2006 12:03:52 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060522160352.0B5F1152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 12 abcm2ps-4.12.18-1.fc4 acpitool-0.4.5-1.fc4.1 bluefish-1.0.5-3.fc4 emacs-auctex-11.82-10.fc4 gts-0.7.6-5.fc4 kipi-plugins-0.1.0-0.8.rc2.fc4 kmymoney2-0.8.4-1.fc4 libnfnetlink-0.0.14-3.fc4 metapixel-1.0.1-4.fc4 perl-Mail-Mbox-MessageParser-1.4003-1.fc4 perl-Socket6-0.19-2.fc4 videodog-0.31-3.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 22 16:04:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 22 May 2006 12:04:32 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060522160432.4CDC8152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 20 abcm2ps-4.12.18-1.fc5 acpitool-0.4.5-1.fc5.1 amarok-1.4.0-4.fc5 bluefish-1.0.5-3.fc5 emacs-auctex-11.82-10.fc5 gtkglextmm-1.2.0-2 gts-0.7.6-5.fc5 kipi-plugins-0.1.0-0.8.rc2.fc5 kmymoney2-0.8.4-1.fc5 lilypond-2.8.3-1.fc5 lilypond-2.8.3-2.fc5 lilypond-doc-2.8.3-1.fc5 metapixel-1.0.1-3.fc5 metapixel-1.0.1-4.fc5 musicbox-0.2.3-3.fc5 perl-Devel-Cycle-1.05-1.fc5 perl-Mail-Mbox-MessageParser-1.4003-1.fc5 perl-PadWalker-1.0-1.fc5 perl-Socket6-0.19-2.fc5 videodog-0.31-3.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 22 16:08:51 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 22 May 2006 12:08:51 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060522160851.C3112152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 21 NetworkManager-vpnc-0.7.0-0.cvs20060521.fc6 abcm2ps-4.12.18-1.fc6 amarok-1.4.0-4.fc6 bluefish-1.0.5-3.fc6 emacs-auctex-11.82-10.fc6 gts-0.7.6-5.fc6 kipi-plugins-0.1.0-0.8.rc2.fc6 kmymoney2-0.8.4-1.fc6 lineakd-0.8.4-4.fc6 mantis-1.0.3-1.fc6 metapixel-1.0.1-3.fc6 metapixel-1.0.1-4.fc6 musicbox-0.2.3-3.fc6 perl-Devel-Cycle-1.05-1.fc6 perl-Mail-Mbox-MessageParser-1.4003-1.fc6 pth-2.0.6-2.fc6 python-cheetah-2.0-0.rc6.0.fc6 python-krbV-1.0.12-3.fc6 python-krbV-1.0.13-2.fc6 synaptic-0.57.2-4.fc6 videodog-0.31-3.fc6 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From jonathan.underwood at gmail.com Mon May 22 16:18:08 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 22 May 2006 17:18:08 +0100 Subject: Updates to Packaging Guidelines In-Reply-To: <1148312656.2295.89.camel@localhost.localdomain> References: <1148312656.2295.89.camel@localhost.localdomain> Message-ID: <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> On 22/05/06, Tom 'spot' Callaway wrote: > Per FESCO, there was one major addition to the Packaging Guidelines: > > The naming scheme for addon emacs compatible components is: > emacs-common-foo, where foo is the upstream name of the component. > This is unclear as regarding the naming of the sub package names for the different flavours of emacs... guidelines now seem to indicate: emacs-common-foo for the package name and files common to all flavours. and subpackage names like xemacs-emacs-common-foo emacs-emacs-common-foo or perhaps, emacs-common-foo-xemacs etc etc. Seems a bit silly (!) However, the rejected alternative would have had the package name emacs-foo, which contains the files for GNU emacs, with subpackages xemacs-foo and emacs-foo-common, if required (the current guideline seems to want a rename of emacs-auctex to emacs-common-auctex, even though the package is only built for GNU Emacs). Eg. http://physics.open.ac.uk/~ju83/emacs-muse.spec Honestly, I really think this guideline should be reconsidered. Jonathan. From chris.stone at gmail.com Mon May 22 17:58:01 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 22 May 2006 10:58:01 -0700 Subject: Updates to Packaging Guidelines In-Reply-To: <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> Message-ID: On 5/22/06, Jonathan Underwood wrote: > However, the rejected alternative would have had the package name > emacs-foo, which contains the files for GNU emacs, with subpackages > xemacs-foo and emacs-foo-common, if required (the current guideline > seems to want a rename of emacs-auctex to emacs-common-auctex, even > though the package is only built for GNU Emacs). It would seem to me that if auctex is only usable for emacs (and not xemacs) then it would be named emacs-auctex. Simple as that. If auctex can be used for both emacs and xemacs then it would be called emacs-common-auctex. I'm not sure where the confusion lies? It seems to me you are over-thinking this issue, and trying to make it more complicated than it actually is. From jonathan.underwood at gmail.com Mon May 22 18:06:02 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 22 May 2006 19:06:02 +0100 Subject: Updates to Packaging Guidelines In-Reply-To: References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> Message-ID: <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> On 22/05/06, Christopher Stone wrote: > It would seem to me that if auctex is only usable for emacs (and not > xemacs) then it would be named emacs-auctex. Simple as that. If > auctex can be used for both emacs and xemacs then it would be called > emacs-common-auctex. I'm not sure where the confusion lies? That's not what the guideline says. That's (part of) the problem. The guideline specifically insists that emacs-auctex be renamed to emacs-common-auctex (go read it and see). > > It seems to me you are over-thinking this issue, and trying to make it > more complicated than it actually is. Yes, I did over think it. Then I realized what the simple solution was (see the emacs-muse.spec). Unfortunately, I made other people over think it too in the process. I suck :) The problem is that the Guideline is unecessarily complicated, when a much simpler and logical alternative exists. J. From jkeating at redhat.com Mon May 22 18:28:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 May 2006 14:28:02 -0400 Subject: Updates to Packaging Guidelines In-Reply-To: <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> Message-ID: <1148322482.337.27.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-22 at 19:06 +0100, Jonathan Underwood wrote: > The problem is that the Guideline is unecessarily complicated, when a > much simpler and logical alternative exists. > And that alternative would be...? -- 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 jonathan.underwood at gmail.com Mon May 22 18:24:54 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 22 May 2006 19:24:54 +0100 Subject: Updates to Packaging Guidelines In-Reply-To: <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> Message-ID: <645d17210605221124ma29d349jc5baec11b93491f6@mail.gmail.com> Actually, perhaps I am overanalysing.:) I'll go away and try it, and offer some suggested clarifications for the wiki. J. From tcallawa at redhat.com Mon May 22 19:04:22 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 22 May 2006 14:04:22 -0500 Subject: Updates to Packaging Guidelines In-Reply-To: <645d17210605221124ma29d349jc5baec11b93491f6@mail.gmail.com> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> <645d17210605221124ma29d349jc5baec11b93491f6@mail.gmail.com> Message-ID: <1148324662.2295.106.camel@localhost.localdomain> On Mon, 2006-05-22 at 19:24 +0100, Jonathan Underwood wrote: > Actually, perhaps I am overanalysing.:) I'll go away and try it, and > offer some suggested clarifications for the wiki. Indeed, it is entirely possible that my examples are not good examples. Please feel free to submit corrections or wording that will make the intent simpler. ~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 shahms at shahms.com Mon May 22 19:41:33 2006 From: shahms at shahms.com (Shahms King) Date: Mon, 22 May 2006 12:41:33 -0700 Subject: Old broken packages Message-ID: <447213ED.5050602@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is related to an earlier message about removing the obsolete and broken arch-specific epydoc package. That specific package has been fixed, but the general problem of old architecture specific packages breaking newer (properly) noarch packages remains. I encountered the problem most recently when trying to install python-reportlab which, like the epydoc package, has both a newer, properly compiled noarch package and a FC3-era i386 package in the repository. And, like epydoc, the old package breaks updating, installing, etc. the new package. Unlike epydoc, the offending python-reportlab package explicitly requires: python < 2.4 and therefore fails to install rather than simply failing to work. I'm not precisely sure where the blame for this lies, but there are certainly a number of candidates: 1. Propagation of packages from old releases to new releases doesn't adequately compare noarch and arch packages. Both of the problem packages I have found are *FC3* packages that have been copied, unchanged, into both FC4 and FC5 despite the existence of newer and properly built noarch packages. 2. Similarly, these packages are not being pruned when newer versions are pushed, rather the old arch-specific packages are sitting in the repository. 3. yum fails to take noarch packages into account on install or update when any arch-specific package exists, regardless of the epoch, version or release. I strongly suspect the problem lies with RPM always comparing an arch-specific package as "newer" than a noarch package, but I'm not certain. Note that these problems *appear* to have been fixed in rawhide as the extras development repository does not contain the offending packages. Additionally, trying to track down any potential problem packages is difficult as repoquery will not check versioned requires and insists that python-0:2.4..2-3.2.1.i386 provides "python < 2.4", which it most assuredly does not. - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEchPt/qs2NkWy11sRAtbeAJ4h2O+t6G8ILJsJIRlJfyhasVtOngCdG2wP 4/1BRYxCccmFIK1s7n9srPg= =o8J0 -----END PGP SIGNATURE----- From peter at thecodergeek.com Mon May 22 19:45:16 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 22 May 2006 12:45:16 -0700 Subject: [Fwd: Re: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both] Message-ID: <447214CC.1020809@thecodergeek.com> My reply should have gone to fedora-extras-list too. Forwarding from fedora-maintainers... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- An embedded message was scrubbed... From: Peter Gordon Subject: Re: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both Date: Mon, 22 May 2006 09:09:21 -0700 Size: 5566 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fenn at stanford.edu Mon May 22 20:39:45 2006 From: fenn at stanford.edu (Tim Fenn) Date: Mon, 22 May 2006 13:39:45 -0700 Subject: scientific license - fedora compatible? Message-ID: <20060522203932.GD12954@stanford.edu> I've made some packages based on some scientific software I (and many other folks in my field) use for various purposes, and I'd like to contribute them to fedora-extras. However, one of the libraries used by some of the software is based on a CCLRC (Council for the Central Laboratory of the Research Councils, http://www.cclrc.ac.uk/) license, described here: ftp://ftp.ccp4.ac.uk/ccp4/academic_software_licence.pdf in section 2.1 ("CCP4 Libraries"), which allows the licensee to distribute the library freely, but requires any non-LGPL or non-GPL derived work to be provided in source form to the CCLRC (section 2.1.2). Is this compatible with fedora-extras? Many apologies if this is the wrong list/forum for this question, and thanks for any help. Regards, Tim Fenn From buildsys at fedoraproject.org Mon May 22 21:14:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 22 May 2006 21:14:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-22 Message-ID: <20060522211411.13210.34366@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From buildsys at fedoraproject.org Mon May 22 21:14:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 22 May 2006 21:14:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-22 Message-ID: <20060522211411.13212.21464@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.ppc scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- php-eaccelerator 5.1.2_0.9.3-0.3.fc5.x86_64 scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: php-eaccelerator - 5.1.2_0.9.3-0.3.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Mon May 22 21:14:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 22 May 2006 21:14:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-22 Message-ID: <20060522211411.13214.37141@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 From buildsys at fedoraproject.org Mon May 22 21:14:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 22 May 2006 21:14:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-22 Message-ID: <20060522211411.13202.21138@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 From laurent.rineau__fedora_extras at normalesup.org Mon May 22 21:25:24 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Mon, 22 May 2006 23:25:24 +0200 Subject: Subpackages should own directories too? Message-ID: <200605222325.24828@rineau.schtroumpfette> Here is a fake package: http://www.di.ens.fr/~rineau/Fedora/foobar.spec (only a spec file, no source). This package foobar owns %{_datadir}/foobar/ and creates an empty file in it. A subpackage foobar-subpackage owns %{_datadir}/foobar/plugins/ and creates an empty file in the latter. As far as I understand the Fedora Extras Guidelines, this is correct. However, if i compile and install then uninstall the two packages at once, the directory %{_datadir}/foobar/ remains, and rpm says no package owns it (after the uninstallation). It is fixed if foobar-subpackage owns %{_datadir}/foobar/ too. However, according to the guidelines: "Packages must not own files or directories already owned by other packages." Who is wrong, the guideline, my version of rpm, or me? My version-release of rpm is 4.4.2-15.2, on fc-5. From pertusus at free.fr Mon May 22 22:12:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 00:12:34 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <20060522203932.GD12954@stanford.edu> References: <20060522203932.GD12954@stanford.edu> Message-ID: <20060522221234.GC2339@free.fr> > ftp://ftp.ccp4.ac.uk/ccp4/academic_software_licence.pdf > > in section 2.1 ("CCP4 Libraries"), which allows the licensee to > distribute the library freely, but requires any non-LGPL or non-GPL > derived work to be provided in source form to the CCLRC (section > 2.1.2). > > Is this compatible with fedora-extras? There are many terms in the licence that are incompatible with free software (obligation to send back patches, only academic use...), so not compatible with fedora. -- Pat From ville.skytta at iki.fi Mon May 22 22:19:15 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 23 May 2006 01:19:15 +0300 Subject: Subpackages should own directories too? In-Reply-To: <200605222325.24828@rineau.schtroumpfette> References: <200605222325.24828@rineau.schtroumpfette> Message-ID: <1148336355.2750.64.camel@localhost.localdomain> On Mon, 2006-05-22 at 23:25 +0200, Laurent Rineau wrote: > However, if i compile and install then uninstall the two packages at once, the > directory %{_datadir}/foobar/ remains, and rpm says no package owns it (after > the uninstallation). https://bugzilla.redhat.com/89500 https://bugzilla.redhat.com/190878#c4 (+rest of comments there) > It is fixed if foobar-subpackage owns %{_datadir}/foobar/ too. However, > according to the guidelines: "Packages must not own files or directories > already owned by other packages." > > Who is wrong, the guideline, my version of rpm, or me? The guideline kind of assumes that rpm does proper erasure ordering, but as far as I know, no FC version ships with such rpm. Strictly speaking, there are *lots* of packages around that may cause empty dirs being left behind because of that (everything except "filesystem"?), and if the fix for #89500 turns out as expected, the affected ones would be instantly fixed without making any changes to packages and multi-ownership of dirs (for this particular purpose) would become zero-value specfile/rpmdb/repodata cruft. In my opinion that's why the guideline should hold. Micro-managing the dirs in a few packages here and there doesn't help much at all in the big picture. #190878 above is a slightly different example because it involves a dependency loop; in such cases it makes actually sense to apply multi-ownership to dirs that are not owned by other packages outside of the loop. From chris.stone at gmail.com Mon May 22 22:19:54 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 22 May 2006 15:19:54 -0700 Subject: Subpackages should own directories too? In-Reply-To: <200605222325.24828@rineau.schtroumpfette> References: <200605222325.24828@rineau.schtroumpfette> Message-ID: On 5/22/06, Laurent Rineau wrote: > Who is wrong, the guideline, my version of rpm, or me? Looks like an rpm bug to me. From pertusus at free.fr Mon May 22 22:26:51 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 00:26:51 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <20060522203932.GD12954@stanford.edu> References: <20060522203932.GD12954@stanford.edu> Message-ID: <20060522222651.GD2339@free.fr> On Mon, May 22, 2006 at 01:39:45PM -0700, Tim Fenn wrote: > in section 2.1 ("CCP4 Libraries"), which allows the licensee to > distribute the library freely, but requires any non-LGPL or non-GPL > derived work to be provided in source form to the CCLRC (section > 2.1.2). I also have checked that they bundle GPL and LGPL codes in ccp4 source, it is forbidden by the GPL and the LGPL. You can report that to them, if you feel brave... (linking with LGPL covered libs is right, however, but they cannot be bundled with ccp4). -- Pat From jonathan.underwood at gmail.com Mon May 22 22:48:31 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 22 May 2006 23:48:31 +0100 Subject: Updates to Packaging Guidelines In-Reply-To: <1148324662.2295.106.camel@localhost.localdomain> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> <645d17210605221124ma29d349jc5baec11b93491f6@mail.gmail.com> <1148324662.2295.106.camel@localhost.localdomain> Message-ID: <645d17210605221548o1b3f9ef8kfcc5e833be2192d5@mail.gmail.com> On 22/05/06, Tom 'spot' Callaway wrote: > On Mon, 2006-05-22 at 19:24 +0100, Jonathan Underwood wrote: > > Actually, perhaps I am overanalysing.:) I'll go away and try it, and > > offer some suggested clarifications for the wiki. > > Indeed, it is entirely possible that my examples are not good examples. > Please feel free to submit corrections or wording that will make the > intent simpler. > May I suggest something like the following: Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming scheme. It is often the case that a component will add functionality to several different compatible editors, or "flavours", such as GNU Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the emacs component. Where a component adds functionality to more than one emacs flavour, the package name should be of the form emacs-common-$NAME. In this case, the main package should contain only files common to all emacs flavours, and the code specific to each flavour should be placed in a subpackage reflecting the flavour $FLAVOUR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An example of this scheme can be found in the package emacs-common-muse. Where a component is designed to add functionality to only a single flavour of emacs, the main package name should reflect this by being called $FLAVOUR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for the GNU Emacs flavour. Jonathan. From jonathan.underwood at gmail.com Mon May 22 23:04:36 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 00:04:36 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <20060522221234.GC2339@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> Message-ID: <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> On 22/05/06, Patrice Dumas wrote: > There are many terms in the licence that are incompatible with free software > (obligation to send back patches, only academic use...), so not compatible > with fedora. Yes, that was my reading to. However, having read through all 20 pages (!!) of their license file, it seems clear that their intentions are good, and that their main concern is that the source code is kept open and free, though they are clumsy in the execution of that. CCLRC is a publically (tax payer) funded research council here in the UK, and I would imagine that they are committed to keeping the source open. I suspect that a carefully worded letter/email explaining the problems with the license and offering suggested solutions would be well received once they are convinced that the GPL would serve their needs. Jonathan. From Axel.Thimm at ATrpms.net Mon May 22 23:05:37 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 01:05:37 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <20060522203932.GD12954@stanford.edu> References: <20060522203932.GD12954@stanford.edu> Message-ID: <20060522230537.GB26518@neu.nirvana> On Mon, May 22, 2006 at 01:39:45PM -0700, Tim Fenn wrote: > in section 2.1 ("CCP4 Libraries"), which allows the licensee to > distribute the library freely, but requires any non-LGPL or non-GPL > derived work to be provided in source form to the CCLRC (section > 2.1.2). > > Is this compatible with fedora-extras? You'll find a lot of scientific software using bogus licensing texts (usually meaning well, but since scientists are even less a lawyer than the rest of us, it's like backfire on them). Usually if you explain the issues to the authors they will gladly review the licensing. Maybe it would be helpful to have a licensing FAQ page in the wiki which can be used to point authors to (maybe there already is one?). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fenn at stanford.edu Mon May 22 23:36:07 2006 From: fenn at stanford.edu (Tim Fenn) Date: Mon, 22 May 2006 16:36:07 -0700 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> Message-ID: <20060522233601.GH12954@stanford.edu> On Tue, May 23, 2006 at 12:04:36AM +0100, Jonathan Underwood wrote: > On 22/05/06, Patrice Dumas wrote: > >There are many terms in the licence that are incompatible with free > >software > >(obligation to send back patches, only academic use...), so not compatible > >with fedora. > > Yes, that was my reading to. However, having read through all 20 pages > (!!) of their license file, it seems clear that their intentions are > good, and that their main concern is that the source code is kept open > and free, though they are clumsy in the execution of that. CCLRC is a > publically (tax payer) funded research council here in the UK, and I > would imagine that they are committed to keeping the source open. I > suspect that a carefully worded letter/email explaining the problems > with the license and offering suggested solutions would be well > received once they are convinced that the GPL would serve their needs. > Thanks all - I'll see if I can discuss this with the developers and/or the CCLRC and get something straightened out. As far as I understand it, the reason they avoided the (L)GPL was due to concerns over its legal standing in the UK: http://home.badc.rl.ac.uk/lawrence/blog/2005/01/08/open_source_licenses http://home.badc.rl.ac.uk/lawrence/blog/2005/01/24/MoreOnOpenSource http://home.badc.rl.ac.uk/lawrence/blog/2005/01/25/legal_stuff Rather than work out these difficulties with the FSF(E), the CCLRC found it best to come up with their own licensing scheme, it seems. Regards, Tim From pertusus at free.fr Tue May 23 00:01:09 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 02:01:09 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> Message-ID: <20060523000109.GA2336@free.fr> > Yes, that was my reading to. However, having read through all 20 pages > (!!) of their license file, it seems clear that their intentions are > good, and that their main concern is that the source code is kept open > and free, though they are clumsy in the execution of that. CCLRC is a I have seen some opposition from scientists to free software, because * they are not opposed to commercial use, but separate commercial use and free use: when there is profit done they must be some money back, and this goes against unrestricted use clause of free software. * they are opposed to forks and free redistribution, they want to be acknowledged for the work and also keep control on it. That also goes against free software. Those 2 points are in the CCLRC licence, so maybe it won't be so easy. And in my opinion these are valid points - although the first point is in fact achieved with the GPL in most cases, at least for scientific software: no profit are made with the code itself. It seems to me that the scientists are more ready to abandon the 2 points above today because free software seems very succesfull and they want to be part of it, but there are still almost free software packages that are not free (I can think of scilab, for example). -- Pat From pertusus at free.fr Tue May 23 00:30:15 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 02:30:15 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <20060522233601.GH12954@stanford.edu> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060522233601.GH12954@stanford.edu> Message-ID: <20060523003015.GB2336@free.fr> > http://home.badc.rl.ac.uk/lawrence/blog/2005/01/08/open_source_licenses > http://home.badc.rl.ac.uk/lawrence/blog/2005/01/24/MoreOnOpenSource > http://home.badc.rl.ac.uk/lawrence/blog/2005/01/25/legal_stuff Regarding liability (and other legal issues), there is the same issue in France, so some research institutes came with a licence (the cecill) that is better tailored to french law than the GPL and is similar with the GPL. However, there are also other voices saying that the GPL/MIT are perfectly acceptable and that the really problematic points are common to both licences. The only real way to check is to wait for a decision in court, so far in Germany the GPL has been recognized. > Rather than work out these difficulties with the FSF(E), the CCLRC > found it best to come up with their own licensing scheme, it seems. Regarding pure legal issue, it's bad, the FSF is always very helpfull on those subjects (even if it takes time...). -- Pat From fenn at stanford.edu Tue May 23 01:05:23 2006 From: fenn at stanford.edu (Tim Fenn) Date: Mon, 22 May 2006 18:05:23 -0700 Subject: scientific license - fedora compatible? In-Reply-To: <20060523000109.GA2336@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> Message-ID: <20060523010523.GI12954@stanford.edu> On Tue, May 23, 2006 at 02:01:09AM +0200, Patrice Dumas wrote: > > Yes, that was my reading to. However, having read through all 20 pages > > (!!) of their license file, it seems clear that their intentions are > > good, and that their main concern is that the source code is kept open > > and free, though they are clumsy in the execution of that. CCLRC is a > > I have seen some opposition from scientists to free software, because > > * they are not opposed to commercial use, but separate commercial use > and free use: when there is profit done they must be some money back, > and this goes against unrestricted use clause of free software. > > * they are opposed to forks and free redistribution, they want to be > acknowledged for the work and also keep control on it. That also goes > against free software. > I agree with this, but its sometimes more complicated than just a money/power hungry scientist looking for control - alot of this tends to be decided by University technology transfer programs, for which Richard Stallman dedicated an entire "howto": http://www.gnu.org/philosophy/university.html This is further complicated by funding for the research and any rules it imposes, the U.S. Bayh-Dole act (USC Title 35, Part II, Chap. 18, Sec. 200) which makes it an "objective of the Congress to use the patent system to promote the utilization of inventions arising from federally supported research or development," and so on. Never mind the fact that most of us don't even know the difference between the GPL, the LGPL, BSD, MIT, etc... Anyway, I'll do my best to fight the good fight. Besides, I think we're preaching to the choir on this list. ;) Regards, Tim From tcallawa at redhat.com Tue May 23 02:50:08 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 22 May 2006 21:50:08 -0500 Subject: Updates to Packaging Guidelines In-Reply-To: <645d17210605221548o1b3f9ef8kfcc5e833be2192d5@mail.gmail.com> References: <1148312656.2295.89.camel@localhost.localdomain> <645d17210605220918w731a504i72dd24d62675485@mail.gmail.com> <645d17210605221106hd31535fhae32e447fdc1c034@mail.gmail.com> <645d17210605221124ma29d349jc5baec11b93491f6@mail.gmail.com> <1148324662.2295.106.camel@localhost.localdomain> <645d17210605221548o1b3f9ef8kfcc5e833be2192d5@mail.gmail.com> Message-ID: <1148352608.7361.12.camel@localhost.localdomain> On Mon, 2006-05-22 at 23:48 +0100, Jonathan Underwood wrote: > On 22/05/06, Tom 'spot' Callaway wrote: > > On Mon, 2006-05-22 at 19:24 +0100, Jonathan Underwood wrote: > > > Actually, perhaps I am overanalysing.:) I'll go away and try it, and > > > offer some suggested clarifications for the wiki. > > > > Indeed, it is entirely possible that my examples are not good examples. > > Please feel free to submit corrections or wording that will make the > > intent simpler. > > > > May I suggest something like the following: > > Packages of emacs add-on components (code that adds additional > functionality to emacs compatible editors) have their own naming > scheme. It is often the case that a component will add functionality > to several different compatible editors, or "flavours", such as GNU > Emacs and XEmacs (and possibly development versions of these editors). > The package name should take into account the upstream name of the > emacs component. > > Where a component adds functionality to more than one emacs flavour, > the package name should be of the form emacs-common-$NAME. In this > case, the main package should contain only files common to all emacs > flavours, and the code specific to each flavour should be placed in a > subpackage reflecting the flavour $FLAVOUR-$NAME eg. xemacs-$NAME, > emacs-$NAME (the latter being the package specific to GNU Emacs). An > example of this scheme can be found in the package emacs-common-muse. > > Where a component is designed to add functionality to only a single > flavour of emacs, the main package name should reflect this by being > called $FLAVOUR-$NAME. An example of this situation can be found in > the package emacs-auctex, which is built only for the GNU Emacs > flavour. Seems good to me, I'm going to use it (with some minor wording changes to avoid American English vs Queens English flamewars). 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 seg at haxxed.com Tue May 23 05:57:56 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 23 May 2006 00:57:56 -0500 Subject: scientific license - fedora compatible? In-Reply-To: <20060523000109.GA2336@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> Message-ID: <1148363877.5164.0.camel@localhost.localdomain> On Tue, 2006-05-23 at 02:01 +0200, Patrice Dumas wrote: > * they are opposed to forks and free redistribution, they want to be > acknowledged for the work and also keep control on it. That also goes > against free software. That sounds like the very definition of proprietary software to me. -------------- 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 kevin.kofler at chello.at Tue May 23 06:08:21 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 23 May 2006 06:08:21 +0000 (UTC) Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-22 References: <20060522211411.13212.21464@extras64.linux.duke.edu> Message-ID: It has been a few days since these started being broken: > Summary of broken packages in fedora-extras-5-i386: > ---------------------------------------------------------------------- > php-eaccelerator 5.1.2_0.9.3-0.3.fc5.i386 This is #192306 (and #192543 which is a duplicate). > scim-fcitx 3.1.1-4.fc5.i386 > scim-fcitx-tools 3.1.1-4.fc5.i386 I filed #192797 for these 2 (apparently built from the same SRPM). > syck-php 0.55-7.fc5.i386 I filed #192798 for this. Kevin Kofler From pmatilai at laiskiainen.org Tue May 23 06:12:05 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 22 May 2006 23:12:05 -0700 (PDT) Subject: Old broken packages In-Reply-To: <447213ED.5050602@shahms.com> References: <447213ED.5050602@shahms.com> Message-ID: On Mon, 22 May 2006, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is related to an earlier message about removing the obsolete and > broken arch-specific epydoc package. That specific package has been > fixed, but the general problem of old architecture specific packages > breaking newer (properly) noarch packages remains. I encountered the > problem most recently when trying to install python-reportlab which, > like the epydoc package, has both a newer, properly compiled noarch > package and a FC3-era i386 package in the repository. And, like epydoc, > the old package breaks updating, installing, etc. the new package. > Unlike epydoc, the offending python-reportlab package explicitly > requires: python < 2.4 and therefore fails to install rather than simply > failing to work. > > I'm not precisely sure where the blame for this lies, but there are > certainly a number of candidates: > > 1. Propagation of packages from old releases to new releases doesn't > adequately compare noarch and arch packages. Both of the problem > packages I have found are *FC3* packages that have been copied, > unchanged, into both FC4 and FC5 despite the existence of newer and > properly built noarch packages. > > 2. Similarly, these packages are not being pruned when newer versions > are pushed, rather the old arch-specific packages are sitting in the > repository. > > 3. yum fails to take noarch packages into account on install or update > when any arch-specific package exists, regardless of the epoch, version > or release. > > I strongly suspect the problem lies with RPM always comparing an > arch-specific package as "newer" than a noarch package, but I'm not certain. RPM will happily upgrade such a package, it's yum-specific behavior to refuse to change package arch. Set exactarch=0 in yum.conf and it'll upgrade that. The other way around this is renaming the package to something else. > Note that these problems *appear* to have been fixed in rawhide as the > extras development repository does not contain the offending packages. > > Additionally, trying to track down any potential problem packages is > difficult as repoquery will not check versioned requires and insists > that python-0:2.4..2-3.2.1.i386 provides "python < 2.4", which it most > assuredly does not. Huh, you're saying 'repoquery --provides python' on FC5 says "python < 2.4"? I have hard time figuring out how it would come up with such a thing if it doesn't exist in the package but... Please show me the exact command to reproduce that so I can check what the heck is going on. Oh and there are such gems around, eg perl has "Provides: perl <= 4:5.8.8" which looks pretty dubious to me. - Panu - From j.w.r.degoede at hhs.nl Tue May 23 07:08:27 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 23 May 2006 09:08:27 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <20060523000109.GA2336@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> Message-ID: <4472B4EB.2070104@hhs.nl> Patrice Dumas wrote: > > It seems to me that the scientists are more ready to abandon the 2 > points above today because free software seems very succesfull and they > want to be part of it, but there are still almost free software packages > that are not free (I can think of scilab, for example). > Exactly and although I agree that the best thing would be if software like that would be relicensed under a truely open source license, unfortunatly this will not always happen. Which brings us the a point which we have been over and over again. We could really use a Non Free or Non Commercial repo for stuff like this, I know we have the repo which may not be named, but the may not be named is exactly the problem, if we want to cater as wide an audience as possible (and IMHO we do) we could really use a Non Commercial repo. I know this doesn't fit into Fedora's goals. Still we could use one, I know I'm free to create such a repo myself, but I don't have the resources and I find it a waste of my (and others) time to invest time into reproducing all the infrastructure FE already has. So let my suggest (again) that "we" start a Non Commercial repo under the Fedora umbrella. Not using the Fedora name (anyone know a good name), but sharing the FE infrastructure. Regards, Hans > -- > Pat > From paul at city-fan.org Tue May 23 07:31:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 08:31:24 +0100 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-22 In-Reply-To: <20060522211411.13202.21138@extras64.linux.duke.edu> References: <20060522211411.13202.21138@extras64.linux.duke.edu> Message-ID: <1148369484.29091.25.camel@laurel.intra.city-fan.org> On Mon, 2006-05-22 at 21:14 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-3-i386: > ---------------------------------------------------------------------- > fluxbox 0.9.15.1-1.fc3.i386 > plague 0.4.4.1-1.fc3.noarch > scim-tables-japanese 0.5.4-2.fc3.i386 > scim-tables-korean 0.5.4-2.fc3.i386 > stripesnoop-devel 1.5-2.fc3.i386 Given that the dependency on createrepo for plague is never going to be fixed, is there some good reason why this version of plague isn't being removed from the repo? And unless there are plans for a soon-ish update for FC4's createrepo, the same question applies there too. Paul. From pertusus at free.fr Tue May 23 09:30:39 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 11:30:39 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <1148363877.5164.0.camel@localhost.localdomain> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> Message-ID: <20060523093039.GA2304@free.fr> On Tue, May 23, 2006 at 12:57:56AM -0500, Callum Lerwick wrote: > On Tue, 2006-05-23 at 02:01 +0200, Patrice Dumas wrote: > > * they are opposed to forks and free redistribution, they want to be > > acknowledged for the work and also keep control on it. That also goes > > against free software. > > That sounds like the very definition of proprietary software to me. No, because the source is given freely to you and you can modify it as you like. The restriction is that the source of the software cannot change. -- Pat From paul at city-fan.org Tue May 23 09:44:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 10:44:19 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <20060523093039.GA2304@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> Message-ID: <4472D973.4050506@city-fan.org> Patrice Dumas wrote: > On Tue, May 23, 2006 at 12:57:56AM -0500, Callum Lerwick wrote: >> On Tue, 2006-05-23 at 02:01 +0200, Patrice Dumas wrote: >>> * they are opposed to forks and free redistribution, they want to be >>> acknowledged for the work and also keep control on it. That also goes >>> against free software. >> That sounds like the very definition of proprietary software to me. > > No, because the source is given freely to you and you can modify it as you > like. The restriction is that the source of the software cannot change. So you can't fix security bugs then? Paul. From pertusus at free.fr Tue May 23 10:10:36 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 12:10:36 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <4472D973.4050506@city-fan.org> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> Message-ID: <20060523101035.GD2304@free.fr> > >No, because the source is given freely to you and you can modify it as you > >like. The restriction is that the source of the software cannot change. > > So you can't fix security bugs then? Hrm, my wording is very very bad. I use source for 2 different things in the same sentence... I'll retry: The source is given freely to you and you can modify it as you like. The restriction is that you cannot redistribute modified versions, you have to send the patches upstream, only them can change the source and redistribute modified versions. -- Pat From jonathan.underwood at gmail.com Tue May 23 10:18:00 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 11:18:00 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <20060523101035.GD2304@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> Message-ID: <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> On 23/05/06, Patrice Dumas wrote: > The source is given freely to you and you can modify it as you like. > The restriction is that you cannot redistribute modified versions, you > have to send the patches upstream, only them can change the source > and redistribute modified versions. >From my reading of the license currently under discussion, that is not the restriction. They basically say, you can redistribute modified versions as long as you make available to the patches for the changes you make. Perhaps I missread. Jonathan From jonathan.underwood at gmail.com Tue May 23 10:20:22 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 11:20:22 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <4472B4EB.2070104@hhs.nl> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> Message-ID: <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> On 23/05/06, Hans de Goede wrote: > Which brings us the a point which we have been over and over again. We > could really use a Non Free or Non Commercial repo for stuff like this, > I know we have the repo which may not be named, but the may not be named > is exactly the problem, if we want to cater as wide an audience as > possible (and IMHO we do) we could really use a Non Commercial repo. It would be nice. The unmentionable repo does not operate in the same way as FE, as far as I can tell - it would be really nice to have a repo for non-commercial stuff not allowed in extras, let's called it Luvna, which uses the same infrastructure as FE, and which is open to contributors. j. From pertusus at free.fr Tue May 23 10:29:37 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 12:29:37 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> Message-ID: <20060523102937.GE2304@free.fr> On Tue, May 23, 2006 at 11:18:00AM +0100, Jonathan Underwood wrote: > On 23/05/06, Patrice Dumas wrote: > > >From my reading of the license currently under discussion, that is not > the restriction. > > They basically say, you can redistribute modified versions as long as > you make available to the patches for the changes you make. Yes, it seems you are right. I misread, but there is no explicit permission to redistribute modified version (the wording is 'use, copy, modify, and enhance and distribute'). So I think I wrongly supposed, based on the following that the redistribution of modified source wasn't possible, but after a more carefull reading, it seems that it is not explicitely forbidden, as the following states that the copyright of changes must be transfered to upstream not anything else... -- Pat From pertusus at free.fr Tue May 23 10:33:30 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 12:33:30 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> Message-ID: <20060523103330.GF2304@free.fr> > It would be nice. The unmentionable repo does not operate in the same > way as FE, as far as I can tell - it would be really nice to have a > repo for non-commercial stuff not allowed in extras, let's called it > Luvna, which uses the same infrastructure as FE, and which is open to > contributors. In the case of that precise licence it won't be acceptable too, because only academic institutions may redistribute it, it is more restrictive than non-commercial use (and it may only be used for academic purpose). -- Pat From fenn at stanford.edu Tue May 23 10:40:57 2006 From: fenn at stanford.edu (Tim Fenn) Date: Tue, 23 May 2006 03:40:57 -0700 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> Message-ID: <20060523104054.GA17786@stanford.edu> On Tue, May 23, 2006 at 11:18:00AM +0100, Jonathan Underwood wrote: > On 23/05/06, Patrice Dumas wrote: > >The source is given freely to you and you can modify it as you like. > >The restriction is that you cannot redistribute modified versions, you > >have to send the patches upstream, only them can change the source > >and redistribute modified versions. > > From my reading of the license currently under discussion, that is not > the restriction. > > They basically say, you can redistribute modified versions as long as > you make available to the patches for the changes you make. > My understanding of the library portion of the license was that making the patches available to the CCLRC was only necessary if the changes are NOT licensed under the (L)GPL (section 2.1.2). There is also something about an "executable program based on or combined with a Library," whatever that means. My intention by contributing the library to fedora-extras was to exclude any non-(L)GPL patches/changes with the library itself, which seems compatible with distribution under the CCLRC license, as well as packaging the library for fedora. I have no intentions on packaging any of the "CCP4 Applications," so section 2.2 is moot. Am I still missing something? Geez, perhaps there ought to be a fedora-legal list for this sort of thing? Regards, Tim From fedora at leemhuis.info Tue May 23 10:56:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 12:56:04 +0200 Subject: Luvna (Re: scientific license - fedora compatible?) In-Reply-To: <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> Message-ID: <1148381764.20933.69.camel@thl.ct.heise.de> Am Dienstag, den 23.05.2006, 11:20 +0100 schrieb Jonathan Underwood: > On 23/05/06, Hans de Goede wrote: > > Which brings us the a point which we have been over and over again. We > > could really use a Non Free or Non Commercial repo for stuff like this, > > I know we have the repo which may not be named, but the may not be named > > is exactly the problem, if we want to cater as wide an audience as > > possible (and IMHO we do) we could really use a Non Commercial repo. > > It would be nice. The unmentionable repo does not operate in the same > way as FE, as far as I can tell - it would be really nice to have a > repo for non-commercial stuff not allowed in extras, Someone has to work out a detailed plan (with some examples which of the current packages would be located in which repo; and how do the sub-repo depend on each other? Stuff like that). Then convince the luvna maintainers that it's a good idea. That's probably the hardest part and will take some time because multiple sub-repos confuse everything a lot. But it might be doable. And there needs to be someone that drives the whole thing forward. See also Luvna's bugzilla #998 (filed yesterday) > let's called it > Luvna, which uses the same infrastructure as FE, The current Luvna tries to do more and more things just like Extras does them -- it for example uses plague these days a similar repo layout (but svn instead of cvs). But it's still far from perfect. > and which is open to contributors. All current Fedora Extras maintainer can get access to Luvna very easily afaik -- just ask for it and it should be granted. Want to get a new package in? Just put it under review in Luvna's bugzilla just as you would do it for Extras (warning, Luvna lacks reviewers, too). But Luvna really is lacking contributors these days. There are AFICS only very few people keeping it alive and they have a lot of work to do already (with Extras and Luvna). That's one of the reasons why the Luvna-documentation for example really sucks. Some of the key contributors are quite frustrated afaik. Luvna really needs more help, otherwise it might fail over time. BTW, some of the Luvna guys also brought the idea "Let's merge with other 3rd party repos to one grant-unified-3rd-party repo that only enhances Core and Extras and does not replace packages from Core and Extas" on the table. There were some private mails with other repo maintainers, but nothing came out of it afaik. CU thl From rdieter at math.unl.edu Tue May 23 11:45:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 May 2006 06:45:53 -0500 Subject: rpms/apt/FC-4 apt.spec,1.18,1.19 References: <200605222010.k4MKAotg019192@cvs-int.fedora.redhat.com> Message-ID: Axel Thimm (athimm) wrote: > Update of /cvs/extras/rpms/apt/FC-4 ... > Modified Files: > apt.spec > Log Message: > Add some missing BuildRequires. ... > -BuildRequires: rpm-devel > +BuildRequires: rpm-devel, beecrypt-devel, elfutils-libelf-devel Shouldn't these extra deps be added to rpm-devel instead? -- Rex From rdieter at math.unl.edu Tue May 23 11:49:18 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 May 2006 06:49:18 -0500 Subject: scientific license - fedora compatible? References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > On 23/05/06, Hans de Goede > wrote: >> Which brings us the a point which we have been over and over again. We >> could really use a Non Free or Non Commercial repo for stuff like this, >> I know we have the repo which may not be named, but the may not be named >> is exactly the problem, if we want to cater as wide an audience as >> possible (and IMHO we do) we could really use a Non Commercial repo. > > It would be nice. The unmentionable repo does not operate in the same > way as FE, as far as I can tell - What makes you say that? At least from my point of view, it's pretty close. -- Rex From skvidal at linux.duke.edu Tue May 23 11:56:53 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 23 May 2006 07:56:53 -0400 Subject: Old broken packages In-Reply-To: References: <447213ED.5050602@shahms.com> Message-ID: <1148385414.5212.6.camel@cutter> On Mon, 2006-05-22 at 23:12 -0700, Panu Matilainen wrote: > On Mon, 22 May 2006, Shahms King wrote: > RPM will happily upgrade such a package, it's yum-specific behavior to > refuse to change package arch. Set exactarch=0 in yum.conf and it'll > upgrade that. The other way around this is renaming the package to > something else. I don't know what yum.conf the above system is coming from but exactarch, by default is only used on the exactarchlist which is a list of pkgs where keeping the same arch update to update makes a difference. -sv From jonathan.underwood at gmail.com Tue May 23 11:57:14 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 12:57:14 +0100 Subject: scientific license - fedora compatible? In-Reply-To: References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> Message-ID: <645d17210605230457r2379412as8e4b53b505fc8c5d@mail.gmail.com> On 23/05/06, Rex Dieter wrote: > > It would be nice. The unmentionable repo does not operate in the same > > way as FE, as far as I can tell - > > What makes you say that? At least from my point of view, it's pretty close. I was harbouring the misconception that one couldn't submit packages to livna - Thorsten in another mail points out that that's not the case. Apologies if I appeared to be critical of livna - that wasn't my intention - I guess I wasn't aware that things were as similar "under the hood" with livna and FE as they actually are. Jonathan From gauret at free.fr Tue May 23 12:08:00 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 23 May 2006 14:08:00 +0200 Subject: Gettext and %find_lang Message-ID: Hi *, At some point in the wiki, there was a packaging guideline stating that the %find_lang macro required gettext (or gettext-devel). I can't find it anymore, so I've looked at /usr/lib/rpm/find-lang.sh and it does not look like it needs gettext. Any info about the rationale behind this ? Was find-lang.sh fixed not to require gettext anymore ? Thanks, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From Axel.Thimm at ATrpms.net Tue May 23 12:15:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 14:15:51 +0200 Subject: Three staged repo structure, official/unofficial/outcast (was: Luvna (Re: scientific license - fedora compatible?)) In-Reply-To: <1148381764.20933.69.camel@thl.ct.heise.de> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> <1148381764.20933.69.camel@thl.ct.heise.de> Message-ID: <20060523121551.GC5829@neu.nirvana> On Tue, May 23, 2006 at 12:56:04PM +0200, Thorsten Leemhuis wrote: > BTW, some of the Luvna guys also brought the idea "Let's merge with > other 3rd party repos to one grant-unified-3rd-party repo that only > enhances Core and Extras and does not replace packages from Core and > Extas" on the table. There were some private mails with other repo > maintainers, but nothing came out of it afaik. At least the discussion I had sounded interesting and promising. But I don't know about any other discussions that took place, so maybe it drowned in the statistics. BTW its' livna not luvna (yes, I known you all know), here its is, I said it and you can all sue me now! ;) Seriously: As long as you don't dress an official position in Fedora (which thl does) and explicitely say "go to livna, atrpms or dag/dries/freshrpms where you can find lots of patented algorithms in software" (which noone in this thread mentioned) you can name the entities by their name. For example mentioning that closed sourced software or not enough open source for Fedora criteria is in the repo is not considered endorsing patent violations. Just don't refer to any patent tainted issues when naming repos by their name in any official way. And don't call livna, atrpms and freinds non-free, on the contrary we're living on the free side of the software world (still ...) Maybe it makes sense to split up repos in a) Fedora official (core/extras and all the bits fitting in the definition of the current open source) b) non-Fedora non-official hosting bits that don't fit in the definition of Fedora, but are still not a general issue (e.g. closed source or not-enough open source bits) c) non-Fedora non-official possibly patent tainted stuff. Official cooperation with naming thing could happen between a) and b) (syncing infrastructure/buildsystems/accounts), which c) remains unspoken of in terms/scope of a) [But maybe b) knows about c) and at least sync buildsystem with it, but not accounts] BTW as everyone here knows c) doesn't exist, at least we never heard of repos doing c) ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas at bawue.net Tue May 23 13:08:41 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 23 May 2006 15:08:41 +0200 (CEST) Subject: Luvna (Re: scientific license - fedora compatible?) In-Reply-To: <1148381764.20933.69.camel@thl.ct.heise.de> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> <1148381764.20933.69.camel@thl.ct.heise.de> Message-ID: On Tue, 23 May 2006, Thorsten Leemhuis wrote: > The current Luvna tries to do more and more things just like Extras does > them -- it for example uses plague these days a similar repo layout (but > svn instead of cvs). But it's still far from perfect. Lack of personell I presume? regards, andreas From pmatilai at laiskiainen.org Tue May 23 13:58:56 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 May 2006 06:58:56 -0700 (PDT) Subject: rpms/apt/FC-4 apt.spec,1.18,1.19 In-Reply-To: References: <200605222010.k4MKAotg019192@cvs-int.fedora.redhat.com> Message-ID: On Tue, 23 May 2006, Rex Dieter wrote: > Axel Thimm (athimm) wrote: >> Update of /cvs/extras/rpms/apt/FC-4 > ... >> Modified Files: >> apt.spec >> Log Message: >> Add some missing BuildRequires. > ... >> -BuildRequires: rpm-devel >> +BuildRequires: rpm-devel, beecrypt-devel, elfutils-libelf-devel > > Shouldn't these extra deps be added to rpm-devel instead? It's fixed in FC5 rpm-devel finally (it's an ages old issue), hardly worth the trouble to push rpm update for FC4 just because of this. - Panu - From qspencer at ieee.org Tue May 23 13:12:27 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 23 May 2006 09:12:27 -0400 Subject: scientific license - fedora compatible? In-Reply-To: <20060523102937.GE2304@free.fr> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> Message-ID: <44730A3B.6070703@ieee.org> Patrice Dumas wrote: > On Tue, May 23, 2006 at 11:18:00AM +0100, Jonathan Underwood wrote: > >> On 23/05/06, Patrice Dumas wrote: >> >> >From my reading of the license currently under discussion, that is not >> the restriction. >> >> They basically say, you can redistribute modified versions as long as >> you make available to the patches for the changes you make. >> > > Yes, it seems you are right. I misread, but there is no explicit permission > to redistribute modified version (the wording is 'use, copy, modify, and > enhance and distribute'). So I think I wrongly supposed, based on the following > that the redistribution of modified source wasn't possible, but after a more > carefull reading, it seems that it is not explicitely forbidden, as the > following states that the copyright of changes must be transfered to > upstream not anything else... > I haven't read the license, but your descriptions sound similar to the license for gnuplot, which is in core. You may want to look at its license. I think it says that modifications may only be distributed as patches. -Quentin From mpeters at mac.com Tue May 23 14:25:00 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 23 May 2006 07:25:00 -0700 Subject: Gettext and %find_lang In-Reply-To: References: Message-ID: <1148394301.16995.9.camel@atlantis.mpeters.local> On Tue, 2006-05-23 at 14:08 +0200, Aurelien Bompard wrote: > Hi *, > > At some point in the wiki, there was a packaging guideline stating that > the %find_lang macro required gettext (or gettext-devel). I can't find it > anymore, so I've looked at /usr/lib/rpm/find-lang.sh and it does not look > like it needs gettext. > > Any info about the rationale behind this ? Was find-lang.sh fixed not to > require gettext anymore ? It isn't find-lang.sh that uses gettext, it is the generation of the .po files during make that does. If gettext isn't installed, the lang files are not generated. From jonathan.underwood at gmail.com Tue May 23 14:33:23 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 15:33:23 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <44730A3B.6070703@ieee.org> References: <20060522203932.GD12954@stanford.edu> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> Message-ID: <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> On 23/05/06, Quentin Spencer wrote: > I haven't read the license, but your descriptions sound similar to the > license for gnuplot, which is in core. You may want to look at its > license. I think it says that modifications may only be distributed as > patches. Your synopsis is broadly right - modified versions must be distributed as original source plus patches. http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright?view=markup From jonathan.underwood at gmail.com Tue May 23 14:41:16 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 15:41:16 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> Message-ID: <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> On 23/05/06, Jonathan Underwood wrote: > On 23/05/06, Quentin Spencer wrote: > > I haven't read the license, but your descriptions sound similar to the > > license for gnuplot, which is in core. You may want to look at its > > license. I think it says that modifications may only be distributed as > > patches. > > Your synopsis is broadly right - modified versions must be distributed > as original source plus patches. > > http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright?view=markup > Not that it should be taken as authority, but wikipedia has this to say about gnuplot: The program is distributed under a license which permits copying and modification of the source code. However, modified versions are only allowed to be distributed as patch files: as such, the gnuplot licence is not compatible with the GPL, and is not free software (according to FSF, DFSG, and OSI). One could ask why it's still in Core... it certainly sounds like it shouldn't be. If, like me, you make daily use of gnuplot, that idea might not fill you with joy. J. From icon at fedoraproject.org Tue May 23 14:21:44 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 23 May 2006 10:21:44 -0400 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060522221234.GC2339@free.fr> <645d17210605221604s197378b9pc146a46e8ac05755@mail.gmail.com> <20060523000109.GA2336@free.fr> <4472B4EB.2070104@hhs.nl> <645d17210605230320j372cb9e6t9d791d5666b19111@mail.gmail.com> Message-ID: On 5/23/06, Jonathan Underwood wrote: > It would be nice. The unmentionable repo does not operate in the same > way as FE, as far as I can tell - it would be really nice to have a > repo for non-commercial stuff not allowed in extras, let's called it > Luvna, which uses the same infrastructure as FE, and which is open to > contributors. Shouldn't we call them "freeluvna" and "non-freeluvna" then? :) -- Konstantin Ryabitsev Montr?al, Qu?bec From jkeating at redhat.com Tue May 23 15:06:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 11:06:07 -0400 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> Message-ID: <1148396767.10695.1.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 15:41 +0100, Jonathan Underwood wrote: > The program is distributed under a license which permits copying and > modification of the source code. However, modified versions are only > allowed to be distributed as patch files: as such, the gnuplot licence > is not compatible with the GPL, and is not free software (according to > FSF, DFSG, and OSI). > > One could ask why it's still in Core... it certainly sounds like it > shouldn't be. If, like me, you make daily use of gnuplot, that idea > might not fill you with joy. > A somewhat good question, however I think that if you look, all packages that Red Hat consumes from upstream are in the same flavor of pristine upstream sources plus our changes in patch files. The rpm build process applies the patches to the sources. -- 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 shahms at shahms.com Tue May 23 15:04:41 2006 From: shahms at shahms.com (Shahms King) Date: Tue, 23 May 2006 08:04:41 -0700 Subject: Old broken packages In-Reply-To: References: <447213ED.5050602@shahms.com> Message-ID: <44732489.8060601@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Panu Matilainen wrote: *snip* >> >> I strongly suspect the problem lies with RPM always comparing an >> arch-specific package as "newer" than a noarch package, but I'm not >> certain. > > RPM will happily upgrade such a package, it's yum-specific behavior to > refuse to change package arch. Set exactarch=0 in yum.conf and it'll > upgrade that. The other way around this is renaming the package to > something else. > The behavior exists both with and without exactarch. >> Note that these problems *appear* to have been fixed in rawhide as the >> extras development repository does not contain the offending packages. >> >> Additionally, trying to track down any potential problem packages is >> difficult as repoquery will not check versioned requires and insists >> that python-0:2.4.2-3.2.1.i386 provides "python < 2.4", which it most >> assuredly does not. > > Huh, you're saying 'repoquery --provides python' on FC5 says "python < > 2.4"? I have hard time figuring out how it would come up with such a > thing if it doesn't exist in the package but... Please show me the exact > command to reproduce that so I can check what the heck is going on. > > Oh and there are such gems around, eg perl has "Provides: perl <= > 4:5.8.8" which looks pretty dubious to me. > > - Panu - Sorry, I mis-typed. Repoquery, when asked --requires --resolve on the offending packages will list the python package as satisfying the requirements, which it doesn't. Similarly, both rpm and repoquery don't deal with versioned '--whatrequires' requests (such as --whatrequires 'python < 2.4'). I'm not sure if this is a big deal or not, but I have encountered two packages exhibiting this problem so far and was trying find any more potential problem packages and having minimal luck. I wouldn't be surprised if python-reportlab.i386 is the last remaining problem package, but the yum-or-rpm behavior that ignores newer noarch packages still seems like a bug to me. - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEcySJ/qs2NkWy11sRAk+IAJ9UzbCt0aZvthxc/26d6qNmJ3BRSACeOjEd Fy/zGccX80Oc/foiuV8E3LY= =Fdof -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Tue May 23 15:09:23 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 23 May 2006 11:09:23 -0400 Subject: Old broken packages In-Reply-To: <44732489.8060601@shahms.com> References: <447213ED.5050602@shahms.com> <44732489.8060601@shahms.com> Message-ID: <1148396964.6325.19.camel@cutter> On Tue, 2006-05-23 at 08:04 -0700, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Panu Matilainen wrote: > *snip* > >> > >> I strongly suspect the problem lies with RPM always comparing an > >> arch-specific package as "newer" than a noarch package, but I'm not > >> certain. > > > > RPM will happily upgrade such a package, it's yum-specific behavior to > > refuse to change package arch. Set exactarch=0 in yum.conf and it'll > > upgrade that. The other way around this is renaming the package to > > something else. > > > > The behavior exists both with and without exactarch. > > >> Note that these problems *appear* to have been fixed in rawhide as the > >> extras development repository does not contain the offending packages. > >> > >> Additionally, trying to track down any potential problem packages is > >> difficult as repoquery will not check versioned requires and insists > >> that python-0:2.4.2-3.2.1.i386 provides "python < 2.4", which it most > >> assuredly does not. > > > > Huh, you're saying 'repoquery --provides python' on FC5 says "python < > > 2.4"? I have hard time figuring out how it would come up with such a > > thing if it doesn't exist in the package but... Please show me the exact > > command to reproduce that so I can check what the heck is going on. > > > > Oh and there are such gems around, eg perl has "Provides: perl <= > > 4:5.8.8" which looks pretty dubious to me. > > > > - Panu - > > Sorry, I mis-typed. Repoquery, when asked --requires --resolve on the > offending packages will list the python package as satisfying the > requirements, which it doesn't. Similarly, both rpm and repoquery don't > deal with versioned '--whatrequires' requests (such as --whatrequires > 'python < 2.4'). > > I'm not sure if this is a big deal or not, but I have encountered two > packages exhibiting this problem so far and was trying find any more > potential problem packages and having minimal luck. I wouldn't be > surprised if python-reportlab.i386 is the last remaining problem > package, but the yum-or-rpm behavior that ignores newer noarch packages > still seems like a bug to me. > Could you report this bug in bugzilla? I've not heard of it happening and I'd like to know more about how you can make it happen. Thanks, -sv From jonathan.underwood at gmail.com Tue May 23 15:11:12 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 16:11:12 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <1148396767.10695.1.camel@dhcp83-49.boston.redhat.com> References: <20060522203932.GD12954@stanford.edu> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> <1148396767.10695.1.camel@dhcp83-49.boston.redhat.com> Message-ID: <645d17210605230811k28f212c3if47fb3b82b9399e3@mail.gmail.com> On 23/05/06, Jesse Keating wrote: > A somewhat good question, however I think that if you look, all packages > that Red Hat consumes from upstream are in the same flavor of pristine > upstream sources plus our changes in patch files. The rpm build process > applies the patches to the sources. Yep, of course, there's nothing contravening the license that is going on. However, I ask the question since gnuplot's license would appear to be incompatible with Fedora... J. From gauret at free.fr Tue May 23 15:10:40 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 23 May 2006 17:10:40 +0200 Subject: Gettext and %find_lang References: <1148394301.16995.9.camel@atlantis.mpeters.local> Message-ID: Michael A. Peters wrote: > On Tue, 2006-05-23 at 14:08 +0200, Aurelien Bompard wrote: >> At some point in the wiki, there was a packaging guideline stating that >> the %find_lang macro required gettext (or gettext-devel). I can't find it >> anymore, so I've looked at /usr/lib/rpm/find-lang.sh and it does not look >> like it needs gettext. >> >> Any info about the rationale behind this ? Was find-lang.sh fixed not to >> require gettext anymore ? > > It isn't find-lang.sh that uses gettext, it is the generation of the .po > files during make that does. If gettext isn't installed, the lang files > are not generated. OK, the locales are always generated in mock because gettext is always installed (it's mandatory in /var/lib/mock/*/root/var/cache/yum/groups/buildroots.xml) So no need to require it in the specfiles. Thanks for the explanation. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr One of the universal rules of happiness is: "Always be wary of any helpful item that weighs less than its operating manual". From shahms at shahms.com Tue May 23 15:16:31 2006 From: shahms at shahms.com (Shahms King) Date: Tue, 23 May 2006 08:16:31 -0700 Subject: Old broken packages In-Reply-To: <1148396964.6325.19.camel@cutter> References: <447213ED.5050602@shahms.com> <44732489.8060601@shahms.com> <1148396964.6325.19.camel@cutter> Message-ID: <4473274F.9060101@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: > > Could you report this bug in bugzilla? I've not heard of it happening > and I'd like to know more about how you can make it happen. > > Thanks, > -sv > > Done. Bug #192837. - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEcydP/qs2NkWy11sRAmtIAJ9JRA24ayvNTtOZbKp6E54svbJ9hACgqA1/ 7cw05jcr0/GsoTcYfymFXjg= =2GRf -----END PGP SIGNATURE----- From rdieter at math.unl.edu Tue May 23 15:25:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 May 2006 10:25:47 -0500 Subject: scientific license - fedora compatible? References: <20060522203932.GD12954@stanford.edu> <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > Not that it should be taken as authority, but wikipedia has this to > say about gnuplot: > > The program is distributed under a license which permits copying and > modification of the source code. However, modified versions are only > allowed to be distributed as patch files: as such, the gnuplot licence > is not compatible with the GPL, and is not free software (according to > FSF, DFSG, and OSI). The assertion that gnuplot's license doesn't comply with OSI's definition isn't clear (not to me anyway). The only possible problem seems to be: >From http://opensource.org/docs/definition.php 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. As I see it, gnuplot *does* allow modifications... under the same terms... -- Rex From pertusus at free.fr Tue May 23 15:31:31 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 May 2006 17:31:31 +0200 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> References: <20060523000109.GA2336@free.fr> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> Message-ID: <20060523153131.GC2304@free.fr> > Not that it should be taken as authority, but wikipedia has this to > say about gnuplot: > > The program is distributed under a license which permits copying and > modification of the source code. However, modified versions are only > allowed to be distributed as patch files: as such, the gnuplot licence > is not compatible with the GPL, and is not free software (according to > FSF, DFSG, and OSI). That's strange. It seems to me that this practice is explicitly taken into account in the point 4. at http://www.opensource.org/docs/definition.php Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source. In my opinion the CCPL licence isn't a free software licence, because it restricts the use (only for academic use) and oblige to send back the patches within one year and transfer the copyright, not because the differences have to be distributed as patches. -- Pat From jspaleta at gmail.com Tue May 23 15:43:12 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 May 2006 11:43:12 -0400 Subject: scientific license - fedora compatible? In-Reply-To: <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <1148363877.5164.0.camel@localhost.localdomain> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> Message-ID: <604aa7910605230843q731b9c15iaa04433e89ad32e@mail.gmail.com> On 5/23/06, Jonathan Underwood wrote: > The program is distributed under a license which permits copying and > modification of the source code. However, modified versions are only > allowed to be distributed as patch files: as such, the gnuplot licence > is not compatible with the GPL, and is not free software (according to > FSF, DFSG, and OSI). Your assessment as to the acceptability of 'patch distribution' restrictions is absolutely incorrect with regard to the DFSG and OSI. If you have authoritative references which you are relying on to back up your assessment, cite them. While this term is most certainly not GPL-compatible, its most certainly DFSG and OSI compatible according to the available DFSG and OSI definition of opensource. Stop trying to equate 'free software' with 'open source software' as you have done in your last sentence above. Section: The Debian Free Software Guidelines (DFSG) .... 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) Section: The Open Source Definition .... 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations. Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source. The patch distribution issue is a NON-ISSUE. The most problematic issue with the licensing that started this thread is restrictions on use, 'academic-only' or 'non-commercial' terms are highly restrictive, and make licensing audits a real pain in the ass for those of us who have to deal with it. God forbid such packages showed up as deps for other packages in Extras. If there is a way forward for these sort of restricted use, but modifiable codebases, it will take the form of a dedicated repository downstream of Core and Extras. -jef"killing pointless masturbatory legal arguments one credible citation reference at a time"spaleta From jonathan.underwood at gmail.com Tue May 23 15:59:25 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 16:59:25 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <604aa7910605230843q731b9c15iaa04433e89ad32e@mail.gmail.com> References: <20060522203932.GD12954@stanford.edu> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> <604aa7910605230843q731b9c15iaa04433e89ad32e@mail.gmail.com> Message-ID: <645d17210605230859i573bdde9k27def834e45342db@mail.gmail.com> On 23/05/06, Jeff Spaleta wrote: > On 5/23/06, Jonathan Underwood wrote: > > The program is distributed under a license which permits copying and > > modification of the source code. However, modified versions are only > > allowed to be distributed as patch files: as such, the gnuplot licence > > is not compatible with the GPL, and is not free software (according to > > FSF, DFSG, and OSI). > > Your assessment as to the acceptability of 'patch distribution' > restrictions is absolutely incorrect with regard to the DFSG and OSI. > If you have authoritative references which you are relying on to back > up your assessment, cite them. If you had read my mail, you would see that I was quoting wikipedia - that wasn't my statement, and I prefixed it by saying it was not necessarily authoratitve. Thanks for the flame though, it warmed my cockles. Jonathan. From jonathan.underwood at gmail.com Tue May 23 16:01:24 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 23 May 2006 17:01:24 +0100 Subject: scientific license - fedora compatible? In-Reply-To: <20060523153131.GC2304@free.fr> References: <20060523000109.GA2336@free.fr> <20060523093039.GA2304@free.fr> <4472D973.4050506@city-fan.org> <20060523101035.GD2304@free.fr> <645d17210605230318w28df20c8qec69089b42aa416@mail.gmail.com> <20060523102937.GE2304@free.fr> <44730A3B.6070703@ieee.org> <645d17210605230733s5c27eeadu6b9142e51d53b1f@mail.gmail.com> <645d17210605230741w4fd9253dkc5f6af9c5673184a@mail.gmail.com> <20060523153131.GC2304@free.fr> Message-ID: <645d17210605230901w7db79027rc6705daccf4843c9@mail.gmail.com> On 23/05/06, Patrice Dumas wrote: > That's strange. It seems to me that this practice is explicitly taken into > account in the point 4. at > http://www.opensource.org/docs/definition.php > > Accordingly, an open-source license must guarantee that source be > readily available, but may require that it be distributed as pristine > base sources plus patches. In this way, "unofficial" changes can be > made available but readily distinguished from the base source. Indeed. Seems the wikipedia entry is off beam. From fedora at leemhuis.info Tue May 23 16:10:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 18:10:14 +0200 Subject: Gettext and %find_lang In-Reply-To: References: <1148394301.16995.9.camel@atlantis.mpeters.local> Message-ID: <1148400615.2297.9.camel@localhost.localdomain> Am Dienstag, den 23.05.2006, 17:10 +0200 schrieb Aurelien Bompard: > OK, the locales are always generated in mock because gettext is always > installed (it's mandatory > in /var/lib/mock/*/root/var/cache/yum/groups/buildroots.xml) What's installed per default in mock could change real soon. FESCo is discussing the list mock currently uses and some people think that gettext should not be in the default buildroot. More details later. And: > So no need to require it in the specfiles. It's not listed in http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions so it should be BuildRequired. CU thl -- Thorsten Leemhuis From gauret at free.fr Tue May 23 16:15:25 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 23 May 2006 18:15:25 +0200 Subject: Gettext and %find_lang References: <1148394301.16995.9.camel@atlantis.mpeters.local> <1148400615.2297.9.camel@localhost.localdomain> Message-ID: Thorsten Leemhuis wrote: >> So no need to require it in the specfiles. > It's not listed in > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > so it should be BuildRequired. How should we find out missing buildrequires if not with mock ? (yes, and fedora-rmdevelrpms). IMHO every package installed by default by mock should be and exception for BuildReqs (that's what buildreqs are for, btw). A. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "L'adulte ne croit pas au P?re No?l. Il vote." -- Pierre Desproges From bdpepple at ameritech.net Tue May 23 16:23:13 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 23 May 2006 12:23:13 -0400 Subject: Gettext and %find_lang In-Reply-To: References: <1148394301.16995.9.camel@atlantis.mpeters.local> <1148400615.2297.9.camel@localhost.localdomain> Message-ID: <1148401393.5513.2.camel@shuttle.piedmont.com> On Tue, 2006-05-23 at 18:15 +0200, Aurelien Bompard wrote: > Thorsten Leemhuis wrote: > >> So no need to require it in the specfiles. > > It's not listed in > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > > so it should be BuildRequired. > > How should we find out missing buildrequires if not with mock ? (yes, and > fedora-rmdevelrpms). IMHO every package installed by default by mock should > be and exception for BuildReqs (that's what buildreqs are for, btw). Agreed. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thomas at apestaart.org Tue May 23 16:40:43 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 23 May 2006 18:40:43 +0200 Subject: twisted 2.x packaging Message-ID: <1148402444.10564.90.camel@otto.amantes> Hey everyone, I wanted to ask what people think I should do to upgrade Twisted. Twisted 2.x is mostly compatible with 1.3. The only depending package of Twisted in Extras at the moment is Flumotion, which I also maintain. Starting from 2.x, Twisted's packaging suggestions ask that Twisted be package as a number of subpackages. See http://twistedmatrix.com/projects/core/documentation/upgrades/2.0/split.html Jeff Pitman has done all the hard work in his pyvault repository. I intend to pretty much copy what he has done, and when I asked about it he was ok with that. I guess the only real issue here is the following - how should I proceed ? Basically, doing it this way means creating 12 new package directories and removing one old one. Should I treat these 12 as completely new ? Am I allowed to import them straight away given that they're replacements/splitout from a previously accepted package ? Of course, there will still be a python-twisted package, which will be a metapackage, as recommended. Possibly, Flumotion will then require only the subpackages it needs, so new installs will be as light as they can be. Thanks in advance, Thomas From ville.skytta at iki.fi Tue May 23 16:58:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 23 May 2006 19:58:06 +0300 Subject: Gettext and %find_lang In-Reply-To: <1148401393.5513.2.camel@shuttle.piedmont.com> References: <1148394301.16995.9.camel@atlantis.mpeters.local> <1148400615.2297.9.camel@localhost.localdomain> <1148401393.5513.2.camel@shuttle.piedmont.com> Message-ID: <1148403486.2750.117.camel@localhost.localdomain> On Tue, 2006-05-23 at 12:23 -0400, Brian Pepple wrote: > On Tue, 2006-05-23 at 18:15 +0200, Aurelien Bompard wrote: > > Thorsten Leemhuis wrote: > > >> So no need to require it in the specfiles. > > > It's not listed in > > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > > > so it should be BuildRequired. > > > > How should we find out missing buildrequires if not with mock ? (yes, and > > fedora-rmdevelrpms). IMHO every package installed by default by mock should > > be and exception for BuildReqs (that's what buildreqs are for, btw). > > Agreed. mock is a useful tool for that, yes, but as mentioned on this list earlier, the list of exceptions has been documented and unchanged for a looooong time, and for some reasons that was not taken into account when the default mock config was set up, which people are working on to fix really soon now. My (somewhat educated) guess is that it's very likely that quite a few packages will be dropped from the default mock setup, and some may be added to the exceptions. If you want to be on the safe side, just keep using the current exceptions list as-is, I don't foresee anything being dropped from it in the near future (well, at least as long as rpm-build has a dependency on perl...) From buildsys at fedoraproject.org Tue May 23 17:27:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 23 May 2006 13:27:23 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20060523172723.7C9BC15218A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 23 17:27:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 23 May 2006 13:27:23 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20060523172723.746E6152189@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 4: 11 apt-0.5.15lorg3.1-5.fc4 bzr-0.8.2-1.fc4 emacs-common-muse-3.02.6b-6.fc4 fedora-package-config-apt-4-4 i810switch-0.6.5-3.fc4 libnetfilter_conntrack-0.0.30-2.fc4 linux_logo-4.13-3.fc4 lyx-1.4.1-5.fc4 p0rn-comfort-0.0.4-3.fc4 perl-Module-Build-0.2801-1.fc4 xvattr-1.3-10.fc4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 23 17:27:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 23 May 2006 13:27:23 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20060523172723.6C4E9152188@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 16 apt-0.5.15lorg3.1-5.fc5 bzr-0.8.2-1.fc5 dia-0.95-3.fc5 emacs-common-muse-3.02.6b-6.fc5 fedora-package-config-apt-5-4 gparted-0.2.5-1.fc5 i810switch-0.6.5-3.fc5 libnetfilter_conntrack-0.0.30-2.fc5 linux_logo-4.13-3.fc5 lyx-1.4.1-5.fc5 p0rn-comfort-0.0.4-3.fc5 pbzip2-0.9.6-3.fc5 perl-Module-Build-0.2801-1.fc5 php-eaccelerator-5.1.4_0.9.5-0.2.beta2.fc5 upx-2.00-2.fc5 xvattr-1.3-10.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue May 23 17:27:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 23 May 2006 13:27:23 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20060523172723.5A4A2152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 17 apt-0.5.15lorg3.1-5.fc6 bzr-0.8.2-1.fc6 dia-0.95-3.fc6 emacs-common-muse-3.02.6b-6.fc6 fwbuilder-2.0.12-1.fc6 gparted-0.2.5-1.fc6 i810switch-0.6.5-3.fc6 libapreq2-2.08-0.rc2.1.fc6 linux_logo-4.13-3.fc6 lyx-1.4.1-5.fc6 p0rn-comfort-0.0.4-3.fc6 pan-0.98-1.fc6 pbzip2-0.9.6-3.fc6 perl-IO-Null-1.01-1.fc6 perl-Module-Build-0.2801-1.fc6 php-eaccelerator-5.1.4_0.9.5-0.2.beta2.fc6 xvattr-1.3-10.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at city-fan.org Tue May 23 17:37:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 18:37:31 +0100 Subject: twisted 2.x packaging In-Reply-To: <1148402444.10564.90.camel@otto.amantes> References: <1148402444.10564.90.camel@otto.amantes> Message-ID: <1148405851.5228.79.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 18:40 +0200, Thomas Vander Stichele wrote: > Hey everyone, > > I wanted to ask what people think I should do to upgrade Twisted. > > Twisted 2.x is mostly compatible with 1.3. The only depending package > of Twisted in Extras at the moment is Flumotion, which I also maintain. This will change with BitTorrent 5.0; the beta (4.9.6) currently uses twisted-core and twisted-web. > Starting from 2.x, Twisted's packaging suggestions ask that Twisted be > package as a number of subpackages. See > http://twistedmatrix.com/projects/core/documentation/upgrades/2.0/split.html This may already be out of date. I *think* Twisted Xish has been incorporated into Twisted Words. > Jeff Pitman has done all the hard work in his pyvault repository. I > intend to pretty much copy what he has done, and when I asked about it > he was ok with that. Can we have it yesterday please :-) I had a go at making Extras-compatible versions of these (as you'll know from bugzilla) and there are a few tweaks needed here and there, such as doing proper directory ownership, ghosting of .pyo files, dependency package name changes (e.g. SOAPpy instead of python-soappy), removal of shellbangs from python files to shut rpmlint up etc. > I guess the only real issue here is the following - how should I > proceed ? Basically, doing it this way means creating 12 new package > directories and removing one old one. Should I treat these 12 as > completely new ? Am I allowed to import them straight away given that > they're replacements/splitout from a previously accepted package ? Well the app has previously been approved but the packaging is now sufficiently different that I think it would be worth re-reviewing. Especially since most of the packages now have separate upstream tarballs, get released at different times etc., and so are really separate new packages. There is a slight chicken-and-egg issue in that all of the packages would need to be released together in order to provide a clean update route from 1.3, but most of the packages have a build dependency on python-twisted-core. So whoever was reviewing them all would have to maintain a local repo if they were to test them using mock. There's also an issue in that there's a new build dep for the main package of python-zope-interface, so that will need to go in first. Paul. From fedora at leemhuis.info Tue May 23 17:47:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 19:47:53 +0200 Subject: Gettext and %find_lang In-Reply-To: References: <1148394301.16995.9.camel@atlantis.mpeters.local> <1148400615.2297.9.camel@localhost.localdomain> Message-ID: <1148406474.2317.30.camel@localhost.localdomain> Am Dienstag, den 23.05.2006, 18:15 +0200 schrieb Aurelien Bompard: > Thorsten Leemhuis wrote: > >> So no need to require it in the specfiles. > > It's not listed in > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > > so it should be BuildRequired. > > How should we find out missing buildrequires if not with mock ? Ville gave a lengthy answer to this already. The problem also simply is: Mock and the #Exceptions in the Packaging guidelines simply didn't match in the past. We noticed this some weeks/days ago and we'll hopefully fix this soon. Sorry for the trouble. CU thl -- Thorsten Leemhuis From buildsys at fedoraproject.org Tue May 23 17:48:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 23 May 2006 17:48:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-23 Message-ID: <20060523174812.11209.78457@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 From buildsys at fedoraproject.org Tue May 23 17:48:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 23 May 2006 17:48:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-23 Message-ID: <20060523174812.11224.49150@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 From buildsys at fedoraproject.org Tue May 23 17:48:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 23 May 2006 17:48:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-23 Message-ID: <20060523174812.11222.29099@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Tue May 23 17:48:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 23 May 2006 17:48:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-23 Message-ID: <20060523174812.11218.76038@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.i386 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.ppc plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: Axel.Thimm AT ATrpms.net package: apt-groupinstall - 0.5.15cnc7-6.fc4.i386 from fedora-extras-4-i386 unresolved deps: apt = 0:0.5.15cnc7-6.fc4 package: apt-groupinstall - 0.5.15cnc7-6.fc4.ppc from fedora-extras-4-ppc unresolved deps: apt = 0:0.5.15cnc7-6.fc4 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From Axel.Thimm at ATrpms.net Tue May 23 19:49:01 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 21:49:01 +0200 Subject: Changing subpackaging Message-ID: <20060523194901.GA14369@neu.nirvana> Hi, when a package stops shipping subpackages the buildsystem gets upset - the old subpackage which required the old main package cries out loud in the broken deps reports. Can a maintainer do something about it? Mail a human plugin of the buildsystem to throw the old subpackage out? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 23 19:59:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 15:59:23 -0400 Subject: Changing subpackaging In-Reply-To: <20060523194901.GA14369@neu.nirvana> References: <20060523194901.GA14369@neu.nirvana> Message-ID: <1148414363.10695.22.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 21:49 +0200, Axel Thimm wrote: > when a package stops shipping subpackages the buildsystem gets upset - > the old subpackage which required the old main package cries out loud > in the broken deps reports. Doesn't help all the way, but do you have Provides: and Obsoletes: the old subpackage name? -- 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 Axel.Thimm at ATrpms.net Tue May 23 20:01:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 22:01:35 +0200 Subject: Changing subpackaging In-Reply-To: <1148414363.10695.22.camel@dhcp83-49.boston.redhat.com> References: <20060523194901.GA14369@neu.nirvana> <1148414363.10695.22.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060523200135.GC14369@neu.nirvana> On Tue, May 23, 2006 at 03:59:23PM -0400, Jesse Keating wrote: > On Tue, 2006-05-23 at 21:49 +0200, Axel Thimm wrote: > > when a package stops shipping subpackages the buildsystem gets upset - > > the old subpackage which required the old main package cries out loud > > in the broken deps reports. > > Doesn't help all the way, but do you have Provides: and Obsoletes: the > old subpackage name? No, in this case (apt-groupinstall) the package wasn't swallowed in (and probably shouldn't). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue May 23 20:01:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 May 2006 15:01:36 -0500 Subject: Changing subpackaging References: <20060523194901.GA14369@neu.nirvana> Message-ID: Axel Thimm wrote: > when a package stops shipping subpackages the buildsystem gets upset - > the old subpackage which required the old main package cries out loud > in the broken deps reports. > > Can a maintainer do something about it? Mail a human plugin of the > buildsystem to throw the old subpackage out? Request the old/stale rpm to be removed from the repo by adding to the "For requesting removal of packages" section one one (or more) of: http://fedoraproject.org/wiki/Extras/FC4Status http://fedoraproject.org/wiki/Extras/FC5Status http://fedoraproject.org/wiki/Extras/FC6Status -- Rex From jwb at redhat.com Tue May 23 21:46:25 2006 From: jwb at redhat.com (John Berninger) Date: Tue, 23 May 2006 17:46:25 -0400 Subject: mock build - need help Message-ID: <447382B1.2090905@redhat.com> I'm trying to build a package in mock, and I'm getting an error in setting up the repo. I've fixed the pointers in the /etc/mock config files to point to the right places, but still can't get anywhere. The result/root.log file says this is the issue: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-5-i386-core/root groupinstall build build-minimal build-base http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Content-Length: 345 Date: Tue, 23 May 2006 21:42:17 GMT Accept-Ranges: bytes Content-Type: text/html Server: lighttpd/1.3.16 Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Am I missing a correction I need to make to my config, or is there something else broken? -- John From gauret at free.fr Tue May 23 22:21:26 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 24 May 2006 00:21:26 +0200 Subject: Gettext and %find_lang References: <1148394301.16995.9.camel@atlantis.mpeters.local> <1148400615.2297.9.camel@localhost.localdomain> <1148406474.2317.30.camel@localhost.localdomain> Message-ID: Thorsten Leemhuis wrote: > Ville gave a lengthy answer to this already. The problem also simply is: > Mock and the #Exceptions in the Packaging guidelines simply didn't match > in the past. We noticed this some weeks/days ago and we'll hopefully fix > this soon. Sorry for the trouble. Great. As long as it's documented, all's well. I may have sounded angry about that, but I am really not. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Programmer: A biological system designed to convert coffee and pizza into code. From paul at all-the-johnsons.co.uk Tue May 23 22:22:19 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 23 May 2006 23:22:19 +0100 Subject: Obsoletes in a spec file Message-ID: <1148422939.24238.13.camel@T7.Linux> Hi, I'm just about to import anjuta-2.0.2 into FE (rawhide only) and would like to make it obsolete the current version (1.2.4a). Do I just add a line obsoletes: anjuta-1.2.4a-{release} or is there more to it than that? TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- 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 paul at all-the-johnsons.co.uk Tue May 23 22:29:19 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 23 May 2006 23:29:19 +0100 Subject: check-rpaths Message-ID: <1148423359.24238.18.camel@T7.Linux> Hi, Both the new version of gnome-build and kiso are giving errors when running them in mock (and outside of it) with the same sort of problem. Is the problem in the code or in the spec file (which doesn't have anything amazing in them)? The error which comes back is ERROR 0001: file '/usr/lib64/gnome-build-1.0/backends/libgbf-mkfile.so.0.0.1' contains a standard rpath '/usr/lib64' in [/usr/lib64] Neither spec file are using make smp_mflags. Any ideas on this? TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Tue May 23 22:41:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 24 May 2006 00:41:38 +0200 Subject: Obsoletes in a spec file In-Reply-To: <1148422939.24238.13.camel@T7.Linux> References: <1148422939.24238.13.camel@T7.Linux> Message-ID: <20060524004138.1b6eee02.bugs.michael@gmx.net> On Tue, 23 May 2006 23:22:19 +0100, Paul wrote: > Hi, > > I'm just about to import anjuta-2.0.2 into FE (rawhide only) and would > like to make it obsolete the current version (1.2.4a). Do I just add a > line > > obsoletes: anjuta-1.2.4a-{release} > > or is there more to it than that? Why do you want to add that at all? (anjuta-2.0.2 is an update/upgrade of anjuta-1.2.4a already) From tcallawa at redhat.com Tue May 23 22:45:11 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 23 May 2006 17:45:11 -0500 Subject: check-rpaths In-Reply-To: <1148423359.24238.18.camel@T7.Linux> References: <1148423359.24238.18.camel@T7.Linux> Message-ID: <1148424312.10606.8.camel@localhost.localdomain> On Tue, 2006-05-23 at 23:29 +0100, Paul wrote: > Hi, > > Both the new version of gnome-build and kiso are giving errors when > running them in mock (and outside of it) with the same sort of problem. > Is the problem in the code or in the spec file (which doesn't have > anything amazing in them)? > > The error which comes back is > > ERROR 0001: file > '/usr/lib64/gnome-build-1.0/backends/libgbf-mkfile.so.0.0.1' contains a > standard rpath '/usr/lib64' in [/usr/lib64] > > Neither spec file are using make smp_mflags. > > Any ideas on this? It's almost certainly the code. If the previous versions didn't embed the standard rpath and the new version does, diff should shed some light on how to hack the rpath out. ~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 bugs.michael at gmx.net Tue May 23 22:42:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 24 May 2006 00:42:31 +0200 Subject: mock build - need help In-Reply-To: <447382B1.2090905@redhat.com> References: <447382B1.2090905@redhat.com> Message-ID: <20060524004231.d35dbb88.bugs.michael@gmx.net> On Tue, 23 May 2006 17:46:25 -0400, John Berninger wrote: > I'm trying to build a package in mock, and I'm getting an error in > setting up the repo. I've fixed the pointers in the /etc/mock config > files to point to the right places, but still can't get anywhere. The > result/root.log file says this is the issue: > > Executing /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-5-i386-core/root groupinstall build build-minimal > build-base > http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Content-Length: 345 Well, this repo baseurl is in invalid actually. Does it match your configuration files? > Cannot open/read repomd.xml file for repository: core > failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. > Error: failure: repodata/repomd.xml from core: [Errno 256] No more > mirrors to try. From bugs.michael at gmx.net Tue May 23 21:14:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 23 May 2006 23:14:08 +0200 Subject: Changing subpackaging In-Reply-To: References: <20060523194901.GA14369@neu.nirvana> Message-ID: <20060523231408.0c7c40be.bugs.michael@gmx.net> On Tue, 23 May 2006 15:01:36 -0500, Rex Dieter wrote: > Axel Thimm wrote: > > > when a package stops shipping subpackages the buildsystem gets upset - > > the old subpackage which required the old main package cries out loud > > in the broken deps reports. > > > > Can a maintainer do something about it? Mail a human plugin of the > > buildsystem to throw the old subpackage out? > > Request the old/stale rpm to be removed from the repo by adding to the "For > requesting removal of packages" section one one (or more) of: > http://fedoraproject.org/wiki/Extras/FC4Status > http://fedoraproject.org/wiki/Extras/FC5Status > http://fedoraproject.org/wiki/Extras/FC6Status This is necessary because "Obsoletes" does not remove an old sub-package from the repository, "yum install" (and Yum queries) still see this package, and it is listed in the repoview pages, too. From jwb at redhat.com Tue May 23 23:26:09 2006 From: jwb at redhat.com (John Berninger) Date: Tue, 23 May 2006 19:26:09 -0400 Subject: mock build - need help In-Reply-To: <20060524004231.d35dbb88.bugs.michael@gmx.net> References: <447382B1.2090905@redhat.com> <20060524004231.d35dbb88.bugs.michael@gmx.net> Message-ID: <44739A11.3020005@redhat.com> Michael Schwendt wrote: >> Executing /usr/sbin/mock-helper yum --installroot >> /var/lib/mock/fedora-5-i386-core/root groupinstall build build-minimal >> build-base >> http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/repodata/repomd.xml: >> [Errno 14] HTTP Error 404: Content-Length: 345 >> > > Well, this repo baseurl is in invalid actually. Does it match your > configuration files? > Yes, and I've successfully build using that repo baseurl before - I've not changed that entry. I'm getting the same error on fc3, fc4, fc5, and fcdevel mock builds. What are the correct repo url's I need to have? -- John From tibbs at math.uh.edu Wed May 24 01:54:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 23 May 2006 20:54:18 -0500 Subject: check-rpaths In-Reply-To: <1148423359.24238.18.camel@T7.Linux> (paul@all-the-johnsons.co.uk's message of "Tue, 23 May 2006 23:29:19 +0100") References: <1148423359.24238.18.camel@T7.Linux> Message-ID: >>>>> "p" == paul writes: p> ERROR 0001: file p> '/usr/lib64/gnome-build-1.0/backends/libgbf-mkfile.so.0.0.1' p> contains a standard rpath '/usr/lib64' in [/usr/lib64] Some references: http://fedoraproject.org/wiki/ToshioKuratomi The thread starting at: http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01751.html A recent package review with this issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192564 Basically the libtool authors think rpath is great and should be set on every library ever built. Fedora guidelines diagree. One possibility is to build using Fedora's libtool. Every solution seems busted in some way. - J< From lists at forevermore.net Wed May 24 05:42:55 2006 From: lists at forevermore.net (Chris Petersen) Date: Tue, 23 May 2006 22:42:55 -0700 Subject: new package: lineak-defaultplugin Message-ID: <4473F25F.5010105@forevermore.net> This goes along with lineakd from the other day, as well as the two other plugins waiting to be looked over. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191605 -Chris From giallu at gmail.com Wed May 24 06:15:15 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 24 May 2006 08:15:15 +0200 Subject: mock build - need help In-Reply-To: <44739A11.3020005@redhat.com> References: <447382B1.2090905@redhat.com> <20060524004231.d35dbb88.bugs.michael@gmx.net> <44739A11.3020005@redhat.com> Message-ID: On 5/24/06, John Berninger wrote: > > Michael Schwendt wrote: > >> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/repodata/repomd.xml > : > Yes, and I've successfully build using that repo baseurl before - I've > not changed that entry. I'm getting the same error on fc3, fc4, fc5, > and fcdevel mock builds. What are the correct repo url's I need to have I think you are missing /os, like in: http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/os -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at all-the-johnsons.co.uk Wed May 24 06:23:53 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 24 May 2006 07:23:53 +0100 Subject: Obsoletes in a spec file In-Reply-To: <20060524004138.1b6eee02.bugs.michael@gmx.net> References: <1148422939.24238.13.camel@T7.Linux> <20060524004138.1b6eee02.bugs.michael@gmx.net> Message-ID: <1148451833.24238.29.camel@T7.Linux> Hi, > > obsoletes: anjuta-1.2.4a-{release} > > > > or is there more to it than that? > > Why do you want to add that at all? > > (anjuta-2.0.2 is an update/upgrade of anjuta-1.2.4a already) I've found with the upgrade (rpm -Uhv) things don't work as well as. Do rpm -e with the old version and everything is great. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- 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 skvidal at linux.duke.edu Wed May 24 06:34:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 24 May 2006 02:34:58 -0400 Subject: Obsoletes in a spec file In-Reply-To: <1148451833.24238.29.camel@T7.Linux> References: <1148422939.24238.13.camel@T7.Linux> <20060524004138.1b6eee02.bugs.michael@gmx.net> <1148451833.24238.29.camel@T7.Linux> Message-ID: <1148452498.19927.26.camel@cutter> On Wed, 2006-05-24 at 07:23 +0100, Paul wrote: > Hi, > > > > obsoletes: anjuta-1.2.4a-{release} > > > > > > or is there more to it than that? > > > > Why do you want to add that at all? > > > > (anjuta-2.0.2 is an update/upgrade of anjuta-1.2.4a already) > > I've found with the upgrade (rpm -Uhv) things don't work as well as. Do > rpm -e with the old version and everything is great. > Why not? If that's true then the older pkg is probably leaving some file it created around. in rpm-terms a: rpm -Uvh is really just: rpm -i newpkg rpm -e oldpkg -sv From Axel.Thimm at ATrpms.net Wed May 24 07:46:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 24 May 2006 09:46:06 +0200 Subject: Obsoletes in a spec file In-Reply-To: <1148451833.24238.29.camel@T7.Linux> References: <1148422939.24238.13.camel@T7.Linux> <20060524004138.1b6eee02.bugs.michael@gmx.net> <1148451833.24238.29.camel@T7.Linux> Message-ID: <20060524074606.GB4018@neu.nirvana> On Wed, May 24, 2006 at 07:23:53AM +0100, Paul wrote: > > > obsoletes: anjuta-1.2.4a-{release} > > > > > > or is there more to it than that? > > > > Why do you want to add that at all? > > > > (anjuta-2.0.2 is an update/upgrade of anjuta-1.2.4a already) > > I've found with the upgrade (rpm -Uhv) things don't work as well as. Do > rpm -e with the old version and everything is great. Then that's either o a bug in %post* %pre* scriplets, and adding obsoletes won't make any difference. You probably get eaten by %postin from the new package being called before %postun from the old one. rpm -e, rpm -i separate these steps (but an explicit obsolete will not, so you'd be back to square 1). o (higly unlikely) a bug in rpm Why don't you report on the issues you have and we can help you fix the package? Paste in any %post* %pre* scripts you've written. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Wed May 24 08:34:57 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 24 May 2006 10:34:57 +0200 Subject: mock build - need help In-Reply-To: <44739A11.3020005@redhat.com> References: <447382B1.2090905@redhat.com> <20060524004231.d35dbb88.bugs.michael@gmx.net> <44739A11.3020005@redhat.com> Message-ID: <20060524103457.15cd0fb3.bugs.michael@gmx.net> On Tue, 23 May 2006 19:26:09 -0400, John Berninger wrote: > Michael Schwendt wrote: > >> Executing /usr/sbin/mock-helper yum --installroot > >> /var/lib/mock/fedora-5-i386-core/root groupinstall build build-minimal > >> build-base > >> http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/repodata/repomd.xml: > >> [Errno 14] HTTP Error 404: Content-Length: 345 > >> > > > > Well, this repo baseurl is in invalid actually. Does it match your > > configuration files? > > > Yes, and I've successfully build using that repo baseurl before - I've > not changed that entry. I'm getting the same error on fc3, fc4, fc5, > and fcdevel mock builds. What are the correct repo url's I need to have? Point your web browser to above URL and traverse the directories starting at the top. You'll find the "repodata" directory in here: http://newmirror.linux.duke.edu/pub/fedora/linux/core/5/i386/os/ From ville.skytta at iki.fi Wed May 24 15:01:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 24 May 2006 18:01:06 +0300 Subject: Obsoletes in a spec file In-Reply-To: <20060524074606.GB4018@neu.nirvana> References: <1148422939.24238.13.camel@T7.Linux> <20060524004138.1b6eee02.bugs.michael@gmx.net> <1148451833.24238.29.camel@T7.Linux> <20060524074606.GB4018@neu.nirvana> Message-ID: <1148482866.2750.174.camel@localhost.localdomain> On Wed, 2006-05-24 at 09:46 +0200, Axel Thimm wrote: > On Wed, May 24, 2006 at 07:23:53AM +0100, Paul wrote: > > > I've found with the upgrade (rpm -Uhv) things don't work as well as. Do > > rpm -e with the old version and everything is great. > > Then that's either > > o a bug in %post* %pre* scriplets, and adding obsoletes won't make any > difference. You probably get eaten by %postin from the new package > being called before %postun from the old one. rpm -e, rpm -i > separate these steps (but an explicit obsolete will not, so you'd be > back to square 1). > > o (higly unlikely) a bug in rpm Or the obvious: anjuta 1.2.4a has "Epoch: 1", that needs to be present in the new one too. From toshio at tiki-lounge.com Wed May 24 17:01:47 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 24 May 2006 10:01:47 -0700 Subject: check-rpaths In-Reply-To: References: <1148423359.24238.18.camel@T7.Linux> Message-ID: <1148490107.3167.11.camel@localhost> On Tue, 2006-05-23 at 20:54 -0500, Jason L Tibbitts III wrote: > >>>>> "p" == paul writes: > > p> ERROR 0001: file > p> '/usr/lib64/gnome-build-1.0/backends/libgbf-mkfile.so.0.0.1' > p> contains a standard rpath '/usr/lib64' in [/usr/lib64] > > Some references: > > http://fedoraproject.org/wiki/ToshioKuratomi > Rather than my personal page (which is a bit of a rat's nest :-) you can find more official information here:: http://fedoraproject.org/wiki/Extras/Schedule/RpathCheckBuildsys That page has a more detailed explanation of the rpath problem in general. It includes several workarounds for it when the rpath is being dragged in by libtool, including the workaround listed on my wiki page. It doesn't seem to mention the less intrusive measure of %configure --disable-rpath but that mostly works with applications, not with libtool-munged library builds. -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 orion at cora.nwra.com Wed May 24 18:00:17 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 24 May 2006 12:00:17 -0600 Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? Message-ID: <44749F31.4010702@cora.nwra.com> I'm look at the pari submission . We get the following rpmlint warning: E: pari shlib-with-non-pic-code /usr/lib/libpari.so.2.1.7 This appears to be because of the following line from objdump: # objdump --headers --private-headers /usr/lib/libpari.so.2.1.7 | grep TEXTREL TEXTREL 0x0 which rpmlint looks for. Other .so's with this: TEXTREL 0x0 /usr/lib/libGL.so TEXTREL 0x0 /usr/lib/libGLU.so TEXTREL 0x0 /usr/lib/libj3dcore-ogl.so TEXTREL 0x0 /usr/lib/libj3dutils.so TEXTREL 0x0 /usr/lib/libmpeg-0.3.0.so TEXTREL 0x0 /usr/lib/libmpeg.so The C code is compiled with -fPIC, but there is one piece of assembly and I it might be caused by that. Anyone out there know for sure? If so, what needs to get done? SRPM is here http://www.cora.nwra.com/~orion/fedora/pari-2.1.7-4.src.rpm -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From roland at redhat.com Wed May 24 18:56:53 2006 From: roland at redhat.com (Roland McGrath) Date: Wed, 24 May 2006 11:56:53 -0700 (PDT) Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? In-Reply-To: Orion Poplawski's message of Wednesday, 24 May 2006 12:00:17 -0600 <44749F31.4010702@cora.nwra.com> Message-ID: <20060524185653.B4718180054@magilla.sf.frob.com> It does require some knowledge of the particular machine you're dealing with. You can look at the .o files that go into the .so with objdump -rd and look for the non-PIC relocations they use. If you don't know how to identify those already, then you will probably have a hard time adjusting the assembly code. From buildsys at fedoraproject.org Wed May 24 20:12:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 24 May 2006 16:12:04 -0400 (EDT) Subject: Fedora Extras Package Build Report Message-ID: <20060524201204.9183615218A@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 14 amarok-1.4.0-5.fc5 bzrtools-0.8.1-4.fc5 conserver-8.1.14-3.fc5 gnubiff-2.2.1-2.fc5 isic-0.06-2.fc5 kipi-plugins-0.1.0-0.9.rc2.fc5 lyx-1.4.1-7.fc5 perl-Data-Structure-Util-0.11-1.fc5 perl-Devel-Cycle-1.07-1.fc5 perl-File-Type-0.22-2.fc5 perl-IO-Null-1.01-1.fc5 python-kid-0.9.1-3.fc5 python-sqlalchemy-0.1.7-1.fc5 serpentine-0.6.91-1.fc5 Packages built and released for Fedora Extras 4: 9 bzrtools-0.8.1-4.fc4 conserver-8.1.14-3.fc4 kipi-plugins-0.1.0-0.9.rc2.fc4 lyx-1.4.1-7.fc4 perl-Data-Structure-Util-0.11-1.fc4 perl-File-Type-0.22-2.fc4 perl-IO-Null-1.01-1.fc4 python-kid-0.9.1-3.fc4 python-sqlalchemy-0.1.7-1.fc4 Packages built and released for Fedora Extras 3: 1 conserver-8.1.14-3.fc3 Packages built and released for Fedora Extras development: 20 amarok-1.4.0-5.fc6 bzrtools-0.8.1-4.fc6 conserver-8.1.14-3.fc6 gnubiff-2.2.1-2.fc6 gtkglextmm-1.2.0-3.fc6 kipi-plugins-0.1.0-0.9.rc2.fc6 lineak-defaultplugin-0.8.4-5.fc6 lineakd-0.8.4-5.fc6 lyx-1.4.1-7.fc6 nedit-5.5-8.fc6 perl-Data-Structure-Util-0.11-1.fc6 perl-Devel-Cycle-1.07-1.fc6 perl-File-Type-0.22-2.fc6 python-kid-0.9.1-3.fc6 python-sqlalchemy-0.1.7-1.fc6 qt4-4.1.3-4.fc6 serpentine-0.6.91-1.fc6 uuid-1.4.2-4.fc6 w3m-el-1.4.4-3.fc6 xmms-1.2.10-24.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 24 20:29:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 24 May 2006 20:29:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-24 Message-ID: <20060524202954.19014.15344@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.i386 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.ppc plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: apt-groupinstall - 0.5.15cnc7-6.fc4.i386 from fedora-extras-4-i386 unresolved deps: apt = 0:0.5.15cnc7-6.fc4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: apt-groupinstall - 0.5.15cnc7-6.fc4.ppc from fedora-extras-4-ppc unresolved deps: apt = 0:0.5.15cnc7-6.fc4 From buildsys at fedoraproject.org Wed May 24 20:29:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 24 May 2006 20:29:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-24 Message-ID: <20060524202954.19018.89476@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Wed May 24 20:29:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 24 May 2006 20:29:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-24 Message-ID: <20060524202954.19011.31939@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From buildsys at fedoraproject.org Wed May 24 20:29:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 24 May 2006 20:29:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-24 Message-ID: <20060524202954.19016.77600@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From orion at cora.nwra.com Wed May 24 20:44:56 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 24 May 2006 14:44:56 -0600 Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? In-Reply-To: <20060524185653.B4718180054@magilla.sf.frob.com> References: <20060524185653.B4718180054@magilla.sf.frob.com> Message-ID: <4474C5C8.7090800@cora.nwra.com> Roland McGrath wrote: > It does require some knowledge of the particular machine you're dealing > with. You can look at the .o files that go into the .so with objdump -rd > and look for the non-PIC relocations they use. If you don't know how to > identify those already, then you will probably have a hard time adjusting > the assembly code. > Well, here is some of the assembly: .text .globl addll .globl subll .globl addllx .globl subllx .globl shiftl .globl shiftlr .globl bfffo .globl mulll .globl addmul .globl divll .globl overflow .globl hiremainder .comm overflow,4,4 .comm hiremainder,4,4 .text .align 8 addll: xorl %edx,%edx movl 4(%esp),%eax addl 8(%esp),%eax adcl %edx,%edx movl %edx,overflow ret It's generated using macros like: GLOBL(C(addll)) GLOBL(C(subll)) ALIGN FUNBEGIN(addll) INSN2(xor,l ,R(edx),R(edx)) /* clear %edx */ INSN2(mov,l ,X4 MEM_DISP(esp,4),R(eax)) /* get x */ INSN2(add,l ,X4 MEM_DISP(esp,8),R(eax)) /* add y */ INSN2(adc,l ,R(edx),R(edx)) /* %edx := carry */ INSN2(mov,l ,R(edx),C(overflow)) /* set overflow */ ret /* return %eax */ FUNEND() If there is something easy that can be done, please let us know. In the meantime, should this be a blocker against pari being accepted into extras? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From j.w.r.degoede at hhs.nl Wed May 24 20:51:24 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 24 May 2006 22:51:24 +0200 Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? In-Reply-To: <4474C5C8.7090800@cora.nwra.com> References: <20060524185653.B4718180054@magilla.sf.frob.com> <4474C5C8.7090800@cora.nwra.com> Message-ID: <4474C74C.5090501@hhs.nl> Orion Poplawski wrote: > In the meantime, should this be a blocker against pari being accepted > into extras? > Non PIC .so's break with SELinux (targeted) being enabled. There is a work around though, checkout Glide3 in cvs, there is some magick in the specfile to fix the SELinux issues. This is not the preferred way to handle this though. Regards, Hans From gemi at bluewin.ch Wed May 24 20:58:40 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 24 May 2006 22:58:40 +0200 Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? In-Reply-To: <4474C74C.5090501@hhs.nl> References: <20060524185653.B4718180054@magilla.sf.frob.com> <4474C5C8.7090800@cora.nwra.com> <4474C74C.5090501@hhs.nl> Message-ID: <1148504321.25179.4.camel@scriabin.tannenrauch.ch> On Wed, 2006-05-24 at 22:51 +0200, Hans de Goede wrote: > > Orion Poplawski wrote: > > In the meantime, should this be a blocker against pari being accepted > > into extras? > > > > Non PIC .so's break with SELinux (targeted) being enabled. There is a > work around though, checkout Glide3 in cvs, there is some magick in the > specfile to fix the SELinux issues. I see, that they change the context to textrel_shlib_t, and create a selinux module for it. However this should only be done, if there is no other way to do it. Normally, ensuring that all the source files going into the shared library are compiled using -fPIC should be enough. Another problem seems to be that on X86_64 they MUST be compiled with -fPIC. Could someone confirm this. What's the situation for ppc? BTW, is ppc 32 or 64 bit? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jpo at lsd.di.uminho.pt Wed May 24 21:07:38 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 24 May 2006 22:07:38 +0100 Subject: Building system: segmentation fault in devel (i386 arch) Message-ID: <4474CB1A.6030703@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am getting segmentation faults (i386) when I try to build the latest version of multitail in rawhide (devel). The same package built successfully in FC-4 and FC-5; it also built successfully in devel for x86_64. Does someone has any clue? gcc update? make 3.81? Partial log: - ---------- ... cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions - -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 - -mtune=generic -fasynchronous-unwind-tables -D`uname` -O2 -Wall - -DVERSION=\"4.0.4\" -g -DCONFIG_FILE=\"//etc/multitail.conf\" -c -o scrollback.o scrollback.c make: *** [scrollback.o] Segmentation fault make: *** Waiting for unfinished jobs.... error: Bad exit status from /var/tmp/rpm-tmp.84130 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.84130 (%build) - ---------- Full log: http://buildsys.fedoraproject.org/logs/fedora-development-extras/9911-multitail-4.0.4-1.fc6/ tia, 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEdMsal0metZG9hRsRAsDOAJ9KF8WYBR9xmz0sJJt3XQTlCkmspACfXfHM VRAh3M/5sMfUYJB361jWtBo= =C+Wv -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From roland at redhat.com Wed May 24 21:43:35 2006 From: roland at redhat.com (Roland McGrath) Date: Wed, 24 May 2006 14:43:35 -0700 (PDT) Subject: Question about "shlib-with-non-pic-code", possibly caused by assembler code? In-Reply-To: Orion Poplawski's message of Wednesday, 24 May 2006 14:44:56 -0600 <4474C5C8.7090800@cora.nwra.com> Message-ID: <20060524214335.98456180054@magilla.sf.frob.com> > Well, here is some of the assembly: [...] > movl %edx,overflow This is a non-PIC data reference. The code has to determine its PC and add that to a PC-relative offset (or GOT-relative, usually, which is an adjusted PC-relative offset). The changes are not very hard to make, but have to be done with an eye to the register usage in the code and so forth. I'm sure you can find other assembly code around that handles PIC in the canonical ways, or look at the output of the compiler. But, as I said, it takes some attention from someone with knowledge of assembly on that machine. From pertusus at free.fr Thu May 25 09:19:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 May 2006 11:19:21 +0200 Subject: build system issue? Message-ID: <20060525091921.GA3346@free.fr> Hello, The build server seems to have issues. On the web interface xboard seems to be building since 13h, and when I try to submit a job, I get: /usr/bin/plague-client build cernlib cernlib-2005-21_fc4 fc4 Package cernlib enqueued. (However, no Job ID was provided in the time required) /usr/bin/plague-client build cernlib cernlib-2005-21_fc4 fc4 Error: connection to the server timed out. '(110, 'Operation timed out.')' make: *** [build] Erreur 1 -- Pat From sean.bruno at dsl-only.net Thu May 25 13:07:10 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 25 May 2006 06:07:10 -0700 Subject: FE 5 Amarok Message-ID: <1148562430.2933.8.camel@home-desk> I've noted that the FE 5 Amarok doesn't seem to be able to connect to streams any longer. Is there a work around out there? I could seem to find one through google... Sean From dcbw at redhat.com Thu May 25 15:09:57 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 25 May 2006 11:09:57 -0400 Subject: build system issue? In-Reply-To: <20060525091921.GA3346@free.fr> References: <20060525091921.GA3346@free.fr> Message-ID: <1148569797.3389.6.camel@localhost.localdomain> On Thu, 2006-05-25 at 11:19 +0200, Patrice Dumas wrote: > Hello, > > The build server seems to have issues. On the web interface xboard seems > to be building since 13h, and when I try to submit a job, I get: > > /usr/bin/plague-client build cernlib cernlib-2005-21_fc4 fc4 > Package cernlib enqueued. (However, no Job ID was provided in the time required) > > > /usr/bin/plague-client build cernlib cernlib-2005-21_fc4 fc4 > Error: connection to the server timed out. '(110, 'Operation timed out.')' > make: *** [build] Erreur 1 It appears that the database server process was stopped by somebody... Anyway, I've kicked the build server. People need to requeue the following job requests: Axel - synaptic-0_57_2-5_fc4, synaptic-0_57_2-5_fc5, synaptic-0_57_2-5_fc6 Ville - xemacs-sumo-20060510-2_fc5_1, xmms-1_2_10-25_fc6 Rex - lyx-1_4_1-7_fc4_1 Patrice - cernlib-2005-21_fc4 Dan From qspencer at ieee.org Thu May 25 15:20:21 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 25 May 2006 10:20:21 -0500 Subject: FE 5 Amarok In-Reply-To: <1148562430.2933.8.camel@home-desk> References: <1148562430.2933.8.camel@home-desk> Message-ID: <4475CB35.4070206@ieee.org> Sean Bruno wrote: >I've noted that the FE 5 Amarok doesn't seem to be able to connect to >streams any longer. > > It doesn't play flac files either, apparently because the developers decided not to support one of the plugins. I think the "upgrade" to 1.4 was a bad idea. Quentin From enrico.scholz at informatik.tu-chemnitz.de Thu May 25 15:36:28 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 25 May 2006 17:36:28 +0200 Subject: check-rpaths In-Reply-To: <1148490107.3167.11.camel@localhost> (Toshio Kuratomi's message of "Wed, 24 May 2006 10:01:47 -0700") References: <1148423359.24238.18.camel@T7.Linux> <1148490107.3167.11.camel@localhost> Message-ID: <87zmh6p14z.fsf@kosh.bigo.ensc.de> toshio at tiki-lounge.com (Toshio Kuratomi) writes: > It doesn't seem to mention the less intrusive measure of %configure > --disable-rpath This works only when upstream tarball is created with an inofficial 'libtool' (e.g. this with the multilib-patch from Fedora Core). The official libtool *will* create /usr/lib64 RPATHs; even with '--disable-rpath'. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From orion at cora.nwra.com Thu May 25 16:04:25 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 25 May 2006 10:04:25 -0600 Subject: mock and build system macros Message-ID: <4475D589.6070005@cora.nwra.com> Where do I put the buildsystem macros that define fcdist/fedora/etc so that my local mock builds can use them? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From dlutter at redhat.com Thu May 25 17:46:45 2006 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 25 May 2006 10:46:45 -0700 Subject: mock and build system macros In-Reply-To: <4475D589.6070005@cora.nwra.com> References: <4475D589.6070005@cora.nwra.com> Message-ID: <1148579205.27153.19.camel@currant.watzmann.net> On Thu, 2006-05-25 at 10:04 -0600, Orion Poplawski wrote: > Where do I put the buildsystem macros that define fcdist/fedora/etc so > that my local mock builds can use them? Not sure if that is the official way, but from looking at the mock source, the best place seems to be in config_opts['macros'] in the mock config for each distro. I have the following in my fedora-development-i386-core.cfg: config_opts['macros'] = """ %_topdir /builddir/build %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm %dist .fc6 """ (The _topdir and _rpmfilename are set in the mock source as defaults, that's why you should add them when you set config_opts['macros'] explicitly) You need to reinitialize/clean the buildroot for the config change to take hold. David From gauret at free.fr Thu May 25 18:39:29 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 25 May 2006 20:39:29 +0200 Subject: FE 5 Amarok References: <1148562430.2933.8.camel@home-desk> Message-ID: Sean Bruno wrote: > I've noted that the FE 5 Amarok doesn't seem to be able to connect to > streams any longer. > > Is there a work around out there? I could seem to find one through > google... Which architecture are you on ? Which engine are you using ? Please use bugzilla for this type of request. 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 gauret at free.fr Thu May 25 18:46:02 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 25 May 2006 20:46:02 +0200 Subject: FE 5 Amarok References: <1148562430.2933.8.camel@home-desk> <4475CB35.4070206@ieee.org> Message-ID: Quentin Spencer wrote: > It doesn't play flac files either, apparently because the developers > decided not to support one of the plugins. I think the "upgrade" to 1.4 > was a bad idea. As said earlier on this list, the amarok developers chose to remove the gstreamer 0.10 engine from the tarball. That leaves us with the Helix engine only, since Xine can't be in extras for patent reasons. Unfortunately, Helix has no flac plugin yet, so amarok won't play flac files for the moment. However, if you live in a country which does not recognizes software patents, you can install the Xine engine from another repository. This one plays flac files. Sigh... Already 4 bug reports because the gstreamer engine has been removed upstream... Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From paul at city-fan.org Thu May 25 19:26:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 25 May 2006 20:26:20 +0100 Subject: mock and build system macros In-Reply-To: <4475D589.6070005@cora.nwra.com> References: <4475D589.6070005@cora.nwra.com> Message-ID: <1148585181.8185.26.camel@laurel.intra.city-fan.org> On Thu, 2006-05-25 at 10:04 -0600, Orion Poplawski wrote: > Where do I put the buildsystem macros that define fcdist/fedora/etc so > that my local mock builds can use them? Yum in FC5 handles groups differently. You need to change in your mock config files: config_opts['buildgroup'] from: 'build' to: 'build-minimal build-base build' See: http://fedoraproject.org/wiki/Extras/MockTricks Paul. From jkeating at redhat.com Thu May 25 19:29:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 May 2006 15:29:05 -0400 Subject: mock and build system macros In-Reply-To: <1148585181.8185.26.camel@laurel.intra.city-fan.org> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> Message-ID: <1148585345.3221.11.camel@ender> On Thu, 2006-05-25 at 20:26 +0100, Paul Howarth wrote: > from: 'build' > to: 'build-minimal build-base build' > > See: http://fedoraproject.org/wiki/Extras/MockTricks Can we not get an update to the mock package for FC5 that incorporates these necessary changes? -- 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 skvidal at linux.duke.edu Thu May 25 19:35:22 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 25 May 2006 15:35:22 -0400 Subject: mock and build system macros In-Reply-To: <1148585345.3221.11.camel@ender> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> Message-ID: <1148585722.8332.30.camel@cutter> On Thu, 2006-05-25 at 15:29 -0400, Jesse Keating wrote: > On Thu, 2006-05-25 at 20:26 +0100, Paul Howarth wrote: > > from: 'build' > > to: 'build-minimal build-base build' > > > > See: http://fedoraproject.org/wiki/Extras/MockTricks > > Can we not get an update to the mock package for FC5 that incorporates > these necessary changes? We probably can. If you ask really nicely :) -sv From jkeating at redhat.com Thu May 25 19:32:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 May 2006 15:32:45 -0400 Subject: mock and build system macros In-Reply-To: <1148585722.8332.30.camel@cutter> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> Message-ID: <1148585565.3221.13.camel@ender> On Thu, 2006-05-25 at 15:35 -0400, seth vidal wrote: > > We probably can. > > If you ask really nicely :) Pretty pretty please? With a pony? -- 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 chris.stone at gmail.com Thu May 25 19:41:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 25 May 2006 12:41:45 -0700 Subject: check-rpaths In-Reply-To: <1148490107.3167.11.camel@localhost> References: <1148423359.24238.18.camel@T7.Linux> <1148490107.3167.11.camel@localhost> Message-ID: On 5/24/06, Toshio Kuratomi wrote: > > http://fedoraproject.org/wiki/ToshioKuratomi I have this rpath problem in one of my packages and I've modified the %build like so: %build %configure --enable-gifplugin --disable-static %{__make} LIBTOOL=/usr/bin/libtool %{?_smp_mflags} This does fix the rpath error, however with this modification, the static library is built even though I specify --disable-static on the %configure line. Any idea why this happens? From seg at haxxed.com Thu May 25 20:47:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 15:47:06 -0500 Subject: mock and build system macros In-Reply-To: <1148585565.3221.13.camel@ender> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> Message-ID: <1148590026.3942.7.camel@localhost.localdomain> On Thu, 2006-05-25 at 15:32 -0400, Jesse Keating wrote: > On Thu, 2006-05-25 at 15:35 -0400, seth vidal wrote: > > > > We probably can. > > > > If you ask really nicely :) > > Pretty pretty please? With a pony? I actually have a mock package with autocache, my yum cache, and my ccache support built in, that I'm using. Dare I unleash it? Though I haven't actually put my configs in the package. My setup is documented here: http://fedoraproject.org/wiki/CallumLerwick/MockHacking Which has not been updated with autocache yet... -------------- 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 skvidal at linux.duke.edu Thu May 25 21:02:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 25 May 2006 17:02:15 -0400 Subject: mock and build system macros In-Reply-To: <1148590026.3942.7.camel@localhost.localdomain> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> <1148590026.3942.7.camel@localhost.localdomain> Message-ID: <1148590935.8332.38.camel@cutter> On Thu, 2006-05-25 at 15:47 -0500, Callum Lerwick wrote: > On Thu, 2006-05-25 at 15:32 -0400, Jesse Keating wrote: > > On Thu, 2006-05-25 at 15:35 -0400, seth vidal wrote: > > > > > > We probably can. > > > > > > If you ask really nicely :) > > > > Pretty pretty please? With a pony? > > I actually have a mock package with autocache, my yum cache, and my > ccache support built in, that I'm using. Dare I unleash it? > > Though I haven't actually put my configs in the package. My setup is > documented here: > > http://fedoraproject.org/wiki/CallumLerwick/MockHacking > > Which has not been updated with autocache yet... why don't you participate on the buildsys-list and we can take a look at your patches like we have with all the ones everyone else has been contributing. -sv From ville.skytta at iki.fi Thu May 25 21:05:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 26 May 2006 00:05:33 +0300 Subject: Buildsys (i386) oddity Message-ID: <1148591133.17615.84.camel@localhost.localdomain> There seems to be something strange with the buildsys (i386/devel): I made some innocent changes to xmms and requested a build, but the i386 build seems to get repeatedly stuck in running/building state. It builds fine in the x86_64 and ppc builders in the buildsys and I can't reproduce any weirdness locally on i386. I've killed/requeued the job already twice, but that hasn't helped: http://buildsys.fedoraproject.org/build-status/job.psp?uid=9945 Could someone take a look? TIA! From seg at haxxed.com Thu May 25 21:06:18 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 16:06:18 -0500 Subject: mock and build system macros In-Reply-To: <1148590935.8332.38.camel@cutter> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> <1148590026.3942.7.camel@localhost.localdomain> <1148590935.8332.38.camel@cutter> Message-ID: <1148591178.3942.15.camel@localhost.localdomain> > why don't you participate on the buildsys-list and we can take a look at > your patches like we have with all the ones everyone else has been > contributing. Well I've been lurking a bit... My patches were intended for my own use, quick hacks by someone who doesn't actually know python. Bluntly, upstreaming them isn't high on my list of priorities. If someone else wants to clean them up enough for upstreaming, please feel free. :) -------------- 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 skvidal at linux.duke.edu Thu May 25 21:14:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 25 May 2006 17:14:46 -0400 Subject: mock and build system macros In-Reply-To: <1148591178.3942.15.camel@localhost.localdomain> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> <1148590026.3942.7.camel@localhost.localdomain> <1148590935.8332.38.camel@cutter> <1148591178.3942.15.camel@localhost.localdomain> Message-ID: <1148591686.8332.40.camel@cutter> On Thu, 2006-05-25 at 16:06 -0500, Callum Lerwick wrote: > > why don't you participate on the buildsys-list and we can take a look at > > your patches like we have with all the ones everyone else has been > > contributing. > > Well I've been lurking a bit... > > My patches were intended for my own use, quick hacks by someone who > doesn't actually know python. Bluntly, upstreaming them isn't high on my > list of priorities. If someone else wants to clean them up enough for > upstreaming, please feel free. :) if it's not high on your list then quit pimping them on every list. It just leads to confusion about what people are using. -sv From seg at haxxed.com Thu May 25 21:21:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 16:21:49 -0500 Subject: mock and build system macros In-Reply-To: <1148591686.8332.40.camel@cutter> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> <1148590026.3942.7.camel@localhost.localdomain> <1148590935.8332.38.camel@cutter> <1148591178.3942.15.camel@localhost.localdomain> <1148591686.8332.40.camel@cutter> Message-ID: <1148592109.3942.22.camel@localhost.localdomain> On Thu, 2006-05-25 at 17:14 -0400, seth vidal wrote: > if it's not high on your list then quit pimping them on every list. It > just leads to confusion about what people are using. Fine, I'll take down my wiki page and keep it all to myself. ;P Sorry I attempted to put it up for review and discussion. -------------- 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 skvidal at linux.duke.edu Thu May 25 21:26:12 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 25 May 2006 17:26:12 -0400 Subject: mock and build system macros In-Reply-To: <1148592109.3942.22.camel@localhost.localdomain> References: <4475D589.6070005@cora.nwra.com> <1148585181.8185.26.camel@laurel.intra.city-fan.org> <1148585345.3221.11.camel@ender> <1148585722.8332.30.camel@cutter> <1148585565.3221.13.camel@ender> <1148590026.3942.7.camel@localhost.localdomain> <1148590935.8332.38.camel@cutter> <1148591178.3942.15.camel@localhost.localdomain> <1148591686.8332.40.camel@cutter> <1148592109.3942.22.camel@localhost.localdomain> Message-ID: <1148592372.8332.43.camel@cutter> On Thu, 2006-05-25 at 16:21 -0500, Callum Lerwick wrote: > On Thu, 2006-05-25 at 17:14 -0400, seth vidal wrote: > > if it's not high on your list then quit pimping them on every list. It > > just leads to confusion about what people are using. > > Fine, I'll take down my wiki page and keep it all to myself. ;P > > Sorry I attempted to put it up for review and discussion. I guess I would just prefer if you'd help out in the devel. That's all. -sv From dtimms at bigpond.net.au Thu May 25 22:00:47 2006 From: dtimms at bigpond.net.au (David Timms) Date: Fri, 26 May 2006 08:00:47 +1000 Subject: OT: Media format patents and commercial installations Message-ID: <4476290F.8050207@bigpond.net.au> Hi all, I am interested in building FC5 based installations for commercial sale. One of the requirements is the capability to play back media of as many types as possible (eg using mplayer/xine/vlc). While Fedora core/extras can't contain patent encumbered nor non-open source software, in general terms is there anything to stop me selling such a box ? eg. for mpeg2 / 4 playback I could use the various libraries available. Does anyone know if other parties have been able to negotiate with the patent holders (I guess MPEG) individual licenses for linux machines ? Is it hideously expensive ? Unfortunately, while most media content that I would need to be played is made available from outside sources as mpeg2 files or DVDVideo discs (non-encrypted), I can definitely see the advantages in the non-patented formats eg ogg / ogm. Losing quality in converting to different formats wouldn't seem to make sense ? From the other viewpoint, is there mature ogg/ogm open-source plugins for adobe premiere or wm coders that I could supply to these outside content creators (on winOS) and hence have the original media in open format to start with ? I welcome any comments from people who may have dabbled in this area. Thanks, DaveT. From Axel.Thimm at ATrpms.net Thu May 25 22:41:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 26 May 2006 00:41:03 +0200 Subject: OT: Media format patents and commercial installations In-Reply-To: <4476290F.8050207@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> Message-ID: <20060525224103.GB2736@neu.nirvana> On Fri, May 26, 2006 at 08:00:47AM +1000, David Timms wrote: > I am interested in building FC5 based installations for commercial sale. > One of the requirements is the capability to play back media of as many > types as possible (eg using mplayer/xine/vlc). While Fedora core/extras > can't contain patent encumbered nor non-open source software, in general > terms is there anything to stop me selling such a box ? > > eg. for mpeg2 / 4 playback I could use the various libraries available. > Does anyone know if other parties have been able to negotiate with the > patent holders (I guess MPEG) individual licenses for linux machines ? Yes, I had been in contact with MPEGLA in a previous contract assignment. > Is it hideously expensive ? The costs are minimal. The pain is in the burocracy. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Thu May 25 22:39:51 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 17:39:51 -0500 Subject: OT: Media format patents and commercial installations In-Reply-To: <4476290F.8050207@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> Message-ID: <1148596791.3942.72.camel@localhost.localdomain> On Fri, 2006-05-26 at 08:00 +1000, David Timms wrote: > eg. for mpeg2 / 4 playback I could use the various libraries available. > Does anyone know if other parties have been able to negotiate with the > patent holders (I guess MPEG) individual licenses for linux machines ? > Is it hideously expensive ? Linspire has done it. For their for-profit distribution. And yes, its hideously expensive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu May 25 23:45:45 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 18:45:45 -0500 Subject: check-rpaths In-Reply-To: <1148490107.3167.11.camel@localhost> References: <1148423359.24238.18.camel@T7.Linux> <1148490107.3167.11.camel@localhost> Message-ID: <1148600745.3942.74.camel@localhost.localdomain> For what its worth, the debian take on the rpath problem: http://wiki.debian.org/RpathIssue -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri May 26 02:16:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 25 May 2006 21:16:59 -0500 Subject: PHP packaging guidelines Message-ID: Tom Callaway, Chris Weyl and I had an impromptu discussion today in #fedora-extras about what needs to happen in order to get the PHP packaging guidelines into shape. (Tom Callaway has the final decision as to the acceptability of these guidelines, and they will stand for both Core and Extras if accepted.) I have updated http://fedoraproject.org/wiki/Packaging/PHP with the results of the discussion. I have also included a log of the IRC discussion for those who would like to see the full rationale. Note that one aspect of the proposal requires updates to the core PHP package; this still needs to be run by the core PHP maintainer (Joe Orton). Hopefully that will happen in the next few days. Your comments are appreciated. - J< From mmcgrath at fedoraproject.org Fri May 26 03:00:02 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 25 May 2006 22:00:02 -0500 Subject: PHP packaging guidelines In-Reply-To: References: Message-ID: <3237e4410605252000pafa5034m97ef1d04fe11056c@mail.gmail.com> > Your comments are appreciated. > At this point my vote is for /usr/share/. Why does /var/www/* even exist? Also, we should probably put in there a little note that says that just because its a web app doesn't mean it can break FHS. (I've been guilty of this on more than one occasion). Its the packagers job to put logs in /var/log, cache or any other files that get written to in their appropriate /var/ directory. Exceptions to this should be rare. We've talked about this a bit on the list before but should we also mention a "All web apps should be available to localhost only by default" guideline. I know most of what I'm talking about is general web app guidelines, perhaps its time to re-evaluate them. Unless they're already out there and I'm not seeing them :-D -Mike From seg at haxxed.com Fri May 26 03:28:07 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 May 2006 22:28:07 -0500 Subject: PHP packaging guidelines In-Reply-To: <3237e4410605252000pafa5034m97ef1d04fe11056c@mail.gmail.com> References: <3237e4410605252000pafa5034m97ef1d04fe11056c@mail.gmail.com> Message-ID: <1148614087.3942.86.camel@localhost.localdomain> On Thu, 2006-05-25 at 22:00 -0500, Mike McGrath wrote: > At this point my vote is for /usr/share/. Why does /var/www/* even > exist? Yes, putting web apps in /var/www/ is just flat out wrong for at least two reasons I can think of: /var/www is where local content goes. Similar to /usr/local, nothing in /var/www should ever be placed there or modified by the package manager. (Yes, its arguable as to if /var/www is the right place for this stuff. This argument still applies to wherever the "right place" may be) Executables of any kind, whether they be binaries or scripts, simply don't belong anywhere in /var, period. They belong somewhere in /usr, which the truly obsessively paranoid can mount readonly, protecting all binaries. -------------- 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 paul at city-fan.org Fri May 26 07:00:54 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 08:00:54 +0100 Subject: PHP packaging guidelines In-Reply-To: References: Message-ID: <1148626854.8185.40.camel@laurel.intra.city-fan.org> On Thu, 2006-05-25 at 21:16 -0500, Jason L Tibbitts III wrote: > Tom Callaway, Chris Weyl and I had an impromptu discussion today in > #fedora-extras about what needs to happen in order to get the PHP > packaging guidelines into shape. (Tom Callaway has the final decision > as to the acceptability of these guidelines, and they will stand for > both Core and Extras if accepted.) > > I have updated http://fedoraproject.org/wiki/Packaging/PHP with the > results of the discussion. I have also included a log of the IRC > discussion for those who would like to see the full rationale. > > Note that one aspect of the proposal requires updates to the core PHP > package; this still needs to be run by the core PHP maintainer (Joe > Orton). Hopefully that will happen in the next few days. > > Your comments are appreciated. Would Smarty (in Extras as php-Smarty) be an PEAR or PECL package? It doesn't appear to me to be either, http://smarty.php.net/ Paul. From sundaram at fedoraproject.org Fri May 26 07:50:54 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 13:20:54 +0530 Subject: OT: Media format patents and commercial installations In-Reply-To: <4476290F.8050207@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> Message-ID: <1148629854.4310.632.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 08:00 +1000, David Timms wrote: > Hi all, > > I am interested in building FC5 based installations for commercial sale. > One of the requirements is the capability to play back media of as many > types as possible (eg using mplayer/xine/vlc). While Fedora core/extras > can't contain patent encumbered nor non-open source software, in general > terms is there anything to stop me selling such a box ? > Nothing stops you from modifying Fedora and including non-free software for OEM systems. Trademark guidelines do not allow this system to be called Fedora anymore though. There has been discussions in fedora- marketing list about this > eg. for mpeg2 / 4 playback I could use the various libraries available. > Does anyone know if other parties have been able to negotiate with the > patent holders (I guess MPEG) individual licenses for linux machines ? > Is it hideously expensive ? > > Unfortunately, while most media content that I would need to be played > is made available from outside sources as mpeg2 files or DVDVideo discs > (non-encrypted), I can definitely see the advantages in the non-patented > formats eg ogg / ogm. Losing quality in converting to different formats > wouldn't seem to make sense ? > > From the other viewpoint, is there mature ogg/ogm open-source plugins > for adobe premiere or wm coders that I could supply to these outside > content creators (on winOS) and hence have the original media in open > format to start with ? > > I welcome any comments from people who may have dabbled in this area. > > Thanks, DaveT. > Rahul From andreas at bawue.net Fri May 26 09:49:31 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 26 May 2006 11:49:31 +0200 (CEST) Subject: PHP packaging guidelines In-Reply-To: <3237e4410605252000pafa5034m97ef1d04fe11056c@mail.gmail.com> References: <3237e4410605252000pafa5034m97ef1d04fe11056c@mail.gmail.com> Message-ID: On Thu, 25 May 2006, Mike McGrath wrote: > At this point my vote is for /usr/share/. This point is not really open for discussion anymore. We already talked about that at last weeks fesco meeting and /usr/share/%{name} was it for normal php-web-apps. This of course means that the packager would have to fiddle a bit with selinux-permission, but it is managable. There are some examples flying around and I plan to flesh out the packaging guidelines with them. Time permitting of course. > Why does /var/www/* even exist? Also, we should probably put in there > a little note that says that just because its a web app doesn't mean it > can break FHS. (I've been guilty of this on more than one occasion). > Its the packagers job to put logs in /var/log, cache or any other files > that get written to in their appropriate /var/ directory. Exceptions to > this should be rare. Naturally. Especially as it is not such a big problem to do so. A little patchfile and everything is fine. Something else I want to strongly suggest when finishing the guidelines: There _SHOULD_ be a 'die("Please configure this application in /etc/%{name}")' at the start of the configuration file (as long as it's php-code and called via include() or something similar). This prevents security problems in case the application is unconfigured. The alternative would be to set the /usr/share/foo mapping to only accept connections from localhost for the webapp in question. This is done in /etc/httpd/conf.d/%{name}.conf. This should probably be required for webapps which offer these darned "installation-wizards". (Ohhh, how I hate them...) > We've talked about this a bit on the list before but should we also > mention a "All web apps should be available to localhost only by > default" guideline. I know most of what I'm talking about is general > web app guidelines, perhaps its time to re-evaluate them. Unless > they're already out there and I'm not seeing them :-D See above. My plans are actually going further than just localhost. regards, andreas From andreas at bawue.net Fri May 26 09:55:33 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 26 May 2006 11:55:33 +0200 (CEST) Subject: PHP packaging guidelines In-Reply-To: <1148626854.8185.40.camel@laurel.intra.city-fan.org> References: <1148626854.8185.40.camel@laurel.intra.city-fan.org> Message-ID: On Fri, 26 May 2006, Paul Howarth wrote: > Would Smarty (in Extras as php-Smarty) be an PEAR or PECL package? It > doesn't appear to me to be either, Well, code-wise it could be considered pear, as the smarty engine is written in pure-php code. However, as the Smarty Template Engine is not part of pear, we can't really put it in as php-pear-Smarty, isn't it? So either we name it just "Smarty", as upstream does it, or we keep calling it "php-Smarty". After all, the pear and pecl packages should in case there's no collision do provide a php-%{name} package. So, php-Smarty sounds somewhat sane. But I guess Smarty is a somewhat border-case: Normal php-webapps should not be required to be kept in a php-prefixed namespace, but one could argue that Smarty is a base-package and thus should live in the php-namespace. bye, andreas From andreas at bawue.net Fri May 26 10:22:17 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 26 May 2006 12:22:17 +0200 (CEST) Subject: PHP packaging guidelines In-Reply-To: References: Message-ID: Hello Tibbs, thx for the mail. Sorry, I couldn't attend yesterday as we had a working holliday and I was absent from the pc. *g* On Thu, 25 May 2006, Jason L Tibbitts III wrote: > I have updated http://fedoraproject.org/wiki/Packaging/PHP with the > results of the discussion. I have also included a log of the IRC > discussion for those who would like to see the full rationale. To answer a few points from the discussion: [17:11] do we really need the additional naming scheme? [17:12] does the end user care if it is PECL or PEAR? Probably. A pear package can be easier included than a pecl package. Consider a web-developer working on his machine. He has to create an app, running on $random webserver, probably a shared host. He needs support for foo, which is available as pecl or pear. He would choose pear, as it means he doesn't need root on the final webserver but in the worst case can just extract the tarball in the webroot. And about the naming conflicts: It's possible. The pear and pecl projects are not sharing the same namespace. Thus a conflict could occur, even though I haven't looked into the matter if there are already conflicting names. [17:14] cweyl: Do you happen to know what the upstream tarballs look like for each type of module? The upstream Tarball is not prefixed by anything, so we can't just blindly follow upstream. [17:19] * spot idly wonders how nice it would be to get a php (abi) define in the core php package I have no idea how often the php-abi changes. But it would sure be nice to depend on a specific abi version. Icing on the cake would be if the buildsystem would automatically enqueue the packages depending on a specific abi version, whenever the abi changes. e.g. new httpd/php/whatever update, the buildsystem enqueues the packages depending on it. [17:31] each package should Provide: php-FOO = %{version}-%{release} [17:31] this way, we should catch the yum install php-FOO case +q [17:42] cweyl: i don't suppose the PEAR modules identify what php they need, do they? [17:43] spot: typically in the README/install, or on pear.php.net They do that. Quite detailed even. Each package on pear/pecl has a list of requirements. For PECL::Package::gnupg this looks like the following: Dependencies Release 1.2: PHP Version: PHP 4.3 or newer Release 1.1: PHP Version: PHP 4.3 or newer Release 1.0: PHP Version: PHP 4.3 or newer For PEAR::Package::HTML_Progress2, it's a bit more: Dependencies: * PHP Version: PHP 4.2.0 or newer * PEAR Package: PEAR Installer 1.4.3 or newer * PEAR Package: HTML_Common 1.2.1 or newer * PEAR Package: Event_Dispatcher 0.9.1 or newer * PHP Extension: gd * PEAR Package: PHP_Compat 1.4.1 or newer (optional) * PEAR Package: PEAR Installer 1.3.5 or newer (optional) * PEAR Package: HTML_QuickForm 3.2.4 or newer (optional) * PEAR Package: HTML_QuickForm_Controller 1.0.4 or newer (optional) * PEAR Package: Image_Color 1.0.1 or newer (optional) * PEAR Package: HTML_Page2 0.5.0 or newer (optional) * PEAR Package: HTML_Template_IT 1.1 or newer (optional) * PEAR Package: HTML_Template_Sigma 1.1.2 or newer (optional) * PEAR Package: Log 1.8.7 or newer (optional) This is detailed enough to feed rpm with a nice list of Requires to satisfy. Anything else I forgot? regards, andreas From buildsys at fedoraproject.org Fri May 26 11:13:50 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 26 May 2006 07:13:50 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-05-26 Message-ID: <20060526111350.72DC6152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 15 cernlib-2005-21.fc5 conntrack-1.0-0.1.beta1.fc5 emacs-auctex-11.82-12.fc5 galago-daemon-0.5.0-3.fc5 libgalago-0.5.1-2.fc5 multitail-4.0.4-1.fc5 perl-Locale-Maketext-Simple-0.16-1.fc5 perl-Module-Info-0.30-3.fc5 perl-Module-ScanDeps-0.60-1.fc5 perl-Test-Prereq-1.031-1.fc5 pgp-tools-0.4.6-1.20060525svn.fc5 qt4-4.1.3-4.fc5.1 synaptic-0.57.2-5.0.fc5 texmaker-1.3-1.fc5 xemacs-sumo-20060510-2.fc5.1 Packages built and released for Fedora Extras 4: 12 cernlib-2005-21.fc4 conntrack-1.0-0.1.beta1.fc4 emacs-auctex-11.82-11.fc4 lyx-1.4.1-7.fc4.1 multitail-4.0.4-1.fc4 perl-Locale-Maketext-Simple-0.16-1.fc4 perl-Module-Info-0.30-3.fc4 perl-Module-ScanDeps-0.60-1.fc4 perl-Test-Prereq-1.031-1.fc4 pgp-tools-0.4.6-1.20060525svn.fc4 qt4-4.1.3-4.fc4 synaptic-0.57.2-5.0.fc4 Packages built and released for Fedora Extras 3: 1 cernlib-2005-21.fc3 Packages built and released for Fedora Extras development: 17 emacs-auctex-11.82-12.fc6 libgalago-0.5.1-3.fc6 milter-regex-1.6-5.fc6 paps-0.6.6-2.fc6 perl-Apache-Session-1.81-1.fc6 perl-DateTime-0.31-1.fc6 perl-IO-All-0.35-1.fc6 perl-Locale-Maketext-Simple-0.16-1.fc6 perl-Module-Info-0.30-3.fc6 perl-Module-ScanDeps-0.60-1.fc6 perl-Test-Prereq-1.031-1.fc6 pgp-tools-0.4.6-1.20060525svn.fc6 rsnapshot-1.2.9-2.fc6 synaptic-0.57.2-5.0.fc6 texmaker-1.3-1.fc6 w3m-el-1.4.4-4.fc6 xboard-4.2.7-13.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 26 11:30:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 26 May 2006 11:30:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-26 Message-ID: <20060526113036.12114.36794@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 From buildsys at fedoraproject.org Fri May 26 11:30:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 26 May 2006 11:30:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-26 Message-ID: <20060526113036.12126.6700@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: toth_bandi AT users.sourceforge.net package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Fri May 26 11:30:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 26 May 2006 11:30:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-26 Message-ID: <20060526113036.12124.65712@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Fri May 26 11:30:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 26 May 2006 11:30:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-26 Message-ID: <20060526113036.12121.70829@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.i386 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.ppc plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: apt-groupinstall - 0.5.15cnc7-6.fc4.i386 from fedora-extras-4-i386 unresolved deps: apt = 0:0.5.15cnc7-6.fc4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: apt-groupinstall - 0.5.15cnc7-6.fc4.ppc from fedora-extras-4-ppc unresolved deps: apt = 0:0.5.15cnc7-6.fc4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 From tibbs at math.uh.edu Fri May 26 13:42:13 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 26 May 2006 08:42:13 -0500 Subject: PHP packaging guidelines In-Reply-To: <1148626854.8185.40.camel@laurel.intra.city-fan.org> (Paul Howarth's message of "Fri, 26 May 2006 08:00:54 +0100") References: <1148626854.8185.40.camel@laurel.intra.city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Would Smarty (in Extras as php-Smarty) be an PEAR or PECL package? PH> It doesn't appear to me to be either, No idea; I have updated the wiki with this question, and will run the issue by Tom. - J< From jpo at lsd.di.uminho.pt Fri May 26 14:00:25 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 26 May 2006 15:00:25 +0100 Subject: Buildsys (i386) oddity + segmentation fault In-Reply-To: <1148591133.17615.84.camel@localhost.localdomain> References: <1148591133.17615.84.camel@localhost.localdomain> Message-ID: <447709F9.9040604@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > There seems to be something strange with the buildsys (i386/devel): I > made some innocent changes to xmms and requested a build, but the i386 > build seems to get repeatedly stuck in running/building state. > > It builds fine in the x86_64 and ppc builders in the buildsys and I > can't reproduce any weirdness locally on i386. > > I've killed/requeued the job already twice, but that hasn't helped: > http://buildsys.fedoraproject.org/build-status/job.psp?uid=9945 > > Could someone take a look? TIA! > And also at this segmentation fault? Job failed on arch i386 http://buildsys.fedoraproject.org/logs/fedora-development-extras/9911-multitail-4.0.4-1.fc6/ - ------------------------------------------------- ... cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions - -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 - -mtune=generic -fasynchronous-unwind-tables -D`uname` -O2 -Wall - -DVERSION=\"4.0.4\" -g -DCONFIG_FILE=\"//etc/multitail.conf\" -c -o scrollback.o scrollback.c make: *** [scrollback.o] Segmentation fault make: *** Waiting for unfinished jobs.... error: Bad exit status from /var/tmp/rpm-tmp.26412 (%build) 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEdwn5l0metZG9hRsRAuHnAJ41rgJYlwQEW4KMmgUM49/7eMUAxACgptsW RBT7E98LKy6gosR7m7/vyAc= =5uLG -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From jspaleta at gmail.com Fri May 26 14:04:44 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 26 May 2006 10:04:44 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148629854.4310.632.camel@sundaram.pnq.redhat.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> Message-ID: <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> On 5/26/06, Rahul Sundaram wrote: > Nothing stops you from modifying Fedora and including non-free software > for OEM systems. Trademark guidelines do not allow this system to be > called Fedora anymore though. There has been discussions in fedora- > marketing list about this The way I read http://fedora.redhat.com/About/legal/trademarks/guidelines/page5.html An OEM can market a system as Fedora + value addon under certain conditions. The original Fedora? code is intact and identifiable at the time of installation and on the media on which the code is delivered; a) The patches are provided independent of the original Fedora? code and are identifiable on the media on which the code is delivered; I read this to mean that when an OEM system is delivered/marketed what comes in Fedora and what the OEM is providing as a value addon are clearly delineated. So in the case of media, the OEM addons are on seperate media than the Fedora software. In the case of a pre-installed system, there must be a breakdown as to what is provided as a value add-on before the system is purchased, and it must be clear in the packaging that certain packages are OEM provided and not Fedora. b) The end user is given the discretion as to whether to install the patches; and I read this to mean that the OEM must provide a means by which to opt-out of any value-added software pre-install, so that the purchaser can choose a stock Fedora operating system install. I would go further and say this should be demanded as a no-cost option to the purchaser. c) Any marketing materials related to such a distribution make clear that the vendor is providing patches which, if installed by the user, will modify the Fedora? code from its original form This clarifies my interpretation of a). Pre-install OEM services are "okay" as long as the OEM makes it clear, before purchase, with specificity, as to what is being installed that either replaces Fedora components or adds new components. Is my interpretation of these conditions wrong? -jef"godaddy's VPS service which offers a highly modified FC2 system is an egregious example of OEM abuse of the trademark guidelines I have quoted."spaleta From dcbw at redhat.com Fri May 26 14:18:10 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 26 May 2006 10:18:10 -0400 Subject: Buildsys (i386) oddity + segmentation fault In-Reply-To: <447709F9.9040604@lsd.di.uminho.pt> References: <1148591133.17615.84.camel@localhost.localdomain> <447709F9.9040604@lsd.di.uminho.pt> Message-ID: <1148653090.2468.6.camel@localhost.localdomain> On Fri, 2006-05-26 at 15:00 +0100, Jose Pedro Oliveira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ville Skytt? wrote: > > There seems to be something strange with the buildsys (i386/devel): I > > made some innocent changes to xmms and requested a build, but the i386 > > build seems to get repeatedly stuck in running/building state. > > > > It builds fine in the x86_64 and ppc builders in the buildsys and I > > can't reproduce any weirdness locally on i386. > > > > I've killed/requeued the job already twice, but that hasn't helped: > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=9945 > > > > Could someone take a look? TIA! > > > > > And also at this segmentation fault? > > Job failed on arch i386 > http://buildsys.fedoraproject.org/logs/fedora-development-extras/9911-multitail-4.0.4-1.fc6/ > - ------------------------------------------------- > ... > cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > - -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 > - -mtune=generic -fasynchronous-unwind-tables -D`uname` -O2 -Wall > - -DVERSION=\"4.0.4\" -g -DCONFIG_FILE=\"//etc/multitail.conf\" -c -o > scrollback.o scrollback.c > make: *** [scrollback.o] Segmentation fault > make: *** Waiting for unfinished jobs.... > error: Bad exit status from /var/tmp/rpm-tmp.26412 (%build) I suppose it would be useful if we set coredump limits higher in the chroot, and if the buildsys detected the message "segmentation fault" and if the job failed, to keep the chroot around for further analysis. Right? :) Dan From Matt_Domsch at dell.com Fri May 26 14:21:43 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 26 May 2006 09:21:43 -0500 Subject: OT: Media format patents and commercial installations In-Reply-To: <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> Message-ID: <20060526142143.GA25131@lists.us.dell.com> On Fri, May 26, 2006 at 10:04:44AM -0400, Jeff Spaleta wrote: > This clarifies my interpretation of a). Pre-install OEM services are > "okay" as long as the OEM makes it clear, before purchase, with > specificity, as to what is being installed that either replaces Fedora > components or adds new components. This would be pretty onerous on OEMs. Keep all materials referring to their products that mention Fedora up-to-date with a list of (changing) add-ons? This week the OEM has to add a driver for a new sound card that isn't in the Fedora kernel yet, next week they need a fix in the net-snmp package that isn't upstream yet, week after that they sign a marketing deal to include some other non-Fedora-provided package in their bundle, ... IMHO, it's Fedora until it's sufficiently changed to not be Fedora. A few relatively minor package substitutions (for hardware features or bug fixes) or additions that don't cause the OS from being recognizable as Fedora, should be allowed. How to define that crisply legally I can't specify, IANAL. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Fri May 26 14:29:40 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 10:29:40 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: <20060526142143.GA25131@lists.us.dell.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> Message-ID: <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-26 at 09:21 -0500, Matt Domsch wrote: > This would be pretty onerous on OEMs. Keep all materials referring to > their products that mention Fedora up-to-date with a list of > (changing) add-ons? This week the OEM has to add a driver for a new > sound card that isn't in the Fedora kernel yet, next week they need a > fix in the net-snmp package that isn't upstream yet, week after that > they sign a marketing deal to include some other non-Fedora-provided > package in their bundle, ... > > IMHO, it's Fedora until it's sufficiently changed to not be Fedora. A > few relatively minor package substitutions (for hardware features or > bug fixes) or additions that don't cause the OS from being > recognizable as Fedora, should be allowed. How to define that crisply > legally I can't specify, IANAL. It is really not that hard to keep track of what is being modified. When all modifications are being done in RPM format, pretty easy to keep track. In the case of the OEM I used to work for, all these packages were applied in a %post during kickstarts. Updates to the post script were regulated and any changes would cause the need for updating various materials, such as a website that listed the changes. It gets _really_ hard to draw the line on when Fedora is changed "enough" to not be Fedora anymore. -- 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 j.w.r.degoede at hhs.nl Fri May 26 14:38:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 26 May 2006 16:38:36 +0200 Subject: Naming guidelines question Message-ID: <447712EC.1040907@hhs.nl> Hi, http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that %{name} should use upstreams advertised name and/or tarbal name. But it says nothing about capitalization. I thought that the rule was to always use all lowercase even if upstream does things differently unless there are arguments in favor of sticking to upstreams capitalization? Also on the same page it talks about release candidates versioning and it advices to use the final version this will become as version (agreed) and to use the following as release: 0.%{X}.%{alphatag} so we get: 0.1.rc1 0.2.rc1 0.3.rc2 Where as I have always used and have seen others use (mostly): 0.rc1.1 0.rc1.2 0.rc2.1 Which works fine 2. I understand that there are scenarios where this scheme will break, but in the scenarios where I've used it / seen it used it works fine, and I personally prefer this second scheme. Is it ok to use my own discretion here, both for my own packages and when reviewing? Or should things always be done as: 0.%{X}.%{alphatag} ? Regards, Hans From sundaram at fedoraproject.org Fri May 26 14:50:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 20:20:48 +0530 Subject: OT: Media format patents and commercial installations In-Reply-To: <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> Message-ID: <1148655049.4310.649.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 10:04 -0400, Jeff Spaleta wrote: > On 5/26/06, Rahul Sundaram wrote: > > Nothing stops you from modifying Fedora and including non-free software > > for OEM systems. Trademark guidelines do not allow this system to be > > called Fedora anymore though. There has been discussions in fedora- > > marketing list about this > > The way I read > http://fedora.redhat.com/About/legal/trademarks/guidelines/page5.html > > An OEM can market a system as Fedora + value addon under certain conditions. > > > The original Fedora? code is intact and identifiable at the time of > installation and on the media on which the code is delivered; > > a) > The patches are provided independent of the original Fedora? code and > are identifiable on the media on which the code is delivered; > > > I read this to mean that when an OEM system is delivered/marketed what > comes in Fedora and what the OEM is providing as a value addon are > clearly delineated. So in the case of media, the OEM addons are on > seperate media than the Fedora software. > In the case of a pre-installed system, there must be a breakdown as to > what is provided as a value add-on before the system is purchased, and > it must be clear in the packaging that certain packages are OEM > provided and not Fedora. > > > b) > The end user is given the discretion as to whether to install the patches; and > > > I read this to mean that the OEM must provide a means by which to > opt-out of any value-added software pre-install, so that the purchaser > can choose a stock Fedora operating system install. I would go > further and say this should be demanded as a no-cost option to the > purchaser. > > > c) Any marketing materials related to such a distribution make clear > that the vendor is providing patches which, if installed by the user, > will modify the Fedora? code from its original form > > > This clarifies my interpretation of a). Pre-install OEM services are > "okay" as long as the OEM makes it clear, before purchase, with > specificity, as to what is being installed that either replaces Fedora > components or adds new components. > > > Is my interpretation of these conditions wrong? Seems to be right. The requirement is a clear segregation of what is part of Fedora and what is not. Rahul From rdieter at math.unl.edu Fri May 26 15:13:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 26 May 2006 10:13:24 -0500 Subject: Naming guidelines question References: <447712EC.1040907@hhs.nl> Message-ID: Hans de Goede wrote: > http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that > %{name} should use upstreams advertised name and/or tarbal name. But it > says nothing about capitalization. I thought that the rule was to always > use all lowercase even if upstream does things differently unless there > are arguments in favor of sticking to upstreams capitalization? I don't think the NamingGuidelines cover capitalization, but I don't think it unreasonable to lowercase everything. > Also on the same page it talks about release candidates versioning and > it advices to use the final version this will become as version (agreed) > and to use the following as release: > 0.%{X}.%{alphatag} > > so we get: > 0.1.rc1 ... > Where as I have always used and have seen others use (mostly): > 0.rc1.1 ... > Is it ok > to use my own discretion here, both for my own packages and when > reviewing? Or should things always be done as: > 0.%{X}.%{alphatag} ? No, yes, respectively. -- Rex From sundaram at fedoraproject.org Fri May 26 15:19:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 20:49:55 +0530 Subject: Naming guidelines question In-Reply-To: References: <447712EC.1040907@hhs.nl> Message-ID: <1148656795.4310.651.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 10:13 -0500, Rex Dieter wrote: > Hans de Goede wrote: > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that > > %{name} should use upstreams advertised name and/or tarbal name. But it > > says nothing about capitalization. I thought that the rule was to always > > use all lowercase even if upstream does things differently unless there > > are arguments in favor of sticking to upstreams capitalization? > > I don't think the NamingGuidelines cover capitalization, but I don't think > it unreasonable to lowercase everything. It would be good to enforce lowercase in the guidelines I think. Rahul From tdiehl at rogueind.com Fri May 26 15:20:37 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 26 May 2006 11:20:37 -0400 (EDT) Subject: OT: Media format patents and commercial installations In-Reply-To: <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> Message-ID: Jesse Keating Wrote: > > On Fri, 2006-05-26 at 09:21 -0500, Matt Domsch wrote: > > This would be pretty onerous on OEMs. Keep all materials referring to > > their products that mention Fedora up-to-date with a list of > > (changing) add-ons? This week the OEM has to add a driver for a new > > sound card that isn't in the Fedora kernel yet, next week they need a > > fix in the net-snmp package that isn't upstream yet, week after that > > they sign a marketing deal to include some other non-Fedora-provided > > package in their bundle, ... > > > > IMHO, it's Fedora until it's sufficiently changed to not be Fedora. A > > few relatively minor package substitutions (for hardware features or > > bug fixes) or additions that don't cause the OS from being > > recognizable as Fedora, should be allowed. How to define that crisply > > legally I can't specify, IANAL. > > It is really not that hard to keep track of what is being modified. > When all modifications are being done in RPM format, pretty easy to keep > track. In the case of the OEM I used to work for, all these packages > were applied in a %post during kickstarts. Updates to the post script > were regulated and any changes would cause the need for updating various > materials, such as a website that listed the changes. I suspect that it is harder than you suggest. I bought hardware from $OEM you used to work for just before you left. When I realized that I did not have the same versions of the $OEM RPMS/SRPMS that came installed on the machines I requested them from $OEM. It took them 2 weeks to get the $OEM RPMS/SRPMS that came installed on the machine. The hardest part for me was convincing $OEM that $OEM RPMS/SRPMS were not on the FC3 cd's they sent with the machines. They did finally get them to me but I was told they needed to contact you after you were gone, to get the SRPMS. This is not a complaint, $OEM did the right thing and a year later I am very happy with said hardware. It is just an example of things that are not always as easy as they seem. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From tcallawa at redhat.com Fri May 26 15:25:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 10:25:06 -0500 Subject: Naming guidelines question In-Reply-To: <1148656795.4310.651.camel@sundaram.pnq.redhat.com> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> Message-ID: <1148657106.2593.40.camel@localhost.localdomain> On Fri, 2006-05-26 at 20:49 +0530, Rahul Sundaram wrote: > On Fri, 2006-05-26 at 10:13 -0500, Rex Dieter wrote: > > Hans de Goede wrote: > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that > > > %{name} should use upstreams advertised name and/or tarbal name. But it > > > says nothing about capitalization. I thought that the rule was to always > > > use all lowercase even if upstream does things differently unless there > > > are arguments in favor of sticking to upstreams capitalization? > > > > I don't think the NamingGuidelines cover capitalization, but I don't think > > it unreasonable to lowercase everything. > > It would be good to enforce lowercase in the guidelines I think. Packager's discretion. If upstream always uses a case sensitive name (ORBit), then it makes sense to uphold that. I'm not going to force anyone to go all lowercase, but if the packager wants to do it, then they can. ~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 jkeating at redhat.com Fri May 26 15:29:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 11:29:37 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-26 at 11:20 -0400, Tom Diehl wrote: > I suspect that it is harder than you suggest. I bought hardware from $OEM > you used to work for just before you left. When I realized that I did not > have the same versions of the $OEM RPMS/SRPMS that came installed on the > machines I requested them from $OEM. It took them 2 weeks to get the > $OEM RPMS/SRPMS that came installed on the machine. The hardest part for > me was convincing $OEM that $OEM RPMS/SRPMS were not on the FC3 cd's they > sent with the machines. They did finally get them to me but I was told they > needed to contact you after you were gone, to get the SRPMS. > > This is not a complaint, $OEM did the right thing and a year later I am very > happy with said hardware. It is just an example of things that are not always > as easy as they seem. The difficulty there was $OEM did not track things for crap. And the workspace I had got rm'd and thus went the SRPMs. It would not have been hard at all if there would have been policy about where to get those rpm/srpms from, a central repository, CVS tracking, etc... -- 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 sundaram at fedoraproject.org Fri May 26 15:41:40 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 21:11:40 +0530 Subject: Naming guidelines question In-Reply-To: <1148657106.2593.40.camel@localhost.localdomain> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> Message-ID: <1148658101.4310.655.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 10:25 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-05-26 at 20:49 +0530, Rahul Sundaram wrote: > > On Fri, 2006-05-26 at 10:13 -0500, Rex Dieter wrote: > > > Hans de Goede wrote: > > > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that > > > > %{name} should use upstreams advertised name and/or tarbal name. But it > > > > says nothing about capitalization. I thought that the rule was to always > > > > use all lowercase even if upstream does things differently unless there > > > > are arguments in favor of sticking to upstreams capitalization? > > > > > > I don't think the NamingGuidelines cover capitalization, but I don't think > > > it unreasonable to lowercase everything. > > > > It would be good to enforce lowercase in the guidelines I think. > > Packager's discretion. If upstream always uses a case sensitive name > (ORBit), then it makes sense to uphold that. I'm not going to force > anyone to go all lowercase, but if the packager wants to do it, then > they can. >From the user's perspective having to remember names is hard enough. Having to remember the case is just not worth it in my opinion. Moreover if package FOo is a completely different one from foo, we are adding up to even more confusion for end users. Rahul From jkeating at redhat.com Fri May 26 15:58:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 11:58:23 -0400 Subject: Naming guidelines question In-Reply-To: <1148658101.4310.655.camel@sundaram.pnq.redhat.com> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> Message-ID: <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-26 at 21:11 +0530, Rahul Sundaram wrote: > From the user's perspective having to remember names is hard enough. > Having to remember the case is just not worth it in my opinion. Moreover > if package FOo is a completely different one from foo, we are adding up > to even more confusion for end users. > This same argument applies when they see 'ORBit' is the name of the package in documentation and upstream and wherever. How confusing is it that the package is really named 'orbit' when using yum? Or querying via rpm? -- 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 sundaram at fedoraproject.org Fri May 26 16:00:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 21:30:08 +0530 Subject: Naming guidelines question In-Reply-To: <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148659209.4310.658.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 11:58 -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 21:11 +0530, Rahul Sundaram wrote: > > From the user's perspective having to remember names is hard enough. > > Having to remember the case is just not worth it in my opinion. Moreover > > if package FOo is a completely different one from foo, we are adding up > > to even more confusion for end users. > > > > This same argument applies when they see 'ORBit' is the name of the > package in documentation and upstream and wherever. How confusing is it > that the package is really named 'orbit' when using yum? Or querying > via rpm? > Do we expect users to notice the specific case of the upstream projects in webpages, documentation and type it correctly in yum everytime? Rahul From Matt_Domsch at dell.com Fri May 26 16:37:13 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 26 May 2006 11:37:13 -0500 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060526163713.GB32444@lists.us.dell.com> On Fri, May 26, 2006 at 11:29:37AM -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 11:20 -0400, Tom Diehl wrote: > > I suspect that it is harder than you suggest. > > The difficulty there was $OEM did not track things for crap. And the > workspace I had got rm'd and thus went the SRPMs. It would not have > been hard at all if there would have been policy about where to get > those rpm/srpms from, a central repository, CVS tracking, etc... In any company with >1 employee, the liklihood of one person not knowing what another person is doing is high. Intentionally tying actions of one person to the work of a (quite likely) functionally unrelated person is frowned upon. Legally requiring that the sales web site, paper (translated) docs, etc. change whenever a software developer fixes a bug is a sure way to ensure Fedora isn't as widely used as we would like. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Fri May 26 16:54:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 12:54:11 -0400 Subject: Naming guidelines question In-Reply-To: <1148659209.4310.658.camel@sundaram.pnq.redhat.com> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> Message-ID: <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-26 at 21:30 +0530, Rahul Sundaram wrote: > Do we expect users to notice the specific case of the upstream projects > in webpages, documentation and type it correctly in yum everytime? > select -> insert _if_ we were ever to make package guidelines be lowercase only, we would need to modify rpm, yum, etc... to accept caps and pass them as lower case. Case sensitivity exists for Websites, some (broken) email systems, and any number of other places. -- 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 jkeating at redhat.com Fri May 26 16:56:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 12:56:03 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: <20060526163713.GB32444@lists.us.dell.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> Message-ID: <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-05-26 at 11:37 -0500, Matt Domsch wrote: > > In any company with >1 employee, the liklihood of one person not > knowing what another person is doing is high. Intentionally tying > actions of one person to the work of a (quite likely) functionally > unrelated person is frowned upon. Legally requiring that the sales > web site, paper (translated) docs, etc. change whenever a software > developer fixes a bug is a sure way to ensure Fedora isn't as widely > used as we would like. So where do you draw the line on when 'changes' are changes enough to require a name change? Blurring the trademark line is a sure way to lose the trademark, and we do NOT want that to happen. -- 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 Liste at famillecollet.com Fri May 26 16:05:46 2006 From: Liste at famillecollet.com (Remi Collet) Date: Fri, 26 May 2006 18:05:46 +0200 Subject: PHP packaging guidelines In-Reply-To: References: Message-ID: <4477275A.4090902@FamilleCollet.com> > [17:19] * spot idly wonders how nice it would be to get a php (abi) define > in the core php package > > I have no idea how often the php-abi changes. But it would sure be nice to > depend on a specific abi version. > This already exists, i think. File main/php.h define PHP_API_VERSION This is provided by php (extract from php-5.1.4 spec file) > %define apiver 20041225 > Provides: php-api = %{apiver} Remi. From ville.skytta at iki.fi Fri May 26 17:42:18 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 26 May 2006 20:42:18 +0300 Subject: Naming guidelines question In-Reply-To: <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148665338.2735.29.camel@localhost.localdomain> On Fri, 2006-05-26 at 12:54 -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 21:30 +0530, Rahul Sundaram wrote: > > Do we expect users to notice the specific case of the upstream projects > > in webpages, documentation and type it correctly in yum everytime? > > > > select -> insert Is that really a goal worth pursuing? Do we expect users to browse into the upstream tarball distribution dirs and select the name of a tarball without the version etc and paste it to their command line (assuming that's what the above means)? Or select it from other documentation where the app/project name is very likely to be spelled in different case than in the tarball? And how about the rest of the guidelines which say that certain packages must be prefixed eg. by perl-*, python-*, or be named like $appname-$plugin? What about subpackages? > _if_ we were ever to make package guidelines be lowercase only, we > would need to modify rpm, yum, etc... to accept caps and pass them as > lower case. As long as the filesystems, rest of the tools in the OS, URLs etc in use are case sensitive, I'm afraid that would not work too well in practice. All lowercase would not solve anywhere near all problems either (see above for some examples), but it would be a much less intrusive way to avoid some of them than the above suggestions, and would be easy to communicate/document. From jkeating at redhat.com Fri May 26 17:55:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 May 2006 13:55:48 -0400 Subject: Naming guidelines question In-Reply-To: <1148665338.2735.29.camel@localhost.localdomain> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> <1148665338.2735.29.camel@localhost.localdomain> Message-ID: <1148666148.4781.6.camel@ender> On Fri, 2006-05-26 at 20:42 +0300, Ville Skytt? wrote: > Do we expect users to browse into the upstream tarball distribution dirs > and select the name of a tarball without the version etc and paste it to > their command line (assuming that's what the above means)? Or select it > from other documentation where the app/project name is very likely to be > spelled in different case than in the tarball? And how about the rest > of the guidelines which say that certain packages must be prefixed eg. > by perl-*, python-*, or be named like $appname-$plugin? What about > subpackages? Not just browsing tarballs, but documentation that says 'You need PackageFoo' installed, or "You need ORBit2 to be able to use this, please install it through your vendor". So the only way I would find acceptable a 'lowercase always' rule is if in each case we are breaking the upstream name we must have a Provides: UpstreamName . > > _if_ we were ever to make package guidelines be lowercase only, we > > would need to modify rpm, yum, etc... to accept caps and pass them as > > lower case. > > As long as the filesystems, rest of the tools in the OS, URLs etc in use > are case sensitive, I'm afraid that would not work too well in practice. > All lowercase would not solve anywhere near all problems either (see > above for some examples), but it would be a much less intrusive way to > avoid some of them than the above suggestions, and would be easy to > communicate/document. > yes, I know it is impraticle/impossible to force rpm / yum to do what I asked, however I was throwing it out there as a blocker to force. That said, using a Provides: RealName is a much easier way of ensuring that 'yum install ORBit2' will succeeed just as well as 'yum install orbit2'. This doesn't solve rpm -q ORBit2 issues, only rpm --whatprovides ORBit2 -- 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 andy at smile.org.ua Fri May 26 17:59:51 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 26 May 2006 20:59:51 +0300 Subject: How to build jack-audio-connection kit? Message-ID: <44774217.6010006@smile.org.ua> Hi! I've downloaded the jack-audio-connection-kit and try to build it. But it failed by following reason: /bin/sh: line 1: 26218 Segmentation fault gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -DREENTRANT -O3 -fomit-frame-pointer -ffast-math -funroll-loops -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -march=pentium2 -mcpu=pentium4 -O3 -ffast-math -funroll-loops -fprefetch-loop-arrays -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -DREENTRANT -O3 -fomit-frame-pointer -ffast-math -funroll-loops -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -march=pentium2 -mcpu=pentium4 -O3 -ffast-math -funroll-loops -fprefetch-loop-arrays -MT lsp.o -MD -MP -MF ".deps/lsp.Tpo" -c -o lsp.o lsp.c make[2]: *** [lsp.o] Error 1 However, x86_64 version was built OK. What does that error mean? What do I need to do? Thanks for any advise! -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From andy at smile.org.ua Fri May 26 18:07:46 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 26 May 2006 21:07:46 +0300 Subject: man-pages-XX package naming Message-ID: <447743F2.20200@smile.org.ua> Hi! I put to request the man-pages-uk package. But PackageGuidelines says in one side "... the name should match the upstream tarball...", another side "Addon Packages (locales) ... Examples: ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)" Main tarball called is the manpages-uk-utf8. How to naming package is preferable? P.S. Refer to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182415, please. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From pmatilai at laiskiainen.org Fri May 26 18:12:36 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 26 May 2006 21:12:36 +0300 Subject: Naming guidelines question In-Reply-To: <1148657106.2593.40.camel@localhost.localdomain> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> Message-ID: <1148667156.13737.12.camel@weasel.turre.laiskiainen.org> On Fri, 2006-05-26 at 10:25 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-05-26 at 20:49 +0530, Rahul Sundaram wrote: > > On Fri, 2006-05-26 at 10:13 -0500, Rex Dieter wrote: > > > Hans de Goede wrote: > > > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines says that > > > > %{name} should use upstreams advertised name and/or tarbal name. But it > > > > says nothing about capitalization. I thought that the rule was to always > > > > use all lowercase even if upstream does things differently unless there > > > > are arguments in favor of sticking to upstreams capitalization? > > > > > > I don't think the NamingGuidelines cover capitalization, but I don't think > > > it unreasonable to lowercase everything. > > > > It would be good to enforce lowercase in the guidelines I think. > > Packager's discretion. If upstream always uses a case sensitive name > (ORBit), then it makes sense to uphold that. I'm not going to force > anyone to go all lowercase, but if the packager wants to do it, then > they can. Well, that's the worst of both worlds: you can never know what a package is called because it might be CaSeSenSiTive or not. ORBit is a very good example - I have to do "grep -i orbit" for it *every single time* I have to look it up because I can never remember the exact case. If everything was forced to lowercase you wouldn't have to remember or try and guess. It seems to work fine for Debian but - Panu - From j.w.r.degoede at hhs.nl Fri May 26 18:22:40 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 26 May 2006 20:22:40 +0200 Subject: Naming guidelines question In-Reply-To: References: <447712EC.1040907@hhs.nl> Message-ID: <44774770.5090700@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: > >> Also on the same page it talks about release candidates versioning and >> it advices to use the final version this will become as version (agreed) >> and to use the following as release: >> 0.%{X}.%{alphatag} >> >> so we get: >> 0.1.rc1 > ... >> Where as I have always used and have seen others use (mostly): >> 0.rc1.1 > ... >> Is it ok >> to use my own discretion here, both for my own packages and when >> reviewing? Or should things always be done as: >> 0.%{X}.%{alphatag} ? > > No, yes, respectively. > Hmm, shortest answer ever, and that is no, yes because? Regards, Hans From ville.skytta at iki.fi Fri May 26 18:31:12 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 26 May 2006 21:31:12 +0300 Subject: Naming guidelines question In-Reply-To: <1148666148.4781.6.camel@ender> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> <1148665338.2735.29.camel@localhost.localdomain> <1148666148.4781.6.camel@ender> Message-ID: <1148668272.2735.53.camel@localhost.localdomain> On Fri, 2006-05-26 at 13:55 -0400, Jesse Keating wrote: > Not just browsing tarballs, but documentation that says 'You need > PackageFoo' installed, or "You need ORBit2 to be able to use this, > please install it through your vendor". So the only way I would find > acceptable a 'lowercase always' rule is if in each case we are breaking > the upstream name we must have a Provides: UpstreamName . No objections to adding useful Provides here. Deciding what is UpstreamName and what sources is a packager/reviewer expected/required to browse through when making that decision would be problematic though, but that problem already exists today for those packagers who don't yet believe that all-lowercase is the right thing to do ;) If the above is not acceptable now, how about turning things upside down and keeping the current guideline in effect, but adding to it that a fully versioned all lowercase Provides for the package's name must be present if the package's name itself is not all lowercase (ditto subpackages), and recommend that all dependencies would be spelled using the lowercase form? That would have some immediate benefits and would pave way for a possible more thorough future policy change. From j.w.r.degoede at hhs.nl Fri May 26 18:33:40 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 26 May 2006 20:33:40 +0200 Subject: Fedora logo license Message-ID: <44774A04.1090300@hhs.nl> Hi all, I'm currently in the progress of packaging tuxkart a racing game. One of the tracks on which you can race is an ordinary racing track with advertisement boards along the side. As shipped by upstream these advertisementboards contain advertisments for real product which clearly violates trademarks for those products. As such I'm in the progress of replacing these advertisement and some other troublish artwork. I've currently replace on the advertisement with the fedora logo, which seems appropriate for a Fedora package. However the license in fedora-logos is erm less then clearly worded and I wonder of my usage of the logo is ok. Notice that I've copy and pasted the logo, I cannot just use the image-file from Fedora-logo's because that is not in the .rgb format, which tuxkart needs. Thanks & Regards, Hans From Liste at FamilleCollet.com Fri May 26 17:54:01 2006 From: Liste at FamilleCollet.com (Remi Collet) Date: Fri, 26 May 2006 19:54:01 +0200 Subject: PHP packaging guidelines In-Reply-To: References: Message-ID: <447740B9.4020607@FamilleCollet.com> Andreas Thienemann a ?crit : > And about the naming conflicts: It's possible. The pear and pecl projects > are not sharing the same namespace. You're right. > Thus a conflict could occur, even > though I haven't looked into the matter if there are already conflicting > names. > I've look and don't see any conflict at this time. PECL packages could(should) probably drop the pecl (php-foo) as some extensions from core php has been dropped and put to pecl (mailparse, with php 4.2 for ex.) and other pecl extensions has been included in php main core tarball (pdo, with php-5.1 for ex.) Only one extension in extras with pecl : php-pecl-mailparse. Lot of extensions without pecl : php-mhash, php-mcrypt, php-tidy, php-dbase... So PEAR packages could keep the pear to avoid name conflict. Only one extension in extras : php-pear-DB But lot of extensions are in review. Remi. From seg at haxxed.com Fri May 26 22:03:57 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 26 May 2006 17:03:57 -0500 Subject: How to build jack-audio-connection kit? In-Reply-To: <44774217.6010006@smile.org.ua> References: <44774217.6010006@smile.org.ua> Message-ID: <1148681038.8271.13.camel@localhost> On Fri, 2006-05-26 at 20:59 +0300, Andy Shevchenko wrote: > Hi! > > I've downloaded the jack-audio-connection-kit and try to build it. > But it failed by following reason: > > /bin/sh: line 1: 26218 Segmentation fault gcc -DHAVE_CONFIG_H -I. > -I. -I.. -I.. -I../config -I.. -I.. -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -Wall -g -DREENTRANT -O3 -fomit-frame-pointer > -ffast-math -funroll-loops -I../config -I.. -I.. -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -Wall -g -march=pentium2 -mcpu=pentium4 -O3 > -ffast-math -funroll-loops -fprefetch-loop-arrays -I../config -I.. -I.. > -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -DREENTRANT -O3 > -fomit-frame-pointer -ffast-math -funroll-loops -I../config -I.. -I.. > -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -march=pentium2 > -mcpu=pentium4 -O3 -ffast-math -funroll-loops -fprefetch-loop-arrays -MT > lsp.o -MD -MP -MF ".deps/lsp.Tpo" -c -o lsp.o lsp.c > make[2]: *** [lsp.o] Error 1 > > > However, x86_64 version was built OK. http://buildsys.fedoraproject.org/logs/fedora-development-extras/9977-jack-audio-connection-kit-0.101.1-8.fc6/i386/build.log Hmmm, something is going horribly wrong with the opt flags. I should have looked at that closer in review. Its quite possible the mess of opt flags are hitting a gcc bug in devel. (It did compile for i386 in mock against FC5 just fine...) I suggest removing the --enable-optimize whether or not it fixes the problem, as it seems to completely ignore the CFLAGS its given. It should be using the standard opt flags anyway. And incidentally, I only just now spotted this: configure: WARNING: *** capabilities not enabled, stripped jackd has no effect Looks like you can take --enable-stripped-jackd flag off, it does nothing. I was wondering what that was for... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Fri May 26 22:26:59 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 17:26:59 -0500 Subject: Naming guidelines question In-Reply-To: <1148668272.2735.53.camel@localhost.localdomain> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> <1148665338.2735.29.camel@localhost.localdomain> <1148666148.4781.6.camel@ender> <1148668272.2735.53.camel@localhost.localdomain> Message-ID: <1148682419.2593.70.camel@localhost.localdomain> On Fri, 2006-05-26 at 21:31 +0300, Ville Skytt? wrote: > how about turning things upside down > and keeping the current guideline in effect, but adding to it that a > fully versioned all lowercase Provides for the package's name must be > present if the package's name itself is not all lowercase This part I agree with, I think it seems to make sense, and I'll take it to FESCO for consideration. This way, if people want to use the name (some upstream groups are VERY picky about what we call their code) they can do so, and fans of a unified lowerspace universe can find what they're searching for. I don't want to take the additional step to tell people that they should use the lowercase dependencies in other packages, because once we've got the Provides for every case, it doesn't matter. Additional overhead for minimal benefit, IMHO. ~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 tcallawa at redhat.com Fri May 26 22:31:18 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 17:31:18 -0500 Subject: man-pages-XX package naming In-Reply-To: <447743F2.20200@smile.org.ua> References: <447743F2.20200@smile.org.ua> Message-ID: <1148682678.2593.75.camel@localhost.localdomain> On Fri, 2006-05-26 at 21:07 +0300, Andy Shevchenko wrote: > Hi! > > I put to request the man-pages-uk package. But PackageGuidelines says in > one side "... the name should match the upstream tarball...", another > side "Addon Packages (locales) > ... > > Examples: > > ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)" > Main tarball called is the manpages-uk-utf8. > > How to naming package is preferable? Based on the precedent for man pages packages, the naming scheme in this particular case is: man-pages-$LOCALE Thus, your package should be: man-pages-uk The locales exception for Addon Packages applies here too, so if you have a locale with an underscore, you can use it here in the name. In your case, you do not (locale is uk). ~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 tcallawa at redhat.com Fri May 26 22:33:30 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 17:33:30 -0500 Subject: PHP packaging guidelines In-Reply-To: <447740B9.4020607@FamilleCollet.com> References: <447740B9.4020607@FamilleCollet.com> Message-ID: <1148682810.2593.78.camel@localhost.localdomain> On Fri, 2006-05-26 at 19:54 +0200, Remi Collet wrote: > Andreas Thienemann a ?crit : > > And about the naming conflicts: It's possible. The pear and pecl projects > > are not sharing the same namespace. > You're right. > > Thus a conflict could occur, even > > though I haven't looked into the matter if there are already conflicting > > names. > > > I've look and don't see any conflict at this time. > > PECL packages could(should) probably drop the pecl (php-foo) as some > extensions from core php has been dropped and put to pecl (mailparse, > with php 4.2 for ex.) and other pecl extensions has been included in > php main core tarball (pdo, with php-5.1 for ex.) We might need to add some php-pecl() provides in the main php package. > Only one extension in extras with pecl : php-pecl-mailparse. > Lot of extensions without pecl : php-mhash, php-mcrypt, php-tidy, > php-dbase... There's always a little pain in doing standards after packages are built. It's better that we do it now before its even worse. ~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 tcallawa at redhat.com Fri May 26 22:59:39 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 17:59:39 -0500 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148684379.2593.104.camel@localhost.localdomain> On Fri, 2006-05-26 at 12:56 -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 11:37 -0500, Matt Domsch wrote: > > > > In any company with >1 employee, the liklihood of one person not > > knowing what another person is doing is high. Intentionally tying > > actions of one person to the work of a (quite likely) functionally > > unrelated person is frowned upon. Legally requiring that the sales > > web site, paper (translated) docs, etc. change whenever a software > > developer fixes a bug is a sure way to ensure Fedora isn't as widely > > used as we would like. > > So where do you draw the line on when 'changes' are changes enough to > require a name change? Blurring the trademark line is a sure way to > lose the trademark, and we do NOT want that to happen. Remember, IANAL, I'm just a man with a SPARC (or twenty). This is a very tricky issue, Debian is going through the same pain. There isn't an easy answer here. When does Fedora stop being Fedora? Does a new kernel stop it? Does a new kernel module stop it? Does a different glibc stop it? Does a different compiler stop it (icc)? Does an addon package outside of Core or Extras stop it? Even with these hard questions, I have a proposal: IMHO, the most logical thing is to say that only board approved Fedora projects can generate new content that is permitted to use the Fedora trademark/logo (people redistributing/selling these generated Fedora works aren't generating new content, so it's still Fedora). (The board would retain the right to cancel projects (what happens if some formerly acceptable project decides to start making malicious Fedora viruses?) and no longer permit those former-projects the right to use the trademark/name.) But while this would cover things like Fedora Legacy and Fedora Unity, it wouldn't cover the Third Party/OEM case where they have a want or need to add/change things in a Fedora work. We want to encourage these vendors to use Fedora works, but at the same time, we don't want to have damage done with something calling itself Fedora. One idea might be an Third Party/OEM policy case, where Fedora Board approved Third Party/OEM works can use the name Fedora as long as it is accompanied with some additional text, and the modifications are documented: Fedora Core 5 $OEM_3RDPARTY_NAME Edition This gives the Fedora Community some oversight into how the trademark/logo is used, but increases the responsibility of the Fedora Board. Does the Third Party/OEM have to "recertify" with the Fedora Board if they want to change/update a package on the release? I'd argue that if they were merely updating it with newer Fedora content (aka, Fedora Core/Extras updates), then they do not, but any other changes (adding new packages not from existing Fedora Works, modifying Fedora Works beyond what was originally documented and approved) would require a new "trademark certification". I'd also like a page on the wiki that lists all approved Third Party/OEM efforts, where each item links to the documented modifications. Thoughts? ~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 Axel.Thimm at ATrpms.net Fri May 26 23:22:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 27 May 2006 01:22:45 +0200 Subject: Naming guidelines question In-Reply-To: <1148665338.2735.29.camel@localhost.localdomain> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> <1148665338.2735.29.camel@localhost.localdomain> Message-ID: <20060526232245.GF28481@neu.nirvana> On Fri, May 26, 2006 at 08:42:18PM +0300, Ville Skytt? wrote: > And how about the rest of the guidelines which say that certain > packages must be prefixed eg. by perl-*, python-*, or be named like > $appname-$plugin? What about subpackages? W/o backing up any side of the discussion: PIL (The python imaging library) is either packaged as PIL or python-imaging. Similar for PyGame, NumArray/Numerics and so on. I've often seen people comment on not having been able to identify the python bits they were after. What I really want to say is that upper/lowercase is the least of the problems, there are other mappings performed that can be more confusing or not to users/developers. The suggestion to use normalized Provides (lowercase) should be extended to more than capitalization. The normalized Provides should conform to some strict guideline and be the ones used for dependencies in other packages, and the core name of the package should be left to the packager with the recommendation to match upstream conventions closest. Packagers win due to a normalized dependency system and packages have a higher recognition value to users and upstream. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Fri May 26 23:38:46 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 27 May 2006 11:38:46 +1200 Subject: orphaned perl modules Message-ID: <44779186.1030406@knox.net.nz> Hey all, The below perl modules are currently orphaned, I am offering to take them on if there is no objection. perl-XML-Simple perl-Chart perl-Net-SCP perl-Net-SSH perl-XML-XQL (needed by InkScape) Regards Michael From stickster at gmail.com Fri May 26 23:54:58 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 26 May 2006 19:54:58 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148684379.2593.104.camel@localhost.localdomain> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> <1148684379.2593.104.camel@localhost.localdomain> Message-ID: <1148687698.5383.8.camel@localhost.localdomain> On Fri, 2006-05-26 at 17:59 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-05-26 at 12:56 -0400, Jesse Keating wrote: > > On Fri, 2006-05-26 at 11:37 -0500, Matt Domsch wrote: > > > > > > In any company with >1 employee, the liklihood of one person not > > > knowing what another person is doing is high. Intentionally tying > > > actions of one person to the work of a (quite likely) functionally > > > unrelated person is frowned upon. Legally requiring that the sales > > > web site, paper (translated) docs, etc. change whenever a software > > > developer fixes a bug is a sure way to ensure Fedora isn't as widely > > > used as we would like. > > > > So where do you draw the line on when 'changes' are changes enough to > > require a name change? Blurring the trademark line is a sure way to > > lose the trademark, and we do NOT want that to happen. > > Remember, IANAL, I'm just a man with a SPARC (or twenty). > > This is a very tricky issue, Debian is going through the same pain. > There isn't an easy answer here. > > When does Fedora stop being Fedora? Does a new kernel stop it? Does a > new kernel module stop it? Does a different glibc stop it? Does a > different compiler stop it (icc)? Does an addon package outside of Core > or Extras stop it? > > Even with these hard questions, I have a proposal: > > IMHO, the most logical thing is to say that only board approved Fedora > projects can generate new content that is permitted to use the Fedora > trademark/logo (people redistributing/selling these generated Fedora > works aren't generating new content, so it's still Fedora). > > (The board would retain the right to cancel projects (what happens if > some formerly acceptable project decides to start making malicious > Fedora viruses?) and no longer permit those former-projects the right to > use the trademark/name.) > > But while this would cover things like Fedora Legacy and Fedora Unity, > it wouldn't cover the Third Party/OEM case where they have a want or > need to add/change things in a Fedora work. We want to encourage these > vendors to use Fedora works, but at the same time, we don't want to have > damage done with something calling itself Fedora. > > One idea might be an Third Party/OEM policy case, where Fedora Board > approved Third Party/OEM works can use the name Fedora as long as it is > accompanied with some additional text, and the modifications are > documented: > > Fedora Core 5 $OEM_3RDPARTY_NAME Edition > > This gives the Fedora Community some oversight into how the > trademark/logo is used, but increases the responsibility of the Fedora > Board. > > Does the Third Party/OEM have to "recertify" with the Fedora Board if > they want to change/update a package on the release? I'd argue that if > they were merely updating it with newer Fedora content (aka, Fedora > Core/Extras updates), then they do not, but any other changes (adding > new packages not from existing Fedora Works, modifying Fedora Works > beyond what was originally documented and approved) would require a new > "trademark certification". > > I'd also like a page on the wiki that lists all approved Third Party/OEM > efforts, where each item links to the documented modifications. > > Thoughts? This is pretty good IMHO. Would it be worthwhile for one of the guidelines to require that the fedora-release package be installed/retained? This would dictate that at least the official repositories are referenced, which would mean that a user of any FCn $OEM edition would be able to install the full range of official Fedora software. This would avoid situations in which users complain about a "broken" $OEM edition which doesn't include expected software. Perhaps there are other "make or break" packages of this type. fedora-logos? kernel*? Just a thought... -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Sat May 27 00:04:19 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 26 May 2006 19:04:19 -0500 Subject: Trouble with the new Amarok version In-Reply-To: References: Message-ID: <1148688259.2593.110.camel@localhost.localdomain> On Sun, 2006-05-21 at 22:17 +0200, Aurelien Bompard wrote: > Kevin Kofler wrote: > > The question is though: how useful is the HelixPlayer engine in practice? > > It works pretty well here, reading ogg vorbis files. I don't know how to add > mp3 support to Helix, but there is still the possibility to get the xine > engine from /somewhere else/. Since without this additional repo you > wouldn't be able to read mp3 files anyway, I think it's not a problem. > > If you suggest I should add back gst10 on all archs, I'd rather follow the > dev's opinion on the maturity of this engine, unless I have no other choice > (as on x86_64). Having no streaming support without warning with gst10 > surprised me a lot, and will probably be the source of many bug reports. Reviving this thread since people are discussing it on irc: Maybe there is value in having an amarok-gst10 and a amarok-helix? gst10 seems to be the only way anyone will get mp3 support without a recompile. ~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 jpo at lsd.di.uminho.pt Sat May 27 00:19:54 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 27 May 2006 01:19:54 +0100 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <44779186.1030406@knox.net.nz> References: <44779186.1030406@knox.net.nz> Message-ID: <44779B2A.8030908@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael J Knox wrote: > Hey all, > > The below perl modules are currently orphaned, I am offering to take > them on if there is no objection. > > perl-XML-Simple perl-XML-Simple is not orphan. It is a Fedora Core 5 package. 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEd5sql0metZG9hRsRAin1AJ4lJGOZ5XHsKZgoNEdVWAj9hcWpsACfVgcO +3f5uFxRO+xcEAD6XmzNq+8= =4rrg -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From lists at forevermore.net Sat May 27 00:27:25 2006 From: lists at forevermore.net (Chris Petersen) Date: Fri, 26 May 2006 17:27:25 -0700 Subject: Trouble with the new Amarok version In-Reply-To: <1148688259.2593.110.camel@localhost.localdomain> References: <1148688259.2593.110.camel@localhost.localdomain> Message-ID: <44779CED.1080001@forevermore.net> > Maybe there is value in having an amarok-gst10 and a amarok-helix? gst10 > seems to be the only way anyone will get mp3 support without a > recompile. Not sure if this helps or not, but I've been getting little amarok notifications from helix about how it can't play mp3's... as it continues to play the mp3 files in question. Maybe amarok is falling back to xine-lib or gstreamer and not telling me, though. -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From michael at knox.net.nz Sat May 27 00:58:07 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 27 May 2006 12:58:07 +1200 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <44779B2A.8030908@lsd.di.uminho.pt> References: <44779186.1030406@knox.net.nz> <44779B2A.8030908@lsd.di.uminho.pt> Message-ID: <4477A41F.3050709@knox.net.nz> Jose Pedro Oliveira wrote: > Michael J Knox wrote: >> Hey all, >> >> The below perl modules are currently orphaned, I am offering to take >> them on if there is no objection. >> >> perl-XML-Simple > > perl-XML-Simple is not orphan. It is a Fedora Core 5 package. Its list under "Potentially unmaintained packages in Fedora Extras". I saw the note about it being a FC5 package, but does that mean its not required in FC4 or FC3 ? if so, I will remove it from the OrphanedPackages page. Michael From jpo at lsd.di.uminho.pt Sat May 27 01:14:25 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 27 May 2006 02:14:25 +0100 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <4477A41F.3050709@knox.net.nz> References: <44779186.1030406@knox.net.nz> <44779B2A.8030908@lsd.di.uminho.pt> <4477A41F.3050709@knox.net.nz> Message-ID: <4477A7F1.2080000@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael J Knox wrote: > Jose Pedro Oliveira wrote: >> Michael J Knox wrote: >>> Hey all, >>> >>> The below perl modules are currently orphaned, I am offering to take >>> them on if there is no objection. >>> >>> perl-XML-Simple >> >> perl-XML-Simple is not orphan. It is a Fedora Core 5 package. > > Its list under "Potentially unmaintained packages in Fedora Extras". I > saw the note about it being a FC5 package, but does that mean its not > required in FC4 or FC3 ? if so, I will remove it from the > OrphanedPackages page. I don't know who orphaned this package. I'm supposed to be the maintainer for FC-3, and FC4. 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEd6fxl0metZG9hRsRAk8ZAKDwm4YlBTfNqK9JpwhdQ4ttgrxwEwCgmaGi z71kqoXQaF+/j3ENbwV7pHg= =4/en -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Sat May 27 01:15:36 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 27 May 2006 13:15:36 +1200 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <4477A7F1.2080000@lsd.di.uminho.pt> References: <44779186.1030406@knox.net.nz> <44779B2A.8030908@lsd.di.uminho.pt> <4477A41F.3050709@knox.net.nz> <4477A7F1.2080000@lsd.di.uminho.pt> Message-ID: <4477A838.3020804@knox.net.nz> Jose Pedro Oliveira wrote: > I don't know who orphaned this package. I'm supposed to be the > maintainer for FC-3, and FC4. Ok, I will remove it from the wiki page Thanks! Michael From jpo at lsd.di.uminho.pt Sat May 27 01:22:35 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 27 May 2006 02:22:35 +0100 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <4477A838.3020804@knox.net.nz> References: <44779186.1030406@knox.net.nz> <44779B2A.8030908@lsd.di.uminho.pt> <4477A41F.3050709@knox.net.nz> <4477A7F1.2080000@lsd.di.uminho.pt> <4477A838.3020804@knox.net.nz> Message-ID: <4477A9DB.2030401@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael J Knox wrote: > Jose Pedro Oliveira wrote: >> I don't know who orphaned this package. I'm supposed to be the >> maintainer for FC-3, and FC4. > > Ok, I will remove it from the wiki page I also corrected the owners file. Thanks, 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEd6nbl0metZG9hRsRAvW5AJ4iVPCGLokQbqUASMDyvVq6DtjE4QCdHiHX MgObE8ABTBoaQOO++gK8Y08= =aR7z -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From dtimms at bigpond.net.au Sat May 27 01:45:52 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 27 May 2006 11:45:52 +1000 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148687698.5383.8.camel@localhost.localdomain> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> <1148684379.2593.104.camel@localhost.localdomain> <1148687698.5383.8.camel@localhost.localdomain> Message-ID: <4477AF50.6020205@bigpond.net.au> Paul W. Frields wrote: > On Fri, 2006-05-26 at 17:59 -0500, Tom 'spot' Callaway wrote: >> On Fri, 2006-05-26 at 12:56 -0400, Jesse Keating wrote: >>> On Fri, 2006-05-26 at 11:37 -0500, Matt Domsch wrote: >>>> In any company with >1 employee, the liklihood of one person not ... >> Does the Third Party/OEM have to "recertify" with the Fedora Board if >> they want to change/update a package on the release? I'd argue that if >> they were merely updating it with newer Fedora content (aka, Fedora >> Core/Extras updates), then they do not, but any other changes (adding >> new packages not from existing Fedora Works, modifying Fedora Works >> beyond what was originally documented and approved) would require a new >> "trademark certification". >> >> I'd also like a page on the wiki that lists all approved Third Party/OEM >> efforts, where each item links to the documented modifications. >> >> Thoughts? > > This is pretty good IMHO. Would it be worthwhile for one of the > guidelines to require that the fedora-release package be > installed/retained? This would dictate that at least the official > repositories are referenced, which would mean that a user of any FCn > $OEM edition would be able to install the full range of official Fedora > software. This would avoid situations in which users complain about a > "broken" $OEM edition which doesn't include expected software. > > Perhaps there are other "make or break" packages of this type. > fedora-logos? kernel*? Just a thought... I reckon this is a good idea. It would mean that an OEM system installed elsewhere can at least have easy (if not automated) Fedora security updates installed (as long as it has a net connection). In terms of naming/branding, another possibility would be "built upon", where an OEM uses their own branding but refers to the underlying work/branding of Fedora. Something like "Company Media Experts releases the Presentation Publisher tm 4 system built upon Fedora tm" ? DaveT. From dtimms at bigpond.net.au Sat May 27 02:21:22 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 27 May 2006 12:21:22 +1000 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148655049.4310.649.camel@sundaram.pnq.redhat.com> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <1148655049.4310.649.camel@sundaram.pnq.redhat.com> Message-ID: <4477B7A2.5090607@bigpond.net.au> Rahul Sundaram wrote: > On Fri, 2006-05-26 at 10:04 -0400, Jeff Spaleta wrote: >> On 5/26/06, Rahul Sundaram wrote: >>> Nothing stops you from modifying Fedora and including non-free software >>> for OEM systems. Trademark guidelines do not allow this system to be >>> called Fedora anymore though. There has been discussions in fedora- >>> marketing list about this Thanks, I'll take a look at the archives. >> The way I read >> http://fedora.redhat.com/About/legal/trademarks/guidelines/page5.html >> >> An OEM can market a system as Fedora + value addon under certain conditions. >> >> >> The original Fedora? code is intact and identifiable at the time of >> installation and on the media on which the code is delivered; >> >> a) >> The patches are provided independent of the original Fedora? code and >> are identifiable on the media on which the code is delivered; >> >> >> I read this to mean that when an OEM system is delivered/marketed what >> comes in Fedora and what the OEM is providing as a value addon are >> clearly delineated. So in the case of media, the OEM addons are on >> seperate media than the Fedora software. Would an OEM need to supply the Fedora DVD and their addons install media even when the hardware has no CD/DVD drive ? Would a required separate network install server (ie ks over ftp) suffice ? >> In the case of a pre-installed system, there must be a breakdown as to >> what is provided as a value add-on before the system is purchased, and I can see how this helps for example: third party patent encumbered or buggy packages because it is made clear that Fedora did not make them. >> it must be clear in the packaging that certain packages are OEM >> provided and not Fedora. So, is this so the end user can know where they need to go for support for their box ? >> >> b) >> The end user is given the discretion as to whether to install the patches; and >> >> >> I read this to mean that the OEM must provide a means by which to >> opt-out of any value-added software pre-install, so that the purchaser >> can choose a stock Fedora operating system install. I would go >> further and say this should be demanded as a no-cost option to the >> purchaser. Interesting angle. Without the addons/packages the box is a pure Fedora box. It can no longer do what the value-add provided. One advantage I can see is if an OEM where making a very price competitive box with addons, the end user could buy the box just to get the cheap hardware pre-installed with Fedora, and not require the effort to build/install/test a basic Fedora system. Is this why this guideline was framed ? Or is it so that the end user could revert to a base Fedora system so that the box becomes "supportable" (eg if the box was having problems) ? >> ... >> Is my interpretation of these conditions wrong? > > Seems to be right. The requirement is a clear segregation of what is > part of Fedora and what is not. It also feels like a shortcut for competitors to an oem to get to the same stage of development. Is the segregation in generalities eg: OEM box has media-player-central-1.0.1.rpm and media-codecs-45.3 ? Or does this disclosure need to cover all config files that are changed from a default install eg. dns / ip / smb / ftp / desktop layout / menus ? {like rpm -Va} Also, thanks to all who have taken part in this discussion, it has been really informative :) DaveT From dtimms at bigpond.net.au Sat May 27 02:38:06 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 27 May 2006 12:38:06 +1000 Subject: OT: Media format patents and commercial installations In-Reply-To: <20060525224103.GB2736@neu.nirvana> References: <4476290F.8050207@bigpond.net.au> <20060525224103.GB2736@neu.nirvana> Message-ID: <4477BB8E.9010309@bigpond.net.au> Axel Thimm wrote: > On Fri, May 26, 2006 at 08:00:47AM +1000, David Timms wrote: >> I am interested in building FC5 based installations for commercial sale. >> One of the requirements is the capability to play back media of as many >> types as possible (eg using mplayer/xine/vlc). While Fedora core/extras >> can't contain patent encumbered nor non-open source software, in general >> terms is there anything to stop me selling such a box ? >> >> eg. for mpeg2 / 4 playback I could use the various libraries available. >> Does anyone know if other parties have been able to negotiate with the >> patent holders (I guess MPEG) individual licenses for linux machines ? > > Yes, I had been in contact with MPEGLA in a previous contract > assignment. > >> Is it hideously expensive ? > > The costs are minimal. The pain is in the burocracy. > Callum wrote: >> Linspire has done it. For their for-profit distribution. And yes, its >> hideously expensive. Perhaps the license for a OS product is looked at differently from small runs (5-10) of OEM boxes (what I was anticipating). Axel, is the costs protected under contract ? If not are you willing to state ball park figures eg per machine ? Was it like $1/2/5/10/20/50/100 per machine ? Thanks, DaveT From rc040203 at freenet.de Sat May 27 04:50:07 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 27 May 2006 06:50:07 +0200 Subject: Upstream changing Licenses [Was: perl-Locale-Maketext-Simple.spec] In-Reply-To: <200605250049.k4P0ngQg006850@cvs-int.fedora.redhat.com> References: <200605250049.k4P0ngQg006850@cvs-int.fedora.redhat.com> Message-ID: <1148705407.27733.33.camel@mccallum.corsepiu.local> On Wed, 2006-05-24 at 17:49 -0700, Steven Pritchard wrote: > Author: steve > > Update of /cvs/extras/rpms/perl-Locale-Maketext-Simple/FC-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6828 > > Modified Files: > .cvsignore perl-Locale-Maketext-Simple.spec sources > Log Message: > Update to 0.16. > License has changed to MIT. Steve, do you think upstream is legitimated to do so? I am facing the same situation with perl-Locale-Maketext-Lexicon (from the same author). There, upstream has changed the license from GPL/Artistic to MIT. IMO, by having done so, upstream probably has violated the law, because, in general, they cannot change the license a package unless they own the copyright of all parts a package consists of. Locale::Maketext::Simple only lists one author, with Locale::Maketext::Lexicon, the situation seems unclear: http://search.cpan.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.61/AUTHORS lists 20-25 contributors, while the source code only lists one individual (the CPAN maintainer). I am not certain on how to handle the situation. To be on the safe side, I considering to regard my perl-Locale-Maketext-Lexicon rpm as derivative work of the original work and consider to ship it under the GPL only. The fundamental questions would be: * Who owns contributions to code in CPAN having been released under GPL/Artistic before? IMO: If the "contribution is copyrightable", the contributor. He is contributing under the licenses the original author had granted. The original author is not legitimated to change the license on such contributions without explicit permission. * Is the maintainer of CPAN modules legitimated to change a license from GPL/Artistic to MIT? Here, I am not sure about the implications of the Artistic license. Opinions? What to do? Ralf From sundaram at fedoraproject.org Sat May 27 07:10:50 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 12:40:50 +0530 Subject: Fedora logo license In-Reply-To: <44774A04.1090300@hhs.nl> References: <44774A04.1090300@hhs.nl> Message-ID: <1148713850.4310.700.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 20:33 +0200, Hans de Goede wrote: > Hi all, > > I'm currently in the progress of packaging tuxkart a racing game. One of > the tracks on which you can race is an ordinary racing track with > advertisement boards along the side. > > As shipped by upstream these advertisementboards contain advertisments > for real product which clearly violates trademarks for those products. > > As such I'm in the progress of replacing these advertisement and some > other troublish artwork. I've currently replace on the advertisement > with the fedora logo, which seems appropriate for a Fedora package. > However the license in fedora-logos is erm less then clearly worded and > I wonder of my usage of the logo is ok. Notice that I've copy and pasted > the logo, I cannot just use the image-file from Fedora-logo's because > that is not in the .rgb format, which tuxkart needs. > > Thanks & Regards, > > Hans The logo guidelines is available from http://fedoraproject.org/wiki/Logo. http://www.redhat.com/mailman/listinfo/fedora-art-list Rahul From sundaram at fedoraproject.org Sat May 27 07:17:05 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 12:47:05 +0530 Subject: Naming guidelines question In-Reply-To: <1148666148.4781.6.camel@ender> References: <447712EC.1040907@hhs.nl> <1148656795.4310.651.camel@sundaram.pnq.redhat.com> <1148657106.2593.40.camel@localhost.localdomain> <1148658101.4310.655.camel@sundaram.pnq.redhat.com> <1148659103.9879.13.camel@dhcp83-49.boston.redhat.com> <1148659209.4310.658.camel@sundaram.pnq.redhat.com> <1148662451.9879.16.camel@dhcp83-49.boston.redhat.com> <1148665338.2735.29.camel@localhost.localdomain> <1148666148.4781.6.camel@ender> Message-ID: <1148714225.4310.703.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 13:55 -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 20:42 +0300, Ville Skytt? wrote: > > Do we expect users to browse into the upstream tarball distribution dirs > > and select the name of a tarball without the version etc and paste it to > > their command line (assuming that's what the above means)? Or select it > > from other documentation where the app/project name is very likely to be > > spelled in different case than in the tarball? And how about the rest > > of the guidelines which say that certain packages must be prefixed eg. > > by perl-*, python-*, or be named like $appname-$plugin? What about > > subpackages? > > Not just browsing tarballs, but documentation that says 'You need > PackageFoo' installed, or "You need ORBit2 to be able to use this, > please install it through your vendor". So the only way I would find > acceptable a 'lowercase always' rule is if in each case we are breaking > the upstream name we must have a Provides: UpstreamName . This argument applies everytime we change the name from the upstream provided one. We do that in many cases already. I dont see how this applies only to case sensitivity but not to other renames. Rahul From sundaram at fedoraproject.org Sat May 27 07:39:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 13:09:12 +0530 Subject: OT: Media format patents and commercial installations In-Reply-To: <4477B7A2.5090607@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <1148655049.4310.649.camel@sundaram.pnq.redhat.com> <4477B7A2.5090607@bigpond.net.au> Message-ID: <1148715552.4310.704.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 12:21 +1000, David Timms wrote: > Rahul Sundaram wrote: > > On Fri, 2006-05-26 at 10:04 -0400, Jeff Spaleta wrote: > >> On 5/26/06, Rahul Sundaram wrote: > >>> Nothing stops you from modifying Fedora and including non-free software > >>> for OEM systems. Trademark guidelines do not allow this system to be > >>> called Fedora anymore though. There has been discussions in fedora- > >>> marketing list about this > Thanks, I'll take a look at the archives. > > >> The way I read > >> http://fedora.redhat.com/About/legal/trademarks/guidelines/page5.html > >> > >> An OEM can market a system as Fedora + value addon under certain conditions. > >> > >> > >> The original Fedora? code is intact and identifiable at the time of > >> installation and on the media on which the code is delivered; > >> > >> a) > >> The patches are provided independent of the original Fedora? code and > >> are identifiable on the media on which the code is delivered; > >> > >> > >> I read this to mean that when an OEM system is delivered/marketed what > >> comes in Fedora and what the OEM is providing as a value addon are > >> clearly delineated. So in the case of media, the OEM addons are on > >> seperate media than the Fedora software. > Would an OEM need to supply the Fedora DVD and their addons install > media even when the hardware has no CD/DVD drive ? Would a required > separate network install server (ie ks over ftp) suffice ? [snip] I think this discussion belongs to fedora-marketing list. Rahul From bugs.michael at gmx.net Sat May 27 08:14:49 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 27 May 2006 10:14:49 +0200 Subject: orphaned perl modules - perl-XML-Simple In-Reply-To: <44779B2A.8030908@lsd.di.uminho.pt> References: <44779186.1030406@knox.net.nz> <44779B2A.8030908@lsd.di.uminho.pt> Message-ID: <20060527101449.d4c79c03.bugs.michael@gmx.net> On Sat, 27 May 2006 01:19:54 +0100, Jose Pedro Oliveira wrote: > Michael J Knox wrote: > > Hey all, > > > > The below perl modules are currently orphaned, I am offering to take > > them on if there is no objection. > > > > perl-XML-Simple > > perl-XML-Simple is not orphan. It is a Fedora Core 5 package. http://fedoraproject.org/wiki/Extras/OrphanedPackages?action=diff&rev2=241&rev1=240 And owners.list: revision 1.773 date: 2006/03/26 10:40:08; author: scop; state: Exp; lines: +13 -13 Orphan perl-Chart, perl-Convert-BinHex, perl-IO-stringy, perl-MailTools, perl-MIME-tools, perl-Net-Netmask, perl-XML-DOM, perl-XML-RegExp, perl-XML-Simple, perl-XML-XPath, uqm, uqm-content revision 1.772 Fedora Extras|perl-XML-Simple|Easy API to maintain XML in Perl|ville.skytta at iki.fi|extras-qa at fedoraproject.org|fedora-perl-devel-list at redhat.com From andy at smile.org.ua Sat May 27 08:32:00 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 27 May 2006 11:32:00 +0300 Subject: How to build jack-audio-connection kit? In-Reply-To: <1148681038.8271.13.camel@localhost> References: <44774217.6010006@smile.org.ua> <1148681038.8271.13.camel@localhost> Message-ID: <44780E80.8050505@smile.org.ua> Callum Lerwick ?????: > Hmmm, something is going horribly wrong with the opt flags. > I suggest removing the --enable-optimize whether or not it fixes the > problem, as it seems to completely ignore the CFLAGS its given. It > should be using the standard opt flags anyway. I've removed the all optimization related switches from %configure. The building process seems fine, but in tail I've got next error on all archs. Where am I wrong? http://buildsys.fedoraproject.org/logs/fedora-development-extras/9997-jack-audio-connection-kit-0.101.1-9.fc6/i386/root.log "ensuring dir /var/lib/mock/fedora-development-i386-core-80a9be4f27b45522c064f87187efed63fd34d645/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-80a9be4f27b45522c064f87187efed63fd34d645/root groupinstall build file:///pub/fedora/linux/core/development/i386/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/core/development/i386/repodata/repomd.xml' Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try." -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From Axel.Thimm at ATrpms.net Sat May 27 08:59:32 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 27 May 2006 10:59:32 +0200 Subject: OT: Media format patents and commercial installations In-Reply-To: <4477BB8E.9010309@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> <20060525224103.GB2736@neu.nirvana> <4477BB8E.9010309@bigpond.net.au> Message-ID: <20060527085932.GA5720@neu.nirvana> On Sat, May 27, 2006 at 12:38:06PM +1000, David Timms wrote: > Axel Thimm wrote: > >On Fri, May 26, 2006 at 08:00:47AM +1000, David Timms wrote: > >>I am interested in building FC5 based installations for commercial sale. > >>One of the requirements is the capability to play back media of as many > >>types as possible (eg using mplayer/xine/vlc). While Fedora core/extras > >>can't contain patent encumbered nor non-open source software, in general > >>terms is there anything to stop me selling such a box ? > >> > >>eg. for mpeg2 / 4 playback I could use the various libraries available. > >>Does anyone know if other parties have been able to negotiate with the > >>patent holders (I guess MPEG) individual licenses for linux machines ? > > > >Yes, I had been in contact with MPEGLA in a previous contract > >assignment. > > > >>Is it hideously expensive ? > > > >The costs are minimal. The pain is in the burocracy. > > > Callum wrote: > >> Linspire has done it. For their for-profit distribution. And yes, its > >> hideously expensive. > > Perhaps the license for a OS product is looked at differently from small > runs (5-10) of OEM boxes (what I was anticipating). > > Axel, is the costs protected under contract ? If not are you willing to > state ball park figures eg per machine ? Was it like $1/2/5/10/20/50/100 > per machine ? No, no NDA, the standard prices are publicly available. The MPEG-2 royalties are 2.5$/unit for decoding, same for encoding. When the prices were a bit higher there was a package price for both, maybe there still is. But it sounds like you only need the decoding license anyway. You'll probably need mp3/mpeg4 and sorensen codecs, too (mpeg4 decoding is free of charge up to the first 50000 units), so this may add up, but you get the idea of licensing costs. Note that if you use hardware like capture cards they very often have a bundled software license for some mpeg products. Many OEMs don't know that and pay double. I was consulting a major capture card manufaturer in terms of Linux until lately, unfortunately many OEMs are still (legally) scared of Linux, they associate open source with patent infringment and teaching them the opposite turns to be very difficult. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sat May 27 09:35:22 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 27 May 2006 11:35:22 +0200 Subject: Fedora logo license In-Reply-To: <1148713850.4310.700.camel@sundaram.pnq.redhat.com> References: <44774A04.1090300@hhs.nl> <1148713850.4310.700.camel@sundaram.pnq.redhat.com> Message-ID: <44781D5A.9060305@hhs.nl> Rahul Sundaram wrote: > On Fri, 2006-05-26 at 20:33 +0200, Hans de Goede wrote: >> Hi all, >> >> I'm currently in the progress of packaging tuxkart a racing game. One of >> the tracks on which you can race is an ordinary racing track with >> advertisement boards along the side. >> >> As shipped by upstream these advertisementboards contain advertisments >> for real product which clearly violates trademarks for those products. >> >> As such I'm in the progress of replacing these advertisement and some >> other troublish artwork. I've currently replace on the advertisement >> with the fedora logo, which seems appropriate for a Fedora package. >> However the license in fedora-logos is erm less then clearly worded and >> I wonder of my usage of the logo is ok. Notice that I've copy and pasted >> the logo, I cannot just use the image-file from Fedora-logo's because >> that is not in the .rgb format, which tuxkart needs. >> >> Thanks & Regards, >> >> Hans > > > The logo guidelines is available from > http://fedoraproject.org/wiki/Logo. > That isn't really helpfull, all I can find there is a pdf which tells me not to change colors etc, iow to use the logo unmodified, which I'm doing. What I want to know if I may use to logo in and distribute it as a part of a Fedora Extras package. Regards, Hans > http://www.redhat.com/mailman/listinfo/fedora-art-list > > Rahul > From sundaram at fedoraproject.org Sat May 27 09:36:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 15:06:11 +0530 Subject: Fedora logo license In-Reply-To: <44781D5A.9060305@hhs.nl> References: <44774A04.1090300@hhs.nl> <1148713850.4310.700.camel@sundaram.pnq.redhat.com> <44781D5A.9060305@hhs.nl> Message-ID: <1148722571.4310.718.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 11:35 +0200, Hans de Goede wrote: > > Rahul Sundaram wrote: > > On Fri, 2006-05-26 at 20:33 +0200, Hans de Goede wrote: > >> Hi all, > >> > >> I'm currently in the progress of packaging tuxkart a racing game. One of > >> the tracks on which you can race is an ordinary racing track with > >> advertisement boards along the side. > >> > >> As shipped by upstream these advertisementboards contain advertisments > >> for real product which clearly violates trademarks for those products. > >> > >> As such I'm in the progress of replacing these advertisement and some > >> other troublish artwork. I've currently replace on the advertisement > >> with the fedora logo, which seems appropriate for a Fedora package. > >> However the license in fedora-logos is erm less then clearly worded and > >> I wonder of my usage of the logo is ok. Notice that I've copy and pasted > >> the logo, I cannot just use the image-file from Fedora-logo's because > >> that is not in the .rgb format, which tuxkart needs. > >> > >> Thanks & Regards, > >> > >> Hans > > > > > > The logo guidelines is available from > > http://fedoraproject.org/wiki/Logo. > > > > That isn't really helpfull, all I can find there is a pdf which tells me > not to change colors etc, iow to use the logo unmodified, which I'm > doing. What I want to know if I may use to logo in and distribute it as > a part of a Fedora Extras package. Why isnt it helpful? As long as you dont violate the guidelines you are free to include it. Rahul From Axel.Thimm at ATrpms.net Sat May 27 09:55:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 27 May 2006 11:55:11 +0200 Subject: Fedora logo license In-Reply-To: <1148722571.4310.718.camel@sundaram.pnq.redhat.com> References: <44774A04.1090300@hhs.nl> <1148713850.4310.700.camel@sundaram.pnq.redhat.com> <44781D5A.9060305@hhs.nl> <1148722571.4310.718.camel@sundaram.pnq.redhat.com> Message-ID: <20060527095511.GE5720@neu.nirvana> On Sat, May 27, 2006 at 03:06:11PM +0530, Rahul Sundaram wrote: > On Sat, 2006-05-27 at 11:35 +0200, Hans de Goede wrote: > > > > Rahul Sundaram wrote: > > > On Fri, 2006-05-26 at 20:33 +0200, Hans de Goede wrote: > > >> Hi all, > > >> > > >> I'm currently in the progress of packaging tuxkart a racing game. One of > > >> the tracks on which you can race is an ordinary racing track with > > >> advertisement boards along the side. > > >> > > >> As shipped by upstream these advertisementboards contain advertisments > > >> for real product which clearly violates trademarks for those products. > > >> > > >> As such I'm in the progress of replacing these advertisement and some > > >> other troublish artwork. I've currently replace on the advertisement > > >> with the fedora logo, which seems appropriate for a Fedora package. > > >> However the license in fedora-logos is erm less then clearly worded and > > >> I wonder of my usage of the logo is ok. Notice that I've copy and pasted > > >> the logo, I cannot just use the image-file from Fedora-logo's because > > >> that is not in the .rgb format, which tuxkart needs. > > > > > > The logo guidelines is available from > > > http://fedoraproject.org/wiki/Logo. > > > > That isn't really helpfull, all I can find there is a pdf which > > tells me not to change colors etc, iow to use the logo unmodified, > > which I'm doing. What I want to know if I may use to logo in and > > distribute it as a part of a Fedora Extras package. > > Why isnt it helpful? As long as you dont violate the guidelines you are > free to include it. Out of curiosity I glanced over the issue. If these guidelines were all one has to fulfill then he could be distributing Debian CDs with this color-true, unstreatched logo. :) What Hans is after is the permission context of trademark/logo usage, not the technical ci/cd constraints. Common sense sais that what Hans wants to do is OK, but the authoritative people probably sit on the fedora-marketing list. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nman64 at n-man.com Sat May 27 10:02:06 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 27 May 2006 05:02:06 -0500 Subject: Fedora logo license In-Reply-To: <1148722571.4310.718.camel@sundaram.pnq.redhat.com> References: <44774A04.1090300@hhs.nl> <44781D5A.9060305@hhs.nl> <1148722571.4310.718.camel@sundaram.pnq.redhat.com> Message-ID: <200605270502.10047.nman64@n-man.com> On Saturday 27 May 2006 04:36, Rahul Sundaram wrote: > > That isn't really helpfull, all I can find there is a pdf which tells me > > not to change colors etc, iow to use the logo unmodified, which I'm > > doing. What I want to know if I may use to logo in and distribute it as > > a part of a Fedora Extras package. > > Why isnt it helpful? As long as you dont violate the guidelines you are > free to include it. > As the page states, you must still submit your request for permission to logo at fedoraproject.org and wait for a response. Your usage case will be considered, and a response will be formulated accordingly. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Sat May 27 13:42:40 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 27 May 2006 15:42:40 +0200 Subject: Trouble with the new Amarok version References: <1148688259.2593.110.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > Maybe there is value in having an amarok-gst10 and a amarok-helix? gst10 > seems to be the only way anyone will get mp3 support without a > recompile. What bothers me is that the Amarok devs removed the gst10 engine deliberately from the final 1.4 tarball. I've added it back for x86_64 because there wasn't any other engine available there, but I'd like to stay as close to upstream as possible. Those people who got mp3 support for gstreamer got it from a repo who has amarok-xine. They should just yum install it, and they will get a fully functional engine for amarok. No recompile. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein From jkeating at redhat.com Sat May 27 13:47:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 27 May 2006 09:47:46 -0400 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148684379.2593.104.camel@localhost.localdomain> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> <1148684379.2593.104.camel@localhost.localdomain> Message-ID: <1148737666.7067.5.camel@ender> On Fri, 2006-05-26 at 17:59 -0500, Tom 'spot' Callaway wrote: > > Thoughts? Sounds good, and a lot like the Fedora OEM proposal I sent up the RH ladder a few months ago, that went nowhere in a hurry. (psst, there might be some resistance) -- 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 jspaleta at gmail.com Sat May 27 13:51:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 27 May 2006 09:51:16 -0400 Subject: Trouble with the new Amarok version In-Reply-To: References: <1148688259.2593.110.camel@localhost.localdomain> Message-ID: <604aa7910605270651s5f5c3cf6w61ed7962099e8b56@mail.gmail.com> On 5/27/06, Aurelien Bompard wrote: > What bothers me is that the Amarok devs removed the gst10 engine > deliberately from the final 1.4 tarball. I've added it back for x86_64 > because there wasn't any other engine available there, but I'd like to stay > as close to upstream as possible. This is a really crap-tastic situation for amarok users, regardless of distribution. I think to keep yourself sane as the maintainer caught in the middle, you should turn the bugreports into a drinking game. Everytime someone new complains about the lack of gst support.. you get to drink a shot of tequila! I hope amarok users are able to work through the issues with the upstream developers. I find it an extremely odd decision right before the release, considering that amarok's "big thing" is audio engine neutrality. Hard to take that claim seriously if they aren't actually shipping support for engines that are part of the G-K desktop stacks. -jef" because these days... these days I tall ya' ... these days its all about the monkeys. --peter mulvey "spaleta From jspaleta at gmail.com Sat May 27 14:01:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 27 May 2006 10:01:24 -0400 Subject: Fedora logo license In-Reply-To: <200605270502.10047.nman64@n-man.com> References: <44774A04.1090300@hhs.nl> <44781D5A.9060305@hhs.nl> <1148722571.4310.718.camel@sundaram.pnq.redhat.com> <200605270502.10047.nman64@n-man.com> Message-ID: <604aa7910605270701g5f71784fk6666cd9c40d1d7b8@mail.gmail.com> On 5/27/06, Patrick W. Barnes wrote: > As the page states, you must still submit your request for permission to > logo at fedoraproject.org and wait for a response. Your usage case will be > considered, and a response will be formulated accordingly. I think the page should be re-ordered for clarity. The absolute most common question is going to be 'how do i get permission' the color-usage pdf should be a seperate item below a 'How to get permission' item. Right now, you read it quickly... and its pretty easy to go 'oh contact that address if I have questions about the pdf.' In fact the 'how do i get permissions' item should provide a very simple set of questions which are expected to be answeres when sending in the request for permission.. even if you think what you have to provide as information when asking for permission is obvious.. it helps immensely for clarity if there is a proforma set of questions people can have up front. Hell have a pre-filled in mailto url link that spawns in the user's local mail client, that has the proforma questions in the email. -jef"you can lead a horse to water... but you can't paint it blue and write the word fedora on its side..because that would be a trademark violation"spaleta From mtasaka at ioa.s.u-tokyo.ac.jp Sat May 27 15:32:55 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 28 May 2006 00:32:55 +0900 Subject: FE-devel buildsys complaints about repomd.xml Message-ID: <44787127.3030804@ioa.s.u-tokyo.ac.jp> Hello, All I am in the process of releasing xscreensaver in FE-extras. Currently, FE-devel buildsys won't rebuild my xscreensaver at all. I checked my build log on http://buildsys.fedoraproject.org/logs/fedora-development-extras/ . I found that buildsys left a EMPTY "build.log" and left a complaint on "root.log" at the last line: file:///pub/fedora/linux/core/development/i386/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/core/development/i386/repodata/repomd.xml' Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. It seems that FE-devel buildsys failed to rebuild several other packages seems with the simular error message. Is this releated to https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00801.html ? Thanks, Mamoru Tasaka From buildsys at fedoraproject.org Sat May 27 15:56:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 27 May 2006 11:56:03 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-05-27 Message-ID: <20060527155603.C8AFB152187@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 8 banshee-0.10.9-1..fc5 crossfire-client-1.9.0-2.fc5 daap-sharp-0.3.3-3.fc5 gcfilms-6.2-1.fc5 loudmouth-1.0.3-3.fc5 milter-regex-1.6-5.fc5 pari-2.3.0-3.fc5 qt4-4.1.3-5.fc5 Packages built and released for Fedora Extras 4: 5 crossfire-client-1.9.0-2.fc4 gcfilms-6.2-1.fc4 milter-regex-1.6-5.fc4 pari-2.3.0-3.fc4 qt4-4.1.3-5.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 7 cernlib-2005-21.fc6 crossfire-client-1.9.0-3.fc6 daap-sharp-0.3.3-4.fc6 loudmouth-1.0.3-4.fc6 pari-2.3.0-3.fc6 php-pear-Mail-1.1.10-4.fc6 qt4-4.1.3-5.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From ville.skytta at iki.fi Sat May 27 16:38:49 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 27 May 2006 19:38:49 +0300 Subject: Fedora Extras packages with broken upgrade paths Message-ID: <1148747929.5182.24.camel@localhost.localdomain> Below is a listing of packages currently in FE where an earlier distro version contains a newer package version than in some newer distro versions. The ugly script and its config used to generate this list are attached, and can be run like "./upgradecheck.py -c fe-sources.conf". The script examines source packages only, and reports problems from the first found problem spot onwards (ie. revisions for old distros that don't have this upgrade problem are not listed). See also https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html which includes instructions how to fix problems in earlier distro versions only without having to rebuild all newer ones. banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 cacti: 4: 0:0.8.6h-6.fc4 5: 0:0.8.6h-6 6: 0:0.8.6h-6 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 gcfilms: 5: 0:6.2-1.fc5 6: 0:6.1-2.fc5 gcl: 3: 0:2.6.7-5.fc3 4: 0:2.6.7-4.fc4 5: 0:2.6.7-11.fc5 6: 0:2.6.7-11.fc6 gnome-yum: 5: 0:0.1.3-1.fc5 6: 0:0.1.3-1 gtkglarea2: 3: 0:1.99.0-2.fc3 4: 0:1.99.0-2 5: 0:1.99.0-6.fc5 6: 0:1.99.0-6.fc5 iozone: 3: 0:3-1.fc3 4: 0:3-1 5: 0:3-2.fc5 6: 0:3-2.fc5 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 kdemultimedia-extras: 5: 6:3.5.2-5.fc5 6: 6:3.5.1-8.fc6 libtranslate: 3: 0:0.99-6.fc3 4: 0:0.99-5.fc4 5: 0:0.99-6.fc5 6: 0:0.99-6.fc6 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 lilypond: 5: 0:2.8.3-2.fc5 6: 0:2.8.3-1.fc6 mhonarc: 3: 0:2.6.12-1.fc3 4: 0:2.6.11-1.fc4 5: 0:2.6.15-4.fc5 6: 0:2.6.15-4.fc5 multitail: 5: 0:4.0.4-1.fc5 6: 0:4.0.3-1.fc6 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 perl-SOAP-Lite: 4: 0:0.67-2.1.fc4 5: 0:0.67-2.fc5 6: 0:0.67-2.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scim-qtimm: 3: 0:0.9.4-0.1.fc3 4: 0:0.9.4-0.fc4 5: (missing) 6: (missing) scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 utrac: 3: 0:0.3.0-7.fc3 4: 0:0.3.0-6.fc4 5: 0:0.3.0-6.fc5 6: 0:0.3.0-6.fc6 wine-docs: 3: 0:0.9.13-1.fc3 4: 0:0.9.13-0.1.fc4 5: 0:0.9.13-1.fc5 6: 0:0.9.13-1.fc6 xbase: 4: 0:2.0.0-4.fc4 5: 0:2.0.0-3.fc5 6: 0:2.0.0-3.fc5 xbsql: 3: 0:0.11-6.fc3 4: 0:0.11-5.fc4 5: 0:0.11-5.fc5 6: 0:0.11-5.fc5 xfce4-taskmanager: 3: 0:0.3.1-3.fc3 4: 0:0.3.1-2.fc4 5: 0:0.3.1-3.fc5 6: 0:0.3.1-3.fc5 xfce4-weather-plugin: 3: 0:0.4.9-5.fc3 4: 0:0.4.9-4.fc4 5: 0:0.4.9-5.fc5 6: 0:0.4.9-5.fc5 -------------- next part -------------- A non-text attachment was scrubbed... Name: fe-sources.conf Type: application/x-cisco-vpn-settings Size: 477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: upgradecheck.py Type: text/x-python Size: 4846 bytes Desc: not available URL: From bugs.michael at gmx.net Sat May 27 16:55:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 27 May 2006 18:55:05 +0200 Subject: Fedora Extras packages with broken upgrade paths In-Reply-To: <1148747929.5182.24.camel@localhost.localdomain> References: <1148747929.5182.24.camel@localhost.localdomain> Message-ID: <20060527185505.6ed28654.bugs.michael@gmx.net> On Sat, 27 May 2006 19:38:49 +0300, Ville Skytt? wrote: > Below is a listing of packages currently in FE where an earlier distro > version contains a newer package version than in some newer distro > versions. Nice, although the results are not so nice. ;) > wine-docs: > 3: 0:0.9.13-1.fc3 > 4: 0:0.9.13-0.1.fc4 > 5: 0:0.9.13-1.fc5 > 6: 0:0.9.13-1.fc6 This was on purpose, since the src.rpm for '4' contains an ugly hack compared with the other trees. The buildsys still fails to build this package. From buildsys at fedoraproject.org Sat May 27 17:01:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 27 May 2006 17:01:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-27 Message-ID: <20060527170113.21941.47644@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.i386 scim-fcitx-tools 3.1.1-4.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- scim-fcitx-tools 3.1.1-4.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- scim-fcitx 3.1.1-4.fc5.x86_64 scim-fcitx-tools 3.1.1-4.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: scim-fcitx - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4)(64bit) libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: scim-fcitx-tools - 3.1.1-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libstdc++-20060203.so.7()(64bit) libstdc++-20060203.so.7(GLIBCXX_4.2)(64bit) libstdc++-20060203.so.7(CXXABI_1.4)(64bit) package: scim-fcitx-tools - 3.1.1-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libstdc++-20060203.so.7(CXXABI_1.4) libstdc++-20060203.so.7 libstdc++-20060203.so.7(GLIBCXX_4.2) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Sat May 27 17:01:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 27 May 2006 17:01:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-27 Message-ID: <20060527170113.21932.90110@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.i386 scim-tables-korean 0.5.4-2.fc3.i386 stripesnoop-devel 1.5-2.fc3.i386 Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch scim-tables-japanese 0.5.4-2.fc3.x86_64 scim-tables-korean 0.5.4-2.fc3.x86_64 stripesnoop-devel 1.5-2.fc3.x86_64 ====================================================================== package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: scim-tables-japanese - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: stripesnoop-devel - 1.5-2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: stripesnoop = 0:1.5-2.fc3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Sat May 27 17:01:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 27 May 2006 17:01:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-27 Message-ID: <20060527170113.21940.13172@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.i386 plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.i386 scim-tables-korean 0.5.4-2.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- apt-groupinstall 0.5.15cnc7-6.fc4.ppc plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.ppc scim-tables-korean 0.5.4-2.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-tables-japanese 0.5.4-2.fc4.x86_64 scim-tables-korean 0.5.4-2.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: apt-groupinstall - 0.5.15cnc7-6.fc4.i386 from fedora-extras-4-i386 unresolved deps: apt = 0:0.5.15cnc7-6.fc4 package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-japanese - 0.5.4-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: scim-tables = 0:0.5.4 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-tables-japanese - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: scim-tables-korean - 0.5.4-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: scim-tables = 0:0.5.4 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: apt-groupinstall - 0.5.15cnc7-6.fc4.ppc from fedora-extras-4-ppc unresolved deps: apt = 0:0.5.15cnc7-6.fc4 From buildsys at fedoraproject.org Sat May 27 17:01:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 27 May 2006 17:01:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-27 Message-ID: <20060527170113.21944.97857@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gnonlin-devel 0.10.0.5-6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gnonlin-devel 0.10.0.5-6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gnonlin-devel 0.10.0.5-6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 unresolved deps: gnonlin = 0:0.10.0.5 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: gnonlin-devel - 0.10.0.5-6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnonlin = 0:0.10.0.5 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnonlin-devel - 0.10.0.5-6.ppc from fedora-extras-development-ppc unresolved deps: gnonlin = 0:0.10.0.5 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From steve at silug.org Sat May 27 19:31:33 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 27 May 2006 14:31:33 -0500 Subject: Fedora Extras Package Build Report 2006-05-27 In-Reply-To: <20060527155603.C8AFB152187@buildsys.fedoraproject.org> References: <20060527155603.C8AFB152187@buildsys.fedoraproject.org> Message-ID: <20060527193133.GA31630@osiris.silug.org> On Sat, May 27, 2006 at 11:56:03AM -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 5: 8 > > banshee-0.10.9-1..fc5 ^^ Somebody fixed this yet? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From steve at silug.org Sat May 27 20:33:18 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 27 May 2006 15:33:18 -0500 Subject: Upstream changing Licenses [Was: perl-Locale-Maketext-Simple.spec] In-Reply-To: <1148705407.27733.33.camel@mccallum.corsepiu.local> References: <200605250049.k4P0ngQg006850@cvs-int.fedora.redhat.com> <1148705407.27733.33.camel@mccallum.corsepiu.local> Message-ID: <20060527203318.GB31630@osiris.silug.org> On Sat, May 27, 2006 at 06:50:07AM +0200, Ralf Corsepius wrote: > do you think upstream is legitimated to do so? I honestly couldn't say. > I am facing the same situation with perl-Locale-Maketext-Lexicon (from > the same author). There, upstream has changed the license from > GPL/Artistic to MIT. > > IMO, by having done so, upstream probably has violated the law, because, > in general, they cannot change the license a package unless they own the > copyright of all parts a package consists of. > Locale::Maketext::Simple only lists one author, with > Locale::Maketext::Lexicon, the situation seems unclear: > http://search.cpan.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.61/AUTHORS > lists 20-25 contributors, while the source code only lists one > individual (the CPAN maintainer). Open a ticket in rt.cpan.org? Maybe email the CPAN maintainers and/or Perl Foundation for some backup? > I am not certain on how to handle the situation. To be on the safe side, > I considering to regard my perl-Locale-Maketext-Lexicon rpm as > derivative work of the original work and consider to ship it under the > GPL only. Couldn't you just call it "GPL or Artistic" still? > The fundamental questions would be: > * Who owns contributions to code in CPAN having been released under > GPL/Artistic before? > IMO: If the "contribution is copyrightable", the contributor. He is > contributing under the licenses the original author had granted. The > original author is not legitimated to change the license on such > contributions without explicit permission. > > * Is the maintainer of CPAN modules legitimated to change a license from > GPL/Artistic to MIT? > Here, I am not sure about the implications of the Artistic license. The CPAN maintainers (or somebody) needs to clarify some of these things. It would also be *really* helpful to have an explicit policy from them for things submitted to CPAN with no stated license. (I'd like to see them make everyone agree to "no license == same terms as Perl".) So far I've had this issue with both Data::UUID and OpenFrame. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From bluekuja at ubuntu.com Sat May 27 22:29:53 2006 From: bluekuja at ubuntu.com (Andrea Veri) Date: Sun, 28 May 2006 00:29:53 +0200 Subject: cvs-import problems Message-ID: <1148768993.26843.23.camel@localhost.localdomain> Hi guys, I'm having some problems uploading a package, I've found out that this problem already happened (https://www.redhat.com/archives/fedora-extras-list/2006-March/msg01073.html) I'm getting the same error, so maybe an administrator can fix this for me. Thanks From seg at haxxed.com Sat May 27 23:39:00 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 27 May 2006 18:39:00 -0500 Subject: How to build jack-audio-connection kit? In-Reply-To: <44780E80.8050505@smile.org.ua> References: <44774217.6010006@smile.org.ua> <1148681038.8271.13.camel@localhost> <44780E80.8050505@smile.org.ua> Message-ID: <1148773140.23158.5.camel@localhost> On Sat, 2006-05-27 at 11:32 +0300, Andy Shevchenko wrote: > I've removed the all optimization related switches from %configure. The > building process seems fine, but in tail I've got next error on all > archs. Where am I wrong? Errr. It would appear the build system is a bit broken at the moment. And its a holiday weekend in the US, so it may not get fixed quickly. Looks like some builds are getting through, but looks like a lot are failing with the same error. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat May 27 23:55:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 28 May 2006 01:55:47 +0200 Subject: cvs-import problems In-Reply-To: <1148768993.26843.23.camel@localhost.localdomain> References: <1148768993.26843.23.camel@localhost.localdomain> Message-ID: <20060528015547.53941cfd.bugs.michael@gmx.net> On Sun, 28 May 2006 00:29:53 +0200, Andrea Veri wrote: > Hi guys, > I'm having some problems uploading a package, I've found out that this > problem already happened > (https://www.redhat.com/archives/fedora-extras-list/2006-March/msg01073.html) > I'm getting the same error, so maybe an administrator can fix this for > me. > Thanks Fixed. Imported "ctorrent-1.3.2-3.src.rpm". Continue there. From sundaram at fedoraproject.org Sun May 28 09:29:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 14:59:12 +0530 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148737666.7067.5.camel@ender> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> <1148684379.2593.104.camel@localhost.localdomain> <1148737666.7067.5.camel@ender> Message-ID: <1148808552.4310.760.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 09:47 -0400, Jesse Keating wrote: > On Fri, 2006-05-26 at 17:59 -0500, Tom 'spot' Callaway wrote: > > > > Thoughts? > > Sounds good, and a lot like the Fedora OEM proposal I sent up the RH > ladder a few months ago, that went nowhere in a hurry. (psst, there > might be some resistance) > Can you post to the fedora advisory board list. Somewhere internal usually gets lost. Rahul From gauret at free.fr Sun May 28 10:42:57 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 28 May 2006 12:42:57 +0200 Subject: Trouble with the new Amarok version References: <1148688259.2593.110.camel@localhost.localdomain> <604aa7910605270651s5f5c3cf6w61ed7962099e8b56@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > This is a really crap-tastic situation for amarok users, regardless of > distribution. I think to keep yourself sane as the maintainer caught > in the middle, you should turn the bugreports into a drinking game. > Everytime someone new complains about the lack of gst support.. you > get to drink a shot of tequila! Man, you've just shed new light on bug reports. I now see the whole concept of "bug-squashing party" with a new eye. This is illuminating ! > I find it an extremely odd decision right before the release, considering > that amarok's "big thing" is audio engine neutrality. Actually, amarok is more about being feature-packed than being engine-neutral. The support for multiple engine is just one of those features. For their defence, the gst0.10 engine did lack some important fonctionality like streaming (webradios). They got fed up with bugreports on incomplete engines, and decided to only include engine with a set of "necessary" features. That left out gst0.10. Anyway, I don't care anymore, I have a bottle of Jose Cuervo Especial. Cheers, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From mpeters at mac.com Sun May 28 11:19:20 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 28 May 2006 04:19:20 -0700 Subject: OT: Media format patents and commercial installations In-Reply-To: <4476290F.8050207@bigpond.net.au> References: <4476290F.8050207@bigpond.net.au> Message-ID: <1148815160.28475.36.camel@atlantis.mpeters.local> On Fri, 2006-05-26 at 08:00 +1000, David Timms wrote: > Hi all, > > I am interested in building FC5 based installations for commercial sale. > One of the requirements is the capability to play back media of as many > types as possible (eg using mplayer/xine/vlc). While Fedora core/extras > can't contain patent encumbered nor non-open source software, in general > terms is there anything to stop me selling such a box ? The GPL. If you include GPL software with patent issues (like lame), even if you license the right to distribute - the GPL says you only have right to distribute if everyone you distribute to also has right to distribute - which is not the case in countries where software patents exist and are enforced. IE if I pay the mpeg consortium (or whatever they are called) for license to distribute an mpeg2 decoder, the mpeg2 encoder I distribute can not be GPL - and I believe (unless there is an exception clause) no GPL software I distribute can use it. If it does - I'm in violation of the GPL and therefore have no right to distribute the work. totem is GPL and I believe has an exception clause, so you could distribute totem with licensed capabilities - software that is BSD or LGPL I also believe is OK - but, for example, you can't have rhythmbox as part of your distribution if you include an mp3 plugin (even the one from fluendo) because it adds mp3 capability to rhythmbox, a GPL product, which your customers are not allowed to freely redistribute (because they haven't licensed the mp3 patents). Thus, you would be in GPL violation (in the US anyway) to distribute rhythmbox with mp3 capabilities - and as such, have no right to distribute rhythmbox at all (unless you got an alternate license from the rhythmbox developers, or they change their license to like what totem has) Maybe I'm wrong in that - but that's the way a GStreamer developer (I believe Thomas, not positive) explained it to me. Anyway - point is, if you are going to include non free software on a Linux distribution - you have to be damned careful that you don't end up in GPL violation. There _are_ GPL zealots who specifically LOOK for such violations. So be very careful. And write your political representatives begging them to eliminate or greatly reduce the lifespan of software patents. Software patents suck. From mtasaka at ioa.s.u-tokyo.ac.jp Sun May 28 13:24:15 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 28 May 2006 22:24:15 +0900 Subject: FE-devel buildsys complaints about repomd.xml In-Reply-To: <44787127.3030804@ioa.s.u-tokyo.ac.jp> References: <44787127.3030804@ioa.s.u-tokyo.ac.jp> Message-ID: <4479A47F.7040907@ioa.s.u-tokyo.ac.jp> Umm... The jobs which were queued to FE-devel buildsys within a day ago all failed to rebuild packages due to the same reason as for me. The failed queues are listed on http://buildsys.fedoraproject.org/build-status/failed.psp . All the jobs which failed within a day ago are for FE-devel. From Axel.Thimm at ATrpms.net Sun May 28 13:36:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 28 May 2006 15:36:39 +0200 Subject: OT: Media format patents and commercial installations In-Reply-To: <1148684379.2593.104.camel@localhost.localdomain> References: <4476290F.8050207@bigpond.net.au> <1148629854.4310.632.camel@sundaram.pnq.redhat.com> <604aa7910605260704n62a606e2uec90e0425fe70980@mail.gmail.com> <20060526142143.GA25131@lists.us.dell.com> <1148653780.9879.3.camel@dhcp83-49.boston.redhat.com> <1148657377.9879.6.camel@dhcp83-49.boston.redhat.com> <20060526163713.GB32444@lists.us.dell.com> <1148662563.16317.0.camel@dhcp83-49.boston.redhat.com> <1148684379.2593.104.camel@localhost.localdomain> Message-ID: <20060528133639.GB23534@neu.nirvana> On Fri, May 26, 2006 at 05:59:39PM -0500, Tom 'spot' Callaway wrote: > One idea might be an Third Party/OEM policy case, where Fedora Board > approved Third Party/OEM works can use the name Fedora as long as it is > accompanied with some additional text, and the modifications are > documented: > > Fedora Core 5 $OEM_3RDPARTY_NAME Edition > > This gives the Fedora Community some oversight into how the > trademark/logo is used, but increases the responsibility of the Fedora > Board. How about simply allowing referencing Fedora as a base like "based on (modified) Fedora sources" or similar. Adding to the use cases: o someone rebuilds Fedora for a (yet) unsupported platform o someone created a distribution with updates only o someone removes bits of the distribution to make it fit on one CD (like the blag project) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun May 28 17:03:35 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 28 May 2006 20:03:35 +0300 Subject: Maintainer sought for lirc-kmod(-common) Message-ID: <1148835815.5182.53.camel@localhost.localdomain> I've sat on lirc-kmod(-common) for too long, sorry about that, but I've just officially orphaned them. More info: https://bugzilla.redhat.com/192621#c1 The thing is that I'm fine with continuing to maintain the main lirc package, but I have no use or hardware for the kernel modules. And the main lirc packages works for many without the modules, so a dependency should not be added. But one the lirc kmods are shipped, we'll need to keep them in sync with the main lirc package. I don't personally think that's problematic and thus having a separate maintainer for the modules should work ok. If there is disagreement and volunteers available to take care of the whole shebang, I can let go of the main lirc package as well though. Any takers? From Axel.Thimm at ATrpms.net Sun May 28 17:16:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 28 May 2006 19:16:27 +0200 Subject: Maintainer sought for lirc-kmod(-common) In-Reply-To: <1148835815.5182.53.camel@localhost.localdomain> References: <1148835815.5182.53.camel@localhost.localdomain> Message-ID: <20060528171627.GA25083@neu.nirvana> On Sun, May 28, 2006 at 08:03:35PM +0300, Ville Skytt? wrote: > I've sat on lirc-kmod(-common) for too long, sorry about that, but I've > just officially orphaned them. > > More info: https://bugzilla.redhat.com/192621#c1 > > The thing is that I'm fine with continuing to maintain the main lirc > package, but I have no use or hardware for the kernel modules. And the > main lirc packages works for many without the modules, so a dependency > should not be added. But one the lirc kmods are shipped, we'll need to > keep them in sync with the main lirc package. I don't personally think > that's problematic and thus having a separate maintainer for the modules > should work ok. If there is disagreement and volunteers available to > take care of the whole shebang, I can let go of the main lirc package as > well though. I think the two are too much tied to be independently maintained. > Any takers? I gladly would, but I need to convince the peers here about kmdl adoption first :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun May 28 17:35:09 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 28 May 2006 20:35:09 +0300 Subject: Maintainer sought for lirc-kmod(-common) In-Reply-To: <20060528171627.GA25083@neu.nirvana> References: <1148835815.5182.53.camel@localhost.localdomain> <20060528171627.GA25083@neu.nirvana> Message-ID: <1148837709.5182.60.camel@localhost.localdomain> On Sun, 2006-05-28 at 19:16 +0200, Axel Thimm wrote: > I think the two are too much tied to be independently maintained. Ditto, and I'm not suggesting that. Having separate "primary" maintainers (of course cooperating) is what I would find doable. From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 29 02:27:24 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Mon, 29 May 2006 11:27:24 +0900 Subject: FE-devel buildsys complaints about repomd.xml [SOLVED] In-Reply-To: <4479A47F.7040907@ioa.s.u-tokyo.ac.jp> References: <44787127.3030804@ioa.s.u-tokyo.ac.jp> <4479A47F.7040907@ioa.s.u-tokyo.ac.jp> Message-ID: <447A5C0C.6010207@ioa.s.u-tokyo.ac.jp> I filed this as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193452 and Jeremy Katz fixed this. From philthegeek at gmail.com Mon May 29 06:18:46 2006 From: philthegeek at gmail.com (Phil Baltar) Date: Sun, 28 May 2006 23:18:46 -0700 Subject: knetworkmanager Message-ID: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> I was wondering if there were any current plans to include knetworkmanager in extras. If not, then I'd like to request that it be. I'm sure I'm not the only one who's been waiting for a way to use NetworkManager with KDE. From sundaram at fedoraproject.org Mon May 29 10:07:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 29 May 2006 15:37:12 +0530 Subject: knetworkmanager In-Reply-To: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> Message-ID: <1148897232.4310.806.camel@sundaram.pnq.redhat.com> On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: > I was wondering if there were any current plans to include > knetworkmanager in extras. If not, then I'd like to request that it > be. I'm sure I'm not the only one who's been waiting for a way to use > NetworkManager with KDE. > I havent seen any submissions. Would you like to get involved in packaging it? http://fedoraproject.org/wiki/Extras Rahul From panemade at gmail.com Mon May 29 11:32:11 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 29 May 2006 17:02:11 +0530 Subject: Need CVS access Message-ID: Hi, I am planning to push 2 packages in Fedora-Extras for that i need CVS sponsor and its access. For more information about those packages please check its package review request. 1)Qcwebcam package review request at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193216 2)Streamer Package review request at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193224 Regards, Parag. From paul at city-fan.org Mon May 29 11:57:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 29 May 2006 12:57:24 +0100 Subject: Need CVS access In-Reply-To: References: Message-ID: <1148903844.2876.44.camel@laurel.intra.city-fan.org> On Mon, 2006-05-29 at 17:02 +0530, Parag N(????) wrote: > Hi, > I am planning to push 2 packages in Fedora-Extras for that i > need CVS sponsor and its access. For more information about those > packages please check its package review request. > 1)Qcwebcam package review request at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193216 > 2)Streamer Package review request at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193224 See: http://www.fedoraproject.org/wiki/Extras/Contributors for how to become a Fedora Extras contributor and get sponsored for cvs access. Paul. From dennis at ausil.us Mon May 29 13:57:33 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 29 May 2006 08:57:33 -0500 Subject: knetworkmanager In-Reply-To: <1148897232.4310.806.camel@sundaram.pnq.redhat.com> References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> <1148897232.4310.806.camel@sundaram.pnq.redhat.com> Message-ID: <200605290857.33486.dennis@ausil.us> On Monday 29 May 2006 5:07 am, Rahul Sundaram wrote: > On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: > > I was wondering if there were any current plans to include > > knetworkmanager in extras. If not, then I'd like to request that it > > be. I'm sure I'm not the only one who's been waiting for a way to use > > NetworkManager with KDE. > > I havent seen any submissions. Would you like to get involved in > packaging it? > > http://fedoraproject.org/wiki/Extras > > Rahul Ive started work on packaging it. Im using it currently. I need to finish my review of the dbus-qt bindings and then submit for review. -- Dennis Gilmore, RHCE Proud Australian From ville.skytta at iki.fi Mon May 29 15:32:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 29 May 2006 18:32:56 +0300 Subject: Buildsys (i386) oddity In-Reply-To: <1148591133.17615.84.camel@localhost.localdomain> References: <1148591133.17615.84.camel@localhost.localdomain> Message-ID: <1148916776.5182.79.camel@localhost.localdomain> On Fri, 2006-05-26 at 00:05 +0300, Ville Skytt? wrote: > There seems to be something strange with the buildsys (i386/devel): I > made some innocent changes to xmms and requested a build, but the i386 > build seems to get repeatedly stuck in running/building state. The problem persists: https://bugzilla.redhat.com/193482 From jpo at lsd.di.uminho.pt Mon May 29 15:48:29 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 29 May 2006 16:48:29 +0100 Subject: Buildsys (i386) oddity + segmentation fault In-Reply-To: <1148653090.2468.6.camel@localhost.localdomain> References: <1148591133.17615.84.camel@localhost.localdomain> <447709F9.9040604@lsd.di.uminho.pt> <1148653090.2468.6.camel@localhost.localdomain> Message-ID: <447B17CD.8040903@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Williams wrote: > On Fri, 2006-05-26 at 15:00 +0100, Jose Pedro Oliveira wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Ville Skytt? wrote: >>> There seems to be something strange with the buildsys (i386/devel): I >>> made some innocent changes to xmms and requested a build, but the i386 >>> build seems to get repeatedly stuck in running/building state. >>> >>> It builds fine in the x86_64 and ppc builders in the buildsys and I >>> can't reproduce any weirdness locally on i386. >>> >>> I've killed/requeued the job already twice, but that hasn't helped: >>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=9945 >>> >>> Could someone take a look? TIA! >>> >> >> And also at this segmentation fault? >> >> Job failed on arch i386 >> http://buildsys.fedoraproject.org/logs/fedora-development-extras/9911-multitail-4.0.4-1.fc6/ >> - ------------------------------------------------- >> ... >> cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> - -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 >> - -mtune=generic -fasynchronous-unwind-tables -D`uname` -O2 -Wall >> - -DVERSION=\"4.0.4\" -g -DCONFIG_FILE=\"//etc/multitail.conf\" -c -o >> scrollback.o scrollback.c >> make: *** [scrollback.o] Segmentation fault >> make: *** Waiting for unfinished jobs.... >> error: Bad exit status from /var/tmp/rpm-tmp.26412 (%build) > > I suppose it would be useful if we set coredump limits higher in the > chroot, and if the buildsys detected the message "segmentation fault" > and if the job failed, to keep the chroot around for further analysis. > Right? :) Today it just built successfully (but last week it failed several times but only in devel i386). Maybe the gcc 4.1.1 update had something to do with it? 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEexfNl0metZG9hRsRAnM3AKDCNQPyCLzBDn54hPLqzrUZq6jhPQCgqufv Uim5DrdUUuMXb9PG9OlYvbU= =FPlW -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Mon May 29 16:41:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 29 May 2006 18:41:53 +0200 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-27 In-Reply-To: <20060527170113.21932.90110@extras64.linux.duke.edu> References: <20060527170113.21932.90110@extras64.linux.duke.edu> Message-ID: <20060529184153.c8604232.bugs.michael@gmx.net> On Sat, 27 May 2006 17:01:13 -0000, Fedora Extras repoclosure wrote: > package: scim-tables-japanese - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 > unresolved deps: > scim-tables = 0:0.5.4 > > package: scim-tables-korean - 0.5.4-2.fc3.i386 from fedora-extras-3-i386 > unresolved deps: > scim-tables = 0:0.5.4 Obsoleted by scim-tables-0.5.6 > package: stripesnoop-devel - 1.5-2.fc3.i386 from fedora-extras-3-i386 > unresolved deps: > stripesnoop = 0:1.5-2.fc3 Obsoleted by stripesnoop-1.5-5.fc3 Packages will be gone for all archs with next push of '3'. See https://bugzilla.redhat.com/190116 on why these obsolete packages are seen by Yum. From bugs.michael at gmx.net Mon May 29 16:41:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 29 May 2006 18:41:29 +0200 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-27 In-Reply-To: <20060527170113.21940.13172@extras64.linux.duke.edu> References: <20060527170113.21940.13172@extras64.linux.duke.edu> Message-ID: <20060529184129.5534fc58.bugs.michael@gmx.net> On Sat, 27 May 2006 17:01:13 -0000, Fedora Extras repoclosure wrote: > package: scim-tables-korean - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 > unresolved deps: > scim-tables = 0:0.5.4 Obsoleted by scim-tables-0.5.6 > package: apt-groupinstall - 0.5.15cnc7-6.fc4.i386 from fedora-extras-4-i386 > unresolved deps: > apt = 0:0.5.15cnc7-6.fc4 Obsoleted by apt-0.5.15lorg3.1-5.fc4 > package: scim-tables-japanese - 0.5.4-2.fc4.i386 from fedora-extras-4-i386 > unresolved deps: > scim-tables = 0:0.5.4 Obsoleted by scim-tables-0.5.6 Packages will be gone for all archs with next push of '4'. See https://bugzilla.redhat.com/190116 on why these obsolete packages are seen by Yum. From bugs.michael at gmx.net Mon May 29 16:41:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 29 May 2006 18:41:40 +0200 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-27 In-Reply-To: <20060527170113.21941.47644@extras64.linux.duke.edu> References: <20060527170113.21941.47644@extras64.linux.duke.edu> Message-ID: <20060529184140.96368c37.bugs.michael@gmx.net> On Sat, 27 May 2006 17:01:13 -0000, Fedora Extras repoclosure wrote: > package: scim-fcitx-tools - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 > unresolved deps: > libstdc++-20060203.so.7(CXXABI_1.4) > libstdc++-20060203.so.7 > libstdc++-20060203.so.7(GLIBCXX_4.2) > > package: scim-fcitx - 3.1.1-4.fc5.i386 from fedora-extras-5-i386 > unresolved deps: > libstdc++-20060203.so.7(CXXABI_1.4) > libstdc++-20060203.so.7 > libstdc++-20060203.so.7(GLIBCXX_4.2) Just plain broken, and there is a bug report about this. Packages will be gone for all archs with next push of '5'. From philthegeek at gmail.com Mon May 29 16:48:49 2006 From: philthegeek at gmail.com (Phil Baltar) Date: Mon, 29 May 2006 09:48:49 -0700 Subject: knetworkmanager Message-ID: <80b4f5eb0605290948x5327ec9ana0c54a94b43358df@mail.gmail.com> Do you have an ETA on that? I just started trying to compile it, but it's giving me trouble. I'm trying to decide whether I should continue wrestling with it or just wait on you. On 5/29/06, Dennis Gilmore wrote: > Ive started work on packaging it. Im using it currently. I need to finish my > review of the dbus-qt bindings and then submit for review. > -- > Dennis Gilmore, RHCE > Proud Australian From bugs.michael at gmx.net Mon May 29 16:41:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 29 May 2006 18:41:18 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-27 In-Reply-To: <20060527170113.21944.97857@extras64.linux.duke.edu> References: <20060527170113.21944.97857@extras64.linux.duke.edu> Message-ID: <20060529184118.8a12b287.bugs.michael@gmx.net> On Sat, 27 May 2006 17:01:13 -0000, Fedora Extras repoclosure wrote: > package: gnonlin-devel - 0.10.0.5-6.i386 from fedora-extras-development-i386 > unresolved deps: > gnonlin = 0:0.10.0.5 Obsoleted by gnonlin-0.10.4-1 Packages will be gone for all archs with next push of 'development'. See https://bugzilla.redhat.com/190116 on why these obsolete packages are seen by Yum. From buildsys at fedoraproject.org Mon May 29 20:38:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 29 May 2006 16:38:44 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-05-29 Message-ID: <20060529203844.CB47015216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 16 TeXmacs-1.0.6.2-3.fc5 azureus-2.4.0.3-0.20060529cvs_1.fc5 byzanz-0.1.1-1.fc5 crossfire-1.9.0-4.fc5 crossfire-maps-1.9.0-1.fc5 ctapi-cyberjack-2.0.8-14.fc5 libeXosip2-2.2.3-1.fc5 liferea-1.0.14-2.fc5 lua-5.1-3.fc5 perl-Cache-Cache-1.05-1.fc5 perl-Chart-2.4.1-3.fc5 perl-Template-Toolkit-2.15-1.fc5 scim-input-pad-0.1.1-4.fc5 scim-skk-0.5.2-5.fc5 scim-tomoe-0.2.0-6.fc5 xmms-1.2.10-25.fc5 Packages built and released for Fedora Extras 4: 9 TeXmacs-1.0.6.2-3.fc4 crossfire-1.9.0-4.fc4 crossfire-maps-1.9.0-1.fc4 ctapi-cyberjack-2.0.8-14.fc4 gtkglarea2-1.99.0-2.fc4 libeXosip2-2.2.3-1.fc4 lua-5.1-3.fc4 perl-Cache-Cache-1.05-1.fc4 texmaker-1.3-1.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 25 NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 TeXmacs-1.0.6.2-4.fc6 asymptote-1.06-5.fc6 byzanz-0.1.1-1.fc6 ctapi-cyberjack-2.0.10-3.fc6 gtkglarea2-1.99.0-6.fc6 gtkwave-3.0.2-2.fc6 gtorrentviewer-0.2b-9.fc6 jack-audio-connection-kit-0.101.1-9.fc6 libeXosip2-2.2.3-1.fc6 liferea-1.0.14-3.fc6 lua-5.1-3.fc6 mod_cband-0.9.7.4-1.fc6 multitail-4.0.4-1.fc6 perl-Cache-Cache-1.05-1.fc6 perl-Chart-2.4.1-3.fc6 perl-Crypt-DSA-0.14-2.fc6 perl-Gtk2-1.122-1.fc6 perl-Template-Toolkit-2.15-1.fc6 python-dns-1.3.5-1.fc6 python-xmpp-0.3.1-1.fc6 qof-0.6.4-5.fc6 rss-glx-0.8.1.p-1.fc6 tcltls-1.5.0-10.fc6 xscreensaver-5.00-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon May 29 20:55:59 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 29 May 2006 20:55:59 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-29 Message-ID: <20060529205559.19982.6297@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From buildsys at fedoraproject.org Mon May 29 20:55:59 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 29 May 2006 20:55:59 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-29 Message-ID: <20060529205559.19985.8306@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Mon May 29 20:55:59 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 29 May 2006 20:55:59 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-29 Message-ID: <20060529205559.19974.23772@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Mon May 29 20:55:59 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 29 May 2006 20:55:59 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-29 Message-ID: <20060529205559.19988.25179@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 From hugo at devin.com.br Tue May 30 11:04:39 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 30 May 2006 08:04:39 -0300 Subject: Buildsys (i386) oddity In-Reply-To: <1148916776.5182.79.camel@localhost.localdomain> References: <1148591133.17615.84.camel@localhost.localdomain> <1148916776.5182.79.camel@localhost.localdomain> Message-ID: <200605300804.39246.hugo@devin.com.br> On Monday 29 May 2006 12:32, Ville Skytt? wrote: > On Fri, 2006-05-26 at 00:05 +0300, Ville Skytt? wrote: > > There seems to be something strange with the buildsys (i386/devel): I > > made some innocent changes to xmms and requested a build, but the i386 > > build seems to get repeatedly stuck in running/building state. > > The problem persists: https://bugzilla.redhat.com/193482 Same for me now, the 'kerry' package is stuck at running/building state for i386/devel. -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From j.w.r.degoede at hhs.nl Tue May 30 11:23:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 30 May 2006 13:23:55 +0200 Subject: (Small) software that needs code audit Message-ID: <447C2B4B.80900@hhs.nl> Hi, As some of you already know I'm a computer science teacher at a Dutch university. Currently I'm giving a course about security. For my next practical lesson I want my students todo an audit of a small piece of C-code. Nothing fancy really just looking for sprintf instead of snprintf, gets instead of fgets, etc. And formatstring vulnerabilities. Does anyone know of some (small!) piece of software in Fedora (Extras) that could benefit from this? And are there any other simple checks my students could do? Any findings will of course be published. Thanks & Regards, Hans From bressers at redhat.com Tue May 30 12:31:01 2006 From: bressers at redhat.com (Josh Bressers) Date: Tue, 30 May 2006 08:31:01 -0400 Subject: (Small) software that needs code audit In-Reply-To: Your message of "Tue, 30 May 2006 13:23:55 +0200." <447C2B4B.80900@hhs.nl> Message-ID: <200605301231.k4UCV11X009451@devserv.devel.redhat.com> > Hi, > > As some of you already know I'm a computer science teacher at a Dutch > university. Currently I'm giving a course about security. > > For my next practical lesson I want my students todo an audit of a small > piece of C-code. Nothing fancy really just looking for sprintf instead > of snprintf, gets instead of fgets, etc. And formatstring vulnerabilities. > > Does anyone know of some (small!) piece of software in Fedora (Extras) > that could benefit from this? > > And are there any other simple checks my students could do? Checking for programs that call open(2) with O_CREAT and don't specify a mode. It's a terribly easy thing to look for and can be an annoying bug. As for having students do it, it has the advantage of making them do some code analysis since not all botched open calls are security issues. If I call open as such open("/tmp/feh", O_CREAT); I end with a file called /tmp/feh with nearly random permissions (bits are sucked off the stack to set the permissions). It's possible the file could be written as world writable (or many other permissions, I'll let you think about the possibilities). I should have called open like this open("/tmp/feh", O_CREAT, 0); Or if I don't want to change the permissions later, I can supply a non zero mode. It's also a fine idea to look for improper usage of temporary files. Using mktemp(3) instead of mkstemp(3). If I could suggest part of your class teaches responsible and sane disclosure. A while back another CS teacher did a similar thing with a class, and at the end of the class dumped a big email to full-disclosure detailing the problems. Luckily none of them were that terribly critical, but there was much scrambling since triaging 30+ issues is painful. Part of finding and fixing security issues is communicating the fixes upstream and deciding what to do about disclosure. I love hearing about classes such as this, good luck :) -- JB From frank-buettner at gmx.net Tue May 30 11:37:43 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Tue, 30 May 2006 13:37:43 +0200 Subject: package signing Message-ID: <447C2E87.6020703@gmx.net> On the build system there are since 3 day packages waiting for signing. Is there an process that only runs one time in week? Or hangs something? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Tue May 30 12:41:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 30 May 2006 14:41:56 +0200 Subject: package signing In-Reply-To: <447C2E87.6020703@gmx.net> References: <447C2E87.6020703@gmx.net> Message-ID: <20060530144156.d8313bc1.bugs.michael@gmx.net> On Tue, 30 May 2006 13:37:43 +0200, Frank B?ttner wrote: > On the build system there are since 3 day packages waiting for signing. > Is there an process that only runs one time in week? Or hangs something? FAQ And the answer is: The buildsys does not know when packages are signed and released from the need_sign queue. Signing them is a manual process, but so far it has been done almost every day. You do have noticed yesterday's build report on this list, don't you? From enrico.scholz at informatik.tu-chemnitz.de Tue May 30 13:35:22 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 30 May 2006 15:35:22 +0200 Subject: (Small) software that needs code audit In-Reply-To: <447C2B4B.80900@hhs.nl> (Hans de Goede's message of "Tue, 30 May 2006 13:23:55 +0200") References: <447C2B4B.80900@hhs.nl> Message-ID: <87verniqjp.fsf@kosh.bigo.ensc.de> j.w.r.degoede at hhs.nl (Hans de Goede) writes: > As some of you already know I'm a computer science teacher at a Dutch > university. Currently I'm giving a course about security. > ... > And are there any other simple checks my students could do? | char foo[2]; | strncpy(foo, bar, sizeof foo); | operate_on(foo); Enrico From jonathan.underwood at gmail.com Tue May 30 13:43:15 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 30 May 2006 14:43:15 +0100 Subject: package signing In-Reply-To: <20060530144156.d8313bc1.bugs.michael@gmx.net> References: <447C2E87.6020703@gmx.net> <20060530144156.d8313bc1.bugs.michael@gmx.net> Message-ID: <645d17210605300643s12a9e445p3887813b30e47d24@mail.gmail.com> On 30/05/06, Michael Schwendt wrote: > On Tue, 30 May 2006 13:37:43 +0200, Frank B?ttner wrote: > > > On the build system there are since 3 day packages waiting for signing. > > Is there an process that only runs one time in week? Or hangs something? > > FAQ > > And the answer is: The buildsys does not know when packages are signed and > released from the need_sign queue. Signing them is a manual process, but so > far it has been done almost every day. Excuse my ignorance, but I was wondering what it is about package signing that means it can't be automated. I expect that there's an obvious security issue with that, but I can't see it currently. J. From fedora at camperquake.de Tue May 30 13:54:36 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 30 May 2006 15:54:36 +0200 Subject: (Small) software that needs code audit In-Reply-To: <447C2B4B.80900@hhs.nl> References: <447C2B4B.80900@hhs.nl> Message-ID: <20060530155436.13595632@duras.int.addix.net> Hi. On Tue, 30 May 2006 13:23:55 +0200, Hans de Goede wrote: > And are there any other simple checks my students could do? Getting the arguments right on memset(). From tibbs at math.uh.edu Tue May 30 15:08:07 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 30 May 2006 10:08:07 -0500 Subject: package signing In-Reply-To: <645d17210605300643s12a9e445p3887813b30e47d24@mail.gmail.com> (Jonathan Underwood's message of "Tue, 30 May 2006 14:43:15 +0100") References: <447C2E87.6020703@gmx.net> <20060530144156.d8313bc1.bugs.michael@gmx.net> <645d17210605300643s12a9e445p3887813b30e47d24@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> Excuse my ignorance, but I was wondering what it is about package JU> signing that means it can't be automated. One would expect that the signing keys are held in devices not normally connected to computers except in the moment of signing and protected by memorized passphrases, or somesuch secure system. That would be not be conducive to automation. - J< From eric.tanguy at univ-nantes.fr Tue May 30 17:54:48 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Tue, 30 May 2006 19:54:48 +0200 Subject: buidsys hangs ? Message-ID: <1149011688.2545.11.camel@bureau.maison> It seems a package is building since more than one day ... Eric From chris.stone at gmail.com Wed May 31 05:14:23 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 30 May 2006 22:14:23 -0700 Subject: MySQL user install possible? Message-ID: I have a package that requires a MySQL user and database be set up in order for the package to function properly. Ideally I would like to do this during the install if possible. What is the best way to handle this problem? Is it possible to handle this within a spec file or must it be done manually by the user installing the software? Upstream informs me that on debian it is possible to get user input during install, or if no user input is possible, then a default MySQL setup allows creation of a user/database without having to enter a root password. From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 31 05:31:03 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Wed, 31 May 2006 14:31:03 +0900 Subject: buidsys hangs ? In-Reply-To: <1149011688.2545.11.camel@bureau.maison> References: <1149011688.2545.11.camel@bureau.maison> Message-ID: <447D2A17.6030004@ioa.s.u-tokyo.ac.jp> Eric Tanguy wrote: > It seems a package is building since more than one day ... > Eric > > Please see https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00874.html . From ej.grace at imperial.ac.uk Wed May 31 08:19:30 2006 From: ej.grace at imperial.ac.uk (Edward Grace) Date: Wed, 31 May 2006 09:19:30 +0100 Subject: Unison fails to syncronise between Fedora Core 5 and Intel OS X - Bugzilla bug #191295 Message-ID: <1149063571.9958.7.camel@ptpc3lin.op.ph.ic.ac.uk> Dear All, As suggested in a comment to my bug on bugzilla, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191295#c5 I thought I would try posting to this list. Unfortunately I am probably a "niche" audience. I am trying to use Unison to syncronise between OS X on Intel and Fedora Core. I seem to remember using Unison ok previously with OS X on PowerPC however these days it goes horribly wrong. Does anyone out there use FC5 and OS X with Unison? If so please get in touch. I'd like to see if my bug is peculiar to me, or the s/w. Thanks, -ed From buildsys at fedoraproject.org Wed May 31 10:18:35 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 31 May 2006 06:18:35 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-05-31 Message-ID: <20060531101835.187AA15216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 24 Coin2-2.4.5-1.fc5 SoQt-1.3.0-3.fc5 freehdl-0.0.2-1.fc5 gobby-0.3.1-1.fc5 gossip-0.11.1-2.fc5 gtkwave-3.0.3-1.fc5 gurlchecker-0.10.0-1.fc5 jpgraph-2.1.2-1.fc5 koffice-1.5.1-1.fc5 koffice-langpack-1.5.1-1.fc5 libchmxx-0.1-2.fc5 libpqxx-2.6.6-1.fc5 perl-GSSAPI-0.22-1.fc5 perl-Pipeline-3.12-2.fc5 poker-eval-131.0-1.fc5 qps-1.9.16-1.fc5 qt4-4.1.3-6.fc5 qucs-0.0.9-1.fc5 rapidsvn-0.9.2-1.fc5 texmaker-1.3-2.fc5 uuid-1.4.2-4.fc5 vpnc-0.3.3-7.1 wine-docs-0.9.14-1.fc5 xbindkeys-1.7.3-1.fc5 Packages built and released for Fedora Extras 4: 20 Coin2-2.4.5-1.fc4 SoQt-1.3.0-3.fc4 freehdl-0.0.2-1.fc4 gcl-2.6.7-6.fc4 gtkwave-3.0.3-1.fc4 gurlchecker-0.10.0-1.fc4 koffice-1.5.1-1.fc4 koffice-langpack-1.5.1-1.fc4 libpqxx-2.6.6-1.fc4 mhonarc-2.6.12-1.fc4 perl-GSSAPI-0.22-1.fc4 perl-Pipeline-3.12-2.fc4 poker-eval-131.0-1.fc4 qps-1.9.16-1.fc4 qt4-4.1.3-6.fc4 qucs-0.0.9-1.fc4 scim-qtimm-0.9.4-1.fc4 texmaker-1.3-2.fc4 uuid-1.4.2-4.fc4 wine-docs-0.9.14-0.1.fc4 Packages built and released for Fedora Extras 3: 6 Coin2-2.4.5-1.fc3 SoQt-1.3.0-3.fc3 freehdl-0.0.2-1.fc3 gtkwave-3.0.3-1.fc3 qucs-0.0.9-1.fc3 wine-docs-0.9.14-1.fc3 Packages built and released for Fedora Extras development: 33 Coin2-2.4.5-1.fc6 SoQt-1.3.0-3.fc6 anjuta-gdl-0.6.1-1.fc6 dbus-qt-0.61-3.fc6 freehdl-0.0.2-1.fc6 gossip-0.11.1-3.fc6 gtkwave-3.0.3-1.fc6 gurlchecker-0.10.0-1.fc6 jpgraph-2.1.2-1.fc6 knemo-0.4.0-4.fc6 koffice-1.5.1-1.fc6 koffice-langpack-1.5.1-1.fc6 libpqxx-2.6.6-1.fc6 libqalculate-0.9.3-2.fc6 mail-notification-2.0-13.fc6 maxima-5.9.3-4.fc6 nautilus-actions-1.2-2.fc6 perl-GSSAPI-0.22-1.fc6 perl-Pipeline-3.12-2.fc6 poker-eval-131.0-1.fc6 python-ogg-1.3-2.fc6 python-vorbis-1.3-2.fc6 qps-1.9.16-1.fc6 qt4-4.1.3-6.fc6 qucs-0.0.9-1.fc6 rapidsvn-0.9.2-1.fc6 sbcl-0.9.13-2.fc6 scim-bridge-0.1.12-1.fc6 scribus-1.3.3.2-1.fc6 sylpheed-2.2.5-1.fc6 texmaker-1.3-2.fc6 vpnc-0.3.3-8 wine-docs-0.9.14-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed May 31 10:32:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 31 May 2006 10:32:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-05-31 Message-ID: <20060531103254.18340.10663@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 texmaker 1:1.3-2.fc5.noarch ====================================================================== New report for: dakingun AT gmail.com package: texmaker - 1:1.3-2.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: libQtGui.so.4 libQtCore.so.4 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-5-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-5-ppc unresolved deps: libpqxx-2.5.5.so ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Wed May 31 10:32:55 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 31 May 2006 10:32:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-05-31 Message-ID: <20060531103255.18344.70798@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gparted 0.2.5-1.fc6.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gparted 0.2.5-1.fc6.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gparted 0.2.5-1.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 texmaker 1:1.3-2.fc6.noarch ====================================================================== New report for: dakingun AT gmail.com package: gparted - 0.2.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.7.so.0 package: gparted - 0.2.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.7.so.0()(64bit) package: texmaker - 1:1.3-2.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: libQtGui.so.4 libQtCore.so.4 package: gparted - 0.2.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.7.so.0 ====================================================================== New report for: tcallawa AT redhat.com package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 ====================================================================== New report for: matthias AT rpmforge.net package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 From buildsys at fedoraproject.org Wed May 31 10:32:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 31 May 2006 10:32:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-05-31 Message-ID: <20060531103254.18336.40308@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-4.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-4.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-4.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 texmaker 1:1.3-2.fc4.noarch ====================================================================== New report for: dakingun AT gmail.com package: texmaker - 1:1.3-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: libQtGui.so.4 libQtCore.so.4 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-4.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-4.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: showimg-pgsql - 0.9.5-4.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpqxx-2.5.5.so ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From buildsys at fedoraproject.org Wed May 31 10:32:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 31 May 2006 10:32:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-05-31 Message-ID: <20060531103254.18328.70995@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From ej.grace at imperial.ac.uk Wed May 31 11:01:05 2006 From: ej.grace at imperial.ac.uk (Edward Grace) Date: Wed, 31 May 2006 12:01:05 +0100 Subject: Syncronisation failure - Tracing problem Message-ID: <7C4C1F72-8C23-41F8-93B8-00B0D7B9156D@imperial.ac.uk> Dear all, I am trying to trace why Unison aborts certain transfers when syncronising between OS X and Linux. So far I have traced the cause of the problem to something near the following log entries: I really want to know exactly *where* in the source the process is failing. Currently the abort message gets triggered with: [abort] Checking line 0 [abort] Abort failure for line 0 I assume this is an error and that the abort message should state where in the source the failure occurred: line zero doesn't seem likely! ;-) My assumption is that something bad occurs when creating the directory, I'd like to find out why. I can make the directory fine on the command line, so it's not a length or other file limitation. Can anyone suggest how I can track this down. This relates to the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191295 Help would be appreciated as this is becoming a real pain! -ed [update] updateArchiveLocal /Users/graceej/Documents tmp [pred] ignore 'tmp' = false [pred] backup 'tmp' = false [files] copyRec tmp --> .#tmp. 64c46d788f5c15bdbf4c3724c5bd86e8.unison.tmp (really to tmp) [files] Creating directory /Users/graceej/Documents/.#tmp. 64c46d788f5c15bdbf4c3724c5bd86e8.unison.tmp [abort] Checking line 0 [abort] Abort failure for line 0 [remote_emit] send [rollBack-args] '\132\149\166\190\000\000\000%\000 \000...' 57 bytes [remote_emit] send [rsp] '\132\149\166\190\000\000\000\n\000\000...' 30 bytes [remote_emit] Sending request (id: 2301) [remote_emit] Remaining tokens: 1 <>![server: remote_emit] Message received (id: 2301) (tokens: 1) [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 33 bytes [server: remote_emit] receive 'rollBack-a...' 70 bytes [server: remote_emit] Waiting for next message [server: remote_emit] Sending result (id: 2301) [server: remote_emit] send [rollBack-res] '\132\149\166\190\000\000 \000\001\000\000...' 21 bytes [server: remote_emit] send [rsp] '\132\149\166\190\000\000\000\001\000 \000...' 21 bytes [server: remote_emit] Remaining tokens: 1 [remote_emit] Message received (id: 2301) (tokens: 1) [remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 24 bytes [remote_emit] receive 'rollBack-r...' 33 bytes [remote_emit] Waiting for next message [thread] Exception caught by Thread.unwindProtect: Aborted [xferhint] deleteEntry: fspath=/Users/graceej/Documents, path=.#tmp. 64c46d788f5c15bdbf4c3724c5bd86e8.unison.tmp [thread] Exception caught by Thread.unwindProtect: Aborted Failed: Aborted From dcbw at redhat.com Wed May 31 11:20:46 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 31 May 2006 07:20:46 -0400 Subject: Buildsys (i386) oddity In-Reply-To: <200605300804.39246.hugo@devin.com.br> References: <1148591133.17615.84.camel@localhost.localdomain> <1148916776.5182.79.camel@localhost.localdomain> <200605300804.39246.hugo@devin.com.br> Message-ID: <1149074446.2487.0.camel@localhost.localdomain> On Tue, 2006-05-30 at 08:04 -0300, Hugo Cisneiros wrote: > On Monday 29 May 2006 12:32, Ville Skytt? wrote: > > On Fri, 2006-05-26 at 00:05 +0300, Ville Skytt? wrote: > > > There seems to be something strange with the buildsys (i386/devel): I > > > made some innocent changes to xmms and requested a build, but the i386 > > > build seems to get repeatedly stuck in running/building state. > > > > The problem persists: https://bugzilla.redhat.com/193482 > > Same for me now, the 'kerry' package is stuck at running/building state for > i386/devel. Unfortunately I can't just run gdb against these, I need to sit down and install 32-bit gdb into the chroot, then the debuginfo for gcc, and then see what's up... which I'll try to do today. Dan From bugzilla at redhat.com Wed May 31 12:27:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 May 2006 08:27:44 -0400 Subject: [Bug 171915] Review Request: texmaker - LaTeX editor In-Reply-To: Message-ID: <200605311227.k4VCRi5O011027@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: texmaker - LaTeX editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171915 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From bugs.michael at gmx.net 2006-05-31 08:19 EST ------- Why did you make it "noarch" after the review process and ignoring that this package is C++ code which is compiled against Qt4? You now have released a PPC binary for i386: $ file texmaker texmaker: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped $ ldd texmaker linux-gate.so.1 => (0x0073e000) libqt-mt.so.3 => /usr/lib/qt-3.3/lib/libqt-mt.so.3 (0x0551b000) libXext.so.6 => /usr/lib/libXext.so.6 (0x009f5000) libX11.so.6 => /usr/lib/libX11.so.6 (0x008f1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0042c000) libm.so.6 => /lib/libm.so.6 (0x00891000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00db6000) libc.so.6 => /lib/libc.so.6 (0x0075c000) libmng.so.1 => /usr/lib/libmng.so.1 (0x033fa000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0302c000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00b6f000) libz.so.1 => /usr/lib/libz.so.1 (0x008be000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00b99000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00bee000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00bfb000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00be9000) libXft.so.2 => /usr/lib/libXft.so.2 (0x0352e000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00abe000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00baa000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00dc4000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00dcf000) libdl.so.2 => /lib/libdl.so.2 (0x008b8000) libpthread.so.0 => /lib/libpthread.so.0 (0x008db000) libXau.so.6 => /usr/lib/libXau.so.6 (0x009f0000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x008d3000) /lib/ld-linux.so.2 (0x0073f000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x031c6000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00bf4000) libexpat.so.0 => /lib/libexpat.so.0 (0x00a9b000) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From roozbeh at farsiweb.info Wed May 31 12:35:33 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Wed, 31 May 2006 16:05:33 +0330 Subject: MySQL user install possible? In-Reply-To: References: Message-ID: <1149078934.3252.2.camel@tameshk.farsiweb.info> ??? ???????? 2006-05-30 ???? 22:14 -0700? Christopher Stone ????: > I have a package that requires a MySQL user and database be set up in > order for the package to function properly. > > Ideally I would like to do this during the install if possible. What > is the best way to handle this problem? Is it possible to handle this > within a spec file or must it be done manually by the user installing > the software? Does the software strictly *require* the MySQL server to be on the same machine? If not (which is the most probable case), please do not do anything about it. Just add a README.fedora or INSTALL.fedora file and explain what should the user do after installing the RPM. roozbeh From bugzilla at redhat.com Wed May 31 13:38:00 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 May 2006 09:38:00 -0400 Subject: [Bug 171915] Review Request: texmaker - LaTeX editor In-Reply-To: Message-ID: <200605311338.k4VDc0mK014817@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: texmaker - LaTeX editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171915 ------- Additional Comments From dakingun at gmail.com 2006-05-31 09:30 EST ------- (In reply to comment #9) > Why did you make it "noarch" after the review process and ignoring > that this package is C++ code which is compiled against Qt4? Long story, I should be sleeping when i made that decision, I'll revert it son-ish. Sorry for the dumb mistake. Deji -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wart at kobold.org Wed May 31 14:46:32 2006 From: wart at kobold.org (Wart) Date: Wed, 31 May 2006 07:46:32 -0700 Subject: (Small) software that needs code audit In-Reply-To: <447C2B4B.80900@hhs.nl> References: <447C2B4B.80900@hhs.nl> Message-ID: <447DAC48.4020707@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans de Goede wrote: > Hi, > > As some of you already know I'm a computer science teacher at a Dutch > university. Currently I'm giving a course about security. > > For my next practical lesson I want my students todo an audit of a small > piece of C-code. Nothing fancy really just looking for sprintf instead > of snprintf, gets instead of fgets, etc. And formatstring vulnerabilities. > > Does anyone know of some (small!) piece of software in Fedora (Extras) > that could benefit from this? > > And are there any other simple checks my students could do? > > Any findings will of course be published. Many of the games in the bsd-games package are fairly small (one or two .c files) and could probably use an audit. Since most of them don't run setgid, and drop any gid privileges before doing anything anyway, security hasn't been an issue with them. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEfaxGDeYlPfs40g8RAqRPAJ9cpNgcMKsWH+RcUgUZ70LXR/cl6wCfZ486 tcVCdQyTg+KEUAE3GnxAD5o= =OxCz -----END PGP SIGNATURE----- From Matt_Domsch at dell.com Wed May 31 15:15:20 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:15:20 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151520.GC30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Wed May 31 10:03:11 CDT 2006 Number failed to build: 174 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 173 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 171 ---------------------------------- Gtk-Perl GtkAda Hermes MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_net SDL_ttf Terminal WindowMaker abe alacarte amaya anjuta-gdl balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp clearsilver colorscheme contact-lookup-applet cowbell csmash dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables enigma epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge freedroid gambas gazpacho gcompris gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd lincity-ng linkchecker lmarbles logjam lucidlife maxima mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool nazghul ncmpc nco netpanzer paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl ppracer pygame pypoker-eval python-TestGears python-cheetah python-goopy qemu qtparted quarry rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly ser serpentine sloccount splint stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool tetex-eurofont torcs tuxpaint tuxtype2 ushare verbiste viruskiller wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed May 31 15:15:55 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:15:55 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151555.GD30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Wed May 31 10:01:38 CDT 2006 Number failed to build: 185 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 174 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 172 ---------------------------------- Gtk-Perl GtkAda Macaulay2 MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_ttf Terminal WindowMaker alacarte amaya anjuta-gdl apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dietlibc dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife maxima mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco new pam_mount paps perl-HTML-Mason perl-Image-Info perl-Log-Log4perl perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl pypoker-eval python-TestGears python-cheetah python-dateutil python-goopy python-reportlab qemu qtparted quarry rpmDirectoryCheck sabayon scmxx scponly ser serpentine sloccount splint stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool tetex-eurofont tuxpaint uqm ushare verbiste wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp z88dk With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From wart at kobold.org Wed May 31 16:27:43 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 31 May 2006 09:27:43 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531151520.GC30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> Message-ID: <447DC3FF.6090304@kobold.org> Matt Domsch wrote: > Of those expected to have worked... > Without a bug filed: 171 > ---------------------------------- > Gtk-Perl > GtkAda > Hermes > MagicPoint > NetworkManager-vpnc > OpenSceneGraph > R-gnomeGUI > SDL_net > SDL_ttf > Terminal > WindowMaker > abe [...] > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Some of these (abe, gcompris) are failing when looking for SDL. But without the configure logs it's hard to tell exactly which BR: is missing that's causing the failure. Is it possible to get access to the build root for any of these failures? --Mike abe: [...] checking for sdl-config... /usr/bin/sdl-config checking for SDL - version >= 1.0.1... no *** Could not run SDL test program, checking why... *** The test program compiled, but did not run. This usually means *** that the run-time linker is not finding SDL or finding the wrong *** version of SDL. If it is not finding SDL, you'll need to set your *** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point *** to the installed location Also, make sure you have run ldconfig if that *** is required on your system *** *** If you have an old version installed, it is best to remove it, although *** you may also be able to get things to work by modifying LD_LIBRARY_PATH *** SDL not found. Configuring without audio or joystick support. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From pertusus at free.fr Wed May 31 16:35:31 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 May 2006 18:35:31 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <447DC3FF.6090304@kobold.org> References: <20060531151520.GC30021@lists.us.dell.com> <447DC3FF.6090304@kobold.org> Message-ID: <20060531163531.GA4522@free.fr> > Some of these (abe, gcompris) are failing when looking for SDL. But > without the configure logs it's hard to tell exactly which BR: is > missing that's causing the failure. Is it possible to get access to the > build root for any of these failures? Guess you are interested in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179670 -- Pat From jpo at lsd.di.uminho.pt Wed May 31 16:42:14 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 31 May 2006 17:42:14 +0100 Subject: CVS branching Message-ID: <447DC766.6070208@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone start processing the CVS request branches in http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ? Some of them are 4 days old. tia, 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 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEfcdml0metZG9hRsRAnh6AJ48BqKHgIZ7JZLmpu6XmT3JWDJchwCcCqvM 9+vHZqrXdtCEyFedl3BK9Lk= =YtyE -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From fedora at leemhuis.info Wed May 31 17:36:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 31 May 2006 19:36:38 +0200 Subject: Summary from last weeks FESCo meeting Message-ID: <1149096999.2313.11.camel@localhost.localdomain> == Summary == Present from FESCo: thl, ensc, jpo, warren, thomasvs, jeremy, scop, Sopwith * buildsys-build * Just a bit background information: The list of packages that mock installed by default currently doesn't match the list of exceptions documented in the [http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions packaging guidelines]. We currently try to clean this mess up a bit and bring the guidelines and mock in sync. There was some discussion about this on the FESCo mailing list. The plan was to kick out these: * autoconf * automake * automake14 * automake15 * automake16 * automake17 * bison * buildsys-macros * byacc * createrepo * ctags * diffstat * doxygen * flex * gdb * gettext * indent * intltool * libtool * openssh-server * patchutils * perl-XML-Dumper * perl-XML-Parser * perl-XML-SAX * pkgconfig * rpm-python * strace * which Some of those on the list (especially which, pkgconfig and gettext) are still under discussion. See [https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00807.html this mail] for some more details. The consens in the meeting was to let "which" out, but it is included in the mdomsch's build efforts now (he extended those to Extas during the weekend). So chances are high that we'll let is stay in the default buildroot. * jeremy> | having the packages with .pc files require pkgconfig instead of having pkgconfig in the base set is fine by me * Do you plan to change it for all supported distributions, or only for the development branch? Undecided, maybe all. But is that worth the trouble? * The plan is to list the explicit "Exceptions" and the extrapolated list (packages that are pulled in via deps or are intalled by default; maybe we need to be list them separately for all distro versions) * Encourage Extras reviews (warren, tibbs) * some ideas from tibbs at http://www.math.uh.edu/~tibbs/review-brainstorm * Fedora Extras metrics (Sopwith) * Sopwith> | Heheh, well, I have been ignoring it for months now. * Sopwith> | Right now, in the bigger picture, we need to start recruiting developers to write code for metrics and other infrastructure pieces. * thl> | Sopwith, we/you probably should talk to Christian; he creates http://www.fedoraproject.org/wiki/Extras/PackageStatus * Sopwith> | If there is any access I can give him to make hosting his stuff easier, I'd be happy to. * CVS access (not on the schedule) * thl> | I'd like to trow this in while jeremy and Sopwith are around * thl> | are there chances that we can open CVS a bit more? e.g. round about [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00506.html proposed here]. * jeremy> | thl: it should be possible to do; shouldn't be too hard I don't think * thl> | Sopwith, jeremy, btw, are you aware of https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00510.html (that's the CTRL-C problem) * warren> | CTRL-C problem cannot be solved unless we make the server take care of that entirely... * warren> | thl, may I suggest that we defer attempting to fix that, because we are seriously looking at replacing CVS with something else after FC6. * thl> | we should fix it soon * scop> | not a fix, but package push reports help in identifying susceptible builds * thomasvs> | it's easily doable - add an ampersand to the trigger, if it runs in the background it can't be interrupted * jeremy> | would need to be tried, it could have other side effects * nirik> | as someone pointed out, you can just upload a new .tar.gz to the lookaside with your evil changes in them... no one is likely to catch that. * tibbs> | Push ACLs down to the individual packages? * scop> | nirik, I assume that buildsys checks md5sums from the "sources" file for everything in lookaside cache * that wrong -> the sums are not checked (that has problems when upstream servers are down or rearrange their layout or ...) and we have modified tarballs (mp3 stuff removed) * tibbs> | Assuming it's relatively easy to give others permission, and the people who need it will always have permissions, what are the objections? * no conclusion was found -> skipped * Weekly sponsorship nomination * wart (Michael Thomas) was accepted * mdomsch was nominated (will be discussed next week) Full log at http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060525 -- Thorsten Leemhuis From bugzilla at redhat.com Wed May 31 17:55:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 May 2006 13:55:19 -0400 Subject: [Bug 171915] Review Request: texmaker - LaTeX editor In-Reply-To: Message-ID: <200605311755.k4VHtJvB001183@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: texmaker - LaTeX editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171915 ------- Additional Comments From ville.skytta at iki.fi 2006-05-31 13:47 EST ------- See bug 193601 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Matt_Domsch at dell.com Wed May 31 18:17:54 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 13:17:54 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <447DC3FF.6090304@kobold.org> References: <20060531151520.GC30021@lists.us.dell.com> <447DC3FF.6090304@kobold.org> Message-ID: <20060531181753.GF30021@lists.us.dell.com> On Wed, May 31, 2006 at 09:27:43AM -0700, Michael Thomas wrote: > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Some of these (abe, gcompris) are failing when looking for SDL. But > without the configure logs it's hard to tell exactly which BR: is > missing that's causing the failure. I'll start saving out the config.log files in the per-package build result/ directory, alongside the existing build.log and root.log files (and rpmdiff and rpmlint log files which are there too if the package does actually build). So starting tomorrow, yes. > Is it possible to get access to the build root for any of these > failures? I can't post all the build roots, it's hundreds of megs of space for each failure. A suitably-configured mock that uses a local trimmed group list (as described here: https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00904.html) can be used to generate it though. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bugs.michael at gmx.net Wed May 31 18:31:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 31 May 2006 20:31:13 +0200 Subject: Summary from last weeks FESCo meeting In-Reply-To: <1149096999.2313.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> Message-ID: <20060531203113.c97223a4.bugs.michael@gmx.net> On Wed, 31 May 2006 19:36:38 +0200, Thorsten Leemhuis wrote: > * scop> | nirik, I assume that buildsys checks md5sums from the > "sources" file for everything in lookaside cache > * that wrong -> the sums are not checked (that has problems when > upstream servers are down or rearrange their layout or ...) and we have > modified tarballs (mp3 stuff removed) scop is right. The buildsys runs "make srpm" which in turn fetches the md5 sums from the "sources" file and only succeeds in downloading tarballs from the lookaside cache if they match the md5 sums. You cannot simply replace a tarball in the lookaside cache, because when its md5 sum differs, you need to update also the "sources" file. From fedora at leemhuis.info Wed May 31 18:49:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 31 May 2006 20:49:52 +0200 Subject: Summary from last weeks FESCo meeting In-Reply-To: <20060531203113.c97223a4.bugs.michael@gmx.net> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> Message-ID: <1149101392.2313.25.camel@localhost.localdomain> Am Mittwoch, den 31.05.2006, 20:31 +0200 schrieb Michael Schwendt: > On Wed, 31 May 2006 19:36:38 +0200, Thorsten Leemhuis wrote: > > > * scop> | nirik, I assume that buildsys checks md5sums from the > > "sources" file for everything in lookaside cache > > * that wrong -> the sums are not checked (that has problems when > > upstream servers are down or rearrange their layout or ...) and we have > > modified tarballs (mp3 stuff removed) > > scop is right. The buildsys runs "make srpm" which in turn fetches the > md5 sums from the "sources" file and only succeeds in downloading > tarballs from the lookaside cache if they match the md5 sums. You > cannot simply replace a tarball in the lookaside cache, because when > its md5 sum differs, you need to update also the "sources" file. Ohh, sorry, yes, that was a bit misleading. The problem simply is: who checks that the md5 sums stored in CVS are fine / those from upstream? Nobody. I can upload a new version of package "foo" at any time and include a rootkit in the tarball I upload. No one would notice. CU thl -- Thorsten Leemhuis From pertusus at free.fr Wed May 31 18:53:04 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 May 2006 20:53:04 +0200 Subject: Summary from last weeks FESCo meeting In-Reply-To: <1149101392.2313.25.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> Message-ID: <20060531185304.GA2462@free.fr> > Ohh, sorry, yes, that was a bit misleading. The problem simply is: who > checks that the md5 sums stored in CVS are fine / those from upstream? > Nobody. I can upload a new version of package "foo" at any time and > include a rootkit in the tarball I upload. No one would notice. Anybody could notice that the source file has changed and could verify that the md5sum matches upstream. I don't think that anybody does, however (I don't ;)... -- Pat From chris.stone at gmail.com Wed May 31 19:06:24 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 May 2006 12:06:24 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531151520.GC30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> Message-ID: On 5/31/06, Matt Domsch wrote: > Of those expected to have worked... > pygame I do not understand why pygame is failing to build on i386 only. It does not look like it is a missing BR issue since it works fine in x86_64. Here is a snippit from the build log: Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.85331 + umask 022 + cd /builddir/build/BUILD + cd pygame-1.7.1release + PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages + /usr/bin/python test/base_test.py Traceback (most recent call last): File "test/base_test.py", line 2, in ? import unittest, pygame File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot after reloc: Permission denied + : + PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages + /usr/bin/python test/image_test.py Traceback (most recent call last): File "test/image_test.py", line 5, in ? import pygame, pygame.image, pygame.pkgdata File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot after reloc: Permission denied error: Bad exit status from /var/tmp/rpm-tmp.85331 (%check) From wart at kobold.org Wed May 31 19:19:08 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 31 May 2006 12:19:08 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531181753.GF30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <447DC3FF.6090304@kobold.org> <20060531181753.GF30021@lists.us.dell.com> Message-ID: <447DEC2C.5060202@kobold.org> Matt Domsch wrote: > On Wed, May 31, 2006 at 09:27:43AM -0700, Michael Thomas wrote: > >>>Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ >> >>Some of these (abe, gcompris) are failing when looking for SDL. But >>without the configure logs it's hard to tell exactly which BR: is >>missing that's causing the failure. > > > I'll start saving out the config.log files in the per-package build > result/ directory, alongside the existing build.log and root.log files > (and rpmdiff and rpmlint log files which are there too if the package > does actually build). So starting tomorrow, yes. That would help a lot. Thanks! >>Is it possible to get access to the build root for any of these >>failures? > > > I can't post all the build roots, it's hundreds of megs of space for > each failure. A suitably-configured mock that uses a local trimmed > group list (as described here: > https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00904.html) > can be used to generate it though. Thanks for the pointer. I was able to reproduce a build failure on another package (bsd-games) with a local build group list, but not with abe. I did notice the following in your build.log: checking for X... no Which seems a little odd. The only difference I saw in the packages that got installed was that I picked up a slightly newer version of mesa-libGL. I'll assume that it fixed the problem and watch for failures in tomorrow's report. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From Matt_Domsch at dell.com Wed May 31 19:31:11 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 14:31:11 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: References: <20060531151520.GC30021@lists.us.dell.com> Message-ID: <20060531193110.GG30021@lists.us.dell.com> On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > On 5/31/06, Matt Domsch wrote: > >Of those expected to have worked... > >pygame > > I do not understand why pygame is failing to build on i386 only. It > does not look like it is a missing BR issue since it works fine in > x86_64. Here is a snippit from the build log: > > Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.85331 > + umask 022 > + cd /builddir/build/BUILD > + cd pygame-1.7.1release > + > PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages > + /usr/bin/python test/base_test.py > Traceback (most recent call last): > File "test/base_test.py", line 2, in ? > import unittest, pygame > File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > after reloc: Permission denied > + : > + > PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages > + /usr/bin/python test/image_test.py > Traceback (most recent call last): > File "test/image_test.py", line 5, in ? > import pygame, pygame.image, pygame.pkgdata > File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > after reloc: Permission denied > error: Bad exit status from /var/tmp/rpm-tmp.85331 (%check) selinux perhaps? -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From chris.stone at gmail.com Wed May 31 19:56:36 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 May 2006 12:56:36 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531193110.GG30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> Message-ID: On 5/31/06, Matt Domsch wrote: > On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > > On 5/31/06, Matt Domsch wrote: > > >Of those expected to have worked... > > >pygame > > > > I do not understand why pygame is failing to build on i386 only. It > > does not look like it is a missing BR issue since it works fine in > > x86_64. Here is a snippit from the build log: > > > > Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.85331 > > + umask 022 > > + cd /builddir/build/BUILD > > + cd pygame-1.7.1release > > + > > PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages > > + /usr/bin/python test/base_test.py > > Traceback (most recent call last): > > File "test/base_test.py", line 2, in ? > > import unittest, pygame > > File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > after reloc: Permission denied > > + : > > + > > PYTHONPATH=/var/tmp/pygame-1.7.1-6.fc6-root-mockbuild/usr/lib/python2.4/site-packages > > + /usr/bin/python test/image_test.py > > Traceback (most recent call last): > > File "test/image_test.py", line 5, in ? > > import pygame, pygame.image, pygame.pkgdata > > File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > after reloc: Permission denied > > error: Bad exit status from /var/tmp/rpm-tmp.85331 (%check) > > > selinux perhaps? So do I have to fix something on my end? Why would it work on x86_64 and not i386? I'm totally ignorant when it comes to selinux :( From Matt_Domsch at dell.com Wed May 31 19:57:41 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 14:57:41 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531193110.GG30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> Message-ID: <20060531195741.GH30021@lists.us.dell.com> On Wed, May 31, 2006 at 02:31:11PM -0500, Matt Domsch wrote: > On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > > On 5/31/06, Matt Domsch wrote: > > >Of those expected to have worked... > > >pygame > > > > I do not understand why pygame is failing to build on i386 only. It > > does not look like it is a missing BR issue since it works fine in > > x86_64. Here is a snippit from the build log: > > [snip] > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > after reloc: Permission denied > > selinux perhaps? OK, this is definitely selinux. However, the workaround posted here: http://fedoraproject.org/wiki/Extras/MockTricks isn't working for me. The build succeeds, but semodule fails. # semodule -i mock.pp libsemanage.semanage_install_active: setfiles returned error code 1. libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! If I can get past this, I'll add this workaround to my build systems and rerun all the failed builds. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From wart at kobold.org Wed May 31 20:05:26 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 31 May 2006 13:05:26 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: References: <20060531151520.GC30021@lists.us.dell.com> Message-ID: <447DF706.6040103@kobold.org> Christopher Stone wrote: [...] > + /usr/bin/python test/image_test.py > Traceback (most recent call last): > File "test/image_test.py", line 5, in ? > import pygame, pygame.image, pygame.pkgdata > File "/usr/lib/python2.4/site-packages/pygame/__init__.py", line 75, in ? > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > after reloc: Permission denied > error: Bad exit status from /var/tmp/rpm-tmp.85331 (%check) I strongly suspect that the failures that I noticed (abe, gcompris) are related, as they failed when configure tried to run a test app that was linked with SDL. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Wed May 31 20:06:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 21:06:43 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531195741.GH30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> <20060531195741.GH30021@lists.us.dell.com> Message-ID: <1149106004.14432.1.camel@laurel.intra.city-fan.org> On Wed, 2006-05-31 at 14:57 -0500, Matt Domsch wrote: > On Wed, May 31, 2006 at 02:31:11PM -0500, Matt Domsch wrote: > > On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > > > On 5/31/06, Matt Domsch wrote: > > > >Of those expected to have worked... > > > >pygame > > > > > > I do not understand why pygame is failing to build on i386 only. It > > > does not look like it is a missing BR issue since it works fine in > > > x86_64. Here is a snippit from the build log: > > > > [snip] > > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > > after reloc: Permission denied > > > > selinux perhaps? > > OK, this is definitely selinux. However, the workaround posted here: > http://fedoraproject.org/wiki/Extras/MockTricks > > isn't working for me. The build succeeds, but semodule fails. > > # semodule -i mock.pp > libsemanage.semanage_install_active: setfiles returned error code 1. > libsemanage.semanage_install_active: setfiles returned error code 1. > semodule: Failed! Is your host system also running rawhide? Someone just posted a very similar-looking issue on fedora-selinux-list. http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00258.html Paul. From bugs.michael at gmx.net Wed May 31 20:38:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 31 May 2006 22:38:29 +0200 Subject: Summary from last weeks FESCo meeting In-Reply-To: <1149101392.2313.25.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> Message-ID: <20060531223829.43fb77dc.bugs.michael@gmx.net> On Wed, 31 May 2006 20:49:52 +0200, Thorsten Leemhuis wrote: > Am Mittwoch, den 31.05.2006, 20:31 +0200 schrieb Michael Schwendt: > > On Wed, 31 May 2006 19:36:38 +0200, Thorsten Leemhuis wrote: > > > > > * scop> | nirik, I assume that buildsys checks md5sums from the > > > "sources" file for everything in lookaside cache > > > * that wrong -> the sums are not checked (that has problems when > > > upstream servers are down or rearrange their layout or ...) and we have > > > modified tarballs (mp3 stuff removed) > > > > scop is right. The buildsys runs "make srpm" which in turn fetches the > > md5 sums from the "sources" file and only succeeds in downloading > > tarballs from the lookaside cache if they match the md5 sums. You > > cannot simply replace a tarball in the lookaside cache, because when > > its md5 sum differs, you need to update also the "sources" file. > > Ohh, sorry, yes, that was a bit misleading. The problem simply is: who > checks that the md5 sums stored in CVS are fine / those from upstream? > Nobody. I can upload a new version of package "foo" at any time and > include a rootkit in the tarball I upload. No one would notice. *sigh* I see you've put that old topic onto your plate. Have fun with it! ;) No, really, it's has to do with "level of trust". You cannot open the gates (for almost everyone to enter) and at the same time lock them. In the past I've pointed this out several times both internally and in the public. The system where stock contributors sponsor the membership and access of new contributors is not bullet-proof. Even if we required all sponsors to verify each and every CVS commit and upload done by their sponsored contributors, weaknesses would remain. Because for instance, you could argue that the sometimes huge tarballs are not checked painstakingly by any packager prior to using them in a package. Or software, which targets only a marginal group, possibly is not checked by any upstream community at all. [The single upstream developer might become hostile eventually. :)] Some contributors are both upstream and packager at the same time. The chain is as weak as its weakest link. You may be able to protect key areas, key infrastructure, and key packages with special access privilege requirements. But you cannot protect everything from the ground up without putting up too many hurdles which would reduce productivity. Further, it is a bold venture for anyone to work on acquiring access through sponsorship with the uncertainty whether really nobody is watching at the time it is tried to do something nasty. From mpeters at mac.com Wed May 31 21:26:30 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 31 May 2006 14:26:30 -0700 Subject: Summary from last weeks FESCo meeting In-Reply-To: <20060531185304.GA2462@free.fr> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531185304.GA2462@free.fr> Message-ID: <1149110790.11032.32.camel@atlantis.mpeters.local> On Wed, 2006-05-31 at 20:53 +0200, Patrice Dumas wrote: > > Ohh, sorry, yes, that was a bit misleading. The problem simply is: who > > checks that the md5 sums stored in CVS are fine / those from upstream? > > Nobody. I can upload a new version of package "foo" at any time and > > include a rootkit in the tarball I upload. No one would notice. > > Anybody could notice that the source file has changed and could verify that > the md5sum matches upstream. I don't think that anybody does, however > (I don't ;)... If the URL is full path, such a check could be scripted - though some checks would need to be manual. Probably not at build time, but a periodic audit. Such a check could also catch cases where upstream does something dirty and changes the src tarball without versioning - happened in one package I reviewed during the review process. From Matt_Domsch at dell.com Wed May 31 21:38:21 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 16:38:21 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531195741.GH30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> <20060531195741.GH30021@lists.us.dell.com> Message-ID: <20060531213821.GI30021@lists.us.dell.com> On Wed, May 31, 2006 at 02:57:41PM -0500, Matt Domsch wrote: > OK, this is definitely selinux. However, the workaround posted here: > http://fedoraproject.org/wiki/Extras/MockTricks > > isn't working for me. The build succeeds, but semodule fails. > > # semodule -i mock.pp > libsemanage.semanage_install_active: setfiles returned error code 1. > libsemanage.semanage_install_active: setfiles returned error code 1. > semodule: Failed! > > If I can get past this, I'll add this workaround to my build > systems and rerun all the failed builds. This worked for me now on my FC5 build systems, and for various reasons I've got selinux disabled on my FC-devel build systems, so I'm good now. I've started rebuilding all the previously-failed packages; results tomorrow. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com