From j.w.r.degoede at hhs.nl Sun Oct 1 06:58:58 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 01 Oct 2006 08:58:58 +0200 Subject: When does FE-6 / devel branch happen? Message-ID: <451F6732.6050509@hhs.nl> Hi all, I would like to know when the FE-6 / devel branch happens. Can / will an announcement be send to the list when this happens? I'm asking because I've got a couple of package updates queued which I don't want to put in FE-6: -imlib2-1.3.0 ABI compatible with 1.2.2 but uses gcc's visibility attribute and thus could break nasty users who use functions not defined in the public header files -ogre-1.2.3 ipdate to 1.2.2 but upstream doesn't understand / cares about C++ abi issues thus even a minor release breaks the ABI (and the soname) Thanks & Regards, Hans From fedora at leemhuis.info Sun Oct 1 07:34:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Oct 2006 09:34:05 +0200 Subject: When does FE-6 / devel branch happen? In-Reply-To: <451F6732.6050509@hhs.nl> References: <451F6732.6050509@hhs.nl> Message-ID: <451F6F6D.8080806@leemhuis.info> Hans de Goede schrieb: > I would like to know when the FE-6 / devel branch happens. Can / will an > announcement be send to the list when this happens? Jeremy did this in the past often two or three days before FC was released (IIRC) (in other words: when FC is ready and pushed out to the mirrors so he has time for things like this again). I assume it will be similar this time. CU thl From paul at city-fan.org Sun Oct 1 09:07:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 01 Oct 2006 10:07:27 +0100 Subject: list of not rebuild arch packages where needs.rebuild was removed In-Reply-To: <451E38C8.9060704@leemhuis.info> References: <451E38C8.9060704@leemhuis.info> Message-ID: <1159693653.14816.8.camel@metropolis.intra.city-fan.org> On Sat, 2006-09-30 at 11:28 +0200, Thorsten Leemhuis wrote: > Hi, > > I just ran my scripts again. It seems there are sill some arch specific > packages that were not rebuild, but needs.rebuild was removed. See this > list: ... > > paul_AT_city-fan.org libpng10 1.0.20-3.fc6 ... > Is there any good reason why these packages were not rebuild? The stated goals of the rebuild are: * New toolset feature to speed up dynamic lib linking by ~50%. * Get all packages built with the new and reduced set of packages installed in the default mock buildroots. * Make sure all packagers/contributors are still around just like we did during the mass rebuild for FC5. libpng10 was built on August 2nd, which was after the buildsystem was switched to the minimal buildroots, and the new toolset features were available long before that, so that covers the first two points. My commit log message for the removal of needs.rebuild was: "built earlier this month, doesn't need rebuilding" I guess that demonstrates that I'm still around. Now I *could* bump the EVR and rebuild this package, but it seems rather pointless to me. Paul. From fedora at leemhuis.info Sun Oct 1 11:54:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Oct 2006 13:54:08 +0200 Subject: list of not rebuild arch packages where needs.rebuild was removed In-Reply-To: <1159693653.14816.8.camel@metropolis.intra.city-fan.org> References: <451E38C8.9060704@leemhuis.info> <1159693653.14816.8.camel@metropolis.intra.city-fan.org> Message-ID: <451FAC60.5080304@leemhuis.info> Paul Howarth schrieb: > On Sat, 2006-09-30 at 11:28 +0200, Thorsten Leemhuis wrote: >> I just ran my scripts again. It seems there are sill some arch specific >> packages that were not rebuild, but needs.rebuild was removed. See this >> list: > ... >>> paul_AT_city-fan.org libpng10 1.0.20-3.fc6 > ... >> Is there any good reason why these packages were not rebuild? > The stated goals of the rebuild are: [...] > Now I *could* bump the EVR and rebuild this package, but it seems rather > pointless to me. Please rebuild it. tia. CU thl From fedora at leemhuis.info Sun Oct 1 12:04:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Oct 2006 14:04:58 +0200 Subject: list of not rebuild arch packages where needs.rebuild was removed In-Reply-To: <451FAC60.5080304@leemhuis.info> References: <451E38C8.9060704@leemhuis.info> <1159693653.14816.8.camel@metropolis.intra.city-fan.org> <451FAC60.5080304@leemhuis.info> Message-ID: <451FAEEA.8030105@leemhuis.info> Thorsten Leemhuis schrieb: > > Paul Howarth schrieb: >> On Sat, 2006-09-30 at 11:28 +0200, Thorsten Leemhuis wrote: >>> I just ran my scripts again. It seems there are sill some arch specific >>> packages that were not rebuild, but needs.rebuild was removed. See this >>> list: >> ... >>>> paul_AT_city-fan.org libpng10 1.0.20-3.fc6 >> ... >>> Is there any good reason why these packages were not rebuild? >> The stated goals of the rebuild are: > [...] >> Now I *could* bump the EVR and rebuild this package, but it seems rather >> pointless to me. > > Please rebuild it. tia. > BTW, I could give reasons for it. But most can be found in the list-archives around the date when we did the the mass-rebuild for FC5. The biggest one that now: We waited for a "go" from Core and started when binutils and other changes were considers stable. That was not the case in early August iirc. CU thl From buildsys at fedoraproject.org Sun Oct 1 17:10:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 1 Oct 2006 13:10:44 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-01 Message-ID: <20061001171044.434F915212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 20 anjuta-gdl-0.6.1-5.fc6 brandy-1.0.19-4.fc6 evolution-bogofilter-0.2.0-3.fc6 hamlib-1.2.5-3.fc6 ksensors-0.7.3-7.fc6 ktrack-0.3.0-15.rc1.fc6 lesstif-0.95.0-10.fc6 libcddb-1.2.2-1.fc6 libdsk-1.1.9-2.fc6 libpng10-1.0.20-4.fc6 linux-libertine-fonts-2.2.0-1.fc6 newsx-1.6-5.fc6 perl-Alien-wxWidgets-0.21-3.fc6 perl-Image-Info-1.23-1.fc6 sshfp-1.1.0-1.fc6 telepathy-butterfly-0.1.0-1.fc6 telepathy-filesystem-0.0.1-1.fc6 telepathy-gabble-0.3.7-1.fc6 tor-0.1.1.23-5.fc6 twinkle-0.8.1-2.fc6 Packages built and released for Fedora Extras 5: 7 evolution-bogofilter-0.2.0-3.fc5 hamlib-1.2.5-3.fc5 ksensors-0.7.3-7.fc5 ktrack-0.3.0-15.rc1.fc5 libcddb-1.2.2-1.fc5 perl-Alien-wxWidgets-0.21-3.fc5 perl-Image-Info-1.23-1.fc5 Packages built and released for Fedora Extras 4: 3 hamlib-1.2.5-3.fc4 ktrack-0.3.0-15.rc1.fc4 perl-Image-Info-1.23-1.fc4 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 Sun Oct 1 17:11:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 1 Oct 2006 13:11:15 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-01 Message-ID: <20061001171115.412D915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): audit FC5-updates > FC6 (0:1.2.7-4.fc5 > 0:1.2.7-2) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) andreas.bierfert AT lowlatency.de: dillo FE3 > FE5 (0:0.8.6-2.fc3 > 0:0.8.6-1.fc5) FE4 > FE5 (0:0.8.6-2.fc4 > 0:0.8.6-1.fc5) chabotc AT xs4all.nl: libtorrent FE4 > FE6 (0:0.10.2-2.fc4 > 0:0.10.2-1.fc6) FE5 > FE6 (0:0.10.2-2.fc5 > 0:0.10.2-1.fc6) gauret AT free.fr: amarok FE5 > FE6 (0:1.4.3-3.fc5 > 0:1.4.1-3.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- amarok: gauret AT free.fr FE5 > FE6 (0:1.4.3-3.fc5 > 0:1.4.1-3.fc6) audit: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.2.7-4.fc5 > 0:1.2.7-2) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dillo: andreas.bierfert AT lowlatency.de FE3 > FE5 (0:0.8.6-2.fc3 > 0:0.8.6-1.fc5) FE4 > FE5 (0:0.8.6-2.fc4 > 0:0.8.6-1.fc5) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) libtorrent: chabotc AT xs4all.nl FE4 > FE6 (0:0.10.2-2.fc4 > 0:0.10.2-1.fc6) FE5 > FE6 (0:0.10.2-2.fc5 > 0:0.10.2-1.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From ville.skytta at iki.fi Sun Oct 1 17:12:49 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 01 Oct 2006 20:12:49 +0300 Subject: Remaining FE6 cleanups Message-ID: <1159722769.28809.48.camel@viper.local> The remaining FE6 package repository cleanups are planned for Wednesday 4th Oct evening (UTC +3): - Removal of orphaned packages in the repository, if any. - Removal of packages with broken dependencies. Sometime at end of this week, hopefully before CVS is branched for FC-6, the CVS devel branch of orphaned packages will be cleaned up and marked with dead.package. There's a bunch of newly orphaned packages as of today which haven't been removed from the repository nor are in Extras/OrphanedPackages page in Wiki yet. Given that this happened so close to when things were supposed to be ready for FC6 and that their removal would break quite a few packages, some alternatives to just removing them are being discussed - more info about that later. But these packages are looking for a new maintainer anyway (effectively since two weeks ago): aspell-mi buildbot deskbar-applet doctorj duplicity fltk freeglut fyre gdk-pixbuf gnofract4d gnome-password-generator gnome-themes-extras gurlchecker leafpad libedit lostirc lua pam_mount pam_mysql pam_script perl-Chart perl-Net-SCP perl-Net-SSH perl-String-ShellQuote perl-XML-XQL prozilla putty python-cvstoys screem From buildsys at fedoraproject.org Sun Oct 1 17:49:22 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 01 Oct 2006 17:49:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-01 Message-ID: <20061001174922.20322.9561@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (16 days) plague - 0.4.4.1-2.fc3.noarch (16 days) plague - 0.4.4.1-2.fc4.noarch (16 days) plague - 0.4.4.1-2.fc4.noarch (16 days) plague - 0.4.4.1-2.fc4.noarch (16 days) gauret AT free.fr amarok - 1.4.1-3.fc6.i386 (66 days) amarok - 1.4.1-3.fc6.ppc (66 days) amarok - 1.4.1-3.fc6.x86_64 (66 days) showimg-pgsql - 0.9.5-7.fc4.i386 (19 days) showimg-pgsql - 0.9.5-7.fc4.ppc (19 days) showimg-pgsql - 0.9.5-7.fc4.x86_64 (19 days) j.w.r.degoede AT hhs.nl tremulous - 1.1.0-2.fc5.i386 (19 days) tremulous - 1.1.0-2.fc5.ppc (19 days) tremulous - 1.1.0-2.fc5.x86_64 (19 days) mdehaan AT redhat.com koan - 0.1.1-8.fc6.noarch (3 days) raven AT pmail.pl gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.i386 (16 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.ppc (16 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.x86_64 (16 days) ville.skytta AT iki.fi em8300 - 0.16.0-0.2.rc1.fc6.i386 (4 days) em8300 - 0.16.0-0.2.rc1.fc6.ppc (4 days) em8300 - 0.16.0-0.2.rc1.fc6.x86_64 (4 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.ppc requires libtunepimp.so.3 em8300-0.16.0-0.2.rc1.fc6.ppc requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.ppc requires gaim = 0:2.0.0-0.11.beta3.fc6 koan-0.1.1-8.fc6.noarch requires syslinux Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.x86_64 requires libtunepimp.so.3()(64bit) em8300-0.16.0-0.2.rc1.fc6.x86_64 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.x86_64 requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.i386 requires libtunepimp.so.3 em8300-0.16.0-0.2.rc1.fc6.i386 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.i386 requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.ppc requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.x86_64 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.i386 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.ppc requires libpqxx-2.6.6.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.x86_64 requires libpqxx-2.6.6.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.i386 requires libpqxx-2.6.6.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From j.w.r.degoede at hhs.nl Sun Oct 1 18:41:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 01 Oct 2006 20:41:18 +0200 Subject: Remaining FE6 cleanups In-Reply-To: <1159722769.28809.48.camel@viper.local> References: <1159722769.28809.48.camel@viper.local> Message-ID: <45200BCE.7010904@hhs.nl> Ville Skytt? wrote: > The remaining FE6 package repository cleanups are planned for Wednesday > 4th Oct evening (UTC +3): > > - Removal of orphaned packages in the repository, if any. > > - Removal of packages with broken dependencies. > > Sometime at end of this week, hopefully before CVS is branched for FC-6, > the CVS devel branch of orphaned packages will be cleaned up and marked > with dead.package. > > There's a bunch of newly orphaned packages as of today which haven't > been removed from the repository nor are in Extras/OrphanedPackages page > in Wiki yet. Given that this happened so close to when things were > supposed to be ready for FC6 and that their removal would break quite a > few packages, some alternatives to just removing them are being > discussed - more info about that later. But these packages are looking > for a new maintainer anyway (effectively since two weeks ago): > > aspell-mi > buildbot > deskbar-applet > doctorj > duplicity > fltk > freeglut > fyre > gdk-pixbuf > gnofract4d > gnome-password-generator > gnome-themes-extras > gurlchecker > leafpad > libedit > lostirc > lua > pam_mount > pam_mysql > pam_script > perl-Chart > perl-Net-SCP > perl-Net-SSH > perl-String-ShellQuote > perl-XML-XQL > prozilla > putty > python-cvstoys > screem > > I would like to volunteer myself hereby as maintainer for freeglut and lua as those are both used by quite a few games and I think one or more of my 70 + packages depend on them. So I'll wait till tomorrow morning (gmt + 1) for any other interested parties to come forward and if no one has yelled hard by then I'll modify owners.list to take ownership. I see they were alreayd rebuild by Michael before he orphaned them, and neither of them has nay open bugs, so it looks like modifying owners.list is all thats needed, or am I missing something? Regards, Hans From michael at knox.net.nz Sun Oct 1 18:39:34 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 02 Oct 2006 07:39:34 +1300 Subject: Remaining FE6 cleanups In-Reply-To: <45200BCE.7010904@hhs.nl> References: <1159722769.28809.48.camel@viper.local> <45200BCE.7010904@hhs.nl> Message-ID: <45200B66.80901@knox.net.nz> Hans de Goede wrote: > I see they were alreayd rebuild by Michael before he orphaned them, and > neither of them has nay open bugs, so it looks like modifying > owners.list is all thats needed, or am I missing something? > > That is correct. All my packages were rebuilt, with one exception. gdk-pixbuf. This needs some autotools love to build in mock. Michael From drzeus-bugzilla at drzeus.cx Sun Oct 1 19:16:30 2006 From: drzeus-bugzilla at drzeus.cx (Pierre Ossman) Date: Sun, 01 Oct 2006 21:16:30 +0200 Subject: Pulse audio? In-Reply-To: <1159548763.2849.16.camel@localhost> References: <451CB6BC.8080509@fedoraproject.org> <1159543496.2597.8.camel@localhost> <451D3F05.50108@fedoraproject.org> <1159548763.2849.16.camel@localhost> Message-ID: <4520140E.30003@drzeus.cx> Toshio Kuratomi wrote: > Ah. So this is probably the root of the problem. Did you try as a > normal user again? Maybe pulseaudio leaves files strewn about after > this kind of failure (such as the pulse-sundaram directory above). I > know pulseaudio will startup for me as a normal user so that's probably > the route you want to take for initial debugging. > > In any case, if this troubleshooting doesn't fix things then you should > file a bugzilla ticket so the packager can diagnose the problems and > kick anything relevant upstream. > Well, packager and upstream happen to be the same person so that should be easy enough. ;) Rahul, please file a ticket though. I'm going on a business trip this week and without a bugzilla entry I'll most likely forget it by the time I get back. Rgds Pierre From paul at city-fan.org Sun Oct 1 19:34:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 01 Oct 2006 20:34:48 +0100 Subject: list of not rebuild arch packages where needs.rebuild was removed In-Reply-To: <451FAEEA.8030105@leemhuis.info> References: <451E38C8.9060704@leemhuis.info> <1159693653.14816.8.camel@metropolis.intra.city-fan.org> <451FAC60.5080304@leemhuis.info> <451FAEEA.8030105@leemhuis.info> Message-ID: <1159731288.14816.20.camel@metropolis.intra.city-fan.org> On Sun, 2006-10-01 at 14:04 +0200, Thorsten Leemhuis wrote: > > Thorsten Leemhuis schrieb: > > > > Paul Howarth schrieb: > >> On Sat, 2006-09-30 at 11:28 +0200, Thorsten Leemhuis wrote: > >>> I just ran my scripts again. It seems there are sill some arch specific > >>> packages that were not rebuild, but needs.rebuild was removed. See this > >>> list: > >> ... > >>>> paul_AT_city-fan.org libpng10 1.0.20-3.fc6 > >> ... > >>> Is there any good reason why these packages were not rebuild? > >> The stated goals of the rebuild are: > > [...] > >> Now I *could* bump the EVR and rebuild this package, but it seems rather > >> pointless to me. > > > > Please rebuild it. tia. > > > BTW, I could give reasons for it. But most can be found in the > list-archives around the date when we did the the mass-rebuild for FC5. > > The biggest one that now: We waited for a "go" from Core and started > when binutils and other changes were considers stable. That was not the > case in early August iirc. OK, bumped and rebuilt. Paul. From rob at choralone.org Sun Oct 1 20:03:58 2006 From: rob at choralone.org (Rob Andrews) Date: Sun, 1 Oct 2006 21:03:58 +0100 Subject: Remaining FE6 cleanups In-Reply-To: <1159722769.28809.48.camel@viper.local> References: <1159722769.28809.48.camel@viper.local> Message-ID: <20061001200356.GA3843@aphasia.badger.choralone.org> On 01-Oct-2006 18:12.49 (BST), Ville Skytt? wrote: > But these packages are looking > for a new maintainer anyway (effectively since two weeks ago): [snip] > gnome-themes-extras I'd be happy to maintain this package, not least because I use it. Problem is, I haven't packaged anything for Extras before, so I haven't been sponsored. I've been packaging things with RPM for a few years now, and I'm familiar with the packaging guidelines. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From bugs.michael at gmx.net Sun Oct 1 21:10:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 1 Oct 2006 23:10:32 +0200 Subject: File conflicts in Fedora Extras Development Message-ID: <20061001231032.f6103c97.bugs.michael@gmx.net> File conflicts have been verified automatically based on MD5 checksum information on the RPM header. leafnode-1.11.5-1.fc6.i386.rpm File conflict with: /usr/bin/newsq File conflict with: /usr/share/man/man1/newsq.1.gz => Package conflicts with: newsx - 1.6-5.fc6.i386 newsx-1.6-5.fc6.i386.rpm File conflict with: /usr/bin/newsq File conflict with: /usr/share/man/man1/newsq.1.gz => Package conflicts with: leafnode - 1.11.5-1.fc6.i386 planet-2.0-1.noarch.rpm File conflict with: /usr/bin/planet => Package conflicts with: plt-scheme - 352-2.fc6.i386 kmenu-gnome-0.6-4.fc6.noarch.rpm File conflict with: /usr/share/desktop-directories/kde-games-kids.directory => Package conflicts with: kdebase - 6:3.5.4-9.fc6.i386 enemies-of-carlotta-1.2.2-2.fc6.noarch.rpm File conflict with: /usr/share/man/fr/man1/enemies-of-carlotta.1.gz => Package conflicts with: man-pages-fr - 2.39-4.fc6.noarch pdftohtml-0.36-8.fc6.i386.rpm File conflict with: /usr/bin/pdftohtml => Package conflicts with: poppler-utils - 0.5.4-1.fc6.i386 geomview-1.8.2-0.20.rc8.fc6.i386.rpm File conflict with: /usr/share/man/man1/sweep.1.gz => Package conflicts with: lam - 2:7.1.2-3.fc6.i386 uw-imap-2006a-1.fc6.i386.rpm File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz => Package conflicts with: cyrus-imapd - 2.3.7-3.fc6.i386 QuantLib-doc-0.3.13-4.fc6.i386.rpm File conflict with: /usr/share/man/man3/err.3.gz File conflict with: /usr/share/man/man3/y0.3.gz => Package conflicts with: man-pages - 2.39-5.noarch cyrus-imapd-2.3.7-3.fc6.i386.rpm File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz => Package conflicts with: uw-imap - 2006a-1.fc6.i386 blackbox-0.70.1-5.fc6.i386.rpm File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot => Package conflicts with: hackedbox - 0.8.4-7.fc6.i386 hackedbox-0.8.4-7.fc6.i386.rpm File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot => Package conflicts with: blackbox - 0.70.1-5.fc6.i386 From bugs.michael at gmx.net Sun Oct 1 21:11:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 1 Oct 2006 23:11:55 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20061001231032.f6103c97.bugs.michael@gmx.net> References: <20061001231032.f6103c97.bugs.michael@gmx.net> Message-ID: <20061001231155.16cdf4a3.bugs.michael@gmx.net> In addition to the posted list, I've REMOVED the following packages from Fedora Extras "development". They will be gone with next push: python-astng-0.16.0-0.fc6.noarch.rpm => %changelog mentions rename: python-logilab-astng - 0.16.1-2.fc6.noarch rekall-common-2.4.0-4.fc5.i386.rpm => All file names in this package are found in the repository elsewhere! => Package conflicts with: rekall - 2.4.3-4.fc6.i386 => %changelog says it's obsolete rekall-runtime-2.4.0-4.fc5.i386.rpm => %changelog says it's obsolete From jamatos at fc.up.pt Mon Oct 2 08:18:26 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Mon, 2 Oct 2006 09:18:26 +0100 Subject: Remaining FE6 cleanups In-Reply-To: <1159722769.28809.48.camel@viper.local> References: <1159722769.28809.48.camel@viper.local> Message-ID: <200610020918.26994.jamatos@fc.up.pt> On Sunday 01 October 2006 18:12, Ville Skytt? wrote: > The remaining FE6 package repository cleanups are planned for Wednesday > 4th Oct evening (UTC +3): > > - Removal of orphaned packages in the repository, if any. > > - Removal of packages with broken dependencies. > > Sometime at end of this week, hopefully before CVS is branched for FC-6, > the CVS devel branch of orphaned packages will be cleaned up and marked > with dead.package. > > There's a bunch of newly orphaned packages as of today which haven't > been removed from the repository nor are in Extras/OrphanedPackages page > in Wiki yet. Given that this happened so close to when things were > supposed to be ready for FC6 and that their removal would break quite a > few packages, some alternatives to just removing them are being > discussed - more info about that later. But these packages are looking > for a new maintainer anyway (effectively since two weeks ago): I am interesting in maintaining: > fltk -- Jos? Ab?lio From fedora at camperquake.de Mon Oct 2 08:36:23 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 02 Oct 2006 10:36:23 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20061001231032.f6103c97.bugs.michael@gmx.net> References: <20061001231032.f6103c97.bugs.michael@gmx.net> Message-ID: <4520CF87.5060402@camperquake.de> Michael Schwendt schrieb: > File conflicts have been verified automatically based on MD5 checksum > information on the RPM header. > enemies-of-carlotta-1.2.2-2.fc6.noarch.rpm > File conflict with: /usr/share/man/fr/man1/enemies-of-carlotta.1.gz > => Package conflicts with: man-pages-fr - 2.39-4.fc6.noarch What the heck. The way I see it m-p-f conflicts with e-o-c, not the other way around. I'll file a bug against m-p-f. From fedora at leemhuis.info Mon Oct 2 11:46:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 02 Oct 2006 13:46:44 +0200 Subject: rebuilt for unwind info generation, broken in gcc-4.1.1-21 Message-ID: <4520FC24.4060402@leemhuis.info> Hi all! Guys watching the rawhide report will notice that there are a lot of packages listed today that have a Changelog entry which lists [...] - rebuilt for unwind info generation, broken in gcc-4.1.1-21 [...] We probably need to rebuild some packages in Extras, too. FESCo currently discusses when/how to do that. Some background: It looks like gcc 4.1.1-21 introduced a bug that wasn't fixed until gcc 4.1.1-26, so there's a window from Sept. 8 until Sept. 26 within which any binary package would have been built with the bad compiler. So only those packages build in the above timeframe need another rebuild in devel. It currently looks like we'll use a script that increases release in CVS, commits the changes and queues the build for all of those. But feel free to build your packages ahead of time (e.g. now) yourself to save the script and FESCo some work. tia! More details to follow. CU thl From kevin-fedora-extras at scrye.com Mon Oct 2 16:21:45 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 02 Oct 2006 10:21:45 -0600 (MDT) Subject: Xfce 4.4rc1 call for testing Message-ID: <20061002.102145.802043680.kevin@scrye.com> Myself and Christoph (The xfce plugins maintainer for extras) have been building and testing Xfce4.4rc1 since it's release (and the betas before it). Things are looking all good with our limited testing now. I think we have addressed everything such as: - Some plugins are no longer available in 4.4 as their functionality has been pulled into core Xfce packages, so we have added the required Obsoletes/Provides to allow smooth upgrades with those installed. - Some packages have changed name (xfcalendar is now orage, etc), and they should be handled correctly. - Lots of cleanups of the packages. So, We would like to invite folks to do some more testing on the packages. If you have never used Xfce, you might take this as a fine chance to take a look at it. It's a lovely quick desktop env. In particular I would like to hear from people who already have the 4.3.2 packages installed and upgrade to the 4.4 packages. I'm not sure if we are going to try and push things in this week before fc6 is released, or wait until after fc6 and push them into devel and then push them into fc6 later. Thoughts on that would be welcome. For your /etc/yum.repos.d/xfce44.repo file: --cut-- [xfce44beta] name=Xfce 4.4 rc1 baseurl=http://www.scrye.com/xfce-4.4rc1/development/RPMS enabled=1 gpgcheck=0 --cut-- Thanks for any feedback and testing you can provide! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Mon Oct 2 19:02:51 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Oct 2006 15:02:51 -0400 Subject: compiz manager In-Reply-To: <4517C16A.7090503@fedoraproject.org> References: <4517C16A.7090503@fedoraproject.org> Message-ID: <1159815771.16086.7.camel@xavier.boston.redhat.com> On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: > Hi > > > Originated in Mandriva and picked up OpenSUSE. > http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ > > Would be nice to have this in Fedora Extras. Note that compiz-manager requires cgwd (compiz generic window decorator, iirc), which in turn requires the compiz-quinn (now known as beryl) compiz fork, which replaces the compiz we've got in FC6. And spec file at the above link is a holy mess, check out this peach of an excerpt: %build tar jxvf /usr/src/packages/SOURCES/cgwd-themes.tar.bz2 Anyone interested in packaging this up should probably look at the specs from here instead, which are tailored for Fedora to begin with (and don't do incredibly stupid things like that tar command): http://www.illawarra.org/linux/index.php?id=howto Playing around with it a bit myself right now... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon Oct 2 19:06:20 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Oct 2006 00:36:20 +0530 Subject: compiz manager In-Reply-To: <1159815771.16086.7.camel@xavier.boston.redhat.com> References: <4517C16A.7090503@fedoraproject.org> <1159815771.16086.7.camel@xavier.boston.redhat.com> Message-ID: <4521632C.4010109@fedoraproject.org> Jarod Wilson wrote: > On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: >> Hi >> >> >> Originated in Mandriva and picked up OpenSUSE. >> http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ >> >> Would be nice to have this in Fedora Extras. > > Note that compiz-manager requires cgwd (compiz generic window decorator, > iirc), which in turn requires the compiz-quinn (now known as beryl) > compiz fork, which replaces the compiz we've got in FC6. I believe it can be installed in parallel which is under review at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192434 And spec file > at the above link is a holy mess, check out this peach of an excerpt: > > %build > tar jxvf /usr/src/packages/SOURCES/cgwd-themes.tar.bz2 Just pointed out the link as a source which talks about what it is. Not suggesting it as a spec source. Rahul From fedora at leemhuis.info Mon Oct 2 20:02:31 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 02 Oct 2006 22:02:31 +0200 Subject: another semi-mass-rebuild (Was: Re: rebuilt for unwind info generation, broken in gcc-4.1.1-21) In-Reply-To: <4520FC24.4060402@leemhuis.info> References: <4520FC24.4060402@leemhuis.info> Message-ID: <45217057.70203@leemhuis.info> Thorsten Leemhuis schrieb: > Guys watching the rawhide report will notice that there are a lot of > packages listed today that have a Changelog entry which lists > > [...] > - rebuilt for unwind info generation, broken in gcc-4.1.1-21 > [...] > > We probably need to rebuild some packages in Extras, too. FESCo > currently discusses when/how to do that. > > Some background: It looks like gcc 4.1.1-21 introduced a bug that wasn't > fixed until gcc 4.1.1-26, so there's a window from Sept. 8 until Sept. > 26 within which any binary package would have been built with the bad > compiler. Some additional details jeremy provided: Essentially, the result is that backtraces in gdb won't (necessarily) work and that any app which calls backtrace() is likely to segfault. There are a few other potential ways that things can go wrong, but suffice to say that, yes, binary packages built in the window will need to be rebuilt :-/ > So only those packages build in the above timeframe need another rebuild > in devel. It currently looks like we'll use a script that increases > release in CVS, commits the changes and queues the build for all of > those. But feel free to build your packages ahead of time (e.g. now) > yourself to save the script and FESCo some work. tia! > > More details to follow. Well, here they are. The current plan is: - do another mass rebuild for all those packages that might be affected. That means: all arch packages that were build from Sept. 8 until Sept. 26 -/+ some hours for safety - let a script ( https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00777.html ?) increase release, commit, tag and queue the build of all effected packages. Someone from FESCo (probably c4chris) will handle that. - we start on Wednesdays evening (CEST) - we hereby encourage maintainers to queue the rebuilds of their stuff of their own before Wednesdays evening Sorry for the trouble. CU thl From buildsys at fedoraproject.org Mon Oct 2 20:24:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Oct 2006 16:24:54 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-02 Message-ID: <20061002202454.2E91D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 36 Inventor-2.1.5-23.fc6 amarok-1.4.3-4.fc6 deskbar-applet-2.16.0-1.fc6 dvb-apps-1.1.1-7.fc6 em8300-0.16.0-0.3.rc1.fc6 factory-2.0.5-10.fc6 fwbackups-1.42.1-2.fc6 geomview-1.8.2-0.21.rc9.fc6 gnome-python2-gda-2.14.2-2.fc6 inotify-tools-2.5-1.fc6 kannel-1.4.1-1.fc6 kbackup-0.5.1-2.fc6 kdeartwork-extras-3.5.4-5.fc6 kid3-0.7-4.fc6 kita-0.177.3-10.fc6 lft-2.5-6.fc6 libassuan-0.9.0-3.fc6 libfac-2.0.5-7.fc6 libglade-0.17-19.fc6 libksba-1.0.0-1.fc6.1 libtunepimp-0.5.2-1.fc6 lyx-1.4.3-3.fc6 mach-0.9.0-3.fc6 maxima-5.10.0-5.fc6 netlabel_tools-0.17-2.fc6 openct-0.6.9-2.fc6 pdftohtml-0.36-9.fc6 perl-Wx-0.57-2.fc6 php-pear-Console-Getargs-1.3.1-1.fc6 php-pear-PHP-CompatInfo-1.4.0-1.fc6.1 piklab-0.12.0-3.fc6 pl-5.6.20-1.fc6 rpmdevtools-5.2-1.fc6 telepathy-butterfly-0.1.1-1.fc6 xmlrpc-c-1.06.05-2.fc6 xplanet-1.2.0-2.1.fc6 Packages built and released for Fedora Extras 5: 19 Inventor-2.1.5-23.fc5 bsd-games-2.17-11.fc5 geomview-1.8.2-0.21.rc9.fc5 inotify-tools-2.5-1.fc5 kbackup-0.5.1-1.fc5 kita-0.177.3-10.fc5 lyx-1.4.3-3.fc5 maxima-5.10.0-4.fc5 pdftohtml-0.36-9.fc5 php-pear-Console-Getargs-1.3.1-1.fc5.1 php-pear-PHP-CompatInfo-1.4.0-1.fc5 piklab-0.12.0-3.fc5 pl-5.6.20-1.fc5 rpmdevtools-5.2-1.fc5 telepathy-butterfly-0.1.1-1.fc5 telepathy-filesystem-0.0.1-1.fc5 telepathy-gabble-0.3.7-1.fc5 twinkle-0.8.1-2.fc5 xmlrpc-c-1.06.05-2.fc5 Packages built and released for Fedora Extras 4: 2 Inventor-2.1.5-23.fc4 lyx-1.4.3-3.fc4 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 Mon Oct 2 20:25:22 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Oct 2006 16:25:22 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-02 Message-ID: <20061002202522.B41A415212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) andreas.bierfert AT lowlatency.de: dillo FE3 > FE5 (0:0.8.6-2.fc3 > 0:0.8.6-1.fc5) FE4 > FE5 (0:0.8.6-2.fc4 > 0:0.8.6-1.fc5) chabotc AT xs4all.nl: libtorrent FE4 > FE6 (0:0.10.2-2.fc4 > 0:0.10.2-1.fc6) FE5 > FE6 (0:0.10.2-2.fc5 > 0:0.10.2-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dillo: andreas.bierfert AT lowlatency.de FE3 > FE5 (0:0.8.6-2.fc3 > 0:0.8.6-1.fc5) FE4 > FE5 (0:0.8.6-2.fc4 > 0:0.8.6-1.fc5) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) libtorrent: chabotc AT xs4all.nl FE4 > FE6 (0:0.10.2-2.fc4 > 0:0.10.2-1.fc6) FE5 > FE6 (0:0.10.2-2.fc5 > 0:0.10.2-1.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From buildsys at fedoraproject.org Mon Oct 2 21:07:42 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 02 Oct 2006 21:07:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-02 Message-ID: <20061002210742.27554.57460@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (2 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (2 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (2 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (17 days) plague - 0.4.4.1-2.fc3.noarch (17 days) plague - 0.4.4.1-2.fc4.noarch (17 days) plague - 0.4.4.1-2.fc4.noarch (17 days) plague - 0.4.4.1-2.fc4.noarch (17 days) gauret AT free.fr amarok - 1.4.1-3.fc6.x86_64 (67 days) showimg-pgsql - 0.9.5-7.fc4.i386 (20 days) showimg-pgsql - 0.9.5-7.fc4.ppc (20 days) showimg-pgsql - 0.9.5-7.fc4.x86_64 (20 days) j.w.r.degoede AT hhs.nl tremulous - 1.1.0-2.fc5.i386 (20 days) tremulous - 1.1.0-2.fc5.ppc (20 days) tremulous - 1.1.0-2.fc5.x86_64 (20 days) mdehaan AT redhat.com koan - 0.1.1-8.fc6.noarch (4 days) raven AT pmail.pl gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.i386 (17 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.ppc (17 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.x86_64 (17 days) rc040203 AT freenet.de InventorXt - 2.1.5-23.fc4.i386 InventorXt - 2.1.5-23.fc4.ppc InventorXt - 2.1.5-23.fc4.x86_64 ville.skytta AT iki.fi em8300 - 0.16.0-0.3.rc1.fc6.i386 em8300 - 0.16.0-0.3.rc1.fc6.ppc em8300 - 0.16.0-0.3.rc1.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- em8300-0.16.0-0.3.rc1.fc6.ppc requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.ppc requires gaim = 0:2.0.0-0.11.beta3.fc6 koan-0.1.1-8.fc6.noarch requires syslinux Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.x86_64 requires libtunepimp.so.3()(64bit) em8300-0.16.0-0.3.rc1.fc6.x86_64 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.x86_64 requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- em8300-0.16.0-0.3.rc1.fc6.i386 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.i386 requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.ppc requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.x86_64 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.i386 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- InventorXt-2.1.5-23.fc4.ppc requires /usr/bin/xmessage plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.ppc requires libpqxx-2.6.6.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- InventorXt-2.1.5-23.fc4.x86_64 requires /usr/bin/xmessage plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.x86_64 requires libpqxx-2.6.6.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- InventorXt-2.1.5-23.fc4.i386 requires /usr/bin/xmessage plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-7.fc4.i386 requires libpqxx-2.6.6.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: ville.skytta AT iki.fi package: em8300 - 0.16.0-0.3.rc1.fc6.ppc from fedora-extras-development-ppc unresolved deps: em8300-kmod >= 0:0.16.0 package: em8300 - 0.16.0-0.3.rc1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: em8300-kmod >= 0:0.16.0 package: em8300 - 0.16.0-0.3.rc1.fc6.i386 from fedora-extras-development-i386 unresolved deps: em8300-kmod >= 0:0.16.0 ====================================================================== New report for: rc040203 AT freenet.de package: InventorXt - 2.1.5-23.fc4.ppc from fedora-extras-4-ppc unresolved deps: /usr/bin/xmessage package: InventorXt - 2.1.5-23.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: /usr/bin/xmessage package: InventorXt - 2.1.5-23.fc4.i386 from fedora-extras-4-i386 unresolved deps: /usr/bin/xmessage From jwilson at redhat.com Mon Oct 2 21:12:51 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Oct 2006 17:12:51 -0400 Subject: compiz manager In-Reply-To: <4521632C.4010109@fedoraproject.org> References: <4517C16A.7090503@fedoraproject.org> <1159815771.16086.7.camel@xavier.boston.redhat.com> <4521632C.4010109@fedoraproject.org> Message-ID: <1159823571.16086.17.camel@xavier.boston.redhat.com> On Tue, 2006-10-03 at 00:36 +0530, Rahul Sundaram wrote: > Jarod Wilson wrote: > > On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: > >> Originated in Mandriva and picked up OpenSUSE. > >> http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ > >> > >> Would be nice to have this in Fedora Extras. > > > > Note that compiz-manager requires cgwd (compiz generic window decorator, > > iirc), which in turn requires the compiz-quinn (now known as beryl) > > compiz fork, which replaces the compiz we've got in FC6. > > I believe it can be installed in parallel which is under review at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192434 I could be wrong, but I don't think so. Both provide some of the same binaries, libs, include files, etc. > > And spec file > > at the above link is a holy mess, check out this peach of an excerpt: > > > > %build > > tar jxvf /usr/src/packages/SOURCES/cgwd-themes.tar.bz2 > > Just pointed out the link as a source which talks about what it is. Not > suggesting it as a spec source. Didn't say ya did, was just trying to help. :) Though the package already under review makes even more sense to look at, obviously. Didn't realize it was already in the works. /me goes off to find a sacrificial box to try this all out on... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Oct 2 21:24:25 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 02 Oct 2006 15:24:25 -0600 Subject: Yet another license question Message-ID: <45218389.6050504@cora.nwra.com> dxhdf5 package: http://www-beams.colorado.edu/dxhdf5/. No, it seems to place a burden on users of the code, but not distributors. License Copyright (c) 2004-2002, University of Colorado All rights reserved. This software is based on work supported by the National Science Foundation under Grant No. 0113907. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the University of Colorado nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. * Any publications or presentations, including but not limited to journal articles, web publications, or conference presentations or proceedings, resulting from the use of this software must include the phrase "visualizations made in part through use of the DXHDF5 package from the University of Colorado" and then must refer to I. Szczesniak, J. R. Cary, "dxhdf5: a software package for importing HDF5 physics data into OpenDX," Computer Physics Communications, vol. 164, issue 1-3, pp. 365-369, 2004. in any visual or written material associated with such publication or presentation. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From fedora-extras-list.listman at linuxnetz.de Mon Oct 2 22:44:52 2006 From: fedora-extras-list.listman at linuxnetz.de (Robert Scheck) Date: Tue, 3 Oct 2006 00:44:52 +0200 Subject: another semi-mass-rebuild (Was: Re: rebuilt for unwind info generation, broken in gcc-4.1.1-21) In-Reply-To: <45217057.70203@leemhuis.info> References: <4520FC24.4060402@leemhuis.info> <45217057.70203@leemhuis.info> Message-ID: <20061002224452.GA30351@hurricane.linuxnetz.de> Hello folks, On Mon, 02 Oct 2006, Thorsten Leemhuis wrote: > Well, here they are. The current plan is: > > - do another mass rebuild for all those packages that might be affected. > That means: all arch packages that were build from Sept. 8 until Sept. > 26 -/+ some hours for safety > - let a script ( > https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00777.html > ?) increase release, commit, tag and queue the build of all effected > packages. Someone from FESCo (probably c4chris) will handle that. > - we start on Wednesdays evening (CEST) > - we hereby encourage maintainers to queue the rebuilds of their stuff > of their own before Wednesdays evening IMHO your current plan is broken or even wrong. Please do something like for i in *debuginfo*; do rpm2cpio $i | strings | grep -E "4.1.1-2[123456]" | sort -u; done to check whether your packages were built using the buggy GCC. Because using the timeframe, there would be (many?) false-positives, e.g. mimedefang-2.57-4.fc6 17-Sep-2006 GNU C 4.1.1 20060828 (Red Hat 4.1.1-20) tcpick-0.2.1-10.fc6 10-Sep-2006 GNU C 4.1.1 20060828 (Red Hat 4.1.1-20) My solution also saves time and ressources of the build system, because two false-positives out of my seven packages seem to be very much - at least for me. Greetings, Robert From pertusus at free.fr Mon Oct 2 22:46:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Oct 2006 00:46:35 +0200 Subject: Yet another license question In-Reply-To: <45218389.6050504@cora.nwra.com> References: <45218389.6050504@cora.nwra.com> Message-ID: <20061002224635.GA2280@free.fr> On Mon, Oct 02, 2006 at 03:24:25PM -0600, Orion Poplawski wrote: > dxhdf5 package: http://www-beams.colorado.edu/dxhdf5/. No, it seems to > place a burden on users of the code, but not distributors. > > * Any publications or presentations, including but not limited to > journal articles, web publications, or conference presentations or > proceedings, resulting from the use of this software must include > the phrase "visualizations made in part through use of the DXHDF5 > package from the University of Colorado" and then must refer to > > I. Szczesniak, J. R. Cary, "dxhdf5: a software package for > importing HDF5 physics data into OpenDX," Computer Physics > Communications, vol. 164, issue 1-3, pp. 365-369, 2004. > > in any visual or written material associated with such publication > or presentation. This is like the old BSD clause. This adds restriction to use, so, in my opinion it is not free software as defined by the OSI. Many scientific packages have (or had) similar clauses, making them unfree in that sense. -- Pat From tibbs at math.uh.edu Mon Oct 2 23:53:49 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 02 Oct 2006 18:53:49 -0500 Subject: another semi-mass-rebuild In-Reply-To: <20061002224452.GA30351@hurricane.linuxnetz.de> (Robert Scheck's message of "Tue, 3 Oct 2006 00:44:52 +0200") References: <4520FC24.4060402@leemhuis.info> <45217057.70203@leemhuis.info> <20061002224452.GA30351@hurricane.linuxnetz.de> Message-ID: >>>>> "RS" == Robert Scheck writes: RS> IMHO your current plan is broken or even wrong. Please do RS> something like RS> for i in *debuginfo*; do rpm2cpio $i | strings | grep -E RS> "4.1.1-2[123456]" | sort -u; done The folks I asked indicated that it was not possible to extract the information about which release of the compiler was used, but perhaps I asked the wrong question or failed to understand the answer. - J< From jpo at di.uminho.pt Tue Oct 3 00:32:27 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 03 Oct 2006 01:32:27 +0100 Subject: another semi-mass-rebuild (Was: Re: rebuilt for unwind info generation, broken in gcc-4.1.1-21) In-Reply-To: <20061002224452.GA30351@hurricane.linuxnetz.de> References: <4520FC24.4060402@leemhuis.info> <45217057.70203@leemhuis.info> <20061002224452.GA30351@hurricane.linuxnetz.de> Message-ID: <4521AF9B.1020706@di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Scheck wrote: > Hello folks, > > On Mon, 02 Oct 2006, Thorsten Leemhuis wrote: >> Well, here they are. The current plan is: >> >> - do another mass rebuild for all those packages that might be affected. >> That means: all arch packages that were build from Sept. 8 until Sept. >> 26 -/+ some hours for safety >> - let a script ( >> https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00777.html >> ?) increase release, commit, tag and queue the build of all effected >> packages. Someone from FESCo (probably c4chris) will handle that. >> - we start on Wednesdays evening (CEST) >> - we hereby encourage maintainers to queue the rebuilds of their stuff >> of their own before Wednesdays evening > > IMHO your current plan is broken or even wrong. Please do something like > > for i in *debuginfo*; do > rpm2cpio $i | strings | grep -E "4.1.1-2[123456]" | sort -u; > done > > to check whether your packages were built using the buggy GCC. Because > using the timeframe, there would be (many?) false-positives, e.g. > > mimedefang-2.57-4.fc6 17-Sep-2006 GNU C 4.1.1 20060828 (Red Hat 4.1.1-20) > tcpick-0.2.1-10.fc6 10-Sep-2006 GNU C 4.1.1 20060828 (Red Hat 4.1.1-20) > > My solution also saves time and ressources of the build system, because two > false-positives out of my seven packages seem to be very much - at least for > me. According to this post https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00005.html the time frame should be: September, 18th to September, 26th. 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.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFIa+bl0metZG9hRsRAtawAJ9v8BmRFQAGpxMoqZl9y+c+8mw4IQCgmJwK z4rOCkp7r8DLO+xX1+CBtVI= =QeWi -----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 tcallawa at redhat.com Tue Oct 3 03:44:20 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 02 Oct 2006 22:44:20 -0500 Subject: Yet another license question In-Reply-To: <45218389.6050504@cora.nwra.com> References: <45218389.6050504@cora.nwra.com> Message-ID: <1159847060.3471.86.camel@localhost.localdomain> On Mon, 2006-10-02 at 15:24 -0600, Orion Poplawski wrote: > * Any publications or presentations, including but not limited to > journal articles, web publications, or conference presentations or > proceedings, resulting from the use of this software must include > the phrase "visualizations made in part through use of the DXHDF5 > package from the University of Colorado" and then must refer to > > I. Szczesniak, J. R. Cary, "dxhdf5: a software package for > importing HDF5 physics data into OpenDX," Computer Physics > Communications, vol. 164, issue 1-3, pp. 365-369, 2004. > > in any visual or written material associated with such publication > or presentation. This is BSD with advertising (GPL-incompatible, but free). OK for Fedora. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From kevin.kofler at chello.at Tue Oct 3 05:13:21 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 3 Oct 2006 05:13:21 +0000 (UTC) Subject: Yet another license question References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway writes: > This is BSD with advertising (GPL-incompatible, but free). OK for > Fedora. No, this is NOT the standard BSD advertising clause. The advertising clause covers DISTRIBUTION of software. This one covers USE. While I understand that the intent of this clause is just to enforce standard academic courtesy, I believe this is not anywhere near Free Software or Open Source. Restrictions on use are simply unacceptable under those guidelines. So I'd say this is NOT OK according to the licensing guidelines (which say the license should be Free Software and/or Open Source according to the FSF and/or OSI). Accidental violations by users not aware of that clause are also something to be concerned about. (As a user, I really do not expect to find this kind of licensing requirements in software I get from Fedora, and I don't think I'm the only one caught by surprise.) Kevin Kofler From rc040203 at freenet.de Tue Oct 3 05:26:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Oct 2006 07:26:32 +0200 Subject: Yet another license question In-Reply-To: References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> Message-ID: <1159853192.13363.242.camel@mccallum.corsepiu.local> On Tue, 2006-10-03 at 05:13 +0000, Kevin Kofler wrote: > Tom 'spot' Callaway writes: > > This is BSD with advertising (GPL-incompatible, but free). OK for > > Fedora. > > No, this is NOT the standard BSD advertising clause. The advertising clause > covers DISTRIBUTION of software. This one covers USE. This is the original UCB ad-clause: 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. Note: "ADVERTISING materials ... or USE ..." The FSF notes about this (http://www.gnu.org/philosophy/bsd.html): "Initially the obnoxious BSD advertising clause was used only in the Berkeley Software Distribution. That did not cause any particular problem, because including one sentence in an ad is not a great practical difficulty." So, I agree with Tom. The DXHDF5 license to me is a variant of the BSD licence. Ralf From kevin.kofler at chello.at Tue Oct 3 05:44:45 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 3 Oct 2006 05:44:45 +0000 (UTC) Subject: Yet another license question References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159853192.13363.242.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > 3. All advertising materials mentioning features or use of this software > must display the following acknowledgement: > This product includes software developed by the University of > California, Berkeley and its contributors. > > > Note: "ADVERTISING materials ... or USE ..." Well, an "advertising material mentioning use of this software" is not the same as "Any publications or presentations, including but not limited to journal articles, web publications, or conference presentations or proceedings, resulting from the use of this software". This clause is a lot more broad. It's as if LaTeX required you to quote a paper on LaTeX in each and every paper you write with it, or if the GIMP required you to quote a paper next to any picture you edit using it. While I don't have any decisive power whatsoever on Fedora, I'd really urge those who do to at least get this issue reviewed (maybe ask the FSF?) before issueing a blanket "it's OK", because I believe this to be a serious issue and a worrying precedent. Kevin Kofler From j.w.r.degoede at hhs.nl Tue Oct 3 06:11:02 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 03 Oct 2006 08:11:02 +0200 Subject: Yet another license question In-Reply-To: References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159853192.13363.242.camel@mccallum.corsepiu.local> Message-ID: <4521FEF6.500@hhs.nl> Kevin Kofler wrote: > Ralf Corsepius writes: >> 3. All advertising materials mentioning features or use of this software >> must display the following acknowledgement: >> This product includes software developed by the University of >> California, Berkeley and its contributors. >> >> >> Note: "ADVERTISING materials ... or USE ..." > > Well, an "advertising material mentioning use of this software" is not the same > as "Any publications or presentations, including but not limited to journal > articles, web publications, or conference presentations or proceedings, > resulting from the use of this software". This clause is a lot more broad. It's > as if LaTeX required you to quote a paper on LaTeX in each and every paper you > write with it, or if the GIMP required you to quote a paper next to any picture > you edit using it. > > While I don't have any decisive power whatsoever on Fedora, I'd really urge > those who do to at least get this issue reviewed (maybe ask the FSF?) before > issueing a blanket "it's OK", because I believe this to be a serious issue and > a worrying precedent. > > Kevin Kofler > +1, its unfurtonate, but this license is not free, as very clearly explained by Kevin. Perhaps upstream can be nudged into changing the license? Regards, Hans From ville.skytta at iki.fi Tue Oct 3 06:44:34 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 03 Oct 2006 09:44:34 +0300 Subject: Remaining FE6 cleanups In-Reply-To: <1159722769.28809.48.camel@viper.local> References: <1159722769.28809.48.camel@viper.local> Message-ID: <1159857874.24351.36.camel@viper.local> On Sun, 2006-10-01 at 20:12 +0300, Ville Skytt? wrote: > There's a bunch of newly orphaned packages as of today which haven't > been removed from the repository nor are in Extras/OrphanedPackages page > in Wiki yet. Given that this happened so close to when things were > supposed to be ready for FC6 and that their removal would break quite a > few packages, some alternatives to just removing them are being > discussed - more info about that later. The mentioned packages have been added to the orphaned page in Wiki, but they will not be removed before FC6 because there's too little time for others to chime in at this point. From jamatos at fc.up.pt Tue Oct 3 07:20:27 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 3 Oct 2006 08:20:27 +0100 Subject: Yet another license question In-Reply-To: <4521FEF6.500@hhs.nl> References: <45218389.6050504@cora.nwra.com> <4521FEF6.500@hhs.nl> Message-ID: <200610030820.27761.jamatos@fc.up.pt> On Tuesday 03 October 2006 07:11, Hans de Goede wrote: > +1, its unfurtonate, but this license is not free, as very clearly > explained by Kevin. I agree. It looks similar to me at least, to the non-commercial clause seen in some software. "Any publication or presentation, including but not limited to ..." Taking this seriously it means that if I am talking with someone about my work, an informal presentation, as it usually happens among scientists I would be breaking the license if I did not mention program. > Perhaps upstream can be nudged into changing the > license? There is other software that carries a similar note like this in README, or in the documentation, but asking for not ordering to. This is nicer and people do usually comply, because they have been asked and not because they have been ordered. People using the software is also aware of the reasons behind the request and in my experience is glad to cite the material used. This should be the point present to authors. > Regards, > > Hans -- Jos? Ab?lio From denis at poolshark.org Tue Oct 3 09:25:10 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 03 Oct 2006 11:25:10 +0200 Subject: awol package submitter (alsa-oss) Message-ID: <45222C76.3030606@poolshark.org> What should we do about an awol package submitter (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187706), does the existing AWOL maintainer policy apply ? I contacted the original submitter directly but no luck, and his last entry is 6 months old. I would like to request a competing package submission be allowed in this case as there seems to be a lot of interest to have this package in time for FC6, or let someone else take over the review. either way. From paul at city-fan.org Tue Oct 3 09:35:54 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 03 Oct 2006 10:35:54 +0100 Subject: awol package submitter (alsa-oss) In-Reply-To: <45222C76.3030606@poolshark.org> References: <45222C76.3030606@poolshark.org> Message-ID: <45222EFA.1090903@city-fan.org> Denis Leroy wrote: > What should we do about an awol package submitter > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187706), does the > existing AWOL maintainer policy apply ? I contacted the original > submitter directly but no luck, and his last entry is 6 months old. > > I would like to request a competing package submission be allowed in > this case as there seems to be a lot of interest to have this package in > time for FC6, or let someone else take over the review. either way. http://fedoraproject.org/wiki/Extras/Policy/StalledReviews Paul. From jwilson at redhat.com Tue Oct 3 15:54:24 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Oct 2006 11:54:24 -0400 Subject: compiz manager In-Reply-To: <1159823571.16086.17.camel@xavier.boston.redhat.com> References: <4517C16A.7090503@fedoraproject.org> <1159815771.16086.7.camel@xavier.boston.redhat.com> <4521632C.4010109@fedoraproject.org> <1159823571.16086.17.camel@xavier.boston.redhat.com> Message-ID: <1159890864.19121.2.camel@xavier.boston.redhat.com> On Mon, 2006-10-02 at 17:12 -0400, Jarod Wilson wrote: > On Tue, 2006-10-03 at 00:36 +0530, Rahul Sundaram wrote: > > Jarod Wilson wrote: > > > On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: > > >> Originated in Mandriva and picked up OpenSUSE. > > >> http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ > > >> > > >> Would be nice to have this in Fedora Extras. > > > > > > Note that compiz-manager requires cgwd (compiz generic window decorator, > > > iirc), which in turn requires the compiz-quinn (now known as beryl) > > > compiz fork, which replaces the compiz we've got in FC6. > > > > I believe it can be installed in parallel which is under review at > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192434 > > I could be wrong, but I don't think so. Both provide some of the same > binaries, libs, include files, etc. Okay, with the renamed beryl fork, I think you actually can have them installed in parallel, as all the bits are renamed, including header files, libraries, etc. > /me goes off to find a sacrificial box to try this all out on... Oy. It go boom. In different ways on 3 different systems. This was a 9/20 snap though, might have better luck with beryl 0.1.0... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dag at wieers.com Tue Oct 3 17:25:40 2006 From: dag at wieers.com (Dag Wieers) Date: Tue, 3 Oct 2006 19:25:40 +0200 (CEST) Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: <45168FA0.6080201@leemhuis.info> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> Message-ID: On Sun, 24 Sep 2006, Thorsten Leemhuis wrote: > Well, after my first more diplomatic shot I'm willing to touch more > dangerous grounds now. > > There are afaics (and *please* correct me if I'm wrong) some more big > differences: Let's correct then. > - rpmforge wants to (or does already?) build for distributions like Suse > or SLES (someone indicated that to me in private on IRC some weeks ago) We do not. We would like to if RPM had the infrastructure for it. But Red Hat is not interested. As a result you can only put 1 SPEC file in a tarball and hope that one works on your distribution (rpm -tb). However we are very interested to work together with other packagers as most of the work is identical. What's more, most of the bug-reports are identical so it makes much more sense to combine the effort for bug-tracking and package-development. (tracing patches, security problems) But now that most RPM community repositories are in control of vendors (see OpenSuSE and Fedora). There is even less interest to join forces. > There were two more in the past, I don't know if they are still valid: > > - rpmforge now and then replaced packages from the the distributions is > was build for (RHEL, Fedora Core and Extras, which i consider as a > integrated part for Fedora Core, but that's just my view); Our position is that the dependency resolve (yum, apt, smart) should provide the policy that the end-user wants. If the end-user wants to stick with a specific lftp or rsync version than yum, apt or smart should allow that. Yum finally has a protectbase plugin that allows this, although it needs more love to be more useful than it currently is. If you think about that, there are many policies an end-user may have and if you want to accomodate for this on the server-side you'd end up with a repository per package/version. So instead of splitting repositories into one that adds to base, and one that replaces base we think the end-user should be able to configure its depresolver. Of course Fedora doesn't have the issue and maybe that's why it is so hard to comprehend. > - rpmforge builds new packages often for several distributions including > those that are in "Maintenance state" (FC3, FC4 currently); Fedora > Extras is more conservative here What about RHEL2.1 and RHEL3 ? People need a decent subversion for those. If you apply your current rules to the release of RHEL2.1 or RHEL3 you'd be providing subversion 0.19 ad 0.90. Very stable and pretty useless ! What we provide does not have a warranty (and you'd be a fool to provide it) and people have to make up their own mind (and think about the consequences). Rules can't mitigate the problems and risks end-users have on a supported system. At least we provide functionality they might require if they made their own assessement. If you look past RHEL and support, you might look at CentOS. And see that a lot of points vanish. Are you going to constrict CentOS users to a world where support is king and users have to be guided into what they should do ? But that doesn't mean I recommend people to enable RPMforge and upgrade to the latest and greatest. Neither should they with Fedora Extras. Whether it replaces packages or not, there are risks involved installing 3rd party stuff. E.g. if they set up nagios 1.0 a year ago, they may wish to upgrade to 1.4 at their own pace. A repository cannot guide them. And without a way to set a policy in the depsolver they are stuck. Apt and smart are best in this regard as they can hold back updates. I've asked Seth multiple times to consider something like protectbase (or decent pinning support) but Fedora was the place to be and no such thing was useful then. If you think I'm bittered about the state of things, you bet I am :) > > The current move to build for centos, EL etc means that this > > fundemental difference should disappear. Of course, rpmforge provides > > many useful packages which couldn't move into FE/EE - it wasn't my > > intention to suggest a merger. > > Well, why not? Merge the stuff into Extras that can be there; merge the > other stuff with livna and atrpms and everybody is happy because "repo > wars" would be mostly history then. How about diversity ? We will need diversity if you apply Fedora rules to RHEL. > > What is true though is that Dag, Dries > > et al. have achieved an awful lot towards the same goals that the > > proposed EE seems to have. Hence my suggestion that it seems a shame > > not to approach these guys to say "We're hoping to expand FE to > > include packages for other distros, and since you guys are the proven > > leaaders in this field, we'd really value working with you to build up > > the infrastructure, as we are sure your knowledge and experience are > > valuable" > > Well, yeah, that might be a good idea. But note that we try to get > z00dax from http://centos.karan.org/ involved. He AFAIK is in contact > with dag and dries. I'm wondering if the wrong community is involved. To me it makes much more sense if CentOS would be involved and leading the RHEL packaging efforts. Fedora and CentOS users are a different kind (even though some live in both worlds, most do not). And even though it seems pretty easy to rebuild the FC3 stuff for RHEL4 and FC6 stuff for RHEL5, reality is much more complex if you consider that RHEL4 users are still there in 2010. I think the CentOS people have a much better understanding of what is required and what balance needs to be struck. > > I can't believe either "side" can't see such benefits. > > Yeah, but what can Fedora Extras offer them? We are heavily tight to > Core and Red Hat and that heavily limits the things we can offer. That's exactly the reason why I think Fedora is not the right place to discuss RHEL packages. Different worlds, different needs, different policies, different people. > They of course are always invited to join us and I'd try my best to give > them everything we can to make it interesting for them to join us. But I > suppose that's not enough. It's impossible to match both worlds I guess. If you go back to the initial discussions about Fedora, they flat out refused to think about RHEL. Now it's too late, or you have to leave behind RHEL2.1 or RHEL3 (or start all over for these). RPM lacks infrastructure, Red Hat should have backported RPM infrastructure from the very start. RHEL2.1 and RHEL3 is what most companies still use. The company I work for is migrating from RHEL2.1 to RHEL3 because of legacy proprietary applications that are not ready for RHEL4 yet. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Tue Oct 3 17:54:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 03 Oct 2006 12:54:15 -0500 Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> Message-ID: Dag Wieers wrote: >> Well, yeah, that might be a good idea. But note that we try to get >> z00dax from http://centos.karan.org/ involved. He AFAIK is in contact >> with dag and dries. > > I'm wondering if the wrong community is involved. To me it makes much more > sense if CentOS would be involved and leading the RHEL packaging efforts. > Fedora and CentOS users are a different kind (even though some live in > both worlds, most do not). ... > I think the CentOS people have a much better understanding of what is > required and what balance needs to be struck. That's all well and good, probably so. Consider who already has the infrastructure (in place already) for community involvement (cvs, plague/mock builders, mirrors, etc...). Fedora (Extras) has that, does CentOS as well? >> They of course are always invited to join us and I'd try my best to give >> them everything we can to make it interesting for them to join us. But I >> suppose that's not enough. > > It's impossible to match both worlds I guess. If you go back to the > initial discussions about Fedora, they flat out refused to think about > RHEL. Now it's too late, or you have to leave behind RHEL2.1 or RHEL3 (or > start all over for these). RPM lacks infrastructure, Red Hat should have > backported RPM infrastructure from the very start. Hey, we gotta start somewhere, and that somewhere is rhel4 (and soon rhel5). If there's interest in rhel3 (or agast rhel2.1), there's no reason these initial efforts cannot be expanded to include them as well. -- Rex From tcallawa at redhat.com Tue Oct 3 18:23:55 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 03 Oct 2006 13:23:55 -0500 Subject: Yet another license question In-Reply-To: References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> Message-ID: <1159899835.3005.4.camel@localhost.localdomain> On Tue, 2006-10-03 at 05:13 +0000, Kevin Kofler wrote: > Tom 'spot' Callaway writes: > > This is BSD with advertising (GPL-incompatible, but free). OK for > > Fedora. > > No, this is NOT the standard BSD advertising clause. The advertising clause > covers DISTRIBUTION of software. This one covers USE. While I understand that > the intent of this clause is just to enforce standard academic courtesy, I > believe this is not anywhere near Free Software or Open Source. Restrictions on > use are simply unacceptable under those guidelines. So I'd say this is NOT OK > according to the licensing guidelines (which say the license should be Free > Software and/or Open Source according to the FSF and/or OSI). I'll ask the FSF, and we'll go from their recommendation. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From buildsys at fedoraproject.org Tue Oct 3 18:54:25 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 3 Oct 2006 14:54:25 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-03 Message-ID: <20061003185425.95A3615212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 45 Inventor-2.1.5-24.fc6 NetworkManager-vpnc-0.7.0-0.cvs20060929.1.fc6 abcm2ps-5.1.1-1.fc6 aiccu-2006.07.25-2.fc6 aide-0.11-3.fc6 alleyoop-0.9.3-2.fc6 cohoba-0.0.4-2.fc6 dillo-0.8.6-3.fc6 gai-0.5.10-8.fc6 gai-pal-0.7-11 gaim-otr-3.0.1-0.2.20060921cvs.fc6 glibmm24-2.12.2-1 gpgme-1.1.2-6.fc6.1 gpp-0.6.6-3.fc6 gtkmm24-2.10.2-1.fc6 gtkwave-3.0.12-2.fc6 gtorrentviewer-0.2b-12.fc6 gutenprint-5.0.0-0.15.fc6 gwenview-1.4.0-3.fc6 i810switch-0.6.5-5.fc6 inotify-tools-2.6-1.fc6 ivman-0.6.12-1.fc6 lat-1.2.0.1-2.fc6 libmatheval-1.1.3-4.fc6 libmodelfile-0.1.92-4.fc6 libmodplug-0.8-3.fc6 libtorrent-0.10.2-3.fc6 miau-0.6.2-3.fc6 multitail-4.2.0-2.fc6 openbox-3.3.1-3.fc6 opensc-0.11.1-4.fc6 openvpn-2.1-0.14.beta16.fc6 perl-Cairo-1.01-2.fc6 perl-Config-Tiny-2.10-1.fc6 perl-GnuPG-Interface-0.33-8.fc6 perl-perlmenu-4.0-4.fc6 php-pear-PHPUnit-1.3.2-1.fc6 plt-scheme-352-3.fc6 python-telepathy-0.13.2-3.fc6 sylpheed-2.2.9-2.fc6 ttywatch-0.14-7.fc6 wavbreaker-0.7-5.fc6 wine-0.9.22-1.fc6 xdg-utils-1.0-0.9.rc1.fc6 xemacs-21.5.27-5.fc6 Packages built and released for Fedora Extras 5: 16 Inventor-2.1.5-24.fc5 abcm2ps-5.1.1-1.fc5 dillo-0.8.6-3.fc5 fwbackups-1.42.1-2.fc5 gwenview-1.4.0-2.fc5 inotify-tools-2.6-1.fc5 libmatheval-1.1.3-4.fc5 libmodplug-0.8-3.fc5 miau-0.6.2-3.fc5 perl-Wx-0.57-2.fc5 php-pear-PHPUnit-1.3.2-1.fc5.1 plt-scheme-352-3.fc5 python-telepathy-0.13.2-2.fc5 wavbreaker-0.7-5.fc5 wine-0.9.22-1.fc5 xdg-utils-1.0-0.9.rc1.fc5 Packages built and released for Fedora Extras 4: 4 Inventor-2.1.5-24.fc4 libmodplug-0.7-4.fc4 showimg-0.9.5-10.fc4 xdg-utils-1.0-0.9.rc1.fc4 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 Oct 3 18:54:53 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 3 Oct 2006 14:54:53 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-03 Message-ID: <20061003185453.0E66215212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From buildsys at fedoraproject.org Tue Oct 3 19:36:54 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 03 Oct 2006 19:36:54 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-03 Message-ID: <20061003193654.31352.96978@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (3 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (3 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (18 days) plague - 0.4.4.1-2.fc3.noarch (18 days) plague - 0.4.4.1-2.fc4.noarch (18 days) plague - 0.4.4.1-2.fc4.noarch (18 days) plague - 0.4.4.1-2.fc4.noarch (18 days) j.w.r.degoede AT hhs.nl tremulous - 1.1.0-2.fc5.i386 (21 days) tremulous - 1.1.0-2.fc5.ppc (21 days) tremulous - 1.1.0-2.fc5.x86_64 (21 days) mr.ecik AT gmail.com kadu-amarok - 0.5.0-0.9.20060915svn.fc6.x86_64 raven AT pmail.pl gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.i386 (18 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.ppc (18 days) gaim-gadugadu - 2:2.0.0-0.11.beta3.fc6.x86_64 (18 days) ville.skytta AT iki.fi em8300 - 0.16.0-0.3.rc1.fc6.i386 em8300 - 0.16.0-0.3.rc1.fc6.ppc em8300 - 0.16.0-0.3.rc1.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- em8300-0.16.0-0.3.rc1.fc6.ppc requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.ppc requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- em8300-0.16.0-0.3.rc1.fc6.x86_64 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.x86_64 requires gaim = 0:2.0.0-0.11.beta3.fc6 kadu-amarok-0.5.0-0.9.20060915svn.fc6.x86_64 requires amarok Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- em8300-0.16.0-0.3.rc1.fc6.i386 requires em8300-kmod >= 0:0.16.0 gaim-gadugadu-2:2.0.0-0.11.beta3.fc6.i386 requires gaim = 0:2.0.0-0.11.beta3.fc6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.ppc requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.x86_64 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.i386 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: mr.ecik AT gmail.com package: kadu-amarok - 0.5.0-0.9.20060915svn.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: amarok From pertusus at free.fr Tue Oct 3 21:09:47 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Oct 2006 23:09:47 +0200 Subject: linking statically against dietlibc: a blocker? Message-ID: <20061003210947.GA2838@free.fr> Hello, 3 packages submitted by Enrico are under review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 Enrico linked these small daemons statically with dietlibc. Other contributors disagree with this choice, but I think that the situation should be clarified once for all, and it should said whether this is a blocker or not. My personal point of view is that linking statically (and against dietlibc) shouldn't be a blocker if * the maintainer is aware of the security implications, and that he has to follow the security issues regarding the package linked statically against and rebuild as soon as it is out, * there is a gain in term of efficiency (and potentially portability). And it should be well understood that these are exceptions. Of course the submitter has still to agree with that. -- Pat From paul at xelerance.com Tue Oct 3 22:20:46 2006 From: paul at xelerance.com (Paul Wouters) Date: Wed, 4 Oct 2006 00:20:46 +0200 (CEST) Subject: Yet another license question In-Reply-To: <1159899835.3005.4.camel@localhost.localdomain> References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159899835.3005.4.camel@localhost.localdomain> Message-ID: On Tue, 3 Oct 2006, Tom 'spot' Callaway wrote: > I'll ask the FSF, and we'll go from their recommendation. Seeing that RMS himself confirmed "approving" the license of Dansguardian for the FSF two weeks ago, that won't do you much good in determining the true meaning of the license. I would have packaged dansguardian if it wasn't for the misleading barrage of weirdo disclaimers: Before downloading, please read the copyright for DansGuardian 2. DansGuardian is not free for commercial use. DansGuardian may not be used by Military governments such as SPDC in Myanmar (formally known as Burma). and For all non-commercial use DansGuardian 2 can be downloaded under the GPL. That after careful reading means "GPL but a strict AUP exists for downloading from my server and official mirrors". So it is free (and debian includes it), but I'm not willing to support weirdo subjective AUP's for the official download site. (eg: I am blocked from downloading the source twice from his server if I sell it once or if I ever do a contract for the burmese government, despite the software being GPL) http://dansguardian.org/?page=download http://dansguardian.org/?page=copyright2 Paul From paul at xelerance.com Tue Oct 3 22:29:18 2006 From: paul at xelerance.com (Paul Wouters) Date: Wed, 4 Oct 2006 00:29:18 +0200 (CEST) Subject: linking statically against dietlibc: a blocker? In-Reply-To: <20061003210947.GA2838@free.fr> References: <20061003210947.GA2838@free.fr> Message-ID: On Tue, 3 Oct 2006, Patrice Dumas wrote: > 3 packages submitted by Enrico are under review: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 > > Enrico linked these small daemons statically with dietlibc. > > Other contributors disagree with this choice, but I think that the > situation should be clarified once for all, and it should said > whether this is a blocker or not. > > My personal point of view is that linking statically (and against > dietlibc) shouldn't be a blocker if > * the maintainer is aware of the security implications, and > that he has to follow the security issues regarding the package > linked statically against and rebuild as soon as it is out, > * there is a gain in term of efficiency (and potentially portability). > > And it should be well understood that these are exceptions. I would say that FC/FE is using glibc, not another c library, and that packages build for FE should be linked against glibc. There is nothing wrong with options to build differently, so one could do: do: rpmbuild -ba foo.spec --define 'dietlibc 1' to get non-default builds from FE sources. But I don't think we should start using different c libraries for random binaries. Paul From sundaram at fedoraproject.org Tue Oct 3 22:33:26 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Oct 2006 04:03:26 +0530 Subject: Yet another license question In-Reply-To: References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159899835.3005.4.camel@localhost.localdomain> Message-ID: <4522E536.2010200@fedoraproject.org> Paul Wouters wrote: > On Tue, 3 Oct 2006, Tom 'spot' Callaway wrote: > >> I'll ask the FSF, and we'll go from their recommendation. > > Seeing that RMS himself confirmed "approving" the license of > Dansguardian for the FSF two weeks ago, that won't do you much good > in determining the true meaning of the license. > > I would have packaged dansguardian if it wasn't for the misleading > barrage of weirdo disclaimers: > > Before downloading, please read the copyright for DansGuardian > 2. DansGuardian is not free for commercial use. DansGuardian may not > be used by Military governments such as SPDC in Myanmar (formally known > as Burma). > > and > > For all non-commercial use DansGuardian 2 can be downloaded under the GPL. > > That after careful reading means "GPL but a strict AUP exists for downloading > from my server and official mirrors". So it is free (and debian includes it), > but I'm not willing to support weirdo subjective AUP's for the official download > site. (eg: I am blocked from downloading the source twice from his server if > I sell it once or if I ever do a contract for the burmese government, despite the > software being GPL) > You cant add restrictions on top of GPL. Once it is licensed as GPL then it is Free software and can be used the terms of the license which does allow commercial usage. IMO, you can ignore the author's confusion and include it in Fedora. Rahul From paul at xelerance.com Tue Oct 3 22:47:57 2006 From: paul at xelerance.com (Paul Wouters) Date: Wed, 4 Oct 2006 00:47:57 +0200 (CEST) Subject: Yet another license question In-Reply-To: <4522E536.2010200@fedoraproject.org> References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159899835.3005.4.camel@localhost.localdomain> <4522E536.2010200@fedoraproject.org> Message-ID: On Wed, 4 Oct 2006, Rahul Sundaram wrote: > You cant add restrictions on top of GPL. Once it is licensed as GPL then it is > Free software and can be used the terms of the license which does allow > commercial usage. IMO, you can ignore the author's confusion and include it in > Fedora. I know that. Though I can see myself breaking the AUP of the server by accidentally downloading the same source twice while creating the pacakge. Can I not sell it anymore then (I guess I can, I would just violate his server's AUP not the GPL). Also, I don't like the signal the author is sending by the misleading statements of pretending that downloads are covered by a license agreement different from the downloaded software. We all want to get rich and release free software. The Dansguardian way is not the way to do it. Paul From denis at poolshark.org Tue Oct 3 22:48:44 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 04 Oct 2006 00:48:44 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <20061003210947.GA2838@free.fr> References: <20061003210947.GA2838@free.fr> Message-ID: <4522E8CC.40800@poolshark.org> Patrice Dumas wrote: > Hello, > > 3 packages submitted by Enrico are under review: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 > > Enrico linked these small daemons statically with dietlibc. > > Other contributors disagree with this choice, but I think that the > situation should be clarified once for all, and it should said > whether this is a blocker or not. > > My personal point of view is that linking statically (and against > dietlibc) shouldn't be a blocker if > * the maintainer is aware of the security implications, and > that he has to follow the security issues regarding the package > linked statically against and rebuild as soon as it is out, > * there is a gain in term of efficiency (and potentially portability). imo this should not be allowed unless it is a specific upstream requirement. I'm concerned with the complexity involved in introducing multiple competing C libraries in FE (duplicated security audit efforts), a choice that to me should be left to the upstream project rather than to the packager. Also I don't buy the efficiency argument: glibc is used by every single executable in a Fedora environment, and therefore is constantly in memory and hot in the cache. There should be a powerful argument to link against something other than glibc, and a faster startup time seems unconvincing. -denis From enrico.scholz at informatik.tu-chemnitz.de Tue Oct 3 22:55:46 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Oct 2006 00:55:46 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: (Paul Wouters's message of "Wed, 4 Oct 2006 00:29:18 +0200 (CEST)") References: <20061003210947.GA2838@free.fr> Message-ID: <871wppau19.fsf@kosh.bigo.ensc.de> paul at xelerance.com (Paul Wouters) writes: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 > ... > But I don't think we should start using different c libraries for > random binaries. Tickets above are not for "random binaries" but for projects which are designed for dietlibc. Using glibc for them would make binaries larger, slower and increases memory usage without providing a single gain. Enrico From pertusus at free.fr Tue Oct 3 22:52:43 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Oct 2006 00:52:43 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4522E8CC.40800@poolshark.org> References: <20061003210947.GA2838@free.fr> <4522E8CC.40800@poolshark.org> Message-ID: <20061003225243.GB2838@free.fr> > rather than to the packager. Also I don't buy the efficiency argument: > glibc is used by every single executable in a Fedora environment, and > therefore is constantly in memory and hot in the cache. There should be > a powerful argument to link against something other than glibc, and a > faster startup time seems unconvincing. Enrico tested the running executables and found those statically linked against dietlibc to be faster. -- Pat From sundaram at fedoraproject.org Tue Oct 3 23:01:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Oct 2006 04:31:36 +0530 Subject: Yet another license question In-Reply-To: References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159899835.3005.4.camel@localhost.localdomain> <4522E536.2010200@fedoraproject.org> Message-ID: <4522EBD0.40101@fedoraproject.org> Paul Wouters wrote: > On Wed, 4 Oct 2006, Rahul Sundaram wrote: > >> You cant add restrictions on top of GPL. Once it is licensed as GPL then it is >> Free software and can be used the terms of the license which does allow >> commercial usage. IMO, you can ignore the author's confusion and include it in >> Fedora. > > I know that. Though I can see myself breaking the AUP of the server by > accidentally downloading the same source twice while creating the pacakge. Can > I not sell it anymore then (I guess I can, I would just violate his server's > AUP not the GPL). Since the software is under GPL, anyone can mirror the software and forget about the original server's AUP and there doesnt seem to be any legally binding use policy in the mirrors. So not sure there is a real problem other than perhaps a minor hurdle in selecting a reliable mirror as the package source. See more on the Debian related note below. > Also, I don't like the signal the author is sending by the misleading > statements of pretending that downloads are covered by a license agreement > different from the downloaded software. > > We all want to get rich and release free software. The Dansguardian way is > not the way to do it. Sure. Nobody likes misleading statements that are not part of the licenses themselves but that's a moral personal line to draw on choosing to use or package the software for other end users. The software itself isn't non-free and IMO we shouldn't deny users the ability to use a GPL licensed useful software just because the author is deliberately or unintentionally misleading. Thats the case for Xchat's windows port too. The limitations of such tricky things seems to be recognised by the author himself. See the FAQ on Debian in this page. http://dansguardian.org/?page=copyright2 Rahul From jwilson at redhat.com Tue Oct 3 23:05:03 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Oct 2006 19:05:03 -0400 Subject: compiz manager In-Reply-To: <1159890864.19121.2.camel@xavier.boston.redhat.com> References: <4517C16A.7090503@fedoraproject.org> <1159815771.16086.7.camel@xavier.boston.redhat.com> <4521632C.4010109@fedoraproject.org> <1159823571.16086.17.camel@xavier.boston.redhat.com> <1159890864.19121.2.camel@xavier.boston.redhat.com> Message-ID: <1159916704.19121.5.camel@xavier.boston.redhat.com> On Tue, 2006-10-03 at 11:54 -0400, Jarod Wilson wrote: > On Mon, 2006-10-02 at 17:12 -0400, Jarod Wilson wrote: > > On Tue, 2006-10-03 at 00:36 +0530, Rahul Sundaram wrote: > > > Jarod Wilson wrote: > > > > On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: > > > >> Originated in Mandriva and picked up OpenSUSE. > > > >> http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ > > > >> > > > >> Would be nice to have this in Fedora Extras. > > > > > > > > Note that compiz-manager requires cgwd (compiz generic window decorator, > > > > iirc), which in turn requires the compiz-quinn (now known as beryl) > > > > compiz fork, which replaces the compiz we've got in FC6. > > > > > > I believe it can be installed in parallel which is under review at > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192434 > > > > I could be wrong, but I don't think so. Both provide some of the same > > binaries, libs, include files, etc. > > Okay, with the renamed beryl fork, I think you actually can have them > installed in parallel, as all the bits are renamed, including header > files, libraries, etc. You can and I do. > > /me goes off to find a sacrificial box to try this all out on... > > Oy. It go boom. In different ways on 3 different systems. This was a > 9/20 snap though, might have better luck with beryl 0.1.0... For gits and shiggles, I built packages for all the beryl/emerald components. You can grab the srpms and spec files here, if you're inclined to play: http://wilsonet.com/packages/beryl/ I'll take it up with the person who submitted the compiz-quinn package review request to figure out where to go from here to get beryl and friends into Extras... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Oct 3 23:09:42 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Oct 2006 01:09:42 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4522E8CC.40800@poolshark.org> (Denis Leroy's message of "Wed, 04 Oct 2006 00:48:44 +0200") References: <20061003210947.GA2838@free.fr> <4522E8CC.40800@poolshark.org> Message-ID: <87wt7h9etl.fsf@kosh.bigo.ensc.de> denis at poolshark.org (Denis Leroy) writes: > I'm concerned with the complexity involved in introducing multiple > competing C libraries in FE (duplicated security audit efforts), Affected packages are very small programs which are using almost only simple syscall wrappers from libc. See [1] for a full analysis of freedt. > a choice that to me should be left to the upstream project rather > than to the packager. Also I don't buy the efficiency argument: See [1] and [2] for some numbers. Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 [2] https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01827.html https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01842.html From rc040203 at freenet.de Wed Oct 4 00:41:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 02:41:47 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <20061003210947.GA2838@free.fr> References: <20061003210947.GA2838@free.fr> Message-ID: <1159922507.13363.258.camel@mccallum.corsepiu.local> On Tue, 2006-10-03 at 23:09 +0200, Patrice Dumas wrote: > Hello, > > 3 packages submitted by Enrico are under review: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 > > Enrico linked these small daemons statically with dietlibc. > > Other contributors disagree with this choice, but I think that the > situation should be clarified once for all, and it should said > whether this is a blocker or not. > > My personal point of view is that linking statically (and against > dietlibc) shouldn't be a blocker if > * the maintainer is aware of the security implications, and > that he has to follow the security issues regarding the package > linked statically against and rebuild as soon as it is out, > * there is a gain in term of efficiency (and potentially portability). Static linkage against dietlibc, IMO is nothing but a script-kiddy's attempt to "pimping Linux". There should not be any room for such undertakings. Ralf From seg at haxxed.com Wed Oct 4 01:33:39 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Oct 2006 20:33:39 -0500 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1159922507.13363.258.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> Message-ID: <1159925619.4438.7.camel@localhost.localdomain> On Wed, 2006-10-04 at 02:41 +0200, Ralf Corsepius wrote: > Static linkage against dietlibc, IMO is nothing but a script-kiddy's > attempt to "pimping Linux". There should not be any room for such > undertakings. +1 This is insane. If there's security or performance problems in glibc, they need to be found and fixed. From seg at haxxed.com Wed Oct 4 01:55:42 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Oct 2006 20:55:42 -0500 Subject: New comps group proposal: audio-production In-Reply-To: <20060928203121.GB20464@nostromo.devel.redhat.com> References: <1159381055.3121.14.camel@localhost.localdomain> <20060927221515.GA19075@nostromo.devel.redhat.com> <1159455062.2768.33.camel@to-dhcp25.toronto.redhat.com> <20060928203121.GB20464@nostromo.devel.redhat.com> Message-ID: <1159926942.4438.19.camel@localhost.localdomain> On Thu, 2006-09-28 at 16:31 -0400, Bill Nottingham wrote: > Anthony Green (green at redhat.com) said: > > > Would we split again > > > for video production? > > > > Fair enough. We could make it an audio-video-production group. > > Content production? I suppose 'content' is an overloaded term, so > audio-video could work. It should probably be "media-production" to match the name I recommended for the SIG. I chose that name exactly for this reason, its hard to draw a line between audio and video because video usually involves audio (and music) as well. Drawing a line between media consumption, and production is much clearer. If you've ever used a full Planet CCRMA system, you know that the Sound & Video menu gets very large and unmanageable. As we move more apps into Extras, someday we're going to want to split off a "Media Production" menu as well. From notting at redhat.com Wed Oct 4 02:39:25 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Oct 2006 22:39:25 -0400 Subject: New comps group proposal: audio-production In-Reply-To: <1159926942.4438.19.camel@localhost.localdomain> References: <1159381055.3121.14.camel@localhost.localdomain> <20060927221515.GA19075@nostromo.devel.redhat.com> <1159455062.2768.33.camel@to-dhcp25.toronto.redhat.com> <20060928203121.GB20464@nostromo.devel.redhat.com> <1159926942.4438.19.camel@localhost.localdomain> Message-ID: <20061004023925.GA16115@nostromo.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > It should probably be "media-production" to match the name I recommended > for the SIG. I chose that name exactly for this reason, its hard to draw > a line between audio and video because video usually involves audio (and > music) as well. > > Drawing a line between media consumption, and production is much > clearer. But then do you blow up the graphics component and move in inkscape and the gimp? Bill From davej at redhat.com Wed Oct 4 03:05:03 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Oct 2006 23:05:03 -0400 Subject: New comps group proposal: audio-production In-Reply-To: <20061004023925.GA16115@nostromo.devel.redhat.com> References: <1159381055.3121.14.camel@localhost.localdomain> <20060927221515.GA19075@nostromo.devel.redhat.com> <1159455062.2768.33.camel@to-dhcp25.toronto.redhat.com> <20060928203121.GB20464@nostromo.devel.redhat.com> <1159926942.4438.19.camel@localhost.localdomain> <20061004023925.GA16115@nostromo.devel.redhat.com> Message-ID: <20061004030503.GB30680@redhat.com> On Tue, Oct 03, 2006 at 10:39:25PM -0400, Bill Nottingham wrote: > Callum Lerwick (seg at haxxed.com) said: > > It should probably be "media-production" to match the name I recommended > > for the SIG. I chose that name exactly for this reason, its hard to draw > > a line between audio and video because video usually involves audio (and > > music) as well. > > > > Drawing a line between media consumption, and production is much > > clearer. > > But then do you blow up the graphics component and move in inkscape > and the gimp? how about groups of groups ? :) media-production pulls in audio-production AND video-production. Dave -- http://www.codemonkey.org.uk From wtogami at redhat.com Wed Oct 4 03:16:24 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 03 Oct 2006 23:16:24 -0400 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <871wppau19.fsf@kosh.bigo.ensc.de> References: <20061003210947.GA2838@free.fr> <871wppau19.fsf@kosh.bigo.ensc.de> Message-ID: <45232788.7080305@redhat.com> Enrico Scholz wrote: > paul at xelerance.com (Paul Wouters) writes: > >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 >> ... >> But I don't think we should start using different c libraries for >> random binaries. > > Tickets above are not for "random binaries" but for projects which are > designed for dietlibc. Using glibc for them would make binaries larger, > slower and increases memory usage without providing a single gain. > You lose the benefit of FORTIFY_SOURCE and address randomization of entry points of libc functions, both of which are detriments to security. Warren Togami wtogami at redhat.com From peter at thecodergeek.com Wed Oct 4 03:17:30 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 03 Oct 2006 20:17:30 -0700 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <20061003210947.GA2838@free.fr> References: <20061003210947.GA2838@free.fr> Message-ID: <452327CA.80107@thecodergeek.com> Patrice Dumas wrote: > Other contributors disagree with this choice, but I think that the > situation should be clarified once for all, and it should said > whether this is a blocker or not. I'm of the opinion that statically linking against *ANYTHING* [1] means that the package in question is flawed by design. Firstly, shared libraries mean that only that specific library needs to be rebuild for any updates. This makes it much more difficult to keep up with security and major bugfix issues, as one would be required to rebuild *EVERY* package that links statically to that library. Secondly, static libraries (as I understand their workings) are stored in memory with the binary image of the program that is running. This leads to (theoretically) multiple copies of that library wasting memory space needlessly. On the other hand, shared libraries also keep multiple copies of the library code in memory, but the kernel handles that effectively by storing only one actual copy and using things like Copy-On-Write and virtual memory addressing to make it appear to userspace that a copy exists per each program. Thirdly, you brought up the point that "there is a gain in term of efficiency (and potentially portability)." The way I see it: Linking statically for these purposes is nothing but a hackish workaround. If glibc or another system library needs fixing for speed or portability issues, then it should be fixed, not bypassed. This would result in virtually *every* application having better speed and increased portability. That is the Right Way(TM), I believe. Yes, it will take longer and the program will run slower until that happens, but doing things the right way over a long period of time is better than hacks for short-term gains. [1] Unless absolutely needed, as in the case of rescue binaries and such where one or more specific shared libraries that are needed are not guaranteed to be functional, much less even assured to be present on the system... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From enrico.scholz at informatik.tu-chemnitz.de Wed Oct 4 06:31:04 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Oct 2006 08:31:04 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <45232788.7080305@redhat.com> (Warren Togami's message of "Tue, 03 Oct 2006 23:16:24 -0400") References: <20061003210947.GA2838@free.fr> <871wppau19.fsf@kosh.bigo.ensc.de> <45232788.7080305@redhat.com> Message-ID: <87sli4a8yf.fsf@kosh.bigo.ensc.de> wtogami at redhat.com (Warren Togami) writes: >> Tickets above are not for "random binaries" but for projects which >> are designed for dietlibc. Using glibc for them would make binaries >> larger, slower and increases memory usage without providing a single >> gain. > > You lose the benefit of FORTIFY_SOURCE and address randomization of > entry points of libc functions, both of which are detriments to > security. Please show me, where an argv0 implementation like ---- #include int main(int argc, char *argv[]) { if (argc<2) return 1; execvp(argv[1], argv+2); return 2; } ---- can benefit from FORTIFY_SOURCE or address randomization. Enrico From jwilson at redhat.com Wed Oct 4 06:33:37 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 04 Oct 2006 02:33:37 -0400 Subject: compiz manager In-Reply-To: <1159916704.19121.5.camel@xavier.boston.redhat.com> References: <4517C16A.7090503@fedoraproject.org> <1159815771.16086.7.camel@xavier.boston.redhat.com> <4521632C.4010109@fedoraproject.org> <1159823571.16086.17.camel@xavier.boston.redhat.com> <1159890864.19121.2.camel@xavier.boston.redhat.com> <1159916704.19121.5.camel@xavier.boston.redhat.com> Message-ID: <1159943617.28067.1.camel@daedalus.wilsonet.com> On Tue, 2006-10-03 at 19:05 -0400, Jarod Wilson wrote: > On Tue, 2006-10-03 at 11:54 -0400, Jarod Wilson wrote: > > On Mon, 2006-10-02 at 17:12 -0400, Jarod Wilson wrote: > > > On Tue, 2006-10-03 at 00:36 +0530, Rahul Sundaram wrote: > > > > Jarod Wilson wrote: > > > > > On Mon, 2006-09-25 at 17:15 +0530, Rahul wrote: > > > > >> Originated in Mandriva and picked up OpenSUSE. > > > > >> http://linux.wordpress.com/2006/09/24/suse-101-new-compiz-manager-themes/ > > > > >> > > > > >> Would be nice to have this in Fedora Extras. I've now submitted my beryl-core, beryl-manager, beryl-settings, beryl-plugins, emerald and emerald-themes packages for review... -- Jarod Wilson jwilson at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Wed Oct 4 06:42:51 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Oct 2006 08:42:51 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <452327CA.80107@thecodergeek.com> (Peter Gordon's message of "Tue, 03 Oct 2006 20:17:30 -0700") References: <20061003210947.GA2838@free.fr> <452327CA.80107@thecodergeek.com> Message-ID: <87odssa8es.fsf@kosh.bigo.ensc.de> peter at thecodergeek.com (Peter Gordon) writes: > Firstly, shared libraries mean that only that specific library needs > to be rebuild for any updates. not relevant for the mentioned packages. They use only some syscalls from libc and almost all logic is implemented in the programs self. > Secondly, static libraries (as I understand their workings) are stored > in memory with the binary image of the program that is running. This > leads to (theoretically) multiple copies of that library wasting memory > space needlessly. Typical glibc propaganda... Numbers [1] show that some dietlibc linked programs need only 10% of (non-shareable) memory than the glibc counterpart. glibc's dynamic loader needs more instructions and memory at startup than the whole dietlibc-built program during its whole lifetime. Enrico Footnotes: [1] https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01842.html From siddharth1105 at yahoo.com Wed Oct 4 06:43:03 2006 From: siddharth1105 at yahoo.com (Siddharth Upmanyu) Date: Tue, 3 Oct 2006 23:43:03 -0700 (PDT) Subject: linking statically against dietlibc: a blocker? Message-ID: <20061004064303.77153.qmail@web36714.mail.mud.yahoo.com> I suggest the developer-co should deside on this issue collectively wether the use of other library can be allowed or not (other the glibc to link the module) the core issue is use of standerds not the optimization... Regards Siddharth ----- Original Message ---- From: Enrico Scholz To: fedora-extras-list at redhat.com Sent: Wednesday, October 4, 2006 12:01:04 PM Subject: Re: linking statically against dietlibc: a blocker? wtogami at redhat.com (Warren Togami) writes: >> Tickets above are not for "random binaries" but for projects which >> are designed for dietlibc. Using glibc for them would make binaries >> larger, slower and increases memory usage without providing a single >> gain. > > You lose the benefit of FORTIFY_SOURCE and address randomization of > entry points of libc functions, both of which are detriments to > security. Please show me, where an argv0 implementation like ---- #include int main(int argc, char *argv[]) { if (argc<2) return 1; execvp(argv[1], argv+2); return 2; } ---- can benefit from FORTIFY_SOURCE or address randomization. Enrico -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list From seg at haxxed.com Wed Oct 4 07:05:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 04 Oct 2006 02:05:49 -0500 Subject: New comps group proposal: audio-production In-Reply-To: <20061004023925.GA16115@nostromo.devel.redhat.com> References: <1159381055.3121.14.camel@localhost.localdomain> <20060927221515.GA19075@nostromo.devel.redhat.com> <1159455062.2768.33.camel@to-dhcp25.toronto.redhat.com> <20060928203121.GB20464@nostromo.devel.redhat.com> <1159926942.4438.19.camel@localhost.localdomain> <20061004023925.GA16115@nostromo.devel.redhat.com> Message-ID: <1159945550.4438.38.camel@localhost.localdomain> On Tue, 2006-10-03 at 22:39 -0400, Bill Nottingham wrote: > Callum Lerwick (seg at haxxed.com) said: > > It should probably be "media-production" to match the name I recommended > > for the SIG. I chose that name exactly for this reason, its hard to draw > > a line between audio and video because video usually involves audio (and > > music) as well. > > > > Drawing a line between media consumption, and production is much > > clearer. > > But then do you blow up the graphics component and move in inkscape > and the gimp? I would label gimp and inkscape as print publishing tools, which does not fall under audio/video media. Yes, its arguable that print media could fall under the name "Media Production", but they don't really seem directly related to me. I'm trying to balance having too many groups (music/audio and video gets hard to distinguish between, when you consider something like Cinelerra.) versus too few. (Adding print to the mix seems like too much) I suppose it could be "Audio/Video Media Production" but that's getting a bit long. "A/V Production" maybe... From seg at haxxed.com Wed Oct 4 07:14:34 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 04 Oct 2006 02:14:34 -0500 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <87odssa8es.fsf@kosh.bigo.ensc.de> References: <20061003210947.GA2838@free.fr> <452327CA.80107@thecodergeek.com> <87odssa8es.fsf@kosh.bigo.ensc.de> Message-ID: <1159946074.4438.43.camel@localhost.localdomain> On Wed, 2006-10-04 at 08:42 +0200, Enrico Scholz wrote: > not relevant for the mentioned packages. They use only some syscalls > from libc and almost all logic is implemented in the programs self. If they need so little from dietlibc, why doesn't upstream just merge what they need into their codebase? > Typical glibc propaganda... Numbers [1] show that some dietlibc > linked programs need only 10% of (non-shareable) memory than the > glibc counterpart. > > glibc's dynamic loader needs more instructions and memory at startup > than the whole dietlibc-built program during its whole lifetime. Please explain why these packages deserve such special treatment. Where's the line? If dietlibc is so great, why aren't we moving the entire distribution over to it? From rc040203 at freenet.de Wed Oct 4 07:36:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 09:36:43 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1159946074.4438.43.camel@localhost.localdomain> References: <20061003210947.GA2838@free.fr> <452327CA.80107@thecodergeek.com> <87odssa8es.fsf@kosh.bigo.ensc.de> <1159946074.4438.43.camel@localhost.localdomain> Message-ID: <1159947404.13363.316.camel@mccallum.corsepiu.local> On Wed, 2006-10-04 at 02:14 -0500, Callum Lerwick wrote: > On Wed, 2006-10-04 at 08:42 +0200, Enrico Scholz wrote: > > not relevant for the mentioned packages. They use only some syscalls > > from libc and almost all logic is implemented in the programs self. > > If they need so little from dietlibc, why doesn't upstream just merge > what they need into their codebase? Both approaches mean circumventing libc by replacing libc functions with private versions. Whether "statically linking against dietlibc" or including private copies doesn't make any real difference. It's essentially the same. Both suffer from the same flaws and problems. > > Typical glibc propaganda... Numbers [1] show that some dietlibc > > linked programs need only 10% of (non-shareable) memory than the > > glibc counterpart. > > > > glibc's dynamic loader needs more instructions and memory at startup > > than the whole dietlibc-built program during its whole lifetime. > > Please explain why these packages deserve such special treatment. > Where's the line? If dietlibc is so great, why aren't we moving the > entire distribution over to it? ... because responsible maintainers care more about intetrating applications into the OS, but circumventing it and by "pimping applications"? Carefully designed applications *use* the OS (of which libc is an essential part of) and "just live with a compromises/trade-offs". Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Oct 4 08:44:41 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Oct 2006 10:44:41 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1159946074.4438.43.camel@localhost.localdomain> (Callum Lerwick's message of "Wed, 04 Oct 2006 02:14:34 -0500") References: <20061003210947.GA2838@free.fr> <452327CA.80107@thecodergeek.com> <87odssa8es.fsf@kosh.bigo.ensc.de> <1159946074.4438.43.camel@localhost.localdomain> Message-ID: <878xjw79mu.fsf@fc5.bigo.ensc.de> seg at haxxed.com (Callum Lerwick) writes: >> not relevant for the mentioned packages. They use only some syscalls >> from libc and almost all logic is implemented in the programs self. > > If they need so little from dietlibc, why doesn't upstream just merge > what they need into their codebase? mmh... just a wild guess: perhaps upstream wants to use the Posix API instead of writing assembler for zillions of different architectures (which would be required for syscalls)? >> Typical glibc propaganda... Numbers [1] show that some dietlibc >> linked programs need only 10% of (non-shareable) memory than the >> glibc counterpart. >> >> glibc's dynamic loader needs more instructions and memory at startup >> than the whole dietlibc-built program during its whole lifetime. > > Please explain why these packages deserve such special treatment. freedt: beats glibc in every aspect; see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582#c2 ipsvd: recommended by upstream; DJB-suite like program fnord: compare the authors of fnord and dietlibc and what they think about glibc > Where's the line? It's a decision of the packager. Basically I would say, when: 1. code does not use other, non-trivial libraries 2. code is short/simple enough to be audited completely 3. code builds with dietlibc without losing features then it is a candidate for dietlibc. DJB-suite like programs ('daemontools' + 'ucspi*' replacements) are usually very hot candidates for dietlibc linking. > If dietlibc is so great, why aren't we moving the entire distribution > over to it? dietlibc does not fit for every program. When a program requires other libraries, you will run into the following problems: * most libraries are not written for static linking (e.g. do not follow the only-one-function-per-compilation-unit concept) * libraries with complex algorithms are prone for security problems; dynamic linking makes replacing much easier -> some libs must be linked dynamically which nullifies the benefits of dietlibc Some programs depend on glibc'isms too and will not build with dietlibc. dietlibc does not have locale(7) functionality which makes it unsuitable for GUI programs. Enrico From j.w.r.degoede at hhs.nl Wed Oct 4 08:54:01 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 04 Oct 2006 10:54:01 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4522E8CC.40800@poolshark.org> References: <20061003210947.GA2838@free.fr> <4522E8CC.40800@poolshark.org> Message-ID: <452376A9.6090100@hhs.nl> Denis Leroy wrote: > Patrice Dumas wrote: >> Hello, >> >> 3 packages submitted by Enrico are under review: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582 >> >> Enrico linked these small daemons statically with dietlibc. >> >> Other contributors disagree with this choice, but I think that the >> situation should be clarified once for all, and it should said >> whether this is a blocker or not. >> >> My personal point of view is that linking statically (and against >> dietlibc) shouldn't be a blocker if >> * the maintainer is aware of the security implications, and >> that he has to follow the security issues regarding the package >> linked statically against and rebuild as soon as it is out, >> * there is a gain in term of efficiency (and potentially portability). > > imo this should not be allowed unless it is a specific upstream > requirement. I'm concerned with the complexity involved in introducing > multiple competing C libraries in FE (duplicated security audit > efforts), a choice that to me should be left to the upstream project > rather than to the packager. Also I don't buy the efficiency argument: > glibc is used by every single executable in a Fedora environment, and > therefore is constantly in memory and hot in the cache. There should be > a powerful argument to link against something other than glibc, and a > faster startup time seems unconvincing. > +1, We have been over this before having dietlibc available prebuild in extras may be handy for people doing development for i386 embedded systems, but besides that it should not be used PERIOD. Please lets not have this flamefest again (and again and again). I say that Fesco or the packaging commitee should take a decission on this and then be done with it. Regards, Hans From caillon at redhat.com Wed Oct 4 15:12:51 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 04 Oct 2006 11:12:51 -0400 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <451BB47A.3010909@poolshark.org> References: <451BB47A.3010909@poolshark.org> Message-ID: <4523CF73.8030405@redhat.com> Denis Leroy wrote: > I hereby claim my interest in picking up orphaned NetworkManager-vpnc > (wiki updated). > Thanks, Denis. I'd like to make a request to FESCO or whomever to please take another look at the process for orphaning packages. In particular, I'm extremely unhappy that NetworkManager-vpnc was dropped from the repository. I did some investigating into what happened, and this is the general way things went: - All packages were tagged as needs.rebuild, mails sent out. - Davidz didn't rebuild the package. - Notting sends davidz a mail saying the package was going to be orphaned, and cc'd extras-list? asking for a new maintainer. - Davidz replied to the mail apologizing and saying he'd take care of it. - Notting sends "never mind, david will take care of it" to the list. - Davidz did nothing with the package. - It was dropped. - Within 48 hours of it being dropped, I received an email and several IRC pings wondering where it was (I own NetworkManager in core). I'm sure Dan Williams did as well, maybe some other people. - Also within 48 hours of it being dropped, Denis Leroy steps up to claim the package. The most important things in that whole sequence are the last two. Clearly, dropping the package impacted Fedora users negatively. And there was community interest in maintaining the package, so it's plausible that had it been given a fair process, it wouldn't have been dropped. I believe the process for orphaning packages needs to address those. I propose this: 1. Clearly after davidz replied to the first mail and the "request for new owners" was dropped, then proceeded to do nothing, ANOTHER request should have been initiated and allowed to go through to the end to allow someone to have the chance to take the package before it was "orphaned". This should be MANDATORY, in my opinion. 2. Packages should never be dropped when they are orphaned until they break. Breaking can be defined as causing the tree to fail repoclosure, or somethin. Debian does something similar to this. The reasoning is that simply because the package is not "maintained" does not mean the package no longer serves a useful purpose to Fedora users. Clearly that was the case for NetworkManager-vpnc. It's possible that it will be *more* likely for someone to step up as maintainer if they realize there is a package they use and nobody to update the package (people seem very adamant about updated packages in extras). Dropping packages carte blanche without at least some sort of individual review is plain wrong. From pertusus at free.fr Wed Oct 4 15:27:55 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Oct 2006 17:27:55 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <452376A9.6090100@hhs.nl> References: <20061003210947.GA2838@free.fr> <4522E8CC.40800@poolshark.org> <452376A9.6090100@hhs.nl> Message-ID: <20061004152755.GF2280@free.fr> On Wed, Oct 04, 2006 at 10:54:01AM +0200, Hans de Goede wrote: > > We have been over this before having dietlibc available prebuild in > extras may be handy for people doing development for i386 embedded > systems, but besides that it should not be used PERIOD. > > Please lets not have this flamefest again (and again and again). It's not a flamefest, there has to be a decision. > I say that Fesco or the packaging commitee should take a decission on > this and then be done with it. Indeed. -- Pat From pertusus at free.fr Wed Oct 4 15:31:43 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Oct 2006 17:31:43 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1159925619.4438.7.camel@localhost.localdomain> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159925619.4438.7.camel@localhost.localdomain> Message-ID: <20061004153143.GG2280@free.fr> On Tue, Oct 03, 2006 at 08:33:39PM -0500, Callum Lerwick wrote: > On Wed, 2006-10-04 at 02:41 +0200, Ralf Corsepius wrote: > > This is insane. If there's security or performance problems in glibc, > they need to be found and fixed. dietlibc and glibc, although they are both libc have very different designs, and in my opinion it won't be possible for the glibc to have the same performance than dietlibc (in those cases). And it won't be possible for dietlibc to have the glibc feature coverage. Differences in design cannot be fixed. -- Pat From jwboyer at jdub.homelinux.org Wed Oct 4 15:40:43 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 04 Oct 2006 10:40:43 -0500 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4523CF73.8030405@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> Message-ID: <1159976443.30534.23.camel@zod.rchland.ibm.com> On Wed, 2006-10-04 at 11:12 -0400, Christopher Aillon wrote: > The most important things in that whole sequence are the last two. > Clearly, dropping the package impacted Fedora users negatively. And > there was community interest in maintaining the package, so it's > plausible that had it been given a fair process, it wouldn't have been > dropped. Note that this is a result of the mass rebuild effort really. Not the orphan process. > > I believe the process for orphaning packages needs to address those. I > propose this: > > 1. Clearly after davidz replied to the first mail and the "request for > new owners" was dropped, then proceeded to do nothing, ANOTHER request > should have been initiated and allowed to go through to the end to allow > someone to have the chance to take the package before it was > "orphaned". This should be MANDATORY, in my opinion. Normally that happens. This particular instance happened to line up with a mass rebuild, which is why it got removed. Believe me, packages typically don't get yanked that quickly. > 2. Packages should never be dropped when they are orphaned until they > break. Breaking can be defined as causing the tree to fail repoclosure, > or somethin. Debian does something similar to this. The reasoning is > that simply because the package is not "maintained" does not mean the > package no longer serves a useful purpose to Fedora users. Clearly that > was the case for NetworkManager-vpnc. It's possible that it will be > *more* likely for someone to step up as maintainer if they realize there > is a package they use and nobody to update the package (people seem very > adamant about updated packages in extras). Dropping packages carte > blanche without at least some sort of individual review is plain wrong. See above. Also note that it just got pulled from the repo, not CVS. josh From rdieter at math.unl.edu Wed Oct 4 15:45:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 04 Oct 2006 10:45:28 -0500 Subject: linking statically against dietlibc: a blocker? References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > Static linkage against dietlibc, IMO is nothing but a script-kiddy's > attempt to "pimping Linux". There should not be any room for such > undertakings. Extend that logic a little, and we shouldn't allow dietlibc in Extras at all. Either dietlibc OK for Extras and for Extras pkgs to link-against/use it, or not. ATM, I'm personally leaning toward the former, especially in cases where upstream and the packager/maintainer prefer using dietlibc. -- Rex From rc040203 at freenet.de Wed Oct 4 16:48:20 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 18:48:20 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> Message-ID: <1159980500.13363.379.camel@mccallum.corsepiu.local> On Wed, 2006-10-04 at 10:45 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > Static linkage against dietlibc, IMO is nothing but a script-kiddy's > > attempt to "pimping Linux". There should not be any room for such > > undertakings. > > Extend that logic a little, and we shouldn't allow dietlibc in Extras at > all. Yes, but it might surprise you, the more I think about it, the more Iam not uncertain about this, because this problem actually consists of several pretty far fetching issues: 1. "circumventing glibc-calls by syscall-wrappers" 2. "static linkage" AFAIK, dietlibc does 1) by applying 2), several application do the same by using local files. Though I consider both ways to be "pretty stupid", one will always find people trying to outsmart themselves this way for various reasons (speed, size, security, portability). Here, having a central library (such as dietlibc) would still be preferable instead of these people starting to ship local copies of individual libc-functions. This consideration however leads to a 3rd issue: To bring this into a maintainable form, we would have to find a way to denote dependencies on specific versions of static libs into individual rpms, which can be applied to check for version updates of static libs rsp. are supposed to break upon updates of static libs. (At minimum something like: BR: dietlibc-static = version-release, or even more radically, require all static libraries to provide a virtual provide a libxxxx_a(..) = version-release, which all packages using this static lib must Require:) > Either dietlibc OK for Extras and for Extras pkgs to link-against/use it, or > not. I am in favor of changing the GuileLines to require *-static (which would require dietlibc to be renamed) and to require someones explicit permission on any case of static linkage. > ATM, I'm personally leaning toward the former, especially in cases > where upstream and the packager/maintainer prefer using dietlibc. As I wrote before, in most cases, a decision on trade-offs and a balance between "pimping" and "maintainability" has to be found. Some packagers/maintainers apparently are "keen on pimping Linux at any price" - I am not willing to be playing it nice to them. In addition to all this, another issue has popped up, which IMO renders shipping static libs as part of Fedora very questionable (to say the least) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 Ralf From tibbs at math.uh.edu Wed Oct 4 17:17:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Oct 2006 12:17:27 -0500 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1159980500.13363.379.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 04 Oct 2006 18:48:20 +0200") References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> In addition to all this, another issue has popped up, which IMO RC> renders shipping static libs as part of Fedora very questionable RC> (to say the least) RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 Surely this is a bug in RPM, though, and shouldn't block otherwise acceptable packages. - J< From fedora at leemhuis.info Wed Oct 4 17:21:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Oct 2006 19:21:23 +0200 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4523CF73.8030405@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> Message-ID: <4523ED93.5090708@leemhuis.info> Christopher Aillon schrieb: > Denis Leroy wrote: >> I hereby claim my interest in picking up orphaned NetworkManager-vpnc >> (wiki updated). > > Thanks, Denis. > > I'd like to make a request to FESCO or whomever to please take another > look at the process for orphaning packages. In particular, I'm > extremely unhappy that NetworkManager-vpnc was dropped from the repository. > > I did some investigating into what happened, and this is the general way > things went: > > - All packages were tagged as needs.rebuild, mails sent out. > - Davidz didn't rebuild the package. He should have gotten at least two mails directly in his inbox that should have told him to rebuild his stuff. > - Notting sends davidz a mail saying the package was going to be > orphaned, and cc'd extras-list? asking for a new maintainer. > - Davidz replied to the mail apologizing and saying he'd take care of it. > - Notting sends "never mind, david will take care of it" to the list. > - Davidz did nothing with the package. > - It was dropped. Note: only from the devel repo. > - Within 48 hours of it being dropped, I received an email and several > IRC pings wondering where it was (I own NetworkManager in core). I'm > sure Dan Williams did as well, maybe some other people. > - Also within 48 hours of it being dropped, Denis Leroy steps up to > claim the package. > > The most important things in that whole sequence are the last two. > Clearly, dropping the package impacted Fedora users negatively. Users of the devel-tree should be able to handle that. And removing the package is the best way to find a new maintainer ;-) > And > there was community interest in maintaining the package, so it's > plausible that had it been given a fair process, it wouldn't have been > dropped. > > I believe the process for orphaning packages needs to address those. I > propose this: > > 1. Clearly after davidz replied to the first mail and the "request for > new owners" was dropped, then proceeded to do nothing, ANOTHER request > should have been initiated and allowed to go through to the end to allow > someone to have the chance to take the package before it was > "orphaned". This should be MANDATORY, in my opinion. jwb replied to that already. But yes, the package probably shouldn't have been dropped after davidz replied. But davidz should have taken care of the package directly when he send this mail, then the package probably wound not have been removed (afaics). > 2. Packages should never be dropped when they are orphaned until they > break. [...] I agree for the stable repo for dists that are released. But for devel: No. No. No. We have to do some cleanup now and then, otherwise it'll soon and in a great unsupported mess -- and devel is the proper place for removals. One of the reasons: Security. Packages that get shipped now for FE6 have to be maintained and update by someone for the whole lifetime of FE6 (including Fedora Legacy). If you of someone else volunteers to take a look after all orphans: okay, that let's leave them in. But I doubt someone is interested in such a job. CU thl From fedora at leemhuis.info Wed Oct 4 17:43:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Oct 2006 19:43:28 +0200 Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> Message-ID: <4523F2C0.3080007@leemhuis.info> Dag Wieers schrieb: > On Sun, 24 Sep 2006, Thorsten Leemhuis wrote: >> There are afaics (and *please* correct me if I'm wrong) some more big >> differences: > Let's correct then. thx >> - rpmforge wants to (or does already?) build for distributions like Suse >> or SLES (someone indicated that to me in private on IRC some weeks ago) > We do not. Sorry. I thought I read such stuff somewhere on the rpmforge website in the past, but seems I was wrong. And somebody told be that some guys close to rpmforge consider building for SLES9. > [...] > However we are very interested to work together with other packagers as > most of the work is identical. What's more, most of the bug-reports are > identical so it makes much more sense to combine the effort for > bug-tracking and package-development. (tracing patches, security > problems) Then we really should work towards in more co-operations between rpmforge and Extras (and livna). > But now that most RPM community repositories are in control of vendors > (see OpenSuSE and Fedora). There is even less interest to join forces. Well, I think taking to each other is in the interest of most packagers. Maybe a common wiki could help where special pacakge knowledge and patches could be shared. >[...] >>> - rpmforge builds new packages often for several distributions including >> those that are in "Maintenance state" (FC3, FC4 currently); Fedora >> Extras is more conservative here > > What about RHEL2.1 and RHEL3 ? People need a decent subversion for those. > If you apply your current rules to the release of RHEL2.1 or RHEL3 you'd > be providing subversion 0.19 ad 0.90. Very stable and pretty useless ! Well, those people are still on RHEL 2.1 and RHEL3 for some reasons. Probably because kernel, gnome, X, and several other stuff is working quite well for them. So if they don't want newer versions of that stuff -- why should they want a new subversion? But I don't think discussing this further makes much sense. I can see you position and I can understand that point of view, even if it differs from mine. So agreeing to disagree here might be the best here. >[...] CU thl From kevin-fedora-extras at scrye.com Wed Oct 4 17:54:22 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 04 Oct 2006 11:54:22 -0600 (MDT) Subject: orphaning xffm Message-ID: <20061004.115422.04443777.kevin@scrye.com> The new version of Xfce (which we are hopefully going to push out in the next few days) no longer uses xffm as it's filemanager. Instead it uses thunar. The current xffm in extras is old and won't compile against the new Xfce 4.4. Upstream xffm is very much alive, but they have changed all their packaging. They split out the main xffm into about 17 packages, and it does all kinds of things now besides file managing. Since this isn't used in core Xfce anymore, and I don't use it, I am going to orphan it. If there is anyone interested in taking it over, please feel free. Note that I am going to also request it be removed from the repos. After the xfce 4.4 update, the current version will be broken. Happy to provide any further info for 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 bugs.michael at gmx.net Wed Oct 4 17:59:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 Oct 2006 19:59:33 +0200 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <1159976443.30534.23.camel@zod.rchland.ibm.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> Message-ID: <20061004195933.031d7455.bugs.michael@gmx.net> On Wed, 04 Oct 2006 10:40:43 -0500, Josh Boyer wrote: > > I believe the process for orphaning packages needs to address those. I > > propose this: > > > > 1. Clearly after davidz replied to the first mail and the "request for > > new owners" was dropped, then proceeded to do nothing, ANOTHER request > > should have been initiated and allowed to go through to the end to allow > > someone to have the chance to take the package before it was > > "orphaned". This should be MANDATORY, in my opinion. > > Normally that happens. This particular instance happened to line up > with a mass rebuild, which is why it got removed. Believe me, packages > typically don't get yanked that quickly. Except: Once they are marked orphaned, they cannot live in the distribution for a long time. We do not want orphaned packages to pile up. Filling Fedora Extras with packages, which don't have any package maintainer, is not one of our goals. And we need means to fight fire'n'forget packages, too. > > 2. Packages should never be dropped when they are orphaned until they > > break. I have strong doubts that FESCo will ever turn that into a policy. It is ridiculous. If you are serious about that, propose reopening Red Hat Contrib Anonymous FTP upload. > > Breaking can be defined as causing the tree to fail repoclosure, > > or somethin. Or bugzilla tickets getting old, unnoticed security vulnerabilities, serious run-time failures without anybody taking notice. > > Debian does something similar to this. Who cares? This is not the Debian project. We have other requirements, other problems. Open your eyes! Just look at the trouble we have with the FE6 preparation! > > The reasoning is > > that simply because the package is not "maintained" does not mean the > > package no longer serves a useful purpose to Fedora users. Unless that means "one user => one to volunteer as becoming the package owner in FE" it's of no value to the project. Users dislike it very much that we offer packages which are not assigned to a human-being in bugzilla. From buildsys at fedoraproject.org Wed Oct 4 18:02:24 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 4 Oct 2006 14:02:24 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-04 Message-ID: <20061004180224.1FC3A15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 36 brasero-0.4.4-3.fc6 clisp-2.40-3.fc6 cpanspec-1.69-1.fc6 ctorrent-1.3.4-2.fc6 digikamimageplugins-doc-0.8.2-2.fc6 em8300-kmod-0.16.0-0.2.rc1.2.6.18_1.2726.fc6 gdl-0.9-0.pre3.1.fc6 guichan-0.5.0-1.fc6 kdesvn-0.9.3-2.fc6 librsync-0.9.7-7.fc6 lighttpd-1.4.12-3.fc6 mimedefang-2.57-5.fc6 mock-0.6.5-1.fc6 octave-2.9.9-1.fc6 openbabel-2.0.2-5.fc6 perl-Alien-wxWidgets-0.22-1.fc6 perl-Class-MOP-0.35-1.fc6 perl-DBIx-SearchBuilder-1.45-1.fc6 perl-Data-Alias-1.01-1.fc6 perl-Moose-0.13-1.fc6 perl-POE-Component-Client-HTTP-0.78-1.fc6 perl-POE-Component-Client-Keepalive-0.0901-1.fc6 perl-POE-Component-Server-SOAP-1.10-1.fc6 perl-POE-Component-SimpleLog-1.04-1.fc6 perl-PPI-Tester-0.06-2.fc6 perl-Params-Util-0.20-1.fc6 perl-SUPER-1.15-1.fc6 perl-Test-Inline-2.105-2.fc6 pessulus-2.16.1-1.fc6 plplot-5.6.1-6.fc6 qt4-4.2.0-1.fc6 rssowl-1.2.2-6.fc6 ruby-mysql-2.7.1-2.fc6 sshfp-1.1.1-1.fc6 telepathy-gabble-0.3.9-1.fc6 wavbreaker-0.7-6.fc6 Packages built and released for Fedora Extras 5: 23 alleyoop-0.9.3-2.fc5 clisp-2.40-3.fc5 cohoba-0.0.4-2.fc5 cpanspec-1.69-1.fc5 gnome-python2-gda-2.14.0-1.fc5 guichan-0.5.0-1.fc5 jasper-1.701.0-15.fc5.1 librsync-0.9.7-7.fc5 mimedefang-2.57-5.fc5 mock-0.6.5-1.fc5 perl-Alien-wxWidgets-0.22-1.fc5 perl-Class-MOP-0.35-1.fc5 perl-DBIx-SearchBuilder-1.45-1.fc5 perl-Data-Alias-1.01-1.fc5 perl-Moose-0.13-1.fc5 perl-POE-Component-Client-HTTP-0.78-1.fc5 perl-POE-Component-Client-Keepalive-0.0901-1.fc5 perl-POE-Component-Server-SOAP-1.10-1.fc5 perl-POE-Component-SimpleLog-1.04-1.fc5 perl-Params-Util-0.20-1.fc5 perl-SUPER-1.15-1.fc5 perl-Test-Inline-2.105-2.fc5 wavbreaker-0.7-6.fc5 Packages built and released for Fedora Extras 4: 5 cpanspec-1.69-1.fc4 jasper-1.701.0-15.fc4.1 librsync-0.9.7-7.fc4 perl-Params-Util-0.20-1.fc4 perl-Test-Inline-2.105-2.fc4 Packages built and released for Fedora Extras 3: 1 librsync-0.9.7-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 Wed Oct 4 18:02:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 4 Oct 2006 14:02:54 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-04 Message-ID: <20061004180254.3F7B415212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From jwilson at redhat.com Wed Oct 4 18:27:05 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 4 Oct 2006 14:27:05 -0400 Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: <4523F2C0.3080007@leemhuis.info> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> <4523F2C0.3080007@leemhuis.info> Message-ID: On Oct 4, 2006, at 1:43 PM, Thorsten Leemhuis wrote: >>>> - rpmforge builds new packages often for several distributions >>>> including >>> those that are in "Maintenance state" (FC3, FC4 currently); Fedora >>> Extras is more conservative here >> >> What about RHEL2.1 and RHEL3 ? People need a decent subversion for >> those. >> If you apply your current rules to the release of RHEL2.1 or RHEL3 >> you'd >> be providing subversion 0.19 ad 0.90. Very stable and pretty >> useless ! > > Well, those people are still on RHEL 2.1 and RHEL3 for some reasons. > Probably because kernel, gnome, X, and several other stuff is working > quite well for them. So if they don't want newer versions of that > stuff > -- why should they want a new subversion? That is a perfectly valid example. I know of folks running mission- critical RHEL3 (or older) servers that they'd like to add something modern, like an up-to-date subversion server to... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Wed Oct 4 18:43:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Oct 2006 20:43:35 +0200 Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> <4523F2C0.3080007@leemhuis.info> Message-ID: <452400D7.2000909@leemhuis.info> Jarod Wilson schrieb: > On Oct 4, 2006, at 1:43 PM, Thorsten Leemhuis wrote: >>>>> - rpmforge builds new packages often for several distributions >>>>> including >>>> those that are in "Maintenance state" (FC3, FC4 currently); Fedora >>>> Extras is more conservative here >>> What about RHEL2.1 and RHEL3 ? People need a decent subversion for those. >>> If you apply your current rules to the release of RHEL2.1 or RHEL3 you'd >>> be providing subversion 0.19 ad 0.90. Very stable and pretty useless ! >> Well, those people are still on RHEL 2.1 and RHEL3 for some reasons. >> Probably because kernel, gnome, X, and several other stuff is working >> quite well for them. So if they don't want newer versions of that stuff >> -- why should they want a new subversion? > That is a perfectly valid example. I know of folks running > mission-critical RHEL3 (or older) servers that they'd like to add > something modern, like an up-to-date subversion server to... Sure. There is always somebody that wants some new stuff. And there are always people that fear new stuff because it might break things. So there are three ways out: 1. update everything always to the latest version 2. publish a dists once and only apply security updates later and never version updates 3. draw a line somewhere between 1 and 2 -- but where? which packages get updates, which not? One want's updates for foo and no updates for bar, the next users the other way around. In fact it's always "3". But RHEL is closer to "2" and Fedora closer to "1". And that's how FE and EPEL should work, too. And for dists that are in "Maintenance state" I think it should always be close to "2" in the default repo. CU thl From buildsys at fedoraproject.org Wed Oct 4 18:45:37 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 04 Oct 2006 18:45:37 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-04 Message-ID: <20061004184537.4850.13874@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (4 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (4 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (4 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (19 days) plague - 0.4.4.1-2.fc3.noarch (19 days) plague - 0.4.4.1-2.fc4.noarch (19 days) plague - 0.4.4.1-2.fc4.noarch (19 days) plague - 0.4.4.1-2.fc4.noarch (19 days) denis AT poolshark.org gnome-python2-gda-devel - 2.14.0-1.fc5.i386 gnome-python2-gda-devel - 2.14.0-1.fc5.ppc gnome-python2-gda-devel - 2.14.0-1.fc5.x86_64 j.w.r.degoede AT hhs.nl tremulous - 1.1.0-2.fc5.i386 (22 days) tremulous - 1.1.0-2.fc5.ppc (22 days) tremulous - 1.1.0-2.fc5.x86_64 (22 days) Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- gnome-python2-gda-devel-2.14.0-1.fc5.ppc requires pygobject2-devel tremulous-1.1.0-2.fc5.ppc requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- gnome-python2-gda-devel-2.14.0-1.fc5.x86_64 requires pygobject2-devel tremulous-1.1.0-2.fc5.x86_64 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- gnome-python2-gda-devel-2.14.0-1.fc5.i386 requires pygobject2-devel tremulous-1.1.0-2.fc5.i386 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: denis AT poolshark.org package: gnome-python2-gda-devel - 2.14.0-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: pygobject2-devel package: gnome-python2-gda-devel - 2.14.0-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: pygobject2-devel package: gnome-python2-gda-devel - 2.14.0-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: pygobject2-devel From tibbs at math.uh.edu Wed Oct 4 18:48:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Oct 2006 13:48:11 -0500 Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: (Jarod Wilson's message of "Wed, 4 Oct 2006 14:27:05 -0400") References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> <4523F2C0.3080007@leemhuis.info> Message-ID: >>>>> "JW" == Jarod Wilson writes: JW> That is a perfectly valid example. I know of folks running JW> mission- critical RHEL3 (or older) servers that they'd like to add JW> something modern, like an up-to-date subversion server to... It's not as if it's difficult to build fresh packages for whatever distro you have, as long as prerequisites don't require you to rebuild half of the distro. And for everyone who would like an updated subversion, there's someone else who would like an updated apache, or an updated openssh. And I'd bet that those who want one package to be updated would really not want everything else to be updated as well. After all, they're still using RHEL Vancient for a reason. - J< From caillon at redhat.com Wed Oct 4 18:58:07 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 04 Oct 2006 14:58:07 -0400 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <1159976443.30534.23.camel@zod.rchland.ibm.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> Message-ID: <4524043F.4070205@redhat.com> Josh Boyer wrote: > On Wed, 2006-10-04 at 11:12 -0400, Christopher Aillon wrote: > >> The most important things in that whole sequence are the last two. >> Clearly, dropping the package impacted Fedora users negatively. And >> there was community interest in maintaining the package, so it's >> plausible that had it been given a fair process, it wouldn't have been >> dropped. > > Note that this is a result of the mass rebuild effort really. Not the > orphan process. Call the process whatever you want, the package dropped because of inactivity of the maintainer (how is this different from orphaned?) without a fair chance for anyone to step up. If it's not the orphan process, I can call it the drop package process or whatever. In either case, something is broken. If a package doesn't get a fair chance to be picked up before dropped, I'd say that's broken. Or, if an auxiliary process such as mass rebuilding gets free reign to ignore other processes, then that is broken. From rdieter at math.unl.edu Wed Oct 4 18:59:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 04 Oct 2006 13:59:20 -0500 Subject: linking statically against dietlibc: a blocker? References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Wed, 2006-10-04 at 10:45 -0500, Rex Dieter wrote: >> Either dietlibc OK for Extras and for Extras pkgs to link-against/use it, >> or not. > I am in favor of changing the GuileLines to require *-static (which > would require dietlibc to be renamed) and to require someones explicit > permission on any case of static linkage. +1, agreed, reasonable. -- Rex From dag at wieers.com Wed Oct 4 19:24:47 2006 From: dag at wieers.com (Dag Wieers) Date: Wed, 4 Oct 2006 21:24:47 +0200 (CEST) Subject: Essential difference between CentOS and Fedora (Was: rpmforge and {enterprise, } Extras) In-Reply-To: <4523F2C0.3080007@leemhuis.info> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> <4523F2C0.3080007@leemhuis.info> Message-ID: On Wed, 4 Oct 2006, Thorsten Leemhuis wrote: > Dag Wieers schrieb: > > On Sun, 24 Sep 2006, Thorsten Leemhuis wrote: > > > >> - rpmforge wants to (or does already?) build for distributions like Suse > >> or SLES (someone indicated that to me in private on IRC some weeks ago) > > We do not. > > Sorry. I thought I read such stuff somewhere on the rpmforge website in > the past, but seems I was wrong. And somebody told be that some guys > close to rpmforge consider building for SLES9. Yes, we discussed this at one point as about 50% of the packages back then translated directly to SLES9. And with adapted RPM infrastructure this is possible. But until now we always used the native RPM capabilities and this brings us back to the lowest common denominator. If RPM functionality would be backported, it would ease our work and it would foster RPM functionality development. As long as an RPM improvement may take 6 or more years before it can be used for the collection of EL distributions, it's a waste. I hope someone from Red Hat is paying attention :) Or maybe jbj. Maybe pyrpm is the answer to this one. > > [...] > > However we are very interested to work together with other packagers as > > most of the work is identical. What's more, most of the bug-reports are > > identical so it makes much more sense to combine the effort for > > bug-tracking and package-development. (tracing patches, security > > problems) > > Then we really should work towards in more co-operations between > rpmforge and Extras (and livna). Of course. > > But now that most RPM community repositories are in control of vendors > > (see OpenSuSE and Fedora). There is even less interest to join forces. > > Well, I think taking to each other is in the interest of most packagers. > Maybe a common wiki could help where special pacakge knowledge and > patches could be shared. I much more prefer a tool that can compare SPEC files (and patches) and keeps a list of updates between comparisons. Something that you can ask "what's new for this package according to the other projects" and then a common forum where you can discuss these changes with your fellow packagers. Something that centralizes both changes, bugreports and discussions. PS By packagers I did not mean RPM packagers specifically. > >[...] > > >>> - rpmforge builds new packages often for several distributions including > >> those that are in "Maintenance state" (FC3, FC4 currently); Fedora > >> Extras is more conservative here > > > > What about RHEL2.1 and RHEL3 ? People need a decent subversion for those. > > If you apply your current rules to the release of RHEL2.1 or RHEL3 you'd > > be providing subversion 0.19 ad 0.90. Very stable and pretty useless ! > > Well, those people are still on RHEL 2.1 and RHEL3 for some reasons. > Probably because kernel, gnome, X, and several other stuff is working > quite well for them. So if they don't want newer versions of that stuff > -- why should they want a new subversion? How about being restricted to RHEL2.1 or RHEL3 because other teams (security, management) have specific rules about supportability of 3rd party software. Even though stuff works on newer distributions it may not be (and often is not) supported. As a result we are forbidden to migrate to RHEL4. And these RHEL3 systems will be in production for another 5 to 6 years. System administrators in big companies are restricted by a lot. We're not on top of the decision-making. One can mock the situation but it is bitter earnest if you're in it :) People choose EL simply because it makes them not having to upgrade when they don't need to. If they were going to upgrade every 1.5 or 2 years, they might as well go with Fedora. That's is the big difference. That's why CentOS is so popular, probably even more popular than Fedora. Especially for all those Linux deployements that one might see as an appliance. (MythTV box, your family computer(s), your file/web server) Everything that does not change or where change is predictable. But I don't have to tell you this. > But I don't think discussing this further makes much sense. I can see > you position and I can understand that point of view, even if it differs > from mine. So agreeing to disagree here might be the best here. That's fine. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Wed Oct 4 19:43:19 2006 From: dag at wieers.com (Dag Wieers) Date: Wed, 4 Oct 2006 21:43:19 +0200 (CEST) Subject: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras= In-Reply-To: References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <4512AFF5.5010703@leemhuis.info> <80d7e4090609211035l1535d43ep4b87d407e0a56528@mail.gmail.com> <20060921220819.bda280fb.bugs.michael@gmx.net> <645d17210609230952q20ad538ehe06cd2d24f645892@mail.gmail.com> <4516651F.8090803@leemhuis.info> <645d17210609240614k79b8efa8u652df8eba09adac@mail.gmail.com> <45168FA0.6080201@leemhuis.info> <4523F2C0.3080007@leemhuis.info> Message-ID: On Wed, 4 Oct 2006, Jason L Tibbitts III wrote: > >>>>> "JW" == Jarod Wilson writes: > > JW> That is a perfectly valid example. I know of folks running > JW> mission- critical RHEL3 (or older) servers that they'd like to add > JW> something modern, like an up-to-date subversion server to... > > It's not as if it's difficult to build fresh packages for whatever > distro you have, as long as prerequisites don't require you to rebuild > half of the distro. > > And for everyone who would like an updated subversion, there's someone > else who would like an updated apache, or an updated openssh. And I'd > bet that those who want one package to be updated would really not > want everything else to be updated as well. After all, they're still > using RHEL Vancient for a reason. Exactly my point ! That's why the dependency resolver should be able to following the end-user's policy. - Do not upgrade base packages (ie. packages from this or that repository) - Do not upgrade this package to a newer version (or to a newer version+release) - Do not upgrade to a package from another repository than the one installed - ... These are all valid policies, and these policies can be different per package. Something like this is important, because you may want to serve a stable subversion repository. But on another server you require the latest subversion client, or maybe not the latest but specifically version 1.2.1. That's why creating more than one repository is not going to be of any help. We need a better Yum, better pinning in Apt. Smart is almost ok as it is :) I've made this case many times. The taolinux developer made a baseprotect patch almost 2 years ago. Seth didn't see a need and there were probably more pressing needs anyway. Now the CentOS people are improving a similar plugin for Yum. Discussions can be seen on the CentOS mailinglists. 'One repository rules them all' is something that was nice to promote when Fedora Extras was taking off. But it's a far cry from reality and diversity/development has been hurt by it. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From jamatos at fc.up.pt Wed Oct 4 19:54:51 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Wed, 4 Oct 2006 20:54:51 +0100 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4524043F.4070205@redhat.com> References: <451BB47A.3010909@poolshark.org> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> Message-ID: <200610042054.51845.jamatos@fc.up.pt> On Wednesday 04 October 2006 19:58, Christopher Aillon wrote: > Call the process whatever you want, the package dropped because of > inactivity of the maintainer (how is this different from orphaned?) > without a fair chance for anyone to step up. ?If it's not the orphan > process, I can call it the drop package process or whatever. > > In either case, something is broken. ?If a package doesn't get a fair > chance to be picked up before dropped, I'd say that's broken. ?Or, if an > auxiliary process such as mass rebuilding gets free reign to ignore > other processes, then that is broken. I agree with you. On the other hand this is the first release where we applied this procedure. I am certain that we will learn with our mistakes. After all this is one of the phew examples that gave wrong results among more than one thousand packages. At least this is why I like Extras, we still learning how to proceed, and IMHO we are doing very well, as any growth process sometimes there are hiccups. -- Jos? Ab?lio From jspaleta at gmail.com Wed Oct 4 21:05:14 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Oct 2006 13:05:14 -0800 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4524043F.4070205@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> Message-ID: <604aa7910610041405ja6683f9hdd5582caea13dc25@mail.gmail.com> On 10/4/06, Christopher Aillon wrote: > In either case, something is broken. If a package doesn't get a fair > chance to be picked up before dropped, I'd say that's broken. Or, if an > auxiliary process such as mass rebuilding gets free reign to ignore > other processes, then that is broken. we are talking about the development tree.... even core-development tree does not claim to be in a self-consistent state from day-to-day. If extras-development is broken because of a mandated pull of a build due to maintainer inaction.. I say good... the sooner we catch problems with maintainer miscommunication or inaction the better. The reality is that preparing for a release tree is going to always run into time constraints associated with any process which allows for iterative communication with inactive maintainers. Even if Davidz's email saying he'd take care of it restarted the clock... there's no garuntee he'd have taken care of it if we gave him a second chance, or a third chance... or a fourth chance. The longer the project waits on a deliquint maintainer to take promised action, the more pressed for time a new maintainer will be when corrective action is needed to meet the release tree deadline. This must be avoided... and if breaking the dependancy chain in the development tree is the reality check that keeps maintainers honest with each other on how to share the workload..then so be it... the package pull has served its purpose and put the problem into focus for all the effected maintainers who were relying on davidz to take the action as promised. The current policy was explicit and honest. If the maintainer in question hadn't responded with a promised action we may have had a new maintainer step up before the clock expired without running into time constraints associated with the release timing. Because davidz promised to take action and didn't, the only way we knew a new maintainer needed to take over was because the package was pulled. If anything was broken in the process, it was accepting the 'i'll take care of it' response without a latching interium deadline as sufficient to prevent a new maintainer from being assigned when this was first brought up. -jef"simple rule, don't say you are going to do something unless you are actually going to do it. Hard deadlines are there specifically to catch these sort of things. Expecting the process to repeatly slip to make up for individual inaction subverts the larger scheduling and workload maintainence demands."spaleta From ville.skytta at iki.fi Wed Oct 4 21:34:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 05 Oct 2006 00:34:46 +0300 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4524043F.4070205@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> Message-ID: <1159997686.24351.141.camel@viper.local> On Wed, 2006-10-04 at 14:58 -0400, Christopher Aillon wrote: > If a package doesn't get a fair chance to be picked up before dropped, > I'd say that's broken. While dropping [0] may be a bit rough, personally I think it worked well as a trigger for someone to actually step up in the NetworkManager-vpnc case. > Or, if an auxiliary process such as mass rebuilding gets free reign > to ignore other processes, then that is broken. Agreed, but I don't think that's what has happened. The rebuild time slot length was intentionally aligned with the maintainer AWOL policy definitions. Some planned post-rebuild/release-preparation actions were actually loosened for a bunch of packages that were orphaned too late when comparing the time we generally reserve for orphaned package takeover to the time we had left until the FC6 release. The time between orphaning not-taken-care-of packages and removing their package files from the repo could have been a bit longer, but aggressively cleaning up orphans this way from devel has been done pretty much all the time anyway. Remove early, remove often in devel ;) - that gives other contributors more time to react before the next release. Anyway, there's definitely quite a few things we can improve in future release preparations and all feedback is valuable, thanks! [0] Even when defined and occurred as "removing only the rpm files from the development repository according to the plan announced well beforehand and separately warned about several times on two lists before it actually took place". From peter at thecodergeek.com Thu Oct 5 05:27:06 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 04 Oct 2006 22:27:06 -0700 Subject: rpms/git/devel .cvsignore, 1.32, 1.33 git.spec, 1.21, 1.22 sources, 1.32, 1.33 In-Reply-To: <200610050503.k9553Sio008492@cvs-int.fedora.redhat.com> References: <200610050503.k9553Sio008492@cvs-int.fedora.redhat.com> Message-ID: <452497AA.4090609@thecodergeek.com> Chris Wright (chrisw) wrote: > Author: chrisw > [...] > %changelog > -* Thu Oct 05 2006 Christian Iseli 1.4.2.1-2 > - - rebuilt for unwind info generation, broken in gcc-4.1.1-21 > +* Wed Oct 4 2006 Chris Wright 1.4.2.3-1 > +- git-1.4.2.3 > Erm. Why was the changelog entry for the previous EVR removed with this commit? -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Thu Oct 5 06:33:31 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 05 Oct 2006 09:33:31 +0300 Subject: rpms/perl-Readonly/devel perl-Readonly.spec,1.2,1.3 In-Reply-To: <200610050126.k951QMSa026211@cvs-int.fedora.redhat.com> References: <200610050126.k951QMSa026211@cvs-int.fedora.redhat.com> Message-ID: <1160030011.24351.159.camel@viper.local> On Wed, 2006-10-04 at 18:26 -0700, Chris Weyl wrote: > %changelog > +* Wed Oct 04 2006 Chris Weyl 1.03-6 > +- add explict requires on perl(Readonly::XS). perl(Readonly::XS) is available > + for all architectures fedora supports, so there's no good reason to not > + require it. Hm... except maybe that there's now a build dependency loop, perl-ReadOnly-XS BuildRequires perl-ReadOnly. From florin at andrei.myip.org Thu Oct 5 07:33:20 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 05 Oct 2006 00:33:20 -0700 Subject: New comps group proposal: audio-production In-Reply-To: <1159381055.3121.14.camel@localhost.localdomain> References: <1159381055.3121.14.camel@localhost.localdomain> Message-ID: <4524B540.3080300@andrei.myip.org> Anthony Green wrote: > > I'd like to propose a new group for these new apps... > > audio-production > <_name>Audio Production > <_description>This is a collection of applications and plugins > geared towards audio production and includes audio recorders, MIDI > sequencers and software synthesizers. I use Linux for audio and music production (I was also one of the people who nagged Fernando to move PlanetCCRMA to Extras). I think the Audio Production group makes a lot of sense from my perspective. I don't need the whole Sound And Video enchilada, but I usually end up pulling all music- and sound-related apps when I install a new system - essentially, the entire gang of apps that migrated from CCRMA to Extras. I believe this is a typical case for people in my situation. I need JACK, of course, but then I need qjackctl. I also need a sequencer, hence I will install Rosegarden or Muse - and also Seq24 for loop-based sequencing. And of course a soft synth is also required so I end up installing ZynAddSubFX. And so on, you get the idea. It would be much easier to just do a group install. Much less painful. Please don't forget to include LADSPA and all its plugins in this group. It's probably best to run this idea on the Fedora Music list, to make sure no application is forgotten. A while ago, I proposed on Fedora Music to change the names of the LADSPA plugins packages to a more consistent format, such as ladspa- or something like that, but so far nothing has happened. -- Florin Andrei http://florin.myip.org/ From rc040203 at freenet.de Thu Oct 5 09:04:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Oct 2006 11:04:17 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> Message-ID: <1160039058.24866.44.camel@mccallum.corsepiu.local> On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> In addition to all this, another issue has popped up, which IMO > RC> renders shipping static libs as part of Fedora very questionable > RC> (to say the least) > RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 > > Surely this is a bug in RPM, RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( > though, and shouldn't block otherwise > acceptable packages. Well, the resulting debuginfo package was empty and the resulting packages were not source-level debugable via debuginfo*.rpm. To me this sufficed to block a package due to bugs in its infrastructure. If GCC was misscompiling a particular package you probably would have done the same. Worse, more general, meanwhile, I am almost certain all static libs are not source-level debugable with debuginfo rpms due to this bug in rpm. I do not want to block further packages due to this, nevertheless this to me is a severe bug, further decreasing my willingness to tolerate static libs and static linkage during reviews. Ralf From paul at city-fan.org Thu Oct 5 09:11:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 05 Oct 2006 10:11:20 +0100 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1160039058.24866.44.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> Message-ID: <4524CC38.6020600@city-fan.org> Ralf Corsepius wrote: > On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: >>>>>>> "RC" == Ralf Corsepius writes: >> RC> In addition to all this, another issue has popped up, which IMO >> RC> renders shipping static libs as part of Fedora very questionable >> RC> (to say the least) >> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 >> >> Surely this is a bug in RPM, > RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( It was jbj that closed it it WONTFIX, not the RH rpm maintainer. Paul. From jonathan.underwood at gmail.com Thu Oct 5 09:52:46 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 5 Oct 2006 10:52:46 +0100 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4524CC38.6020600@city-fan.org> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> Message-ID: <645d17210610050252g4bef41b9i32c43327ec16e70a@mail.gmail.com> On 05/10/06, Paul Howarth wrote: > Ralf Corsepius wrote: > > On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: > >>>>>>> "RC" == Ralf Corsepius writes: > >> RC> In addition to all this, another issue has popped up, which IMO > >> RC> renders shipping static libs as part of Fedora very questionable > >> RC> (to say the least) > >> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 > >> > >> Surely this is a bug in RPM, > > RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( > > It was jbj that closed it it WONTFIX, not the RH rpm maintainer. It's unfortunate, but RHs rpm maintainer very rarely comments on rpm bugs, which helps perpetuatethe idea that jeff johnson is still the maintainer. From rc040203 at freenet.de Thu Oct 5 09:56:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Oct 2006 11:56:03 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4524CC38.6020600@city-fan.org> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> Message-ID: <1160042163.24866.47.camel@mccallum.corsepiu.local> On Thu, 2006-10-05 at 10:11 +0100, Paul Howarth wrote: > Ralf Corsepius wrote: > > On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: > >>>>>>> "RC" == Ralf Corsepius writes: > >> RC> In addition to all this, another issue has popped up, which IMO > >> RC> renders shipping static libs as part of Fedora very questionable > >> RC> (to say the least) > >> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 > >> > >> Surely this is a bug in RPM, > > RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( > > It was jbj that closed it it WONTFIX, not the RH rpm maintainer. <*grin*/> I am aware about this, nevertheless I regard anybody who closes bugs on an FC package (Note: this PR was against rpm*fc5.*.rpm) to be a RH maintainer. Ralf From Christian.Iseli at licr.org Thu Oct 5 09:56:07 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 5 Oct 2006 11:56:07 +0200 Subject: semi-mass rebuild completed Message-ID: <20061005115607.5a42c921@ludwig-alpha> Hi folks, I have rebuilt all remaining packages that had been built in the Sep 18 Sep 26 window (list below). There are three duds: libcdio http://buildsys.fedoraproject.org/build-status/job.psp?uid=18982 kawa http://buildsys.fedoraproject.org/build-status/job.psp?uid=19052 liblrdf http://buildsys.fedoraproject.org/build-status/job.psp?uid=19046 Guess I'll open 3 BZ tickets... Cheers, C ---- adns ardour autotrace azureus basket blktool bochs cfengine clamav cyrus-imapd dap-freeform_handler dap-hdf4_handler dap-netcdf_handler dap-server dhcp-forwarder dssi dynamite ebtables eds-feed eventlog exim farsight fatsort fftw filelight fluidsynth fluidsynth-dssi fontforge FreeWnn gaim-galago gaim-guifications gajim galeon gcin git gkrellm gnash gnet2 gnokii gnome-build gnomesword gossip gpsim gputils grace grads gstreamer-python gtk-sharp hexter-dssi ipe ip-sentinel itext jakarta-commons-cli jhead jogl k3d kawa kdiff3 kicad kover lash leafnode libannodex libcdio libcmml libdap libetpan libgalago-gtk libifp liblo liblrdf libnc-dap liboggz libpaper libsynaptics libuninameslist licq liferea lsscsi milter-greylist mod_annodex monodoc most mtd-utils mxml mysql-connector-java nexuiz ninja octave-forge ode oooqs2 opencv orange pdsh pengupop perl-Device-SerialPort perl-Gnome2-Canvas perl-Imager perl-Readonly-XS perl-Spreadsheet-ParseExcel php-pecl-Fileinfo picocom pikdev python-enchant python-twisted PyX rafkill raptor rdiff-backup rekall rman R-RScaLAPACK sabayon sblim-cmpi-base sblim-cmpi-devel sblim-wbemcli SDL_gfx seq24 showimg smarteiffel ss5 swh-plugins sword synce-gnomevfs synce-software-manager synce-trayicon t1lib t1utils tellico Thunar tuxpaint unshield util-vserver uuid vorbisgain whatmask XaraLX xchm xfce4-weather-plugin z88dk zynaddsubfx From bugs.michael at gmx.net Thu Oct 5 10:39:11 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 Oct 2006 12:39:11 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4524CC38.6020600@city-fan.org> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> Message-ID: <20061005123911.bf13073a.bugs.michael@gmx.net> On Thu, 05 Oct 2006 10:11:20 +0100, Paul Howarth wrote: > >> RC> In addition to all this, another issue has popped up, which IMO > >> RC> renders shipping static libs as part of Fedora very questionable > >> RC> (to say the least) > >> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 > >> > >> Surely this is a bug in RPM, > > RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( > > It was jbj that closed it it WONTFIX, not the RH rpm maintainer. No, he did not. He _suggested_ WONTFIX in a comment only: https://bugzilla.redhat.com/bugzilla/show_activity.cgi?id=209316 From tarjei.knapstad at gmail.com Thu Oct 5 11:15:16 2006 From: tarjei.knapstad at gmail.com (Tarjei Knapstad) Date: Thu, 5 Oct 2006 13:15:16 +0200 Subject: Glade 3 is not in Core In-Reply-To: <1159625194.3252.2.camel@localhost.localdomain> References: <1159623961.2684.2.camel@vader.jdub.homelinux.org> <1159625194.3252.2.camel@localhost.localdomain> Message-ID: On 9/30/06, Matthias Clasen wrote: > On Sat, 2006-09-30 at 08:46 -0500, Josh Boyer wrote: > > On Sat, 2006-09-30 at 15:18 +0200, Damien Durand wrote: > > > Hi, > > > > > > Just a small mail to inform you that glade 3 is not in core. The > > > version available is not up to date, 2.12 and it'll be great to > > > upgrade to the latest release., > > > > 1) I'm pretty sure the package maintainer knows this already. > > > > 2) Things like this belong in bugzilla. > > > > 3) I highly doubt any sort of upgrade for Fedora Core 6 is out of the > > question given that the freeze is in place. Perhaps for FC7 though. > > > > josh > > > > It should be pointed out that despite the name, glade3 is a different > program and not just a newer version of glade2. And when thinking about > obsoleting glade2, there are interesting alternatives like gazpacho. > I thought glade2 was for gtk 2.6, while glade3 exposes the gtk 2.8 API? Given this it's a bit strange I think to include a GUI builder tool for an API that is obsolete in the distro (Fedora 6 is at gtk 2.10 so this might be a problem in any case?) Anyway, gazpacho is here for anyone interested: http://gazpacho.sicem.biz/ Regards, -- Tarjei From denis at poolshark.org Thu Oct 5 11:28:06 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 05 Oct 2006 13:28:06 +0200 Subject: Glade 3 is not in Core In-Reply-To: References: <1159623961.2684.2.camel@vader.jdub.homelinux.org> <1159625194.3252.2.camel@localhost.localdomain> Message-ID: <4524EC46.9080200@poolshark.org> Tarjei Knapstad wrote: > Anyway, gazpacho is here for anyone interested: > http://gazpacho.sicem.biz/ And C++ fans will enjoy Gideon, submitted for review. From fedora at camperquake.de Thu Oct 5 11:34:23 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 5 Oct 2006 13:34:23 +0200 Subject: Glade 3 is not in Core In-Reply-To: References: <1159623961.2684.2.camel@vader.jdub.homelinux.org> <1159625194.3252.2.camel@localhost.localdomain> Message-ID: <20061005133423.7473df13@banea.int.addix.net> Hi. On Thu, 5 Oct 2006 13:15:16 +0200, Tarjei Knapstad wrote: > Anyway, gazpacho is here for anyone interested: > http://gazpacho.sicem.biz/ It is also in Extras :) From kushaldas at gmail.com Thu Oct 5 12:20:42 2006 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 5 Oct 2006 17:50:42 +0530 Subject: Need help for my talk proposal at FOSS.IN Message-ID: <200610051750.47777.kushaldas@gmail.com> Hi, Me submitting a talk proposal for FOSS.IN (http://foss.in) on Fedora Extras. The current proposal: ********************************************************************************************* "Inside of Fedora Extras" Fedora Extras is part of the larger Fedora Project and is a volunteer-based community effort to create a repository of packages that compliment Fedora Core. The Fedora Extras repository is available for Fedora Core 3 and above versions. This repository is enabled by default from Fedora Core 4 onwards. Any one can contribute to the Fedora Extras project by following the rules listed at the site. The first part of the talk is to clarify these steps one by another giving stress on "Install the Build-System Client Tools ", "Configure Your System for Fedora Extras CVS" The second part will be more technical. Explaining the guidelines with a real application spec file. This will include things like: # Naming # Legal # Writing a package from scratch # Modifying an existing package # Filesystem Layout # Use rpmlint # Changelogs # Tags # Build root tag # Requires # BuildRequires # Summary and description # Encoding # Documentation # Compiler flags # Exclusion of Static Libraries # Duplication of system libraries # Configuration files # Desktop files # Macros ********************************************************************************************* I need help to refresh the proposal, the last date of submission is coming up.. Regards, Kushal -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Oct 5 12:27:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Oct 2006 17:57:39 +0530 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1160042163.24866.47.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> <1160042163.24866.47.camel@mccallum.corsepiu.local> Message-ID: <4524FA3B.3020302@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2006-10-05 at 10:11 +0100, Paul Howarth wrote: >> Ralf Corsepius wrote: >>> On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: >>>>>>>>> "RC" == Ralf Corsepius writes: >>>> RC> In addition to all this, another issue has popped up, which IMO >>>> RC> renders shipping static libs as part of Fedora very questionable >>>> RC> (to say the least) >>>> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 >>>> >>>> Surely this is a bug in RPM, >>> RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( >> It was jbj that closed it it WONTFIX, not the RH rpm maintainer. > > <*grin*/> I am aware about this, nevertheless I regard anybody who > closes bugs on an FC package (Note: this PR was against rpm*fc5.*.rpm) > to be a RH maintainer. Anybody in the fedorabugs group has the ability to close bugs in all of Fedora. It doesnt have to be a RH maintainer and moreover the bug was not closed. Rahul From bugs.michael at gmx.net Thu Oct 5 13:16:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 5 Oct 2006 15:16:47 +0200 Subject: Need help for my talk proposal at FOSS.IN In-Reply-To: <200610051750.47777.kushaldas@gmail.com> References: <200610051750.47777.kushaldas@gmail.com> Message-ID: <20061005151647.d92fcf84.bugs.michael@gmx.net> On Thu, 5 Oct 2006 17:50:42 +0530, Kushal Das wrote: > Hi, > > Me submitting a talk proposal for FOSS.IN (http://foss.in) on Fedora Extras. > > The current proposal: > > ********************************************************************************************* > "Inside of Fedora Extras" > > Fedora Extras is part of the larger Fedora Project and is a volunteer-based > community effort to create a repository of packages that compliment Fedora > Core. The Fedora Extras repository is available for Fedora Core 3 and above > versions. This repository is enabled by default from Fedora Core 4 onwards. > > Any one can contribute to the Fedora Extras project by following the rules > listed at the site. > The first part of the talk is to clarify these steps one by another giving > stress on "Install the Build-System Client Tools ", "Configure Your System > for Fedora Extras CVS" > The second part will be more technical. Explaining the guidelines with a real > application spec file. > > This will include things like: > # Naming > # Legal > # Writing a package from scratch > # Modifying an existing package > # Filesystem Layout > # Use rpmlint > # Changelogs > # Tags > # Build root tag > # Requires > # BuildRequires > # Summary and description > # Encoding > # Documentation > # Compiler flags > # Exclusion of Static Libraries > # Duplication of system libraries > # Configuration files > # Desktop files > # Macros > > ********************************************************************************************* > > I need help to refresh the proposal, the last date of submission is coming > up.. What help do you need exactly? There's not a single question mark in your message. Are you a Fedora Extras contributor with hands-on experience? Are you familiar with the guidelines and processes? Or are you trying to base your talk on the fragments found in the Fedora Extras Wiki? From kushaldas at gmail.com Thu Oct 5 13:27:03 2006 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 5 Oct 2006 18:57:03 +0530 Subject: Need help for my talk proposal at FOSS.IN In-Reply-To: <20061005151647.d92fcf84.bugs.michael@gmx.net> References: <200610051750.47777.kushaldas@gmail.com> <20061005151647.d92fcf84.bugs.michael@gmx.net> Message-ID: <200610051857.03288.kushaldas@gmail.com> On Thursday 05 October 2006 18:46, Michael Schwendt wrote: > What help do you need exactly? There's not a single question mark in your > message. Are you a Fedora Extras contributor with hands-on experience? Are > you familiar with the guidelines and processes? Or are you trying to base > your talk on the fragments found in the Fedora Extras Wiki? Me started as a Fedora Extras a contributor with only one package. I am familiar with the process and the guidelines(not totally the second one, still learning). My talk will be based on the wiki 'coz people are going to read that at starting. regards, Kushal From Christian.Iseli at licr.org Thu Oct 5 13:39:40 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 5 Oct 2006 15:39:40 +0200 Subject: semi-mass rebuild completed In-Reply-To: <20061005115607.5a42c921@ludwig-alpha> References: <20061005115607.5a42c921@ludwig-alpha> Message-ID: <20061005153940.1811ef72@ludwig-alpha> On Thu, 5 Oct 2006 11:56:07 +0200, Christian Iseli wrote: > There are three duds: > libcdio http://buildsys.fedoraproject.org/build-status/job.psp?uid=18982 > kawa http://buildsys.fedoraproject.org/build-status/job.psp?uid=19052 > liblrdf http://buildsys.fedoraproject.org/build-status/job.psp?uid=19046 > > Guess I'll open 3 BZ tickets... libcdio seems to have been taken care of. So now we have: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209451 (kawa) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209453 (liblrdf) C From rc040203 at freenet.de Thu Oct 5 14:18:38 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Oct 2006 16:18:38 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <4524FA3B.3020302@fedoraproject.org> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> <1160042163.24866.47.camel@mccallum.corsepiu.local> <4524FA3B.3020302@fedoraproject.org> Message-ID: <1160057919.24866.58.camel@mccallum.corsepiu.local> On Thu, 2006-10-05 at 17:57 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Thu, 2006-10-05 at 10:11 +0100, Paul Howarth wrote: > >> Ralf Corsepius wrote: > >>> On Wed, 2006-10-04 at 12:17 -0500, Jason L Tibbitts III wrote: > >>>>>>>>> "RC" == Ralf Corsepius writes: > >>>> RC> In addition to all this, another issue has popped up, which IMO > >>>> RC> renders shipping static libs as part of Fedora very questionable > >>>> RC> (to say the least) > >>>> RC> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 > >>>> > >>>> Surely this is a bug in RPM, > >>> RH's rpm maintainers don't seem to agree, they closed it "WONTFIX" :( > >> It was jbj that closed it it WONTFIX, not the RH rpm maintainer. > > > > <*grin*/> I am aware about this, nevertheless I regard anybody who > > closes bugs on an FC package (Note: this PR was against rpm*fc5.*.rpm) > > to be a RH maintainer. > > Anybody in the fedorabugs group has the ability to close bugs in all of > Fedora. It doesnt have to be a RH maintainer Then it might be time to reconsider this practice. The way some sort of PRs are being handled *at* RH slowly p***es ME off. > and moreover the bug was not closed. This half of your sentence is true, I stand corrected, in this case, unlike many other before, it had not been closed. Ralf From sundaram at fedoraproject.org Thu Oct 5 14:28:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Oct 2006 19:58:39 +0530 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1160057919.24866.58.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> <1160042163.24866.47.camel@mccallum.corsepiu.local> <4524FA3B.3020302@fedoraproject.org> <1160057919.24866.58.camel@mccallum.corsepiu.local> Message-ID: <45251697.1010901@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2006-10-05 at 17:57 +0530, Rahul Sundaram wrote: >> Anybody in the fedorabugs group has the ability to close bugs in all of >> Fedora. It doesnt have to be a RH maintainer > Then it might be time to reconsider this practice. The way some sort of > PRs are being handled *at* RH slowly p***es ME off. Fedorabugs group access is very useful for triaging and I dont want to throw away that unnecessarily. If you believe that non maintainers are closing bug reports when they shouldnt, point out the person to the list and the person can be advised or removed from the fedorabugs group. If Red Hat maintainers are closing bug reports when they shouldnt, fedorabugs group has nothing to do with it and removing people off that group wont solve the problem. Rahul From rc040203 at freenet.de Thu Oct 5 15:41:14 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Oct 2006 17:41:14 +0200 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <45251697.1010901@fedoraproject.org> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> <1160042163.24866.47.camel@mccallum.corsepiu.local> <4524FA3B.3020302@fedoraproject.org> <1160057919.24866.58.camel@mccallum.corsepiu.local> <45251697.1010901@fedoraproject.org> Message-ID: <1160062874.24866.84.camel@mccallum.corsepiu.local> On Thu, 2006-10-05 at 19:58 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Thu, 2006-10-05 at 17:57 +0530, Rahul Sundaram wrote: > > >> Anybody in the fedorabugs group has the ability to close bugs in all of > >> Fedora. It doesnt have to be a RH maintainer > > Then it might be time to reconsider this practice. The way some sort of > > PRs are being handled *at* RH slowly p***es ME off. > > Fedorabugs group access is very useful for triaging and I dont want to > throw away that unnecessarily. > > If you believe that non maintainers are closing bug reports when they > shouldnt, point out the person to the list and the person can be advised > or removed from the fedorabugs group. I don't consider it to be my task to denunciate your colleagues in public. It's RH's management's job to monitor their employees and to take appropriate measures to improve overall quality of the product and coordination of work with people outside of RH. All I am doing is expressing my opinion and it's redhat's freedom to ignore it, or to find channels to communicate this to the appropriate "switches". > If Red Hat maintainers are closing > bug reports when they shouldnt, fedorabugs group has nothing to do with > it and removing people off that group wont solve the problem. fedorabugs and bugzilla are implementation details. To put this on another level, what I am actually saying is: I question their current usage and implementation in their usability and effectiveness. Ralf From jkeating at redhat.com Thu Oct 5 15:49:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Oct 2006 11:49:26 -0400 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1160062874.24866.84.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <45251697.1010901@fedoraproject.org> <1160062874.24866.84.camel@mccallum.corsepiu.local> Message-ID: <200610051149.30462.jkeating@redhat.com> On Thursday 05 October 2006 11:41, Ralf Corsepius wrote: > fedorabugs and bugzilla are implementation details. To put this on > another level, what I am actually saying is: I question their current > usage and implementation in their usability and effectiveness. Question all you want. Provide alternative options and maybe somebody will pay attention. Ya know, constructive feedback. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Oct 5 15:58:17 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Oct 2006 21:28:17 +0530 Subject: linking statically against dietlibc: a blocker? In-Reply-To: <1160062874.24866.84.camel@mccallum.corsepiu.local> References: <20061003210947.GA2838@free.fr> <1159922507.13363.258.camel@mccallum.corsepiu.local> <1159980500.13363.379.camel@mccallum.corsepiu.local> <1160039058.24866.44.camel@mccallum.corsepiu.local> <4524CC38.6020600@city-fan.org> <1160042163.24866.47.camel@mccallum.corsepiu.local> <4524FA3B.3020302@fedoraproject.org> <1160057919.24866.58.camel@mccallum.corsepiu.local> <45251697.1010901@fedoraproject.org> <1160062874.24866.84.camel@mccallum.corsepiu.local> Message-ID: <45252B99.3040506@fedoraproject.org> Ralf Corsepius wrote: > I don't consider it to be my task to denunciate your colleagues in > public. It's RH's management's job to monitor their employees and to > take appropriate measures to improve overall quality of the product and > coordination of work with people outside of RH. All I am doing is > expressing my opinion and it's redhat's freedom to ignore it, or to find > channels to communicate this to the appropriate "switches". Unless you state your problems clearly there is no way anything is going to be fixed. So again, do you have problems with maintainers closing bugs or do you have problems with non maintainers closing bugs? Point out specific bugzilla reports and people can deal with them. >> If Red Hat maintainers are closing >> bug reports when they shouldnt, fedorabugs group has nothing to do with >> it and removing people off that group wont solve the problem. > fedorabugs and bugzilla are implementation details. To put this on > another level, what I am actually saying is: I question their current > usage and implementation in their usability and effectiveness. Your claim incorrectly that only Red Hat maintainers can close bugs in Fedora Core. The particular bug report was not closed either. When I pointed out that non maintainers can close bug reports, you said that fedorabugs practice should be reconsidered. If maintainers are closing bugs, reconsidering the practice of fedorabugs group is going to make zero differences to that. Painting broad strokes wont help anyone. Rahul From green at redhat.com Thu Oct 5 18:01:01 2006 From: green at redhat.com (Anthony Green) Date: Thu, 05 Oct 2006 11:01:01 -0700 Subject: semi-mass rebuild completed In-Reply-To: <20061005153940.1811ef72@ludwig-alpha> References: <20061005115607.5a42c921@ludwig-alpha> <20061005153940.1811ef72@ludwig-alpha> Message-ID: <1160071261.2970.49.camel@localhost.localdomain> On Thu, 2006-10-05 at 15:39 +0200, Christian Iseli wrote: > So now we have: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209451 (kawa) This is a gjdoc regression from a recent update. I'm putting a work-around in the kawa package for now. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209453 (liblrdf) I was %excluding the .la file in the %files section, but I guess that doesn't work anymore. I'll delete the file after installation instead. AG From caillon at redhat.com Thu Oct 5 20:06:13 2006 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 05 Oct 2006 16:06:13 -0400 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <1159997686.24351.141.camel@viper.local> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> Message-ID: <452565B5.5040608@redhat.com> Ville Skytt? wrote: > On Wed, 2006-10-04 at 14:58 -0400, Christopher Aillon wrote: > >> If a package doesn't get a fair chance to be picked up before dropped, >> I'd say that's broken. > > While dropping [0] may be a bit rough, personally I think it worked well > as a trigger for someone to actually step up in the NetworkManager-vpnc > case. We had people ready to step up beforehand. I had volunteered, and perhaps others. But david said he had it, so it was left alone. > [0] Even when defined and occurred as "removing only the rpm files from > the development repository according to the plan announced well > beforehand and separately warned about several times on two lists before > it actually took place". There was fair warning, but nothing anyone can do if the owner is holding a package hostage. David, the owner, said he would do it, and didn't. And then it was dropped. That's broken. From cweyl at alumni.drew.edu Thu Oct 5 21:52:25 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 5 Oct 2006 14:52:25 -0700 Subject: rpms/perl-Readonly/devel perl-Readonly.spec,1.2,1.3 In-Reply-To: <1160030011.24351.159.camel@viper.local> References: <200610050126.k951QMSa026211@cvs-int.fedora.redhat.com> <1160030011.24351.159.camel@viper.local> Message-ID: <7dd7ab490610051452u3de87153o67b210c73760c35b@mail.gmail.com> On 10/4/06, Ville Skytt? wrote: > On Wed, 2006-10-04 at 18:26 -0700, Chris Weyl wrote: > > > %changelog > > +* Wed Oct 04 2006 Chris Weyl 1.03-6 > > +- add explict requires on perl(Readonly::XS). perl(Readonly::XS) is available > > + for all architectures fedora supports, so there's no good reason to not > > + require it. > > Hm... except maybe that there's now a build dependency loop, > perl-ReadOnly-XS BuildRequires perl-ReadOnly. Almost... perl-Readonly requires (not buildrequires) perl(Readonly::XS), whereas perl-Readonly-XS requires and buildrequires perl(Readonly). So long as perl-Readonly is built and in the repos before perl-Readonly-XS is queued, and perl-Readonly-XS is available before someone tries to install perl-Readonly, we're good.... right? -Chris -- Chris Weyl Ex astris, scientia From buildsys at fedoraproject.org Fri Oct 6 00:16:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 5 Oct 2006 20:16:29 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-05 Message-ID: <20061006001629.E705D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 182 FreeWnn-1.1.1_a021-2.fc6 NetworkManager-vpnc-0.7.0-0.cvs20060929.2.fc6 OpenSceneGraph-1.2-1.fc6 PyKDE-3.16.0-2.fc6 PyX-0.9-3.fc6 R-RScaLAPACK-0.5.1-8.fc6 SDL_gfx-2.0.13-7.fc6 Thunar-0.4.0-0.6.rc1.fc6 XaraLX-0.7-7.fc6.r1759 adns-1.2-5.fc6 amarok-1.4.3-5.fc6 ardour-0.99.3-7.fc6 autotrace-0.31.1-14.fc6 azureus-2.5.0.0-7.fc6 banner-1.3.1-4.fc6 basket-0.5.0-10.fc6 blktool-4-6.fc6 bochs-2.3-3.fc6 bwm-ng-0.5-8.fc6 cfengine-2.1.21-2.fc6 clamav-0.88.4-4.fc6 cyrus-imapd-2.3.7-4.fc6 dap-freeform_handler-3.7.2-2.fc6 dap-hdf4_handler-3.7.2-3.fc6 dap-netcdf_handler-3.7.3-2.fc6 dap-server-3.7.1-3.fc6 dhcp-forwarder-0.7-11.fc6 dssi-0.9.1-10.fc6 dynamite-0.1-6.fc6 ebtables-2.0.8-0.7.rc2.fc6 eds-feed-0.5.0-2.fc6 eventlog-0.2.5-2.fc6 exim-4.63-5.fc6 exiv2-0.11-3.fc6 farsight-0.1.8-3.fc6 fatsort-0.9.6.1-8.fc6 fftw-3.1.2-3.fc6 filelight-1.0-9.fc6 fluidsynth-1.0.7-8.a.fc6 fluidsynth-dssi-0.9.1-7.fc6 fontforge-20060822-2.fc6 gaim-galago-0.5.0-3.fc6 gaim-guifications-2.13-0.3.beta3.fc6 gajim-0.10.1-3.fc6 galeon-2.0.3-2.fc6 gcin-1.2.6-2.fc6 git-1.4.2.3-1.fc6 gkrellm-2.2.9-10.fc6 gnash-0.7.1-9.fc6 gnet2-2.0.7-9.fc6 gnokii-0.6.14-2.fc6 gnome-build-0.1.3-11.fc6 gnomesword-2.1.6-5.fc6 gnupg2-1.9.22-8.fc6 gossip-0.17-2.fc6 gpsim-0.21.11-9.fc6 gputils-0.13.4-2.fc6 grace-5.1.20-6.fc6 grads-1.9b4-17.fc6 graphviz-2.8-5.fc6 gstreamer-python-0.10.5-2.fc6 gtk-sharp-1.0.10-11.fc6 guiloader-2.8.0-2.fc6 hexter-dssi-0.5.9-6.fc6 htop-0.6.4-1.fc6 ip-sentinel-0.12-9.fc6 ipe-6.0-0.14.pre27.fc6 itext-1.3-3.fc6 jakarta-commons-cli-1.0-6jpp_10.fc6 jasper-1.701.0-15.fc6.2 jhead-2.6-3.fc6 jogl-1.0.0-5.7.beta5.fc6 k3d-0.6.2.0-2.fc6 kawa-1.8-11.fc6 kdemultimedia-extras-3.5.4-8.fc6 kdesvn-0.10.0-1.fc6 kdiff3-0.9.90-7.fc6 kicad-2006.08.28-2.fc6 koffice-1.5.2-3.fc6 kover-2.9.6-8 kphotoalbum-2.2-6.fc6 lash-0.5.1-10.fc6 leafnode-1.11.5-2.fc6 libannodex-0.7.3-5.fc6 libcdio-0.77-3.fc6 libcmml-0.9.1-3.fc6 libdap-3.7.2-2.fc6 libdnet-1.10-4.fc6 libetpan-0.46-2.fc6 libgalago-gtk-0.5.0-3.fc6 libifp-1.0.0.2-4.fc6 liblo-0.23-11.fc6 liblrdf-0.4.0-10.fc6 libnc-dap-3.6.2-4.fc6 liboggz-0.9.4-3.fc6 libpaper-1.1.20-5.fc6 libpqxx-2.6.8-3.fc6 libstatgrab-0.13-3.fc6 libsynaptics-0.14.6b-4.fc6 libuninameslist-0.0-6.20060907 licq-1.3.2-11 liferea-1.0.23-2.fc6 lsscsi-0.17-4 milter-greylist-2.1.12-3.fc6 mod_annodex-0.2.2-6.fc6 monodoc-1.1.17-6.fc6 most-4.10.2-5.fc6 mtd-utils-1.0.1-2.fc6 mxml-2.2.2-7.fc6 mysql-connector-java-3.1.12-3.fc6 nexuiz-2.1-2.fc6 ngrep-1.44-7.fc6 ninja-1.5.8.1-6 octave-forge-2006.07.09-7.fc6 ode-0.7-2.fc6 oooqs2-1.0-3.fc6 opencv-0.9.9-3.fc6 orange-0.3-3.cvs20051118.fc6 pam_keyring-0.0.8-3.fc6 paraview-2.4.4-2.fc6 pdsh-2.11-5.fc6 pengupop-2.1.4-3.fc6 perl-Device-SerialPort-1.002-3.fc6 perl-Error-0.17005-1.fc6 perl-Gnome2-Canvas-1.002-6.fc6 perl-Imager-0.54-2.fc6 perl-Module-CoreList-2.09-1.fc6 perl-POE-Component-DBIAgent-0.26-2.fc6 perl-Readonly-1.03-6.fc6 perl-Readonly-XS-1.04-5.fc6 perl-Spreadsheet-ParseExcel-0.2603-3.fc6 perl-Test-MockObject-1.07-1.fc6 php-pear-Console-Getargs-1.3.2-1.fc6 php-pecl-Fileinfo-1.0.3-3.fc6 picocom-1.4-3.fc6 pikdev-0.9.2-2.fc6 plone-2.5-4.fc6 python-enchant-1.1.5-5.fc6 python-twisted-1.3.0-7.fc6 qps-1.9.18.6-1.fc6 rafkill-1.2.2-4.fc6 raptor-1.4.9-5.fc6 rblcheck-1.5-12.fc6 rdiff-backup-1.0.4-3.fc6 rekall-2.4.3-5.fc6 rman-3.2-5.fc6 sabayon-2.12.4-4.fc6 sblim-cmpi-base-1.5.4-6.fc6 sblim-cmpi-devel-1.0.4-4.fc6 sblim-wbemcli-1.5.1-4.fc6 scanssh-2.1-9.fc6 scribus-1.3.3.4-1.fc6 seq24-0.8.7-6.fc6 showimg-0.9.5-11.fc6 smarteiffel-2.2-6.fc6 spandsp-0.0.2-1.pre26 ss5-3.5.9-3 swh-plugins-0.4.15-4.fc6 sword-1.5.8-10.fc6 synce-gnomevfs-0.9.0-5.fc6 synce-software-manager-0.9.0-7.fc6 synce-trayicon-0.9.0-8.fc6 sysprof-1.0.3-4.fc6 sysprof-kmod-1.0.3-3.2.6.18_1.2726.fc6 t1lib-5.1.0-8.fc6 t1utils-1.32-8.fc6 telepathy-gabble-0.3.10-1.fc6 tellico-1.2.2-2.fc6 tor-0.1.1.24-1.fc6 tuxpaint-0.9.15b-4.fc6 unshield-0.5-5.fc6 util-vserver-0.30.210-5.fc6 uuid-1.5.1-2.fc6 uw-imap-2006a-4.fc6 vorbisgain-0.34-3.fc6 whatmask-1.2-4.fc6 wxMaxima-0.7.0a-1.fc6.1 xchm-1.9-6.fc6 xfce4-weather-plugin-0.4.9-8.fc6 yum-utils-1.0-2.fc6 z88dk-1.6-10.fc6 zynaddsubfx-2.2.1-13.fc6 Packages built and released for Fedora Extras 5: 14 amarok-1.4.3-5.fc5 git-1.4.2.3-1.fc5 gnome-python2-gda-2.14.0-2.fc5 htop-0.6.4-1.fc5 octave-2.9.9-1.fc5 octave-forge-2006.07.09-6.fc5 perl-Error-0.17005-1.fc5 perl-Module-CoreList-2.09-1.fc5 perl-Readonly-1.03-6.fc5 perl-Test-MockObject-1.07-1.fc5 php-pear-Console-Getargs-1.3.2-1.fc5 plone-2.5-4.fc5 qps-1.9.18.6-1.fc5 uw-imap-2006a-4.fc5 Packages built and released for Fedora Extras 4: 2 git-1.4.2.3-1.fc4 perl-Module-CoreList-2.09-1.fc4 Packages built and released for Fedora Extras 3: 1 git-1.4.2.3-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 Oct 6 00:16:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 5 Oct 2006 20:16:59 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-05 Message-ID: <20061006001659.70C8615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE5 > FE6 (0:0.2.0-6.fc5.1 > 0:0.2.0-5.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From buildsys at fedoraproject.org Fri Oct 6 00:56:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 06 Oct 2006 00:56:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-05 Message-ID: <20061006005614.9845.12330@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (5 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (5 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (5 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (20 days) plague - 0.4.4.1-2.fc3.noarch (20 days) plague - 0.4.4.1-2.fc4.noarch (20 days) plague - 0.4.4.1-2.fc4.noarch (20 days) plague - 0.4.4.1-2.fc4.noarch (20 days) giallu AT gmail.com kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i586 kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 kmod-sysprof-PAE - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 sysprof - 1.0.3-4.fc6.ppc j.w.r.degoede AT hhs.nl tremulous - 1.1.0-2.fc5.i386 (23 days) tremulous - 1.1.0-2.fc5.ppc (23 days) tremulous - 1.1.0-2.fc5.x86_64 (23 days) orion AT cora.nwra.com paraview - 2.4.4-2.fc6.i386 paraview - 2.4.4-2.fc6.ppc paraview - 2.4.4-2.fc6.x86_64 paraview-mpi - 2.4.4-2.fc6.i386 paraview-mpi - 2.4.4-2.fc6.ppc paraview-mpi - 2.4.4-2.fc6.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 kmod-em8300-PAE - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 kmod-em8300-smp - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6 kmod-em8300-smp-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6smp paraview-2.4.4-2.fc6.ppc requires libvtkPVServerCommonPython.so paraview-2.4.4-2.fc6.ppc requires libvtkPVServerManagerPython.so paraview-mpi-2.4.4-2.fc6.ppc requires libvtkPVServerCommonPython.so paraview-mpi-2.4.4-2.fc6.ppc requires libvtkPVServerManagerPython.so sysprof-1.0.3-4.fc6.ppc requires kmod-sysprof >= 0:1.0.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen paraview-2.4.4-2.fc6.x86_64 requires libvtkPVServerManagerPython.so()(64bit) paraview-2.4.4-2.fc6.x86_64 requires libvtkPVServerCommonPython.so()(64bit) paraview-mpi-2.4.4-2.fc6.x86_64 requires libvtkPVServerManagerPython.so()(64bit) paraview-mpi-2.4.4-2.fc6.x86_64 requires libvtkPVServerCommonPython.so()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-em8300-PAE-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-sysprof-PAE-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen paraview-2.4.4-2.fc6.i386 requires libvtkPVServerCommonPython.so paraview-2.4.4-2.fc6.i386 requires libvtkPVServerManagerPython.so paraview-mpi-2.4.4-2.fc6.i386 requires libvtkPVServerCommonPython.so paraview-mpi-2.4.4-2.fc6.i386 requires libvtkPVServerManagerPython.so Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.ppc requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.x86_64 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- tremulous-1.1.0-2.fc5.i386 requires tremulous-data = 0:1.1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: giallu AT gmail.com package: sysprof - 1.0.3-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: kmod-sysprof >= 0:1.0.3 package: kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6xen package: kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6 package: kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump package: kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6 package: kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6xen package: kmod-sysprof-PAE - 1.0.3-3.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6PAE package: kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2726.fc6 package: kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6kdump ====================================================================== New report for: orion AT cora.nwra.com package: paraview - 2.4.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview-mpi - 2.4.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview - 2.4.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvtkPVServerManagerPython.so()(64bit) libvtkPVServerCommonPython.so()(64bit) package: paraview-mpi - 2.4.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvtkPVServerManagerPython.so()(64bit) libvtkPVServerCommonPython.so()(64bit) package: paraview - 2.4.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview-mpi - 2.4.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so ====================================================================== New report for: ville.skytta AT iki.fi package: kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2726.fc6 package: kmod-em8300-smp - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2726.fc6smp package: kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump package: kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6xen package: kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2726.fc6 package: kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2726.fc6 package: kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6 package: kmod-em8300-PAE - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6PAE package: kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6kdump package: kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2726.fc6xen From bugs.michael at gmx.net Fri Oct 6 01:19:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 6 Oct 2006 03:19:53 +0200 Subject: rpms/perl-Readonly/devel perl-Readonly.spec,1.2,1.3 In-Reply-To: <7dd7ab490610051452u3de87153o67b210c73760c35b@mail.gmail.com> References: <200610050126.k951QMSa026211@cvs-int.fedora.redhat.com> <1160030011.24351.159.camel@viper.local> <7dd7ab490610051452u3de87153o67b210c73760c35b@mail.gmail.com> Message-ID: <20061006031953.8d948e66.bugs.michael@gmx.net> On Thu, 5 Oct 2006 14:52:25 -0700, Chris Weyl wrote: > On 10/4/06, Ville Skytt? wrote: > > On Wed, 2006-10-04 at 18:26 -0700, Chris Weyl wrote: > > > > > %changelog > > > +* Wed Oct 04 2006 Chris Weyl 1.03-6 > > > +- add explict requires on perl(Readonly::XS). perl(Readonly::XS) is available > > > + for all architectures fedora supports, so there's no good reason to not > > > + require it. > > > > Hm... except maybe that there's now a build dependency loop, > > perl-ReadOnly-XS BuildRequires perl-ReadOnly. > > Almost... perl-Readonly requires (not buildrequires) > perl(Readonly::XS), whereas perl-Readonly-XS requires and > buildrequires perl(Readonly). So long as perl-Readonly is built and > in the repos before perl-Readonly-XS is queued, and perl-Readonly-XS > is available before someone tries to install perl-Readonly, we're > good.... right? Still a loop, or what am I missing? Assume you start from scratch: 1. rpmbuild perl-Readonly => works 2. rpmbuild perl-Readonly-XS => needs BuildRequires perl-Readonly, which in turn Requires perl-Readonly-XS, which hasn't been built yet => *boom* From dwmw2 at infradead.org Fri Oct 6 09:30:15 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 06 Oct 2006 10:30:15 +0100 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <452565B5.5040608@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> Message-ID: <1160127015.26064.154.camel@pmac.infradead.org> On Thu, 2006-10-05 at 16:06 -0400, Christopher Aillon wrote: > We had people ready to step up beforehand. I had volunteered, and > perhaps others. But david said he had it, so it was left alone. > ... > > There was fair warning, but nothing anyone can do if the owner is > holding a package hostage. David, the owner, said he would do it, and > didn't. And then it was dropped. That's broken. The reason this doesn't happen in Core is because we tend not to be so possessive about our packages. With a few highly-strung exceptions, you can generally just commit sensible fixes to any package which needs them and the maintainer will be happy that you helped them out. It's a _team_ effort. Extras seems to lack that ethos, and people get massively proprietorial about their packages. And _that_, I think, is the root of the problem here. David is busy. He meant to fix it up, but he just didn't get round to it -- I can sympathise with that. But if this package had been in Core, someone else would have done it. -- dwmw2 From fedora at leemhuis.info Fri Oct 6 09:51:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Oct 2006 11:51:05 +0200 Subject: Team Effort (was: Re: Dear Fesco: Orphan package process needs work) In-Reply-To: <1160127015.26064.154.camel@pmac.infradead.org> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> Message-ID: <45262709.9020000@leemhuis.info> David Woodhouse schrieb: > On Thu, 2006-10-05 at 16:06 -0400, Christopher Aillon wrote: >> We had people ready to step up beforehand. I had volunteered, and >> perhaps others. But david said he had it, so it was left alone. >> There was fair warning, but nothing anyone can do if the owner is >> holding a package hostage. David, the owner, said he would do it, and >> didn't. And then it was dropped. That's broken. > > The reason this doesn't happen in Core is because we tend not to be so > possessive about our packages. With a few highly-strung exceptions, you > can generally just commit sensible fixes to any package which needs them > and the maintainer will be happy that you helped them out. It's a _team_ > effort. > > Extras seems to lack that ethos, and people get massively proprietorial > about their packages. And _that_, I think, is the root of the problem > here. This is part of the problem, not the root of it IMHO. I agree that we need to change this in Extras to make it more a team effort. That was discussed already in FESCo, but other things took more attention for now. But it's still on my Todo-List But the root of the problem in this case is FESCo-made. We didn't want people to fix other peoples packages because one of the major goals of the m{ae}ss-rebuild was: Make sure all maintainers are still around, know their packages, khow to commit changes to CVS and all that stuff. That's needed (until we have something better) in Extras because people simply vanish often without telling us. That something that normally does not happen in Core. CU thl From kushaldas at gmail.com Fri Oct 6 09:52:42 2006 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 6 Oct 2006 15:22:42 +0530 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <1160127015.26064.154.camel@pmac.infradead.org> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> Message-ID: Where can I find a list of the orphaned packages ? On 10/6/06, David Woodhouse wrote: > On Thu, 2006-10-05 at 16:06 -0400, Christopher Aillon wrote: > > We had people ready to step up beforehand. I had volunteered, and > > perhaps others. But david said he had it, so it was left alone. > > > ... > > > > There was fair warning, but nothing anyone can do if the owner is > > holding a package hostage. David, the owner, said he would do it, and > > didn't. And then it was dropped. That's broken. > > The reason this doesn't happen in Core is because we tend not to be so > possessive about our packages. With a few highly-strung exceptions, you > can generally just commit sensible fixes to any package which needs them > and the maintainer will be happy that you helped them out. It's a _team_ > effort. > > Extras seems to lack that ethos, and people get massively proprietorial > about their packages. And _that_, I think, is the root of the problem > here. > > David is busy. He meant to fix it up, but he just didn't get round to it > -- I can sympathise with that. But if this package had been in Core, > someone else would have done it. > > -- > dwmw2 > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From paul at city-fan.org Fri Oct 6 09:55:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Oct 2006 10:55:59 +0100 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> Message-ID: <4526282F.6050807@city-fan.org> Kushal Das wrote: > Where can I find a list of the orphaned packages ? http://fedoraproject.org/wiki/Extras/OrphanedPackages Paul. From kushaldas at gmail.com Fri Oct 6 11:04:31 2006 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 6 Oct 2006 16:34:31 +0530 Subject: Want to claim ownership of the orphaned package straw Message-ID: Hi, I want to claim ownership of the orphaned package straw. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186731 Regards, Kushal From fedora at leemhuis.info Fri Oct 6 11:22:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Oct 2006 13:22:28 +0200 Subject: Want to claim ownership of the orphaned package straw In-Reply-To: References: Message-ID: <45263C74.8070007@leemhuis.info> Kushal Das schrieb: > I want to claim ownership of the orphaned package straw. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186731 The old maintainer is back again and wants to maintain it again. He prepared updates already and will update owners.list and the wiki soon. CU thl From kushaldas at gmail.com Fri Oct 6 12:05:12 2006 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 6 Oct 2006 17:35:12 +0530 Subject: Want to claim ownership of the orphaned package straw In-Reply-To: <45263C74.8070007@leemhuis.info> References: <45263C74.8070007@leemhuis.info> Message-ID: On 10/6/06, Thorsten Leemhuis wrote: > > > Kushal Das schrieb: > > I want to claim ownership of the orphaned package straw. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186731 > > The old maintainer is back again and wants to maintain it again. He > prepared updates already and will update owners.list and the wiki soon. No problem :) Regards, Kushal From kushaldas at gmail.com Fri Oct 6 12:16:07 2006 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 6 Oct 2006 17:46:07 +0530 Subject: What about prozilla (Re: Want to claim ownership of the orphaned package straw) Message-ID: What about prozilla ? Can I go for that ? regards, Kushal From cweyl at alumni.drew.edu Fri Oct 6 16:25:13 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 6 Oct 2006 09:25:13 -0700 Subject: rpms/perl-Readonly/devel perl-Readonly.spec,1.2,1.3 In-Reply-To: <20061006031953.8d948e66.bugs.michael@gmx.net> References: <200610050126.k951QMSa026211@cvs-int.fedora.redhat.com> <1160030011.24351.159.camel@viper.local> <7dd7ab490610051452u3de87153o67b210c73760c35b@mail.gmail.com> <20061006031953.8d948e66.bugs.michael@gmx.net> Message-ID: <7dd7ab490610060925v1a211a17se802746625e686b0@mail.gmail.com> On 10/5/06, Michael Schwendt wrote: > On Thu, 5 Oct 2006 14:52:25 -0700, Chris Weyl wrote: > > > On 10/4/06, Ville Skytt? wrote: > > > On Wed, 2006-10-04 at 18:26 -0700, Chris Weyl wrote: > > > > > > > %changelog > > > > +* Wed Oct 04 2006 Chris Weyl 1.03-6 > > > > +- add explict requires on perl(Readonly::XS). perl(Readonly::XS) is available > > > > + for all architectures fedora supports, so there's no good reason to not > > > > + require it. > > > > > > Hm... except maybe that there's now a build dependency loop, > > > perl-ReadOnly-XS BuildRequires perl-ReadOnly. > > > > Almost... perl-Readonly requires (not buildrequires) > > perl(Readonly::XS), whereas perl-Readonly-XS requires and > > buildrequires perl(Readonly). So long as perl-Readonly is built and > > in the repos before perl-Readonly-XS is queued, and perl-Readonly-XS > > is available before someone tries to install perl-Readonly, we're > > good.... right? > > Still a loop, or what am I missing? Assume you start from scratch: > > 1. rpmbuild perl-Readonly => works > > 2. rpmbuild perl-Readonly-XS => needs BuildRequires perl-Readonly, > which in turn Requires perl-Readonly-XS, which hasn't been built yet > => *boom* Ah. Nice :) Ok, on examination, perl-Readonly-XS doesn't strictly buildrequires perl-Readonly, so I've dropped that BR and patched the Makefile.PL to not complain. That should cut the loop. -Chris -- Chris Weyl Ex astris, scientia From overholt at redhat.com Fri Oct 6 18:59:29 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 06 Oct 2006 14:59:29 -0400 Subject: semi-mass rebuild completed In-Reply-To: <1160071261.2970.49.camel@localhost.localdomain> References: <20061005115607.5a42c921@ludwig-alpha> <20061005153940.1811ef72@ludwig-alpha> <1160071261.2970.49.camel@localhost.localdomain> Message-ID: <1160161169.26317.19.camel@tophat.toronto.redhat.com> On Thu, 2006-05-10 at 11:01 -0700, Anthony Green wrote: > On Thu, 2006-10-05 at 15:39 +0200, Christian Iseli wrote: > > So now we have: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209451 (kawa) > > This is a gjdoc regression from a recent update. Technically the bug was always there but was masked due to the fact that it was non-BC compiled. The fix -- a simple missing Requires -- will be in tomorrow's rawhide push. Andrew "setting the record straight :)" Overholt -------------- 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 Oct 6 19:04:28 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 06 Oct 2006 14:04:28 -0500 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <1160127015.26064.154.camel@pmac.infradead.org> (David Woodhouse's message of "Fri, 06 Oct 2006 10:30:15 +0100") References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Extras seems to lack that ethos, and people get massively DW> proprietorial about their packages. And _that_, I think, is the DW> root of the problem here. I haven't seen too much of that, except for a few highly-strung exceptions. I've gone through and fixed packages before, and in fact we have a policy in under discussion that codifies this. (Basically, trusted members of the community always are free to fix things that need fixing.) That, however, isn't what the current issue is about. The bottom line is that packages still need to have at least one active maintainer, and if the maintainer disappears then we need to make sure that packages don't make it into the next release of the distro. We're up against a deadline here. Packages can always come back; nothing is permanently deleted, and there's no cutoff data for CDs or anything like that. All if would have taken to avoid this issue was a note saying "I'm really busy right now; someone please rebuild my packages and if you like add yourself as a co-maintainer." Problem solved. This happens all the time. We even have SIGs which act as virtual co-maintainers. - J< From tibbs at math.uh.edu Fri Oct 6 19:05:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 06 Oct 2006 14:05:45 -0500 Subject: Want to claim ownership of the orphaned package straw In-Reply-To: <45263C74.8070007@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 06 Oct 2006 13:22:28 +0200") References: <45263C74.8070007@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> The old maintainer is back again and wants to maintain it TL> again. He prepared updates already and will update owners.list and TL> the wiki soon. Which doesn't mean that it couldn't use a co-maintainer. - J< From bugs.michael at gmx.net Fri Oct 6 19:48:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 6 Oct 2006 21:48:40 +0200 Subject: owners.list to PackageDB translation status and opinions In-Reply-To: <45194CBE.4080007@fedoraproject.org> References: <1159251105.2864.54.camel@localhost> <45194CBE.4080007@fedoraproject.org> Message-ID: <20061006214840.8172aed1.bugs.michael@gmx.net> On Tue, 26 Sep 2006 21:22:30 +0530, Rahul wrote: > Toshio Kuratomi wrote: > > Hey guys, > > > > I'm working on a script to parse owners.list and import it into the new > > PackageDB. So far, the biggest hurdle has been that some email > > addresses in owners.list do not match with the email addresses in the > > accounts system. I've tracked most of these down with a few exceptions > > and caveats. > > > > extras-qa [] fedoraproject.org: This is the initial qa contact that is > > entered into bugzilla for bugs on a package. I'd like to discard this > > information and start fresh in the new packageDB. If a qa-contact > > should be applied to the package then it should be entered for each > > package, otherwise there will be no qa-contact. If we are currently > > using extras-qa to do something useful please let me know so we can work > > out what's sane to do here. > > > > extras-orphan [] fedoraproject.org: For orphaned packages. I think > > we're going to create an orphan account to fill this. > > > > Is there any particular reason this should be changed from nobody [] > fedoraproject.org? The bugzilla account e-mail address for orphaned packages has always been extras-orphan [] fedoraproject.org -- this is useful, because the address can be monitored and use in custom queries. Eliminating it would not be good. From Christian.Iseli at licr.org Fri Oct 6 20:50:38 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 6 Oct 2006 22:50:38 +0200 Subject: owners.list to PackageDB translation status and opinions In-Reply-To: <20061006214840.8172aed1.bugs.michael@gmx.net> References: <1159251105.2864.54.camel@localhost> <45194CBE.4080007@fedoraproject.org> <20061006214840.8172aed1.bugs.michael@gmx.net> Message-ID: <20061006225038.12607db1@ludwig-alpha> On Fri, 6 Oct 2006 21:48:40 +0200, Michael Schwendt wrote: > The bugzilla account e-mail address for orphaned packages has > always been extras-orphan [] fedoraproject.org -- this is useful, > because the address can be monitored and use in custom queries. > Eliminating it would not be good. +1 C From Christian.Iseli at licr.org Fri Oct 6 22:15:56 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 00:15:56 +0200 Subject: paraview dependency problem Message-ID: <20061007001556.414865e1@ludwig-alpha> Hi all, Ville asked me to keep an eye on unresolved deps in devel while he's away... Here's one I'd like some feedback on. Thanks, C package: paraview - 2.4.4-2.fc6.i386 from extras-development-i386 unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview-mpi - 2.4.4-2.fc6.i386 from extras-development-i386 unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview-mpi - 2.4.4-2.fc6.ppc from extras-development-ppc unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview - 2.4.4-2.fc6.ppc from extras-development-ppc unresolved deps: libvtkPVServerCommonPython.so libvtkPVServerManagerPython.so package: paraview - 2.4.4-2.fc6.x86_64 from extras-development-x86_64 unresolved deps: libvtkPVServerManagerPython.so()(64bit) libvtkPVServerCommonPython.so()(64bit) package: paraview-mpi - 2.4.4-2.fc6.x86_64 from extras-development-x86_64 unresolved deps: libvtkPVServerManagerPython.so()(64bit) libvtkPVServerCommonPython.so()(64bit) From Christian.Iseli at licr.org Fri Oct 6 23:07:37 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 01:07:37 +0200 Subject: Soon to be marked dead packages Message-ID: <20061007010737.79dd63fc@ludwig-alpha> Hi folks, The following list of packages will soon (tomorrow-ish) be marked dead in CVS (to avoid them being branched for FC-6 with no maintainer). Cheers, C ---- alsa-firmware alsa-tools amaya blam camstream cfs cpan2rpm dogtail doulos-fonts ecore edb edje eet embryo evas fonttools gdeskcal gfontview gnome-applet-netmon gnugo gourmet grhino gtkhtml36 gtranslator html-xml-utils icmpdn john lcdf-typetools lcov libevent libmatchbox MagicPoint mantis mediawiki nucleo polyxmass-common polyxmass-data polyxmass-doc pyspi python-nltk quadkonsole quarry repoml rkhunter rpmDirectoryCheck scim-chinese-standard scribus-templates silky spicctrl Sprog straw system-config-control tetex-fontools translate-toolkit ttf2pt1 v2strip zeroinstall-injector zoo From davej at redhat.com Fri Oct 6 23:19:19 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Oct 2006 19:19:19 -0400 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <20061006231919.GE31533@redhat.com> On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: > Hi folks, > > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). Are these actually broken in FC6 ? If they still compile, perhaps we can automate building some of them until a maintainer steps up ? I think magicpoint is the only thing I'd be sad to see go, but I have nowhere near the time to maintain it. Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Fri Oct 6 23:21:40 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Oct 2006 19:21:40 -0400 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <200610061921.44199.jkeating@redhat.com> On Friday 06 October 2006 19:07, Christian Iseli wrote: > dogtail > pyspi These two moved from Extras to Core a while ago, and were requested to get removed on http://fedoraproject.org/wiki/Extras/FC6Status . Those are not listed there anymore so one would think they got removed, so why are they showing up in needrebuild orphaned list? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Oct 7 00:26:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 06 Oct 2006 19:26:46 -0500 Subject: Soon to be marked dead packages In-Reply-To: <20061006231919.GE31533@redhat.com> (Dave Jones's message of "Fri, 6 Oct 2006 19:19:19 -0400") References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> Message-ID: >>>>> "DJ" == Dave Jones writes: DJ> If they still compile, perhaps we can automate building some of DJ> them until a maintainer steps up ? They need actual maintainers, not just some automated rebuilds. What happens if there's a security problem or a decision needs to be made about updates? A package can always branch for FC6 later if at least one maintainer appears. - J< From christoph.wickert at nurfuerspam.de Sat Oct 7 00:52:51 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 07 Oct 2006 02:52:51 +0200 Subject: taking over gnome-applet-netmon (Re: Soon to be marked dead packages) In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <1160182371.3639.5.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 01:07 +0200 schrieb Christian Iseli: > Hi folks, > > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). > > Cheers, > C > > ---- > gnome-applet-netmon I'd like to take this one over since I use it regularly and I already maintain some panel applets. Any objections or should I just go ahead? Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From buildsys at fedoraproject.org Sat Oct 7 00:57:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Oct 2006 20:57:16 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-06 Message-ID: <20061007005716.82CAE15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 62 Terminal-0.2.5.6-0.3.rc1.fc6 Thunar-0.4.0-0.10.rc1.fc6 acpitool-0.4.6-2.fc6 alsa-oss-1.0.12-3.fc6 cobbler-0.2.2-1.fc6 dirvish-1.2.1-2.fc6 exo-0.3.1.10-0.6.rc1.fc6 ghdl-0.25-0.73svn.0.fc6 gtk-xfce-engine-2.3.99.1-3.fc6 guiloader-c++-2.8.0-2.fc6 libassuan-0.9.2-1.fc6 libsmi-0.4.5-2.fc6 libxfce4mcs-4.3.99.1-2.fc6 libxfce4util-4.3.99.1-3.fc6 libxfcegui4-4.3.99.1-3.fc6 mirrormagic-2.0.2-2.fc6 mousepad-0.2.8-2.fc6 orage-4.3.99.1-4.fc6 perl-Readonly-XS-1.04-7.fc6 plib-1.8.4-8.fc6 plplot-5.6.1-7.fc6 python-matplotlib-0.87.6-1.fc6 python-turbojson-0.9.9-2.fc6 renrot-0.25-2.fc6 scim-tomoe-0.2.0-6.fc6 spandsp-0.0.3-1.pre23 supertuxkart-0.2-3.fc6 uw-imap-2006b-1.fc6 xfce-mcs-manager-4.3.99.1-3.fc6 xfce-mcs-plugins-4.3.99.1-3.fc6 xfce-utils-4.3.99.1-5.fc6 xfce4-appfinder-4.3.99.1-3.fc6 xfce4-battery-plugin-0.4.90.2-3.fc6 xfce4-clipman-plugin-0.5.99.1-3.fc6 xfce4-cpugraph-plugin-0.3.0-3.fc6 xfce4-dev-tools-4.3.99.1-3.fc6 xfce4-diskperf-plugin-2.0-3.fc6 xfce4-fsguard-plugin-0.3.0-3.fc6 xfce4-genmon-plugin-2.0-3.fc6 xfce4-icon-theme-4.3.99.1-3.fc6 xfce4-mailwatch-plugin-1.0.1-4.fc6 xfce4-minicmd-plugin-0.4-3.fc6 xfce4-mixer-4.3.99.1-3.fc6 xfce4-mount-plugin-0.4.8-1.fc6 xfce4-netload-plugin-0.4.0-3.fc6 xfce4-notes-plugin-1.3.99.1-3.fc6 xfce4-panel-4.3.99.1-7.fc6 xfce4-quicklauncher-plugin-1.9.2-1.fc6 xfce4-screenshooter-plugin-1.0.0-3.fc6 xfce4-sensors-plugin-0.10.0-1.fc6 xfce4-session-4.3.99.1-6.fc6 xfce4-systemload-plugin-0.4.0-3.fc6 xfce4-taskmanager-0.4.0-0.2.rc2.fc6 xfce4-wavelan-plugin-0.5.3-3.fc6 xfce4-weather-plugin-0.5.99.1-3.fc6 xfce4-websearch-plugin-0.1.1-0.2.20060923svn.fc6 xfce4-xkb-plugin-0.3.6-0.2.20060923svn.fc6 xfce4-xmms-plugin-0.4.2-2.fc6 xfdesktop-4.3.99.1-5.fc6 xfprint-4.3.99.1-3.fc6 xfwm4-4.3.99.1-5.fc6 xfwm4-themes-4.3.99.1-3.fc6 Packages built and released for Fedora Extras 5: 12 acpitool-0.4.6-2.fc5 digikamimageplugins-doc-0.8.2-2.fc5 libtunepimp-0.5.2-1.fc5 perl-POE-Component-DBIAgent-0.26-2.fc5 perl-PPI-Tester-0.06-2.fc5 perl-Readonly-XS-1.04-7.fc5 plib-1.8.4-8.fc5 plplot-5.6.1-5.fc5 renrot-0.25-2.fc5 sysprof-1.0.3-4.fc5 sysprof-kmod-1.0.3-3.2.6.17_1.2187_FC5 uw-imap-2006b-1.fc5 Packages built and released for Fedora Extras 4: 1 renrot-0.25-2.fc4 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 Sat Oct 7 00:57:48 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Oct 2006 20:57:48 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-06 Message-ID: <20061007005748.71F5115212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From bugs.michael at gmx.net Sat Oct 7 01:06:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 03:06:18 +0200 Subject: Soon to be marked dead packages In-Reply-To: <200610061921.44199.jkeating@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <200610061921.44199.jkeating@redhat.com> Message-ID: <20061007030618.d0fa91dc.bugs.michael@gmx.net> On Fri, 6 Oct 2006 19:21:40 -0400, Jesse Keating wrote: > On Friday 06 October 2006 19:07, Christian Iseli wrote: > > dogtail > > pyspi > > These two moved from Extras to Core a while ago, and were requested to get > removed on http://fedoraproject.org/wiki/Extras/FC6Status . Those are not > listed there anymore so one would think they got removed, That page is about removing rpms from the repository, not about removing stuff from CVS. In CVS, the ex-maintainer should have 'cvs -f remove'd the files and should have created a "dead.package" file. > so why are they > showing up in needrebuild orphaned list? Most likely, because they are still active in CVS "devel" plus flagged with a "needs.rebuild" file. From christoph.wickert at nurfuerspam.de Sat Oct 7 01:17:26 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 07 Oct 2006 03:17:26 +0200 Subject: taking over gnome-applet-netmon (Re: Soon to be marked dead packages) In-Reply-To: <1160182371.3639.5.camel@hal9000.local.lan> References: <20061007010737.79dd63fc@ludwig-alpha> <1160182371.3639.5.camel@hal9000.local.lan> Message-ID: <1160183846.3639.14.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 02:52 +0200 schrieb Christoph Wickert: > Am Samstag, den 07.10.2006, 01:07 +0200 schrieb Christian Iseli: > > Hi folks, > > > > The following list of packages will soon (tomorrow-ish) be marked dead > > in CVS (to avoid them being branched for FC-6 with no maintainer). > > > > Cheers, > > C > > > > ---- > > > gnome-applet-netmon > > I'd like to take this one over since I use it regularly and I already > maintain some panel applets. Please forget about it, I was thinking of gnome-applet-netspeed, sorry for the confusion. gnome-applet-netmon seems to be dead, upstream and in FE. Last changelog entry it from March 2005 and I cant find the package anywhere in the repo. It's not listed orphaned in the wiki. Any idea why it's showing up on this list? > Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From buildsys at fedoraproject.org Sat Oct 7 01:37:41 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 07 Oct 2006 01:37:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-06 Message-ID: <20061007013741.24319.40930@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (6 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (6 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (6 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (21 days) plague - 0.4.4.1-2.fc3.noarch (21 days) plague - 0.4.4.1-2.fc4.noarch (21 days) plague - 0.4.4.1-2.fc4.noarch (21 days) plague - 0.4.4.1-2.fc4.noarch (21 days) gauret AT free.fr amarok - 1.4.1-3.fc5.x86_64 amarok - 1.4.3-5.fc5.i386 amarok - 1.4.3-5.fc5.ppc giallu AT gmail.com kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i586 kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 kmod-sysprof-PAE - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.i686 kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 sysprof - 1.0.3-4.fc5.ppc kevin-redhat-bugzilla AT tummy.com xfcalendar - 4.2.3-3.fc6.i386 xfcalendar - 4.2.3-3.fc6.ppc xfcalendar - 4.2.3-3.fc6.x86_64 orion AT cora.nwra.com paraview - 2.4.4-2.fc6.i386 paraview - 2.4.4-2.fc6.ppc paraview - 2.4.4-2.fc6.x86_64 paraview-mpi - 2.4.4-2.fc6.i386 paraview-mpi - 2.4.4-2.fc6.ppc paraview-mpi - 2.4.4-2.fc6.x86_64 ville.skytta AT iki.fi kid3 - 0.7-1.fc5.i386 kid3 - 0.7-1.fc5.ppc kid3 - 0.7-1.fc5.x86_64 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 kmod-em8300-PAE - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 kmod-em8300-smp - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6 kmod-em8300-smp-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6smp paraview-2.4.4-2.fc6.ppc requires libvtkPVServerCommonPython.so paraview-2.4.4-2.fc6.ppc requires libvtkPVServerManagerPython.so paraview-mpi-2.4.4-2.fc6.ppc requires libvtkPVServerCommonPython.so paraview-mpi-2.4.4-2.fc6.ppc requires libvtkPVServerManagerPython.so xfcalendar-4.2.3-3.fc6.ppc requires libxfcegui4.so.3 xfcalendar-4.2.3-3.fc6.ppc requires libxfce4mcs-client.so.2 xfcalendar-4.2.3-3.fc6.ppc requires libxfce4util.so.1 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen paraview-2.4.4-2.fc6.x86_64 requires libvtkPVServerManagerPython.so()(64bit) paraview-2.4.4-2.fc6.x86_64 requires libvtkPVServerCommonPython.so()(64bit) paraview-mpi-2.4.4-2.fc6.x86_64 requires libvtkPVServerManagerPython.so()(64bit) paraview-mpi-2.4.4-2.fc6.x86_64 requires libvtkPVServerCommonPython.so()(64bit) xfcalendar-4.2.3-3.fc6.x86_64 requires libxfcegui4.so.3()(64bit) xfcalendar-4.2.3-3.fc6.x86_64 requires libxfce4mcs-client.so.2()(64bit) xfcalendar-4.2.3-3.fc6.x86_64 requires libxfce4util.so.1()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-em8300-PAE-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-sysprof-PAE-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen paraview-2.4.4-2.fc6.i386 requires libvtkPVServerCommonPython.so paraview-2.4.4-2.fc6.i386 requires libvtkPVServerManagerPython.so paraview-mpi-2.4.4-2.fc6.i386 requires libvtkPVServerCommonPython.so paraview-mpi-2.4.4-2.fc6.i386 requires libvtkPVServerManagerPython.so xfcalendar-4.2.3-3.fc6.i386 requires libxfcegui4.so.3 xfcalendar-4.2.3-3.fc6.i386 requires libxfce4mcs-client.so.2 xfcalendar-4.2.3-3.fc6.i386 requires libxfce4util.so.1 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- amarok-1.4.3-5.fc5.ppc requires libtunepimp.so.3 kid3-0.7-1.fc5.ppc requires libtunepimp.so.3 sysprof-1.0.3-4.fc5.ppc requires kmod-sysprof >= 0:1.0.3 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- amarok-1.4.1-3.fc5.x86_64 requires libtunepimp.so.3()(64bit) kid3-0.7-1.fc5.x86_64 requires libtunepimp.so.3()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- amarok-1.4.3-5.fc5.i386 requires libtunepimp.so.3 kid3-0.7-1.fc5.i386 requires libtunepimp.so.3 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: kevin-redhat-bugzilla AT tummy.com package: xfcalendar - 4.2.3-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libxfcegui4.so.3 libxfce4mcs-client.so.2 libxfce4util.so.1 package: xfcalendar - 4.2.3-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libxfcegui4.so.3()(64bit) libxfce4mcs-client.so.2()(64bit) libxfce4util.so.1()(64bit) package: xfcalendar - 4.2.3-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libxfcegui4.so.3 libxfce4mcs-client.so.2 libxfce4util.so.1 ====================================================================== New report for: ville.skytta AT iki.fi package: kid3 - 0.7-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libtunepimp.so.3 package: kid3 - 0.7-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libtunepimp.so.3()(64bit) package: kid3 - 0.7-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libtunepimp.so.3 ====================================================================== New report for: gauret AT free.fr package: amarok - 1.4.3-5.fc5.ppc from fedora-extras-5-ppc unresolved deps: libtunepimp.so.3 package: amarok - 1.4.1-3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libtunepimp.so.3()(64bit) package: amarok - 1.4.3-5.fc5.i386 from fedora-extras-5-i386 unresolved deps: libtunepimp.so.3 ====================================================================== New report for: giallu AT gmail.com package: sysprof - 1.0.3-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: kmod-sysprof >= 0:1.0.3 From jkeating at redhat.com Sat Oct 7 03:16:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Oct 2006 23:16:23 -0400 Subject: Soon to be marked dead packages In-Reply-To: <20061007030618.d0fa91dc.bugs.michael@gmx.net> References: <20061007010737.79dd63fc@ludwig-alpha> <200610061921.44199.jkeating@redhat.com> <20061007030618.d0fa91dc.bugs.michael@gmx.net> Message-ID: <200610062316.26832.jkeating@redhat.com> On Friday 06 October 2006 21:06, Michael Schwendt wrote: > That page is about removing rpms from the repository, not about removing > stuff from CVS. In CVS, the ex-maintainer should have 'cvs -f remove'd > the files and should have created a "dead.package" file. Is there any place in the wiki that covers this? The developer in question couldn't find it, or found the other wiki page. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Sat Oct 7 03:33:32 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 06 Oct 2006 23:33:32 -0400 Subject: Soon to be marked dead packages In-Reply-To: References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> Message-ID: <4527200C.7040905@redhat.com> Jason L Tibbitts III wrote: >>>>>> "DJ" == Dave Jones writes: > > DJ> If they still compile, perhaps we can automate building some of > DJ> them until a maintainer steps up ? > > They need actual maintainers, not just some automated rebuilds. What > happens if there's a security problem or a decision needs to be made > about updates? The same thing that happens if I say I'll maintain them today, rebuild them, and then the day that FC6 is released, say I don't want them anymore. From caillon at redhat.com Sat Oct 7 03:53:53 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 06 Oct 2006 23:53:53 -0400 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> Message-ID: <452724D1.1060305@redhat.com> Jason L Tibbitts III wrote: > All if would have taken to avoid this issue was a note saying "I'm > really busy right now; someone please rebuild my packages and if you > like add yourself as a co-maintainer." Problem solved. This happens > all the time. We even have SIGs which act as virtual co-maintainers. The problem was the maintainer said "I will personally take care of my package" and then didn't, effectively taking it hostage. At some point after he said he'd rebuild it, it was determined to simply drop it without giving it a fair chance to be reclaimed. Nothing against david, I'm good friends with him, but the issue is just simply before a package gets dropped, people need a chance to reclaim it. That did not happen. The process seems great for when the package maintainer says "no i don't want to deal with this" anymore, but it seems to fall down when they say "I'm still here" but then aren't. From tibbs at math.uh.edu Sat Oct 7 04:38:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 06 Oct 2006 23:38:05 -0500 Subject: Soon to be marked dead packages In-Reply-To: <4527200C.7040905@redhat.com> (Christopher Aillon's message of "Fri, 06 Oct 2006 23:33:32 -0400") References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> Message-ID: >>>>> "CA" == Christopher Aillon writes: CA> The same thing that happens if I say I'll maintain them today, CA> rebuild them, and then the day that FC6 is released, say I don't CA> want them anymore. So we should just give up and not bother trying to get unmaintained things out of the distro? Or do you instead have something constructive to offer? - J< From michel.salim at gmail.com Sat Oct 7 04:58:13 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 7 Oct 2006 00:58:13 -0400 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <883cfe6d0610062158m2af9f9a6l2831337e7a0bd1e@mail.gmail.com> On 10/6/06, Christian Iseli wrote: > Hi folks, > > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). > > Cheers, > C > > ---- > gnugo > grhino > python-nltk > quarry > zeroinstall-injector These are mine, and I'm going to rebuild them as soon as I figured out what's wrong with my CVS accent. Best, -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From fedora at theholbrooks.org Sat Oct 7 07:35:02 2006 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Sat, 07 Oct 2006 02:35:02 -0500 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <452758A6.3060802@theholbrooks.org> Christian Iseli wrote: > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). > > mediawiki I'd really hate to see mediawiki kicked out, and will gladly volunteer to take ownership. Any comments / history? From wtogami at redhat.com Sat Oct 7 07:54:52 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 07 Oct 2006 16:54:52 +0900 Subject: Soon to be marked dead packages In-Reply-To: <4527200C.7040905@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> Message-ID: <45275D4C.60709@redhat.com> Christopher Aillon wrote: > Jason L Tibbitts III wrote: >>>>>>> "DJ" == Dave Jones writes: >> >> DJ> If they still compile, perhaps we can automate building some of >> DJ> them until a maintainer steps up ? >> >> They need actual maintainers, not just some automated rebuilds. What >> happens if there's a security problem or a decision needs to be made >> about updates? > > The same thing that happens if I say I'll maintain them today, rebuild > them, and then the day that FC6 is released, say I don't want them anymore. > The orphan removal policy was created because the Fedora Project must sustainably grow in a responsible way. If maintainers are unwilling to maintain packages, the responsible thing to do is to declare the packages orphaned and move on. If a maintainer with a bad attitude did as you described, that would be a breach of responsibility. The organization may decide to take measures to either enforce responsibility or revoke access in the event of willful non-compliance with project policies and processes. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Sat Oct 7 08:43:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 10:43:22 +0200 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <452724D1.1060305@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> <452724D1.1060305@redhat.com> Message-ID: <20061007104322.646ea291.bugs.michael@gmx.net> On Fri, 06 Oct 2006 23:53:53 -0400, Christopher Aillon wrote: > Jason L Tibbitts III wrote: > > All if would have taken to avoid this issue was a note saying "I'm > > really busy right now; someone please rebuild my packages and if you > > like add yourself as a co-maintainer." Problem solved. This happens > > all the time. We even have SIGs which act as virtual co-maintainers. > > The problem was the maintainer said "I will personally take care of my > package" and then didn't, effectively taking it hostage. At some point > after he said he'd rebuild it, it was determined to simply drop it > without giving it a fair chance to be reclaimed. But you and him are used to deadlines like this. It was simply not enough for the maintainer to make only a promise in order to escape from the deadline, because maintenance _action_ was needed. The process required maintainers to work on the package in a given time-frame and at least submit a rebuild job, as else the package would continue to show up on the radar of those who monitor where the FE6 preparation still fails. > Nothing against david, I'm good friends with him, but the issue is just > simply before a package gets dropped, people need a chance to reclaim > it. That did not happen. The process seems great for when the package > maintainer says "no i don't want to deal with this" anymore, but it > seems to fall down when they say "I'm still here" but then aren't. Co-maintainership to the rescue. Where a maintainer rejects co-maintainers, conflict resolvement through FESCo to the rescue. What else is needed? From bugs.michael at gmx.net Sat Oct 7 08:54:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 10:54:09 +0200 Subject: Soon to be marked dead packages In-Reply-To: <200610062316.26832.jkeating@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <200610061921.44199.jkeating@redhat.com> <20061007030618.d0fa91dc.bugs.michael@gmx.net> <200610062316.26832.jkeating@redhat.com> Message-ID: <20061007105409.3d89d695.bugs.michael@gmx.net> On Fri, 6 Oct 2006 23:16:23 -0400, Jesse Keating wrote: > On Friday 06 October 2006 21:06, Michael Schwendt wrote: > > That page is about removing rpms from the repository, not about removing > > stuff from CVS. In CVS, the ex-maintainer should have 'cvs -f remove'd > > the files and should have created a "dead.package" file. > > Is there any place in the wiki that covers this? The developer in question > couldn't find it, or found the other wiki page. He could have asked. The answer is at the top of every FCXStatus page, the 4th bullet. Plus, the http://fedoraproject.org/wiki/Extras/PackageEndOfLife page is linked in bold from the main http://fedoraproject.org/wiki/Extras section on Adding/removing packages. Btw, just yesterday I've revamped the main Fedora Extras a retain some of the old clearer structure where you don't get lost in too many sections. From bugs.michael at gmx.net Sat Oct 7 08:58:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 10:58:26 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-06 In-Reply-To: <20061007013741.24319.40930@extras64.linux.duke.edu> References: <20061007013741.24319.40930@extras64.linux.duke.edu> Message-ID: <20061007105826.f38e18e1.bugs.michael@gmx.net> On Sat, 07 Oct 2006 01:37:41 -0000, Fedora Extras repoclosure wrote: > Broken packages in fedora-extras-5-ppc: > ---------------------------------------------------------------------- > sysprof-1.0.3-4.fc5.ppc requires kmod-sysprof >= 0:1.0.3 *ahem* This made me wonder when I saw the pkg removal request for ppc without a corresponding ExcludeArch in the spec. > ====================================================================== > New report for: giallu AT gmail.com > > package: sysprof - 1.0.3-4.fc5.ppc from fedora-extras-5-ppc > unresolved deps: > kmod-sysprof >= 0:1.0.3 From Axel.Thimm at ATrpms.net Sat Oct 7 09:00:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 7 Oct 2006 11:00:10 +0200 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <20061007090010.GH21843@neu.nirvana> On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: > mediawiki That's a pity, I'd like to step up and maintain it. Is it too late for deorphaning before the FC6 fork? -- 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 paul at all-the-johnsons.co.uk Sat Oct 7 09:22:32 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 07 Oct 2006 10:22:32 +0100 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <1160212952.4255.77.camel@T7.Linux> Hi, > gdeskcal Dunno how that slipped through the net, but it's now been rebuilt. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 Sat Oct 7 09:27:09 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 07 Oct 2006 18:27:09 +0900 Subject: Soon to be marked dead packages In-Reply-To: <20061007090010.GH21843@neu.nirvana> References: <20061007010737.79dd63fc@ludwig-alpha> <20061007090010.GH21843@neu.nirvana> Message-ID: <452772ED.6000608@redhat.com> Axel Thimm wrote: > On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: >> mediawiki > > That's a pity, I'd like to step up and maintain it. Is it too late for > deorphaning before the FC6 fork? > It is never too late. Nothing stops someone from maintaining it again, and it could then be readded to FE6. Warren Togami wtogami at redhat.com From pertusus at free.fr Sat Oct 7 09:30:00 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Oct 2006 11:30:00 +0200 Subject: paraview dependency problem In-Reply-To: <20061007001556.414865e1@ludwig-alpha> References: <20061007001556.414865e1@ludwig-alpha> Message-ID: <20061007093000.GA2287@free.fr> On Sat, Oct 07, 2006 at 12:15:56AM +0200, Christian Iseli wrote: > Hi all, > > Ville asked me to keep an eye on unresolved deps in devel while he's > away... > > Here's one I'd like some feedback on. I watch that package and I have seen a cvs commit enabling python I guess this is where the issue comes. Paraview is not something easy to test locally since it takes hours to compile. -- Pat From Axel.Thimm at ATrpms.net Sat Oct 7 09:37:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 7 Oct 2006 11:37:31 +0200 Subject: Claiming ownership of mediawiki (was: Soon to be marked dead packages) In-Reply-To: <452772ED.6000608@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061007090010.GH21843@neu.nirvana> <452772ED.6000608@redhat.com> Message-ID: <20061007093731.GK21843@neu.nirvana> On Sat, Oct 07, 2006 at 06:27:09PM +0900, Warren Togami wrote: > Axel Thimm wrote: > >On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: > >>mediawiki > > > >That's a pity, I'd like to step up and maintain it. Is it too late for > >deorphaning before the FC6 fork? > > > > It is never too late. Nothing stops someone from maintaining it again, > and it could then be readded to FE6. OK, sending the mail as required in http://fedoraproject.org/wiki/Extras/OrphanedPackages mediawiki is orphaned since 2006-09-19, so the ten days are over, but I saw that Brandon Holbrook also volunteered for maintaining mediawiki and I don't want to just grab it yet. Brandon is it OK with you if I pick up mediawiki? -- 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 christoph.wickert at nurfuerspam.de Sat Oct 7 10:37:52 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 07 Oct 2006 12:37:52 +0200 Subject: Soon to be marked dead packages In-Reply-To: <1160212952.4255.77.camel@T7.Linux> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> Message-ID: <1160217473.3647.1.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 10:22 +0100 schrieb Paul: > Hi, > > > gdeskcal > > Dunno how that slipped through the net, but it's now been rebuilt. > Can you also update to 1.0? TIA Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From christoph.wickert at nurfuerspam.de Sat Oct 7 11:00:10 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 07 Oct 2006 13:00:10 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-06 In-Reply-To: <20061007013741.24319.40930@extras64.linux.duke.edu> References: <20061007013741.24319.40930@extras64.linux.duke.edu> Message-ID: <1160218810.3647.5.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 01:37 +0000 schrieb Fedora Extras repoclosure: > Summary of broken packages (by owner): > ---------------------------------------------------------------------- > > kevin-redhat-bugzilla AT tummy.com > xfcalendar - 4.2.3-3.fc6.i386 > xfcalendar - 4.2.3-3.fc6.ppc > xfcalendar - 4.2.3-3.fc6.x86_64 xfcalendar is replaced/obsoleted by orage and should be removed from the repo. Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From bugs.michael at gmx.net Sat Oct 7 12:23:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 14:23:03 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-06 In-Reply-To: <1160218810.3647.5.camel@hal9000.local.lan> References: <20061007013741.24319.40930@extras64.linux.duke.edu> <1160218810.3647.5.camel@hal9000.local.lan> Message-ID: <20061007142303.164d0fab.bugs.michael@gmx.net> On Sat, 07 Oct 2006 13:00:10 +0200, Christoph Wickert wrote: > Am Samstag, den 07.10.2006, 01:37 +0000 schrieb Fedora Extras > repoclosure: > > Summary of broken packages (by owner): > > ---------------------------------------------------------------------- > > > > kevin-redhat-bugzilla AT tummy.com > > xfcalendar - 4.2.3-3.fc6.i386 > > xfcalendar - 4.2.3-3.fc6.ppc > > xfcalendar - 4.2.3-3.fc6.x86_64 > > xfcalendar is replaced/obsoleted by orage and should be removed from the > repo. Then please fix the "orage" package's Obsoletes and submit an rpm removal request at: http://fedoraproject.org/wiki/Extras/FC6Status From mmcgrath at fedoraproject.org Sat Oct 7 14:54:10 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 7 Oct 2006 09:54:10 -0500 Subject: CVS Maintenance Message-ID: <3237e4410610070754r49306617o45c11299de17f405@mail.gmail.com> We can certainly wait until FC6 is released but when would be a good time for you guys to have some downtime on CVS? I'm estimating only a few hours, just the Fedora CVS server, not the internal RH one. -Mike From mtasaka at ioa.s.u-tokyo.ac.jp Sat Oct 7 15:11:36 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 08 Oct 2006 00:11:36 +0900 Subject: Multiple entries in comps-fe6.xml.in Message-ID: <4527C3A8.6090405@ioa.s.u-tokyo.ac.jp> Hello. When I checked comps/comps-fe6.xml.in, I found that several packages are listed in multiple groups. [tasaka1 at localhost comps]$ cat comps-fe6.xml.in | sed -n -e 's|.*\(.*\) <1160218810.3647.5.camel@hal9000.local.lan> <20061007142303.164d0fab.bugs.michael@gmx.net> Message-ID: <20061007.092325.532247633.kevin@scrye.com> Michael> On Sat, 07 Oct 2006 13:00:10 +0200, Christoph Wickert wrote: >> Am Samstag, den 07.10.2006, 01:37 +0000 schrieb Fedora Extras >> repoclosure: > Summary of broken packages (by owner): > >> ---------------------------------------------------------------------- >> > >> > kevin-redhat-bugzilla AT tummy.com > xfcalendar - >> 4.2.3-3.fc6.i386 > xfcalendar - 4.2.3-3.fc6.ppc > xfcalendar - >> 4.2.3-3.fc6.x86_64 >> >> xfcalendar is replaced/obsoleted by orage and should be removed >> from the repo. Michael> Then please fix the "orage" package's Obsoletes and submit an Michael> rpm removal request at: Michael> http://fedoraproject.org/wiki/Extras/FC6Status Sorry, that was my fault. ;( I just built a new fixed orage, and requested removal of all the obsolete Xfce packages. kevin -------------- 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 Sat Oct 7 15:34:46 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 7 Oct 2006 17:34:46 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-06 In-Reply-To: <20061007105826.f38e18e1.bugs.michael@gmx.net> References: <20061007013741.24319.40930@extras64.linux.duke.edu> <20061007105826.f38e18e1.bugs.michael@gmx.net> Message-ID: On 10/7/06, Michael Schwendt wrote: > On Sat, 07 Oct 2006 01:37:41 -0000, Fedora Extras repoclosure wrote: > > > Broken packages in fedora-extras-5-ppc: > > ---------------------------------------------------------------------- > > sysprof-1.0.3-4.fc5.ppc requires kmod-sysprof >= 0:1.0.3 > > *ahem* This made me wonder when I saw the pkg removal request for ppc > without a corresponding ExcludeArch in the spec. Sorry for this... I forgot the commit for the spec in -devel, so when the FC-5 branch appeared, I (wrongly) assumed Exclusivearch was there I'm committing now -5 Time to make another request for deletion :( From caillon at redhat.com Sat Oct 7 15:37:44 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 07 Oct 2006 11:37:44 -0400 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <20061007104322.646ea291.bugs.michael@gmx.net> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> <452724D1.1060305@redhat.com> <20061007104322.646ea291.bugs.michael@gmx.net> Message-ID: <4527C9C8.3040505@redhat.com> Michael Schwendt wrote: > On Fri, 06 Oct 2006 23:53:53 -0400, Christopher Aillon wrote: > >> Jason L Tibbitts III wrote: >>> All if would have taken to avoid this issue was a note saying "I'm >>> really busy right now; someone please rebuild my packages and if you >>> like add yourself as a co-maintainer." Problem solved. This happens >>> all the time. We even have SIGs which act as virtual co-maintainers. >> The problem was the maintainer said "I will personally take care of my >> package" and then didn't, effectively taking it hostage. At some point >> after he said he'd rebuild it, it was determined to simply drop it >> without giving it a fair chance to be reclaimed. > > But you and him are used to deadlines like this. Are we going to expect this of every single contributor? Please ignore the fact that he worked at Red Hat here, I'm talking in a more broad sense. > It was simply not enough for the maintainer to make only a promise in > order to escape from the deadline, because maintenance _action_ was > needed. Agreed. Penalizing users of the software because the maintainer makes empty promises is just plain wrong. Action was indeed needed on someone's part for the package. We should have found someone to perform the action if the maintainer was making empty promises, rather than just nix the package. > The process required maintainers to work on the package in a given > time-frame and at least submit a rebuild job, as else the package would > continue to show up on the radar of those who monitor where the FE6 > preparation still fails. Great. That process is nice. It works. What I'm talking about and what doesn't work is that when a package maintainer is pinged and given notice that "Hi. You need to do this. Will you? If not, I will find someone else" and then proceeds to agree to do work, stifling the correct process of finding a new owner. He stopped that process from happening by promising to do work. And then failed to do work. I'm arguing that *in all cases* there should be an attempt to find a new owner for the package the instant it is deemed the maintainer isn't doing their job for the package. There was none in this case because the owner stifled that. From fedora at theholbrooks.org Sat Oct 7 15:58:35 2006 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Sat, 07 Oct 2006 10:58:35 -0500 Subject: Claiming ownership of mediawiki In-Reply-To: <20061007093731.GK21843@neu.nirvana> References: <20061007010737.79dd63fc@ludwig-alpha> <20061007090010.GH21843@neu.nirvana> <452772ED.6000608@redhat.com> <20061007093731.GK21843@neu.nirvana> Message-ID: <4527CEAB.2010809@theholbrooks.org> Axel Thimm wrote: > On Sat, Oct 07, 2006 at 06:27:09PM +0900, Warren Togami wrote: > >> Axel Thimm wrote: >> >>> On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: >>> >>>> mediawiki >>>> >>> That's a pity, I'd like to step up and maintain it. Is it too late for >>> deorphaning before the FC6 fork? >>> >>> >> It is never too late. Nothing stops someone from maintaining it again, >> and it could then be readded to FE6. >> > > OK, sending the mail as required in > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > mediawiki is orphaned since 2006-09-19, so the ten days are over, but > I saw that Brandon Holbrook also volunteered for maintaining mediawiki > and I don't want to just grab it yet. Brandon is it OK with you if I > pick up mediawiki? > Sure, that works for me. Put me down as a comaintainer. -Brandon From giallu at gmail.com Sat Oct 7 16:00:19 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 7 Oct 2006 18:00:19 +0200 Subject: Claiming ownership of mantis (was: Soon to be marked dead packages) Message-ID: I am going to pick up mantis ( I am using it at work as our bug / issue tracker ). However, I will appreciate if someone else step up for co-maintaining it with me. Gianluca From tibbs at math.uh.edu Sat Oct 7 17:23:28 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 07 Oct 2006 12:23:28 -0500 Subject: Claiming ownership of mantis In-Reply-To: (Gianluca Sforna's message of "Sat, 7 Oct 2006 18:00:19 +0200") References: Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> I am going to pick up mantis ( I am using it at work as our bug / GS> issue tracker ). I hope the group that ends up maintaining mantis can give some thought to the currently open security issues. See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191089 And these open issues in the security audit: fe3:CVE-2006-1577 VULNERABLE (mantis) bz#191089 fe3:CVE-2006-0841 VULNERABLE (mantis) bz#191089 fe3:CVE-2006-0840 VULNERABLE (mantis) bz#191089 fe3:CVE-2006-0665 VULNERABLE (mantis) bz#191089 fe3:CVE-2006-0664 VULNERABLE (mantis) bz#191089 fe4:CVE-2006-1577 VULNERABLE (mantis) bz#191089 fe4:CVE-2006-0841 VULNERABLE (mantis) bz#191089 fe4:CVE-2006-0840 VULNERABLE (mantis) bz#191089 fe4:CVE-2006-0665 VULNERABLE (mantis) bz#191089 fe4:CVE-2006-0664 VULNERABLE (mantis) bz#191089 fe5:CVE-2006-1577 VULNERABLE (mantis) bz#191089 The big question is how to fix the older versions or whether it's possible to seamlessly upgrade them to something more recent. Releases and versions: 3 0.18.3 2 /nas/redhat/mirror-extras/3/SRPMS/mantis-0.18.3-2.src.rpm 4 0.19.4 1.fc4 /nas/redhat/mirror-extras/4/SRPMS/mantis-0.19.4-1.fc4.src.rpm 5 1.0.1 1.fc5 /nas/redhat/mirror-extras/5/SRPMS/mantis-1.0.1-1.fc5.src.rpm - J< From Christian.Iseli at licr.org Sat Oct 7 20:20:02 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:20:02 +0200 Subject: Multiple entries in comps-fe6.xml.in In-Reply-To: <4527C3A8.6090405@ioa.s.u-tokyo.ac.jp> References: <4527C3A8.6090405@ioa.s.u-tokyo.ac.jp> Message-ID: <20061007222002.798907fd@ludwig-alpha> On Sun, 08 Oct 2006 00:11:36 +0900, Mamoru Tasaka wrote: > When I checked comps/comps-fe6.xml.in, I found that several > packages are listed in multiple groups. ... > Is this allowed? Last I heard, this is frowned upon and discouraged. But it seems to happen for several language support packages. C From Christian.Iseli at licr.org Sat Oct 7 20:24:34 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:24:34 +0200 Subject: Soon to be marked dead packages In-Reply-To: <200610061921.44199.jkeating@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <200610061921.44199.jkeating@redhat.com> Message-ID: <20061007222434.237e1b79@ludwig-alpha> On Fri, 6 Oct 2006 19:21:40 -0400, Jesse Keating wrote: > > dogtail > > pyspi > > These two moved from Extras to Core a while ago Ok, marked dead in CVS extras now. C From Christian.Iseli at licr.org Sat Oct 7 20:28:17 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:28:17 +0200 Subject: taking over gnome-applet-netmon (Re: Soon to be marked dead packages) In-Reply-To: <1160183846.3639.14.camel@hal9000.local.lan> References: <20061007010737.79dd63fc@ludwig-alpha> <1160182371.3639.5.camel@hal9000.local.lan> <1160183846.3639.14.camel@hal9000.local.lan> Message-ID: <20061007222817.10828f6a@ludwig-alpha> On Sat, 07 Oct 2006 03:17:26 +0200, Christoph Wickert wrote: > gnome-applet-netmon seems to be dead, upstream and in FE. Last changelog > entry it from March 2005 and I cant find the package anywhere in the > repo. It's not listed orphaned in the wiki. Any idea why it's showing up > on this list? Simply because it still had a spec file in devel, along the needs.rebuild file... Marked dead now. C From bugs.michael at gmx.net Sat Oct 7 20:34:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 Oct 2006 22:34:45 +0200 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4527C9C8.3040505@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> <452724D1.1060305@redhat.com> <20061007104322.646ea291.bugs.michael@gmx.net> <4527C9C8.3040505@redhat.com> Message-ID: <20061007223445.7be77583.bugs.michael@gmx.net> On Sat, 07 Oct 2006 11:37:44 -0400, Christopher Aillon wrote: > > But you and him are used to deadlines like this. > > Are we going to expect this of every single contributor? Please ignore > the fact that he worked at Red Hat here, I'm talking in a more broad sense. Yes, when there's a deadline of some sort and announced properly, it will be very difficult to lower the hurdle for some packagers. Either there is the goal to be ready with the repository at a given point of time or there is no such goal. And if so short before the deadline unmaintained packages are discovered, the only rescue would be to decide quickly and who may step in and help with the needed action. That, however, must be in accordance with the "no orphaned packages" rule as to avoid that somebody contributes only the missing build jobs without interest in taking over package maintenance, too (and for instance, also examine the package status prior to just rebuilding it). Fedora Extras are still learning. We've tried out different roads before and perhaps will try out even other approaches next time. What has been determined as bad, however, is to find out *after* the official release of the distribution (i.e. Core+Extras) that there are orphaned rpms in what we offer in the repository, possibly with open bug reports and security vulnerabilities and that there are no volunteers to fix them, and regardless of how important or popular a package may be according to some voices. What's needed is packagers or full package maintainers. It may be the individual packager, who has failed, but this falls back on Fedora Extras as a whole, too. > Penalizing users of the software because the maintainer makes > empty promises is just plain wrong. Action was indeed needed on > someone's part for the package. We should have found someone to perform > the action if the maintainer was making empty promises, rather than just > nix the package. You're exaggerating with regard to the impact of removing rpms from a "Development" type of repository. There's still time to bring them back. Still a chance to name one or more co-maintainers. > Great. That process is nice. It works. What I'm talking about and > what doesn't work is that when a package maintainer is pinged and given > notice that "Hi. You need to do this. Will you? If not, I will find > someone else" and then proceeds to agree to do work, stifling the > correct process of finding a new owner. He stopped that process from > happening by promising to do work. And then failed to do work. > > I'm arguing that *in all cases* there should be an attempt to find a new > owner for the package the instant it is deemed the maintainer isn't > doing their job for the package. There was none in this case because > the owner stifled that. This has been commented on before. From Christian.Iseli at licr.org Sat Oct 7 20:44:06 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:44:06 +0200 Subject: Soon to be marked dead packages In-Reply-To: <20061006231919.GE31533@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> Message-ID: <20061007224406.36659cc0@ludwig-alpha> On Fri, 6 Oct 2006 19:19:19 -0400, Dave Jones wrote: > I think magicpoint is the only thing I'd be sad to see go, but I have > nowhere near the time to maintain it. There are two people listed as co-maintainers (though the package itself is marked orphaned) : rms at 1407.org byte at fedoraproject.org Maybe if you ping them... :-) C From Christian.Iseli at licr.org Sat Oct 7 20:45:18 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:45:18 +0200 Subject: Soon to be marked dead packages In-Reply-To: <883cfe6d0610062158m2af9f9a6l2831337e7a0bd1e@mail.gmail.com> References: <20061007010737.79dd63fc@ludwig-alpha> <883cfe6d0610062158m2af9f9a6l2831337e7a0bd1e@mail.gmail.com> Message-ID: <20061007224518.3adaa8de@ludwig-alpha> On Sat, 7 Oct 2006 00:58:13 -0400, Michel Salim wrote: > These are mine, and I'm going to rebuild them as soon as I figured out > what's wrong with my CVS accent. Great. Thanks, C From Christian.Iseli at licr.org Sat Oct 7 20:46:57 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:46:57 +0200 Subject: paraview dependency problem In-Reply-To: <20061007093000.GA2287@free.fr> References: <20061007001556.414865e1@ludwig-alpha> <20061007093000.GA2287@free.fr> Message-ID: <20061007224657.5f20bbac@ludwig-alpha> On Sat, 7 Oct 2006 11:30:00 +0200, Patrice Dumas wrote: > I watch that package and I have seen a cvs commit enabling python I guess > this is where the issue comes. Paraview is not something easy to test > locally since it takes hours to compile. Yes, I heard from Orion that he's looking into it. C From Christian.Iseli at licr.org Sat Oct 7 20:49:47 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:49:47 +0200 Subject: CVS Maintenance In-Reply-To: <3237e4410610070754r49306617o45c11299de17f405@mail.gmail.com> References: <3237e4410610070754r49306617o45c11299de17f405@mail.gmail.com> Message-ID: <20061007224947.49607221@ludwig-alpha> On Sat, 7 Oct 2006 09:54:10 -0500, Mike McGrath wrote: > We can certainly wait until FC6 is released but when would be a good > time for you guys to have some downtime on CVS? I'm estimating only a > few hours, just the Fedora CVS server, not the internal RH one. How about right before the FC-6 branches are created ? Then the branches can be created while the system is quiet and then everything gets back online smoothly... C From Christian.Iseli at licr.org Sat Oct 7 20:52:43 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 22:52:43 +0200 Subject: Soon to be marked dead packages In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <20061007225243.1852e933@ludwig-alpha> On Sat, 7 Oct 2006 01:07:37 +0200, I wrote: > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). I started to do some cleaning, but it turns out I have to be offline for a while now. I'll try to continue the cleanup next wednesday... unless someone beats me to it of course :-) C From Christian.Iseli at licr.org Sat Oct 7 21:08:09 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Oct 2006 23:08:09 +0200 Subject: offline/vacations Message-ID: <20061007230809.23fc83cc@ludwig-alpha> Hi folks, I'll be totally offline from now til next Wednesday when I'll have a short time window to catch up a bit on email... then I'll be semi offline for the remainder of the week. Sorry I couldn't find the time to produce the weekly PackageStatus report... I'll get to it when I return (or if someone is willing to try: be my guest). TTYL C From pertusus at free.fr Sat Oct 7 21:15:48 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Oct 2006 23:15:48 +0200 Subject: help needed on the gwyddion review Message-ID: <20061007211548.GA14728@free.fr> Hello, There is a review for gwyddion submitted by David Necas, it is his first package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187294 I am doing a review, but it is stalled, and I am not completly sure on what is right. We are disagreeing on the packaging of some modules (python, perl and ruby). These modules are there to handle a file format used by some kind of gwyddion plugins. These kind of plugins are more or less deprecated, but some examples are packaged in the gwyddion-plugin-examples subpackage. Currently David put the modules in the libs subpackage (together with the gwyddion libs), below %{_libdir}/%{name}, without having the subpackage requires the interpreters (python, perl and ruby). His reasoning is that they are available, and a user has to have the interpreter available anyway, so no need to Requires them. Nothing shows that the modules are in this subpackage, and users have to set set some path explicitely, but for him having those bits a bit hard to use it is not an issue since it is associated with a deprecated interface. I disagree, and tend to think that these modules should be packaged as far as possible like usual modules, each in a subpackage with a dependency on the interpreter. I don't have a clear opinion on this, could you have one? -- Pat From michel.salim at gmail.com Sat Oct 7 21:26:27 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 7 Oct 2006 17:26:27 -0400 Subject: help needed on the gwyddion review In-Reply-To: <20061007211548.GA14728@free.fr> References: <20061007211548.GA14728@free.fr> Message-ID: <883cfe6d0610071426i40485320u2914a808c1c6c63d@mail.gmail.com> On 10/7/06, Patrice Dumas wrote: > Hello, > > There is a review for gwyddion submitted by David Necas, it is his > first package: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187294 > [snip] > Currently David put the modules in the libs subpackage (together with the > gwyddion libs), below %{_libdir}/%{name}, without having the subpackage > requires the interpreters (python, perl and ruby). His reasoning is > that they are available, and a user has to have the interpreter available > anyway, so no need to Requires them. Nothing shows that the modules are in > this subpackage, and users have to set set some path explicitely, but > for him having those bits a bit hard to use it is not an issue since it > is associated with a deprecated interface. > > I disagree, and tend to think that these modules should be packaged as > far as possible like usual modules, each in a subpackage with a dependency > on the interpreter. > > I don't have a clear opinion on this, could you have one? > It would make sense (to me, anyway) to have the deprecated modules packaged like normal, as you suggested, but perhaps with an ifdef. Probably set them to be built by default for now? > -- > Pat > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From pertusus at free.fr Sat Oct 7 21:31:20 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Oct 2006 23:31:20 +0200 Subject: help needed on the gwyddion review In-Reply-To: <883cfe6d0610071426i40485320u2914a808c1c6c63d@mail.gmail.com> References: <20061007211548.GA14728@free.fr> <883cfe6d0610071426i40485320u2914a808c1c6c63d@mail.gmail.com> Message-ID: <20061007213120.GB14728@free.fr> On Sat, Oct 07, 2006 at 05:26:27PM -0400, Michel Salim wrote: > On 10/7/06, Patrice Dumas wrote: > >Hello, > It would make sense (to me, anyway) to have the deprecated modules > packaged like normal, as you suggested, but perhaps with an ifdef. > Probably set them to be built by default for now? They have to be packaged unconditionnally because the gwyddion-plugin-examples need them. -- Pat From giallu at gmail.com Sat Oct 7 21:45:46 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 7 Oct 2006 23:45:46 +0200 Subject: Claiming ownership of mantis In-Reply-To: References: Message-ID: On 10/7/06, Jason L Tibbitts III wrote: > > The big question is how to fix the older versions or whether it's > possible to seamlessly upgrade them to something more recent. Backporting fixes is always possible, of course at an higher cost (Enterprise Linux exists for a reason...) so I am not in a position where I can guarantee such a level of service. Another (slightly cheaper) option would be to update all versions, but that implies: 1. deploy and test an automated update method in the rpm transaction 2. test the resulting stuff on various older installations Now, I could (hardly) find the time to do 1 ( which would be a nice feature ), but for sure I can't do 2, both because I haven't anymore FC3 and FC4 machines _and_ I haven't anymore mantis databases with the older schemas (not counting again the time needed for such tests) If there are here any mantis users on older (AKA legacy) distros, maybe we can arrange a test grid with them but, again, that's going to be a fairly big work Anyway ( sorry for being clueless ) why should we worry about legacy distros, instead of leaving that to something like an "Extras Legacy" SIG? Any suggestion on how to handle the situation will be greatly appreciated G. From tibbs at math.uh.edu Sat Oct 7 22:26:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 07 Oct 2006 17:26:42 -0500 Subject: Claiming ownership of mantis In-Reply-To: (Gianluca Sforna's message of "Sat, 7 Oct 2006 23:45:46 +0200") References: Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> If there are here any mantis users on older (AKA legacy) distros, GS> maybe we can arrange a test grid with them but, again, that's GS> going to be a fairly big work Well, obviously if there aren't any users then the security issues aren't a problem. And maybe it is better to just say "if you're running Mantis on FC3 or FC4, we can't really help you". Which would be unfortunate, because it looks as if Debian already did the work to backport at least some of the fixes. GS> Anyway ( sorry for being clueless ) why should we worry about GS> legacy distros, instead of leaving that to something like an GS> "Extras Legacy" SIG? And who would do that, exactly? The security team exists to help, but maintenance of a package on all supported Fedora releases is still the responsibility of the maintainer of said package. I don't think that anyone expects maintainers to keep a machine with each OS revision loaded so that everything can be tested; the community should be relied on for some of that. But when there are security problems it's still the maintainer's responsibility to evaluate them and evaluate the possible solutions and at least get those evaluations into the relevant bugzilla tickets. Even if it's just to say "sorry, it's just not feasible to fix this in a reasonable fashion" and perhaps provide packages somewhere that the user can manually upgrade to if they can't upgrade their full OS install. Right now we don't even know how bad the security issues are, or if anyone has taken a look at how hard it would be to push an update. - J< From nicolas.mailhot at laposte.net Sat Oct 7 23:41:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 08 Oct 2006 01:41:21 +0200 Subject: Multiple entries in comps-fe6.xml.in In-Reply-To: <20061007222002.798907fd@ludwig-alpha> References: <4527C3A8.6090405@ioa.s.u-tokyo.ac.jp> <20061007222002.798907fd@ludwig-alpha> Message-ID: <1160264481.3239.4.camel@rousalka.dyndns.org> Le samedi 07 octobre 2006 ? 22:20 +0200, Christian Iseli a ?crit : > On Sun, 08 Oct 2006 00:11:36 +0900, Mamoru Tasaka wrote: > > When I checked comps/comps-fe6.xml.in, I found that several > > packages are listed in multiple groups. > ... > > Is this allowed? > > Last I heard, this is frowned upon and discouraged. The language support groups unfortunately do not allow much sharing. That's why the cleanup stylesheet only warns about multi-group packages (other kinds of duplicates are killed on sight). If you feel it's too lenient just say so and it will treat these duplicates like the others. > But it seems to > happen for several language support packages. Actually, a quick run of the cleanup stylesheet will show most of the offenders are not in the language support groups anymore. Regards, -- Nicolas Mailhot From giallu at gmail.com Sat Oct 7 23:57:53 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 8 Oct 2006 01:57:53 +0200 Subject: Claiming ownership of mantis In-Reply-To: References: Message-ID: On 10/8/06, Jason L Tibbitts III wrote: > Right now we don't even know how bad the security issues are, or if > anyone has taken a look at how hard it would be to push an update. > Fair enough. I will have less speculation and more facts after having a look at those issues and to what debian has to "offer" to resolve them. Stay tuned G. From buildsys at fedoraproject.org Sun Oct 8 00:29:37 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 7 Oct 2006 20:29:37 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-07 Message-ID: <20061008002937.BB2E315212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 26 agave-0.4.1-1.fc6 amarok-1.4.3-6.fc6 comix-3.6-2.fc6 fuse-2.5.3-4.fc6 gaim-galago-0.5.1-1.fc6 galago-daemon-0.5.1-1.fc6 gdeskcal-0.57.1-6.fc6 jd-1.7.0-2.fc6 kadu-0.5.0-0.14.20060915svn.fc6 konversation-1.0.1-1.fc6 kphotobymail-0.4-1.fc6 libgalago-0.5.2-1.fc6 orage-4.3.99.1-5.fc6 paraview-2.4.4-3.fc6 perl-Calendar-Simple-1.14-2.fc6 perl-Email-Simple-1.992-1.fc6 perl-Error-0.17006-1.fc6 python-eyed3-0.6.10-2.fc6 python-vobject-0.4.3-1.fc6 quodlibet-0.23.1-1.fc6 root-tail-1.2-2.fc6 sipsak-0.9.6-1.fc6 spandsp-0.0.3-1.pre24.fc6 sylpheed-claws-2.5.3-1.fc6 sysprof-1.0.3-5.fc6 wmctrl-1.07-2.fc6 Packages built and released for Fedora Extras 5: 18 agave-0.4.1-1.fc5 amarok-1.4.3-6.fc5 comix-3.6-2.fc5 fuse-2.5.3-4.fc5 jd-1.7.0-2.fc5 kdemultimedia-extras-3.5.4-8.fc5 konversation-1.0.1-1.fc5 kphotobymail-0.4-1.fc5 perl-Calendar-Simple-1.14-2.fc5 perl-Email-Simple-1.992-1.fc5 perl-Error-0.17006-1.fc5 python-vobject-0.4.3-1.fc5 root-tail-1.2-2.fc5 spandsp-0.0.3-1.pre24.fc5 sylpheed-claws-2.5.3-1.fc5 sysprof-1.0.3-5.fc5 tor-0.1.1.24-1.fc5 wmctrl-1.07-2.fc5 Packages built and released for Fedora Extras 4: 3 fuse-2.5.3-4.fc4 perl-Calendar-Simple-1.14-2.fc4 sylpheed-claws-2.5.3-1.fc4 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 Sun Oct 8 00:30:08 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 7 Oct 2006 20:30:08 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-07 Message-ID: <20061008003008.A1E8D15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From buildsys at fedoraproject.org Sun Oct 8 01:08:19 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 08 Oct 2006 01:08:19 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-07 Message-ID: <20061008010819.29087.48489@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (7 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (7 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (7 days) bdpepple AT ameritech.net eds-feed - 0.5.0-2.fc6.i386 eds-feed - 0.5.0-2.fc6.ppc eds-feed - 0.5.0-2.fc6.x86_64 libgalago-gtk - 0.5.0-3.fc6.i386 libgalago-gtk - 0.5.0-3.fc6.ppc libgalago-gtk - 0.5.0-3.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (22 days) plague - 0.4.4.1-2.fc3.noarch (22 days) plague - 0.4.4.1-2.fc4.noarch (22 days) plague - 0.4.4.1-2.fc4.noarch (22 days) plague - 0.4.4.1-2.fc4.noarch (22 days) gauret AT free.fr amarok - 1.4.1-2.fc5.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i586 (2 days) kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i686 (2 days) kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (2 days) kmod-sysprof-PAE - 1.0.3-3.2.6.18_1.2726.fc6.i686 (2 days) kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.i686 (2 days) kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (2 days) kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.i686 (2 days) kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (2 days) ville.skytta AT iki.fi kid3 - 0.7-1.fc5.i386 kid3 - 0.7-1.fc5.ppc kid3 - 0.7-1.fc5.x86_64 kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 (2 days) kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 (2 days) kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc (2 days) kmod-em8300 - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 (2 days) kmod-em8300-PAE - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 (2 days) kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 (2 days) kmod-em8300-kdump - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 (2 days) kmod-em8300-smp - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc (2 days) kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 (2 days) kmod-em8300-xen - 0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 (2 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- eds-feed-0.5.0-2.fc6.ppc requires libgalago.so.2 kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6 kmod-em8300-smp-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2726.fc6smp libgalago-gtk-0.5.0-3.fc6.ppc requires libgalago.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- eds-feed-0.5.0-2.fc6.x86_64 requires libgalago.so.2()(64bit) kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen libgalago-gtk-0.5.0-3.fc6.x86_64 requires libgalago.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- eds-feed-0.5.0-2.fc6.i386 requires libgalago.so.2 kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-em8300-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-em8300-PAE-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-em8300-kdump-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-em8300-xen-0.16.0-0.2.rc1.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-sysprof-PAE-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen libgalago-gtk-0.5.0-3.fc6.i386 requires libgalago.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- kid3-0.7-1.fc5.ppc requires libtunepimp.so.3 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- amarok-1.4.1-2.fc5.x86_64 requires libtunepimp.so.3()(64bit) kid3-0.7-1.fc5.x86_64 requires libtunepimp.so.3()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- kid3-0.7-1.fc5.i386 requires libtunepimp.so.3 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: gauret AT free.fr package: amarok - 1.4.1-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libtunepimp.so.3()(64bit) ====================================================================== New report for: bdpepple AT ameritech.net package: eds-feed - 0.5.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgalago.so.2 package: libgalago-gtk - 0.5.0-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgalago.so.2 package: eds-feed - 0.5.0-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgalago.so.2()(64bit) package: libgalago-gtk - 0.5.0-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgalago.so.2()(64bit) package: libgalago-gtk - 0.5.0-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgalago.so.2 package: eds-feed - 0.5.0-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgalago.so.2 From Matt_Domsch at dell.com Sun Oct 8 02:41:59 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 7 Oct 2006 21:41:59 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-10-07 Message-ID: <20061007214159.A11724@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Sat Oct 7 20:07:14 CDT 2006 Note: This is using a reduced set of packages in the build chroot starting with FC6test2. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Note: You will need to rebuild your packages in Fedora Extras for FC6 starting August 28, 2006. See here for more details: http://www.redhat.com/archives/fedora-maintainers/2006-August/msg00160.html Total packages: 2224 Number failed to build: 30 Number expected to fail due to ExclusiveArch or ExcludeArch: 21 Leaving: 9 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 9 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com atitvout-0.4-6 andreas.bierfert at lowlatency.de em8300-kmod-0.16.0-0.2.rc1.2.6.18_1.2726.fc6 ville.skytta at iki.fi libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de mlton-20051202-8.fc6.1 adam at spicenitz.org python-reportlab-1.21.1-1.fc6 bdpepple at ameritech.net s3switch-0.0-9.20020912.fc6 paul at xelerance.com sysprof-kmod-1.0.3-3.2.6.18_1.2726.fc6 giallu at gmail.com xfce4-weather-plugin-0.5.99.1-3.fc6 fedora at christoph-wickert.de With bugs filed: 0 ---------------------------------- 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 Sun Oct 8 02:42:08 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 7 Oct 2006 21:42:08 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-10-07 Message-ID: <20061007214208.A11746@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sat Oct 7 20:11:11 CDT 2006 Note: This is using a reduced set of packages in the build chroot starting with FC6test2. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Note: You will need to rebuild your packages in Fedora Extras for FC6 starting August 28, 2006. See here for more details: http://www.redhat.com/archives/fedora-maintainers/2006-August/msg00160.html Total packages: 2224 Number failed to build: 6 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 5 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 5 ---------------------------------- em8300-kmod-0.16.0-0.2.rc1.2.6.18_1.2726.fc6 ville.skytta at iki.fi kbackup-0.5.1-2.fc6 aportal at univ-montp2.fr octave-2.9.9-1.fc6 qspencer at ieee.org sysprof-kmod-1.0.3-3.2.6.18_1.2726.fc6 giallu at gmail.com xfce4-weather-plugin-0.5.99.1-3.fc6 fedora at christoph-wickert.de With bugs filed: 0 ---------------------------------- 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 a.badger at gmail.com Sun Oct 8 05:31:39 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 07 Oct 2006 22:31:39 -0700 Subject: MaintainerResponsibilityPolicy (was Re: Claiming ownership of mantis) In-Reply-To: References: Message-ID: <1160285499.2631.62.camel@localhost> On Sat, 2006-10-07 at 17:26 -0500, Jason L Tibbitts III wrote: > >>>>> "GS" == Gianluca Sforna writes: > GS> Anyway ( sorry for being clueless ) why should we worry about > GS> legacy distros, instead of leaving that to something like an > GS> "Extras Legacy" SIG? > > And who would do that, exactly? The security team exists to help, but > maintenance of a package on all supported Fedora releases is still > the responsibility of the maintainer of said package. I don't think > that anyone expects maintainers to keep a machine with each OS > revision loaded so that everything can be tested; the community should > be relied on for some of that. But when there are security > problems it's still the maintainer's responsibility to evaluate them > and evaluate the possible solutions and at least get those evaluations > into the relevant bugzilla tickets. No. This is currently nobody's responsibility. Which is a problem which has not yet been adequately addressed. Many Extras contributors have signed on to maintain packages for the currently active releases only (where active does not include Legacy.) Others have no problems with supporting Legacy as well. We don't know how many are in each camp, only that there are squeaky wheels on both sides. We need to discuss that aspect of http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy and either make a decision or come up with a plan to make a decision: FESCo votes? Extras Contributors vote? Package by package basis? Greaco-Roman wrestling competition between the leaders on each side? I have several problems with the constant claim that it is the maintainers responsibility to maintain packages until Legacy ends: 1) I didn't sign up for that. Legacy wasn't brought up with relation to Extras until long after I joined. 2) The decision to support for that length of time is not something I had any ability to help determine. If Extras contributors were able to help decide how long Legacy support lasts it would be fair to expect that they would help to make that a reality by maintaining their packages for that length. Since this isn't currently the case, it is unfair to place the burden for supporting that decision on them. This is part of the foundation of opensource: those who do the work make the decisions. 3) The expectations for how a package is maintained while in Legacy mode are different than in the current releases. This requires a different mindset as a packager. Devel and current releases push for "latest and greatest" unless that is known to break something. Legacy releases are more suited for (but don't require) backports for (required criteria) security and serious bug fixes. 4) The package maintainer has to accept help to fix architecture specific problems if offered but isn't responsible for creating the fixes if they have no access to the arches, why is the expectation different for releases that the maintainer does not have access to test on? 5) How many contributors are against being responsible for legacy releases? If it's a small number then we either create the legacy policy and have people that pick up the slack for the few who don't want to do it (or those people will quit the project in disgust and their packages will become orphaned on all releases.) If it's a large number then attempting to hold people responsible for those releases is going to be like trying to bail out a sinking ship with a sieve. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sun Oct 8 05:45:51 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 07 Oct 2006 22:45:51 -0700 Subject: Dear Fesco: Orphan package process needs work In-Reply-To: <4527C9C8.3040505@redhat.com> References: <451BB47A.3010909@poolshark.org> <4523CF73.8030405@redhat.com> <1159976443.30534.23.camel@zod.rchland.ibm.com> <4524043F.4070205@redhat.com> <1159997686.24351.141.camel@viper.local> <452565B5.5040608@redhat.com> <1160127015.26064.154.camel@pmac.infradead.org> <452724D1.1060305@redhat.com> <20061007104322.646ea291.bugs.michael@gmx.net> <4527C9C8.3040505@redhat.com> Message-ID: <1160286351.2631.73.camel@localhost> On Sat, 2006-10-07 at 11:37 -0400, Christopher Aillon wrote: > I'm arguing that *in all cases* there should be an attempt to find a new > owner for the package the instant it is deemed the maintainer isn't > doing their job for the package. There was none in this case because > the owner stifled that. > I see the following options: 1) Do not allow the package owner to promise to reupdate the package. They've shown they do not have time, someone else has to take responsibility. 2) Force co-maintainers -- at the juncture where it is determined that package foo has not met the deadline, open it up for comaintainers to put their name in and start the rebuild. The owner can rebuild before a comaintainer gets a chance to but they have to accept the comaintainers as part of their team. 3) Postpone the release of Fedora Core until someone steps forward to maintain the Fedora Extras package. In no case can the package go into the repository for the next FC release without a maintainer. #2 is probably the best of these three options but it is far from perfect. There is plenty of room for miscommunication and conflict. Do you have a better suggestion? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sun Oct 8 05:57:09 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 07 Oct 2006 22:57:09 -0700 Subject: Soon to be marked dead packages In-Reply-To: References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> Message-ID: <1160287029.2631.84.camel@localhost> On Fri, 2006-10-06 at 23:38 -0500, Jason L Tibbitts III wrote: > >>>>> "CA" == Christopher Aillon writes: > > CA> The same thing that happens if I say I'll maintain them today, > CA> rebuild them, and then the day that FC6 is released, say I don't > CA> want them anymore. > If this happened with some regularity, the contributor would probably get a warning and then be de-sponsored. Maintaining packages is about *maintaining*. It means being responsible for them. It means being available to take care of bugs, issue updates, and liaison with upstream. If you don't have the time to do this responsibly then you shouldn't be pretending you can maintain the package. > So we should just give up and not bother trying to get unmaintained > things out of the distro? Or do you instead have something > constructive to offer? I second this. Give us ideas so we can work out something that serves everyone's needs better. -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 Sun Oct 8 09:52:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 08 Oct 2006 11:52:37 +0200 Subject: Soon to be marked dead packages In-Reply-To: <20061006231919.GE31533@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> Message-ID: <4528CA65.4070809@hhs.nl> Dave Jones wrote: > On Sat, Oct 07, 2006 at 01:07:37AM +0200, Christian Iseli wrote: > > Hi folks, > > > > The following list of packages will soon (tomorrow-ish) be marked dead > > in CVS (to avoid them being branched for FC-6 with no maintainer). > > Are these actually broken in FC6 ? > If they still compile, perhaps we can automate building some of them > until a maintainer steps up ? > I think magicpoint is the only thing I'd be sad to see go, but I have > nowhere near the time to maintain it. > I've taken a look at unorphaning it, not because I use it, but I like the magicpoint concept and I thought it would be nice to help out the Fedora kernel maintainer. And as we all know only the sun shines for free, so I was of course also hoping for a favorable treatment of kernel bugs reported by me ;) Unfortunately it requires freetype1 which is is currently stuck in review: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198836 I'm currently rather busy myself. When I find some more spare time I'll take a look at first helping the freetype1 review and when thats done unorphaning magicpoint. In the mean time a kind request if anyone else wants to work on this, please keep me posted, I hate doing double work. Regards, Hans From Axel.Thimm at ATrpms.net Sun Oct 8 10:33:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 8 Oct 2006 12:33:53 +0200 Subject: Claiming ownership of mediawiki In-Reply-To: <4527CEAB.2010809@theholbrooks.org> References: <20061007010737.79dd63fc@ludwig-alpha> <20061007090010.GH21843@neu.nirvana> <452772ED.6000608@redhat.com> <20061007093731.GK21843@neu.nirvana> <4527CEAB.2010809@theholbrooks.org> Message-ID: <20061008103353.GC21299@neu.nirvana> On Sat, Oct 07, 2006 at 10:58:35AM -0500, Brandon Holbrook wrote: > Sure, that works for me. Put me down as a comaintainer. I've added you the the initialcclist and also on all active bugs, I think that's all what currently (before the package db) can be done for setting up comaintainership. -- 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 christoph.wickert at nurfuerspam.de Sun Oct 8 11:10:21 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sun, 08 Oct 2006 13:10:21 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-10-07 In-Reply-To: <20061007214208.A11746@humbolt.us.dell.com> References: <20061007214208.A11746@humbolt.us.dell.com> Message-ID: <1160305821.3027.7.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 21:42 -0500 schrieb Matt Domsch: > Extras Rawhide-in-Mock Build Results for i386 Sat Oct 7 20:11:11 CDT 2006 > ... > > Of those expected to have worked... > Without a bug filed: 5 > ---------------------------------- ... > xfce4-weather-plugin-0.5.99.1-3.fc6 fedora at christoph-wickert.de This looks like an error of your script, cause the package that failed to build was not 0.5.99.1-3 but the old version 0.4.9-8 (according to http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/00-failed-to-build.txt ) This is not because of the reduced buildroot, but because of the upgrade to xfce 4.4. xfce4-weather-plugin-0.5.99.1 builds fine, see http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/xfce4-weather-plugin-0.5.99.1-3.fc6.src.rpm/result/build.log Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From dtimms at iinet.net.au Sun Oct 8 11:23:34 2006 From: dtimms at iinet.net.au (David Timms) Date: Sun, 08 Oct 2006 21:23:34 +1000 Subject: packaging of gui app: should it require X + wm ? Message-ID: <4528DFB6.7020300@iinet.net.au> Hi, Just trying some minimal installs of the dev tree, succesfully booting to text mode (ie no X nor wm). I did a yum install gkrellm. This installed lm-sensors, but didn't force or warn that an X implmentation or window manager should be installed. Is this considered normal, ie shouldn't yum/the package either warn that it can install because no X (or wm) exists ? I'm not specifically concerned about gkrellm, more about gui packages in general :) DaveT. From fedora at leemhuis.info Sun Oct 8 11:48:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Oct 2006 13:48:03 +0200 Subject: Need your help: Docs in the wiki Message-ID: <4528E573.2050607@leemhuis.info> Hi, I took a quick look into the Extras/part of the wiki. I did some cleanups here and there, but there were some things I didn't want to decide or fix on my own: http://www.fedoraproject.org/wiki/Extra/QAFormat - not linked from Extras/ Frontpage. - not up2date - it would be nice to have, but someone should update it, otherwise I'll remove it http://www.fedoraproject.org/wiki/Extras/BuildRequests - not linked from Extras/ Frontpage - should probably be merged into http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup http://www.fedoraproject.org/wiki/Extras/CvsAccess - should IMHO be integrated into http://www.fedoraproject.org/wiki/Extras/UsingCvsFaq http://www.fedoraproject.org/wiki/Extras/FullExceptionList - added "FIXME: We need this section per dist because there will be differences." - not linked from Extras/ Frontpage http://www.fedoraproject.org/wiki/Extras/LegacyRPMUpgrade - is that still needed? http://www.fedoraproject.org/wiki/Extras/Mirrors - last edit: 2006-05-08 - not linked from Extras/ Frontpage http://www.fedoraproject.org/wiki/Extras/NewPackageProcessMarkTwo - last real edit: 2005-08-11 - not linked from Extras/ Frontpage - is that one still needed http://www.fedoraproject.org/wiki/Extras/OrphanedPackagesFC4 - do we still need that http://www.fedoraproject.org/wiki/Extras/Policy - needs a proper front page http://www.fedoraproject.org/wiki/Extras/PackagesNeedingBootstrap http://www.fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel http://www.fedoraproject.org/wiki/Extras/RPMMacros http://www.fedoraproject.org/wiki/Extras/ReferenceMandrakeRPMMacros http://www.fedoraproject.org/wiki/Extras/ReferencePLDRPMMacros http://www.fedoraproject.org/wiki/Extras/RepositoryMixingProblems - I anybody really looking at this pages? http://www.fedoraproject.org/wiki/Extras/ReviewDay - that idea never took of; remove the page? Keep it somewhere in case we want to reactive it later? http://www.fedoraproject.org/wiki/Extras/SelfIntroduction - we don't do that anymore. Should we? http://www.fedoraproject.org/wiki/Extras/SponsorsNeeded - I can't delete it :-/ http://www.fedoraproject.org/wiki/Extras/TreeMaintenance - not linked from Extras/ Frontpage http://www.fedoraproject.org/wiki/Extras/szip - what's this? CU thl From christoph.wickert at nurfuerspam.de Sun Oct 8 12:06:36 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sun, 08 Oct 2006 14:06:36 +0200 Subject: taking over gnome-applet-netmon (Re: Soon to be marked dead packages) In-Reply-To: <20061007222817.10828f6a@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> <1160182371.3639.5.camel@hal9000.local.lan> <1160183846.3639.14.camel@hal9000.local.lan> <20061007222817.10828f6a@ludwig-alpha> Message-ID: <1160309196.3027.9.camel@hal9000.local.lan> Am Samstag, den 07.10.2006, 22:28 +0200 schrieb Christian Iseli: > On Sat, 07 Oct 2006 03:17:26 +0200, Christoph Wickert wrote: > > gnome-applet-netmon seems to be dead, upstream and in FE. Last changelog > > entry it from March 2005 and I cant find the package anywhere in the > > repo. It's not listed orphaned in the wiki. Any idea why it's showing up > > on this list? > > Simply because it still had a spec file in devel, along the > needs.rebuild file... > > Marked dead now. I also added the package to http://fedoraproject.org/wiki/Extras/RetiredPackages to avoid further confusion. Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From bugs.michael at gmx.net Sun Oct 8 13:58:28 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 Oct 2006 15:58:28 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <4528E573.2050607@leemhuis.info> References: <4528E573.2050607@leemhuis.info> Message-ID: <20061008155828.ae0fa406.bugs.michael@gmx.net> On Sun, 08 Oct 2006 13:48:03 +0200, Thorsten Leemhuis wrote: > I took a quick look into the Extras/part of the wiki. I did some > cleanups here and there, but there were some things I didn't want to > decide or fix on my own: You've reverted some of my cleanups from 1-2 days ago. ;-) Now there is one big misplaced section "For Developers" again in which you can get lost easily. Searching for things becomes to difficult. The table of contents is gone, too. > http://www.fedoraproject.org/wiki/Extras/BuildRequests > - not linked from Extras/ Frontpage > - should probably be merged into > http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup The page is linked from the FCXStatus page. This has historical reasons, as originally build requests were submitted via those Wiki pages. > http://www.fedoraproject.org/wiki/Extras/OrphanedPackagesFC4 > - do we still need that Unimportant. It doesn't hurt to keep it until FC7 Test1. A drawback of Wiki based tracking is that over time information like these lists get inaccurate. > http://www.fedoraproject.org/wiki/Extras/TreeMaintenance > - not linked from Extras/ Frontpage Could need a minor update, but doesn't make sense to put it on the front page until we re-introduce more sub-sections there. > http://www.fedoraproject.org/wiki/Extras/szip > - what's this? Looks like a temporary page for license/patent related examination of whether to include szip or not. From pertusus at free.fr Sun Oct 8 13:59:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 8 Oct 2006 15:59:12 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <20061008155828.ae0fa406.bugs.michael@gmx.net> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> Message-ID: <20061008135912.GA2267@free.fr> > > http://www.fedoraproject.org/wiki/Extras/szip > > - what's this? > > Looks like a temporary page for license/patent related examination > of whether to include szip or not. Indeed, and it has been settled, szip appears in ForbiddenItems, so the szip page may be removed. -- Pat From nicolas.mailhot at laposte.net Sun Oct 8 14:09:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 08 Oct 2006 16:09:20 +0200 Subject: Multiple entries in comps-fe6.xml.in In-Reply-To: <1160264481.3239.4.camel@rousalka.dyndns.org> References: <4527C3A8.6090405@ioa.s.u-tokyo.ac.jp> <20061007222002.798907fd@ludwig-alpha> <1160264481.3239.4.camel@rousalka.dyndns.org> Message-ID: <1160316560.2540.1.camel@rousalka.dyndns.org> Le dimanche 08 octobre 2006 ? 01:41 +0200, Nicolas Mailhot a ?crit : > Le samedi 07 octobre 2006 ? 22:20 +0200, Christian Iseli a ?crit : > > On Sun, 08 Oct 2006 00:11:36 +0900, Mamoru Tasaka wrote: > > > When I checked comps/comps-fe6.xml.in, I found that several > > > packages are listed in multiple groups. > > But it seems to > > happen for several language support packages. > > Actually, a quick run of the cleanup stylesheet will show most of the > offenders are not in the language support groups anymore. And I prove it (a run on the fedora core 6 comps is worse): xsltproc --novalid -o test comps-cleanup.xsl comps-fe6.xml.in ? Package dejavu-fonts is referenced in 4 groups: ? optional package in group Arabic Support (arabic-support) ? optional package in group Armenian Support (armenian-support) ? optional package in group X Window System (base-x) ? optional package in group Hebrew Support (hebrew-support) ? Package dejavu-fonts-experimental is referenced in 4 groups: ? optional package in group Arabic Support (arabic-support) ? optional package in group Armenian Support (armenian-support) ? optional package in group X Window System (base-x) ? optional package in group Hebrew Support (hebrew-support) ? Package deskbar-applet is referenced in 2 groups: ? optional package in group GNOME Desktop Environment (gnome-desktop) ? optional package in group Graphical Internet (graphical-internet) ? Package kickpim is referenced in 2 groups: ? optional package in group Graphical Internet (graphical-internet) ? optional package in group KDE (K Desktop Environment) (kde-desktop) ? Package gnotime is referenced in 2 groups: ? optional package in group GNOME Desktop Environment (gnome-desktop) ? optional package in group Office/Productivity (office) ? Package krecipes is referenced in 2 groups: ? optional package in group KDE (K Desktop Environment) (kde-desktop) ? optional package in group Office/Productivity (office) ? Package qcad is referenced in 2 groups: ? optional package in group Engineering and Scientific (engineering-and-scientific) ? optional package in group Office/Productivity (office) ? Package ushare is referenced in 2 groups: ? optional package in group Network Servers (network-server) ? optional package in group Sound and Video (sound-and-video) ? Package fwbuilder is referenced in 2 groups: ? optional package in group Graphical Internet (graphical-internet) ? optional package in group System Tools (system-tools) ? Package sabayon is referenced in 2 groups: ? optional package in group GNOME Desktop Environment (gnome-desktop) ? optional package in group System Tools (system-tools) ? Package x3270-x11 is referenced in 2 groups: ? optional package in group Graphical Internet (graphical-internet) ? optional package in group System Tools (system-tools) ??? Empty group Web Development (web-development)! -- Nicolas Mailhot From fedora at leemhuis.info Sun Oct 8 14:14:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Oct 2006 16:14:32 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <20061008155828.ae0fa406.bugs.michael@gmx.net> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> Message-ID: <452907C8.90902@leemhuis.info> Michael Schwendt schrieb: > On Sun, 08 Oct 2006 13:48:03 +0200, Thorsten Leemhuis wrote: > >> I took a quick look into the Extras/part of the wiki. I did some >> cleanups here and there, but there were some things I didn't want to >> decide or fix on my own: > You've reverted some of my cleanups from 1-2 days ago. ;-) Sorry. Was not on purpose. > Now there is one big misplaced section "For Developers" again in which you > can get lost easily. Well, before I got over it and moved things back and forth I found some thing in sections where I wouldn't have found them myself. So it was intuitive either afaics. > Searching for things becomes to difficult. Feel free to enhance it again. But the old way was worse imho. > The table > of contents is gone, too. I was not sure it it made much sense and I removed it therefore. But if people disagree just add it again. Maybe we should simply split the whole page into three pages -- one for users, one for developers, and one new Frontpage. >> http://www.fedoraproject.org/wiki/Extras/BuildRequests >> - not linked from Extras/ Frontpage >> - should probably be merged into >> http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup > The page is linked from the FCXStatus page. This has historical reasons, > as originally build requests were submitted via those Wiki pages. Well, I doubt new contributors are to much interested in historical things (read: they get confused by it). Let's try to get rid of the old cruft. >> http://www.fedoraproject.org/wiki/Extras/OrphanedPackagesFC4 >> - do we still need that > Unimportant. It doesn't hurt to keep it until FC7 Test1. A drawback of > Wiki based tracking is that over time information like these lists get > inaccurate. Exactly. That why I removed some old stuff ;-) >> http://www.fedoraproject.org/wiki/Extras/TreeMaintenance >> - not linked from Extras/ Frontpage > Could need a minor update, but doesn't make sense to put it on the > front page until we re-introduce more sub-sections there. Well, it is linked to from anywhere? I'd say put it there. > [...] CU thl From dominik at greysector.net Sun Oct 8 14:23:29 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 8 Oct 2006 16:23:29 +0200 Subject: FE-Legal bugzilla tickets Message-ID: <20061008142329.GB14557@rathann.pekin.waw.pl> Hello. How long does it take to handle the FE-Legal issues? Some of them have been stalled for 6 months already... Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bugs.michael at gmx.net Sun Oct 8 15:09:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 Oct 2006 17:09:35 +0200 Subject: packaging of gui app: should it require X + wm ? In-Reply-To: <4528DFB6.7020300@iinet.net.au> References: <4528DFB6.7020300@iinet.net.au> Message-ID: <20061008170935.7354dff4.bugs.michael@gmx.net> On Sun, 08 Oct 2006 21:23:34 +1000, David Timms wrote: > Hi, > Just trying some minimal installs of the dev tree, succesfully booting > to text mode (ie no X nor wm). I did a yum install gkrellm. This > installed lm-sensors, but didn't force or warn that an X implmentation > or window manager should be installed. > > Is this considered normal, ie shouldn't yum/the package either warn that > it can install because no X (or wm) exists ? > > I'm not specifically concerned about gkrellm, more about gui packages in > general :) How about running the X app on a remote display? From fedora at camperquake.de Sun Oct 8 15:08:22 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 08 Oct 2006 17:08:22 +0200 Subject: packaging of gui app: should it require X + wm ? In-Reply-To: <4528DFB6.7020300@iinet.net.au> References: <4528DFB6.7020300@iinet.net.au> Message-ID: <45291466.6010808@camperquake.de> Hi. David Timms schrieb: > Just trying some minimal installs of the dev tree, succesfully booting > to text mode (ie no X nor wm). I did a yum install gkrellm. This > installed lm-sensors, but didn't force or warn that an X implmentation > or window manager should be installed. Did it pull in (or did you have installed before) xorg-x11-libs? This is (usually) enough to get remote X going, you do not necessarily need a WM or X on the machine itself. From bugs.michael at gmx.net Sun Oct 8 15:14:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 Oct 2006 17:14:27 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <452907C8.90902@leemhuis.info> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> <452907C8.90902@leemhuis.info> Message-ID: <20061008171427.99046821.bugs.michael@gmx.net> On Sun, 08 Oct 2006 16:14:32 +0200, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Sun, 08 Oct 2006 13:48:03 +0200, Thorsten Leemhuis wrote: > > > >> I took a quick look into the Extras/part of the wiki. I did some > >> cleanups here and there, but there were some things I didn't want to > >> decide or fix on my own: > > You've reverted some of my cleanups from 1-2 days ago. ;-) > > Sorry. Was not on purpose. > > > Now there is one big misplaced section "For Developers" again in which you > > can get lost easily. > > Well, before I got over it and moved things back and forth I found some > thing in sections where I wouldn't have found them myself. So it was > intuitive either afaics. http://fedoraproject.org/wiki/Extras?action=recall&rev=113 What did you dislike? From eamitdey at yahoo.com Sun Oct 8 15:33:59 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Sun, 8 Oct 2006 08:33:59 -0700 (PDT) Subject: I am a newbie. Can i get some ideas Message-ID: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> Hi I have never contributed to the fedora extras before. But I would like to start now. Since i don't have any idea of this. I don't know what kind of packages to send. Can someone give me an idea or just briefly guide me. It would be a great help. --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Sun Oct 8 15:47:13 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 8 Oct 2006 17:47:13 +0200 Subject: I am a newbie. Can i get some ideas In-Reply-To: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> References: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> Message-ID: <20061008154713.GG1240@rathann.pekin.waw.pl> On Sunday, 08 October 2006 at 17:33, Amit Dey wrote: > Hi I have never contributed to the fedora extras before. But I would like > to start now. That's great. > Since i don't have any idea of this. I don't know what kind of packages > to send. Can someone give me an idea or just briefly guide me. Here are some starting points: http://fedoraproject.org/wiki/Extras/ Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rdieter at math.unl.edu Sun Oct 8 16:23:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 08 Oct 2006 11:23:06 -0500 Subject: FE-Legal bugzilla tickets In-Reply-To: <20061008142329.GB14557@rathann.pekin.waw.pl> References: <20061008142329.GB14557@rathann.pekin.waw.pl> Message-ID: Dominik 'Rathann' Mierzejewski wrote: > How long does it take to handle the FE-Legal issues? Some of them have been > stalled for 6 months already... The legal peoples' have been pinged, unfortunately, they're also very busy folks. -- Rex From fedora at leemhuis.info Sun Oct 8 18:11:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Oct 2006 20:11:01 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <20061008171427.99046821.bugs.michael@gmx.net> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> <452907C8.90902@leemhuis.info> <20061008171427.99046821.bugs.michael@gmx.net> Message-ID: <45293F35.2010203@leemhuis.info> Michael Schwendt schrieb: > On Sun, 08 Oct 2006 16:14:32 +0200, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> On Sun, 08 Oct 2006 13:48:03 +0200, Thorsten Leemhuis wrote: >>> Now there is one big misplaced section "For Developers" again in which you >>> can get lost easily. >> Well, before I got over it and moved things back and forth I found some >> thing in sections where I wouldn't have found them myself. So it was >> intuitive either afaics. > http://fedoraproject.org/wiki/Extras?action=recall&rev=113 > What did you dislike? - [TOC] IMHO takes to much space in the most important area for a small gain - "Contributing to Fedora Extras" should be more on top -- those that are contributors already will be able to find their stuff even if it's not that well placed; - "Extras for x86_64 status and FAQ", obsolete, old, unamitained -> removed; dito "Extras Ideas Sandbox" - "CVS Admin requests" should be in the same area as "Repository status pages for requesting manual copies and removals of packages" - "How to sponsor a new contributor?" directly behind "How to get sponsored?" is IMHO confusing because one that interested in the later will never be intereted in the first - "Reporting Issues" -> was not sure about this one myself, but maybe is more a users task? - "Contributing to Fedora Extras" and "Adding packages to Fedora Extras" -> Contributing to Fedora Extras means in 99% of the cases to add packages to Fedora Extras. So where is the difference? - Stuff that Packaging/ IMHO should have s separate section Those are some reasons behind by re-organization. CU thl From pemboa at gmail.com Sun Oct 8 18:25:34 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 8 Oct 2006 13:25:34 -0500 Subject: I am a newbie. Can i get some ideas In-Reply-To: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> References: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> Message-ID: <16de708d0610081125t67e2cc2bq26d9bc8b205862ba@mail.gmail.com> On 10/8/06, Amit Dey wrote: > Hi I have never contributed to the fedora extras before. But I would like to > start now. > > Since i don't have any idea of this. I don't know what kind of packages to > send. Can someone give me an idea or just briefly guide me. > > It would be a great help. > > I think the general advice in regards to that is to find out what thigns you like that are not currently packaged for Fedora, and try to package them for yourself and get them into extras. -- Fedora Core 5 and proud From chris.stone at gmail.com Sun Oct 8 18:33:49 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 8 Oct 2006 11:33:49 -0700 Subject: I am a newbie. Can i get some ideas In-Reply-To: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> References: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> Message-ID: On 10/8/06, Amit Dey wrote: > Since i don't have any idea of this. I don't know what kind of packages to > send. Can someone give me an idea or just briefly guide me. http://fedoraproject.org/wiki/Extras/WishList There is a list of packages people have requested others to work on. I'm still hoping a spam expert will package spambayes myself. From chris.stone at gmail.com Sun Oct 8 18:39:24 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 8 Oct 2006 11:39:24 -0700 Subject: I am a newbie. Can i get some ideas In-Reply-To: References: <20061008153359.74961.qmail@web36809.mail.mud.yahoo.com> Message-ID: On 10/8/06, Christopher Stone wrote: > On 10/8/06, Amit Dey wrote: > > Since i don't have any idea of this. I don't know what kind of packages to > > send. Can someone give me an idea or just briefly guide me. > > http://fedoraproject.org/wiki/Extras/WishList > > There is a list of packages people have requested others to work on. > I'm still hoping a spam expert will package spambayes myself. Ofcourse also the Games SIG also has a huge list of packages we need help on: http://fedoraproject.org/wiki/Extras/SIGs/Games From bugs.michael at gmx.net Sun Oct 8 19:13:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 8 Oct 2006 21:13:26 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <45293F35.2010203@leemhuis.info> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> <452907C8.90902@leemhuis.info> <20061008171427.99046821.bugs.michael@gmx.net> <45293F35.2010203@leemhuis.info> Message-ID: <20061008211326.270d166e.bugs.michael@gmx.net> On Sun, 08 Oct 2006 20:11:01 +0200, Thorsten Leemhuis wrote: > > http://fedoraproject.org/wiki/Extras?action=recall&rev=113 > > > > What did you dislike? > > - [TOC] IMHO takes to much space in the most important area for a small gain On the contrary, it adds readability when more sections and sub-sections will be added to the page. While section headlines appear in the TOC, individual bullets do not. What I didn't like about the previous page layout was that there was not clear structure. A first attempt at creating more small sections fixed that. The most recent page layout is a step backwards, IMO. Now there is one huge section "Ressources for Fedora Extras contributors" and everything squeezed into it: howtos, policies, guidelines, hints, links to external urls,... > - "Contributing to Fedora Extras" should be more on top -- ... which is only a matter of moving it up or down. However, users can also contribute to Fedora Extras, so maybe we should agree on terminology first: - Users [including pure consumers] - Contributors Maybe decide between Contributors and Developers, but not use both? Are packagers "Package Developers", "Package Maintainers"? Do we need the confusion? Are bug reports, patches, notifications or other things submitted by Users not contributions, too? Where cover anonymous CVS access? It may be relevant for Users, so why not replicate it in the "For Users" section? Then continue there: - Users [including pure consumers] - general info about FE (including mentioning FESCo!) - documentation about the repositories and packages available - info about where to report bugs - info on resources like anon CVS - Contributors - howto on signing up and getting sponsored - docs on how to sponsor other contributors - FESCo Then move on to technical stuff, policies, guidelines, hints: - Fedora Extras CVS services - howto, links to external CVS docs - admin requests (could we use OTRS instead?) - Packaging - Fedora Extras build-system - plague howto, certs howto - needsign (build-results howto) - Repository status pages - FCXStatus pages (could we use OTRS instead?) - Orphaned Packages - Retired Packages > - "CVS Admin requests" should be in the same area as "Repository status > pages for requesting manual copies and removals of packages" Which is also only a matter of moving it. Somebody just needs to do it, as it was in a different section for a long time. There a mysterious http://fedoraproject.org/wiki/Extras/Policy page in "Around Fedora Extras" which mentions policies not available on the main page. All this is very difficult to navigate. > - "How to sponsor a new contributor?" directly behind "How to get > sponsored?" is IMHO confusing because one that interested in the later > will never be intereted in the first And now it is somewhere in the middle of a huge section, somewhere under "Around Fedora Extras". IMO, everything about sponsorship ought to be in the same section: - How to become a new contributor? -and- How to get sponsored? - How to sponsor a new contributor? > - "Reporting Issues" -> was not sure about this one myself, but maybe is > more a users task? It is a bad link right now. Compare with the older http://fedoraproject.org/wiki/Extras?action=recall&rev=113 > - "Contributing to Fedora Extras" and "Adding packages to Fedora Extras" > -> Contributing to Fedora Extras means in 99% of the cases to add > packages to Fedora Extras. So where is the difference? > - Stuff that Packaging/ IMHO should have s separate section > > Those are some reasons behind by re-organization. Still not a reason to mix packaging topics with the entire rest which may be relevant to existing contributors. While 99% of being a FE contributor may be about dealing with packages, the Wiki page must cover many other things: reviews, working in FE CVS, plague, sponsoring (unless it is moved to a separate section). And it is only due to our focus on packaging that a section "Contributing to Fedora Extras" does not include documents on how to contribute other work (e.g. Security SIG, co-maintainership, buildsys or QA related tools, ...) In short, are you happy with the current look of the page? To he honest, I was not happy with rev113, but found it to be a step into the right direction. From buildsys at fedoraproject.org Sun Oct 8 20:03:30 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 8 Oct 2006 16:03:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-08 Message-ID: <20061008200330.D639115212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 16 codeblocks-1.0-0.10.20061007svn3030.fc6 eds-feed-0.5.0-3.fc6 ejabberd-1.1.2-1.fc6 em8300-kmod-0.16.0-0.3.rc1.2.6.18_1.2747.fc6 libgalago-gtk-0.5.0-4.fc6 libmcrypt-2.5.7-5.fc6 pcsc-tools-1.4.7-1.fc6 perl-AppConfig-1.63-2.fc6 perl-GD-2.35-2.fc6 pgp-tools-0.4.8-1.fc6 quarry-0.1.19-1.fc6 scrot-0.8-2.fc6 sylpheed-claws-plugins-2.5.2-2.fc6 telepathy-butterfly-0.1.2-1.fc6 yumex-1.1.4-1.0.fc6 zeroinstall-injector-0.23-1.fc6 Packages built and released for Fedora Extras 5: 12 codeblocks-1.0-0.10.20061007svn3030.fc5 dirvish-1.2.1-2.fc5 ejabberd-1.1.2-1.fc5 kid3-0.7-2.fc5 libmcrypt-2.5.7-4.fc5 pcsc-tools-1.4.7-1.fc5 pgp-tools-0.4.8-1.fc5 quarry-0.1.19-1.fc5 quodlibet-0.23.1-1.fc5 sylpheed-claws-plugins-2.5.2-2.fc5 telepathy-butterfly-0.1.2-1.fc5 zeroinstall-injector-0.23-1.fc5 Packages built and released for Fedora Extras 4: 5 ejabberd-1.1.2-1.fc4 libmcrypt-2.5.7-4.fc4 pgp-tools-0.4.8-1.fc4 quarry-0.1.19-1.fc4 zeroinstall-injector-0.23-1.fc4 Packages built and released for Fedora Extras 3: 2 quarry-0.1.19-1.fc3 zeroinstall-injector-0.23-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 Oct 8 20:04:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 8 Oct 2006 16:04:00 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-08 Message-ID: <20061008200400.D39D915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) scott AT perturb.org: qcomicbook FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) qcomicbook: scott AT perturb.org FE5 > FE6 (0:0.3.3-2.fc5 > 0:0.3.2-6.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) From ville.skytta at iki.fi Sun Oct 8 20:35:27 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 08 Oct 2006 23:35:27 +0300 Subject: Soon to be marked dead packages In-Reply-To: <1160212952.4255.77.camel@T7.Linux> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> Message-ID: <1160339727.3100.31.camel@viper.local> On Sat, 2006-10-07 at 10:22 +0100, Paul wrote: > Hi, > > > gdeskcal > > Dunno how that slipped through the net, but it's now been rebuilt. It was still listed as orphaned in Extras/OrphanedPackages in the Wiki and owners.list in CVS - I've fixed them. Everyone, if you claim something from the orphaned list, don't just push rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki *and* owners.list in CVS. From buildsys at fedoraproject.org Sun Oct 8 20:42:37 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 08 Oct 2006 20:42:37 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-08 Message-ID: <20061008204237.16567.85344@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (8 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (8 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (8 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (23 days) plague - 0.4.4.1-2.fc3.noarch (23 days) plague - 0.4.4.1-2.fc4.noarch (23 days) plague - 0.4.4.1-2.fc4.noarch (23 days) plague - 0.4.4.1-2.fc4.noarch (23 days) giallu AT gmail.com kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i586 (3 days) kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.i686 (3 days) kmod-sysprof - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (3 days) kmod-sysprof-PAE - 1.0.3-3.2.6.18_1.2726.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (3 days) kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.i686 (3 days) kmod-sysprof-xen - 1.0.3-3.2.6.18_1.2726.fc6.x86_64 (3 days) mr.ecik AT gmail.com kadu-amarok - 0.5.0-0.8.20060915svn.fc5.x86_64 tla AT rasmil.dk yumex - 1.1.4-1.0.fc6.noarch yumex - 1.1.4-1.0.fc6.noarch yumex - 1.1.4-1.0.fc6.noarch Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- yumex-1.1.4-1.0.fc6.noarch requires yum >= 0:3.0.0 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6 kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2726.fc6xen yumex-1.1.4-1.0.fc6.noarch requires yum >= 0:3.0.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2726.fc6 kmod-sysprof-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6 kmod-sysprof-PAE-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6PAE kmod-sysprof-kdump-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6kdump kmod-sysprof-xen-1.0.3-3.2.6.18_1.2726.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2726.fc6xen yumex-1.1.4-1.0.fc6.noarch requires yum >= 0:3.0.0 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- kadu-amarok-0.5.0-0.8.20060915svn.fc5.x86_64 requires amarok Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: tla AT rasmil.dk package: yumex - 1.1.4-1.0.fc6.noarch from fedora-extras-development-ppc unresolved deps: yum >= 0:3.0.0 package: yumex - 1.1.4-1.0.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: yum >= 0:3.0.0 package: yumex - 1.1.4-1.0.fc6.noarch from fedora-extras-development-i386 unresolved deps: yum >= 0:3.0.0 ====================================================================== New report for: mr.ecik AT gmail.com package: kadu-amarok - 0.5.0-0.8.20060915svn.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: amarok From paul at all-the-johnsons.co.uk Sun Oct 8 20:48:43 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 08 Oct 2006 21:48:43 +0100 Subject: Soon to be marked dead packages In-Reply-To: <1160339727.3100.31.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> <1160339727.3100.31.camel@viper.local> Message-ID: <1160340523.4255.135.camel@T7.Linux> Hi, > > > gdeskcal > > > > Dunno how that slipped through the net, but it's now been rebuilt. > > It was still listed as orphaned in Extras/OrphanedPackages in the Wiki > and owners.list in CVS - I've fixed them. Um, it was fixed in the owners.list this morning. > Everyone, if you claim something from the orphaned list, don't just push > rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki > *and* owners.list in CVS. Do I need to claim a package already mine? Fair enough... TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Sun Oct 8 21:03:00 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 Oct 2006 00:03:00 +0300 Subject: Soon to be marked dead packages In-Reply-To: <1160340523.4255.135.camel@T7.Linux> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> <1160339727.3100.31.camel@viper.local> <1160340523.4255.135.camel@T7.Linux> Message-ID: <1160341380.3100.45.camel@viper.local> On Sun, 2006-10-08 at 21:48 +0100, Paul wrote: > Hi, > > > > > gdeskcal > > > > > > Dunno how that slipped through the net, but it's now been rebuilt. > > > > It was still listed as orphaned in Extras/OrphanedPackages in the Wiki > > and owners.list in CVS - I've fixed them. > > Um, it was fixed in the owners.list this morning. Nope, I fixed it about an hour ago, it had been assigned to the orphan owner since Sep 20 before that: http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&r1=1.1798&r2=1.1799 > > Everyone, if you claim something from the orphaned list, don't just push > > rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki > > *and* owners.list in CVS. > > Do I need to claim a package already mine? Fair enough... If it's listed having the extras-orphan owner in owners.list and included in the orphans page, it's orphaned, not yours... From dtimms at iinet.net.au Sun Oct 8 22:29:56 2006 From: dtimms at iinet.net.au (David Timms) Date: Mon, 09 Oct 2006 08:29:56 +1000 Subject: packaging of gui app: should it require X + wm ? In-Reply-To: <45291466.6010808@camperquake.de> References: <4528DFB6.7020300@iinet.net.au> <45291466.6010808@camperquake.de> Message-ID: <45297BE4.9000308@iinet.net.au> Ralf Ertzinger wrote: > Hi. > > David Timms schrieb: > >> Just trying some minimal installs of the dev tree, succesfully booting >> to text mode (ie no X nor wm). I did a yum install gkrellm. This >> installed lm-sensors, but didn't force or warn that an X implmentation >> or window manager should be installed. > > Did it pull in (or did you have installed before) xorg-x11-libs? > This is (usually) enough to get remote X going, you do not necessarily > need a WM or X on the machine itself. > Thanks Ralf and Michael for the explanation. My minimal install did already have: libX11-1.0.3-4.fc6 installed. Is this the current name for what you are referring to ? I found the following in the packaging guidelines- http://www.fedoraproject.org/wiki/Packaging/Guidelines#Requires : === Requires RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: XFree86 when the dependency has already been picked up by rpm in the form of depending on libraries in the XFree86 package. === This tells me what not to do. I can't find what I should do (other than to include/install a .desktop file http://www.fedoraproject.org/wiki/Packaging/Guidelines#desktop ) with requires when I'm a packaging a gui app. For eg gkrellm includes: libSM-devel and not much else that would indicate X: http://cvs.fedora.redhat.com/viewcvs/rpms/gkrellm/devel/gkrellm.spec?root=extras&view=markup Perhaps it is part of the {invisible} list of packages that I shouldn't require ? Also, I was unable to find the list of packages that are in the newer mock base build - any pointer to such a list ? Thanks, DaveT. From mmcgrath at fedoraproject.org Sun Oct 8 23:44:08 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 8 Oct 2006 18:44:08 -0500 Subject: CVS Maintenance In-Reply-To: <20061007224947.49607221@ludwig-alpha> References: <3237e4410610070754r49306617o45c11299de17f405@mail.gmail.com> <20061007224947.49607221@ludwig-alpha> Message-ID: <3237e4410610081644q58b53dccyb4efcc2c26acf5cf@mail.gmail.com> On 10/7/06, Christian Iseli wrote: > On Sat, 7 Oct 2006 09:54:10 -0500, Mike McGrath wrote: > > We can certainly wait until FC6 is released but when would be a good > > time for you guys to have some downtime on CVS? I'm estimating only a > > few hours, just the Fedora CVS server, not the internal RH one. > > How about right before the FC-6 branches are created ? Then the > branches can be created while the system is quiet and then everything > gets back online smoothly... Doesn't matter to me, when will that happen? -Mike From fedora at leemhuis.info Mon Oct 9 04:54:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 09 Oct 2006 06:54:59 +0200 Subject: Need your help: Docs in the wiki In-Reply-To: <20061008211326.270d166e.bugs.michael@gmx.net> References: <4528E573.2050607@leemhuis.info> <20061008155828.ae0fa406.bugs.michael@gmx.net> <452907C8.90902@leemhuis.info> <20061008171427.99046821.bugs.michael@gmx.net> <45293F35.2010203@leemhuis.info> <20061008211326.270d166e.bugs.michael@gmx.net> Message-ID: <4529D623.2040505@leemhuis.info> Michael Schwendt schrieb: > On Sun, 08 Oct 2006 20:11:01 +0200, Thorsten Leemhuis wrote: >>> http://fedoraproject.org/wiki/Extras?action=recall&rev=113 > [...] > In short, are you happy with the current look of the page? I am not happy with it, but I think it's a step into the right direction. > To he honest, I was not happy with rev113, but found it to be a step > into the right direction. I don't want to argue endlessly on mailinglist over details, because that doesn't work to well and is wasting a lot of time. Michael, if you think some (or all) of my modifications are bad just remove them again or try to find a middle ground between our changes. It's a wiki and I'd really like if more people would participate in it. That worked in the beginning of Fedora Extras quite good, but these days it seems to be no one wants to touch parts of it because one might step on somebody else toes. That's quite sad and I'd like that to change that again because it can only work well if more people participate. This discussion is helping with it. CU thl P.S.: I think we really need a "official position" for one or two people that should take care of the Extras/ part of the wiki and make the decisions in discussions like this. Any volunteers? From aportal at univ-montp2.fr Mon Oct 9 07:53:59 2006 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Mon, 9 Oct 2006 09:53:59 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-10-07 In-Reply-To: <20061007214208.A11746@humbolt.us.dell.com> References: <20061007214208.A11746@humbolt.us.dell.com> Message-ID: <200610090953.59564.aportal@univ-montp2.fr> Le dimanche 8 octobre 2006 04:42, Matt Domsch a ?crit?: > Extras Rawhide-in-Mock Build Results for i386 Sat Oct 7 20:11:11 CDT 2006 > > Note: This is using a reduced set of packages in the build chroot > starting with FC6test2. See > http://fedoraproject.org/wiki/QA/FixBuildRequires for more > information, including the list of packages removed from the default > build chroot. There isn't a such list. > kbackup-0.5.1-2.fc6 aportal at univ-montp2.fr Please could you try a new built. kbackup build successfully on Oct, 2 http://buildsys.fedoraproject.org/logs/fedora-development-extras/18736-kbackup-0.5.1-2.fc6/ -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- 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 Mon Oct 9 07:56:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 Oct 2006 09:56:21 +0200 Subject: packaging of gui app: should it require X + wm ? In-Reply-To: <45297BE4.9000308@iinet.net.au> References: <4528DFB6.7020300@iinet.net.au> <45291466.6010808@camperquake.de> <45297BE4.9000308@iinet.net.au> Message-ID: <20061009095621.b5397bc2.bugs.michael@gmx.net> On Mon, 09 Oct 2006 08:29:56 +1000, David Timms wrote: > >> Just trying some minimal installs of the dev tree, succesfully booting > >> to text mode (ie no X nor wm). I did a yum install gkrellm. This > >> installed lm-sensors, but didn't force or warn that an X implmentation > >> or window manager should be installed. > > > > Did it pull in (or did you have installed before) xorg-x11-libs? > > This is (usually) enough to get remote X going, you do not necessarily > > need a WM or X on the machine itself. > > > Thanks Ralf and Michael for the explanation. My minimal install did > already have: > libX11-1.0.3-4.fc6 installed. Is this the current name for what you > are referring to ? Yes, and it is one of the dependencies of gkrellm. > I found the following in the packaging guidelines- > http://www.fedoraproject.org/wiki/Packaging/Guidelines#Requires : > === > Requires > > RPM has very good capabilities of automatically finding dependencies for > libraries and eg. Perl modules. In short, don't reinvent the wheel, but > just let rpm do its job. There is usually no need to explicitly list eg. > Requires: XFree86 when the dependency has already been picked up by rpm > in the form of depending on libraries in the XFree86 package. > === > This tells me what not to do. I can't find what I should do (other than > to include/install a .desktop file > http://www.fedoraproject.org/wiki/Packaging/Guidelines#desktop ) with > requires when I'm a packaging a gui app. It _does_ tell you what to do. Quote: "just let rpm do its job". When looking at "rpm --query --requires gkrellm" you will see the automatically added dependencies on X11, GTK+ v2 and many other libraries. It is built against stuff that depends on X11, and hence rpmbuild found out about such dependencies automatically. > For eg gkrellm includes: libSM-devel and not much else that would > indicate X: > http://cvs.fedora.redhat.com/viewcvs/rpms/gkrellm/devel/gkrellm.spec?root=extras&view=markup > gtk2-devel > Perhaps it is part of the {invisible} list of packages that I shouldn't > require ? Also, I was unable to find the list of packages that are in > the newer mock base build - any pointer to such a list ? Can't answer that since I find it difficult to navigate in the Fedora Extras Wiki pages. From bugs.michael at gmx.net Mon Oct 9 10:24:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 Oct 2006 12:24:23 +0200 Subject: rpms/listen/devel listen.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200610090826.k998QKcc001179@cvs-int.fedora.redhat.com> References: <200610090826.k998QKcc001179@cvs-int.fedora.redhat.com> Message-ID: <20061009122423.b5d10b3a.bugs.michael@gmx.net> On Mon, 9 Oct 2006 01:26:18 -0700, Ha?kel Gu?mar wrote: > Author: hguemar > > Update of /cvs/extras/rpms/listen/devel > %files > %defattr(-,root,root,-) > %doc gpl.txt > %{_bindir}/%{name} > %{_libdir}/%{name}/ > %{_datadir}/%{name}/trackedit.glade > %{_datadir}/%{name}/img/ > %{_datadir}/pixmaps/%{name}.png > %{_datadir}/applications/*.desktop Directory %{_datadir}/%{name}/ is missing! From ghenry at suretecsystems.com Mon Oct 9 08:41:37 2006 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 9 Oct 2006 09:41:37 +0100 (BST) Subject: [All Rebuilt] Re: Final reminder, Fedora Extras rebuild for FC6 In-Reply-To: <20060915000834.bc393c96@ludwig-alpha> References: <20060915000834.bc393c96@ludwig-alpha> Message-ID: <39432.192.168.100.90.1160383297.squirrel@webmail.suretecsystems.com> All done now. Really, really sorry for the lack of responses. Thanks to Steven Pratchet for some of the perl- rebuilds already. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ > Hi, > > This is the final reminder that all FE packages should be rebuilt for > FC-6. > > Please see > https://www.redhat.com/archives/fedora-extras-list/2006-September/msg00367.html > https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00611.html > http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild > > It appears the following packages you maintain still have a needs.rebuild > file in the devel directory. > > Regards, > Christian > ---- > cpan2rpm > gnome-applet-netmon > html-xml-utils > john > librsync > perl-Apache-LogRegex > perl-Gnome2-Canvas > perl-Gtk2-GladeXML > perl-Imager > pgadmin3 > rdiff-backup > Sprog > From jima at beer.tclug.org Mon Oct 9 15:31:59 2006 From: jima at beer.tclug.org (Jima) Date: Mon, 9 Oct 2006 10:31:59 -0500 (CDT) Subject: Unorphaning putty Message-ID: As per the instructions in Extras/OrphanedPackages, I'm hereby proclaiming that I'm unorphaning putty. Thanks! Jima From kushaldas at gmail.com Mon Oct 9 15:48:26 2006 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 9 Oct 2006 21:18:26 +0530 Subject: Charge of Prozilla Message-ID: <200610092118.27082.kushaldas@gmail.com> Hi, I took the charge of prozilla. Regards, Kushal From chitlesh at fedoraproject.org Mon Oct 9 15:53:56 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 9 Oct 2006 15:53:56 +0000 Subject: Charge of Prozilla In-Reply-To: <200610092118.27082.kushaldas@gmail.com> References: <200610092118.27082.kushaldas@gmail.com> Message-ID: <13dbfe4f0610090853k4e618c4dofc647683f67af737@mail.gmail.com> On 10/9/06, Kushal Das wrote: > Hi, > I took the charge of prozilla. You mean you are the packager of prozilla ? I've assigned myself as the reviewer of prozilla. chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Mon Oct 9 15:56:31 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 9 Oct 2006 15:56:31 +0000 Subject: Charge of Prozilla In-Reply-To: <13dbfe4f0610090853k4e618c4dofc647683f67af737@mail.gmail.com> References: <200610092118.27082.kushaldas@gmail.com> <13dbfe4f0610090853k4e618c4dofc647683f67af737@mail.gmail.com> Message-ID: <13dbfe4f0610090856i3342328ei815e5a421334292b@mail.gmail.com> On 10/9/06, Chitlesh GOORAH wrote: > I've assigned myself as the reviewer of prozilla. Oh I see it's been already in FE. However I feel this package needs work. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209870 chitlesh -- http://clunixchit.blogspot.com From kushaldas at gmail.com Mon Oct 9 16:08:23 2006 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 9 Oct 2006 21:38:23 +0530 Subject: Charge of Prozilla In-Reply-To: <13dbfe4f0610090853k4e618c4dofc647683f67af737@mail.gmail.com> References: <200610092118.27082.kushaldas@gmail.com> <13dbfe4f0610090853k4e618c4dofc647683f67af737@mail.gmail.com> Message-ID: <200610092138.23479.kushaldas@gmail.com> On Monday 09 October 2006 21:23, Chitlesh GOORAH wrote: > On 10/9/06, Kushal Das wrote: > > Hi, > > I took the charge of prozilla. > > You mean you are the packager of prozilla ? > > I've assigned myself as the reviewer of prozilla. > I am taking the charge of packaging of prozilla. :) regards, Kushal From caillon at redhat.com Mon Oct 9 16:33:03 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 09 Oct 2006 12:33:03 -0400 Subject: Soon to be marked dead packages In-Reply-To: <1160287029.2631.84.camel@localhost> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> <1160287029.2631.84.camel@localhost> Message-ID: <452A79BF.3070302@redhat.com> Toshio Kuratomi wrote: > On Fri, 2006-10-06 at 23:38 -0500, Jason L Tibbitts III wrote: >>>>>>> "CA" == Christopher Aillon writes: >> CA> The same thing that happens if I say I'll maintain them today, >> CA> rebuild them, and then the day that FC6 is released, say I don't >> CA> want them anymore. >> > If this happened with some regularity, the contributor would probably > get a warning and then be de-sponsored. Maintaining packages is about > *maintaining*. It means being responsible for them. It means being > available to take care of bugs, issue updates, and liaison with > upstream. If you don't have the time to do this responsibly then you > shouldn't be pretending you can maintain the package. Then we need a minimum requirement of time for package maintainers to serve. >> So we should just give up and not bother trying to get unmaintained >> things out of the distro? Or do you instead have something >> constructive to offer? > > I second this. Give us ideas so we can work out something that serves > everyone's needs better. I really am not sure why anyone would want to hear my opinion if my past opinions are deemed not "constructive". Zack explained the Debian guys have a bunch of orphan criteria that are something like: - Must have had a period for people to claim the package - Has security or major bugs Lean to leaving package in if: - No blocker bugs - Package still works - Package still useful to people. - Package is the latest upstream release - Has unique functionality - Package is popular - ...? might be more. Really, a package that meets the "don't orphan" criteria will have a maintainer soon. There will be someone who will want to maintain it. So, rather than put the package in flux, and make it so that nobody can install it for the day or three that it's waiting on a new owner, we ought to be proactive about finding new owners, especially so on these packages. Again, three people who are definitely not developers in the span of 24 hours found me about the package. Removing packages harms users of the package. Sure, this is devel. They should expect brokenness. But we shouldn't break things if we can help it. In one instance, they are using devel because FC5 didn't support their hardware. From caillon at redhat.com Mon Oct 9 16:35:36 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 09 Oct 2006 12:35:36 -0400 Subject: Soon to be marked dead packages In-Reply-To: <45275D4C.60709@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> <45275D4C.60709@redhat.com> Message-ID: <452A7A58.2070208@redhat.com> Warren Togami wrote: > Christopher Aillon wrote: >> Jason L Tibbitts III wrote: >>>>>>>> "DJ" == Dave Jones writes: >>> >>> DJ> If they still compile, perhaps we can automate building some of >>> DJ> them until a maintainer steps up ? >>> >>> They need actual maintainers, not just some automated rebuilds. What >>> happens if there's a security problem or a decision needs to be made >>> about updates? >> >> The same thing that happens if I say I'll maintain them today, rebuild >> them, and then the day that FC6 is released, say I don't want them >> anymore. >> > > The orphan removal policy was created because the Fedora Project must > sustainably grow in a responsible way. If maintainers are unwilling to > maintain packages, the responsible thing to do is to declare the > packages orphaned and move on. > > If a maintainer with a bad attitude did as you described, that would be > a breach of responsibility. The organization may decide to take > measures to either enforce responsibility or revoke access in the event > of willful non-compliance with project policies and processes. Someone wants to maintain a package for a short while, then determines they won't have the time to responsibly continue to do so in the future. Not sure how that constitutes bad attitude. If nothing else, they provided a newer package for people to use. That's a good thing, right? From jima at beer.tclug.org Mon Oct 9 16:45:40 2006 From: jima at beer.tclug.org (Jima) Date: Mon, 9 Oct 2006 11:45:40 -0500 (CDT) Subject: Soon to be marked dead packages In-Reply-To: <452A79BF.3070302@redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <20061006231919.GE31533@redhat.com> <4527200C.7040905@redhat.com> <1160287029.2631.84.camel@localhost> <452A79BF.3070302@redhat.com> Message-ID: On Mon, 9 Oct 2006, Christopher Aillon wrote: > Lean to leaving package in if: ... > - Package is popular Good luck figuring this out. I'm not aware of any way to determine this. I realize Debian has popcon (popularity contest), which can at least give a general idea of a package's user base (the ones willing to report what packages they use, at least), but we don't have any such mechanism. You could try asking who's using the package on a mailing list (either upstream's or a Fedora-centric one), but you're not remotely guaranteed a statistically significant number of users are subscribed to either. It's actually kind of a pity. Sometimes it'd be nice to know how much effort really needs to be put into keeping a package alive. Jima From notting at redhat.com Mon Oct 9 17:12:55 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Oct 2006 13:12:55 -0400 Subject: Soon to be marked dead packages In-Reply-To: <1160339727.3100.31.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> <1160339727.3100.31.camel@viper.local> Message-ID: <20061009171255.GB9892@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > It was still listed as orphaned in Extras/OrphanedPackages in the Wiki > and owners.list in CVS - I've fixed them. > > Everyone, if you claim something from the orphaned list, don't just push > rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki > *and* owners.list in CVS. How much work would it be to automate this? Bill From eamitdey at yahoo.com Mon Oct 9 18:03:14 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Mon, 9 Oct 2006 11:03:14 -0700 (PDT) Subject: How to reply to the mail in the mailing list Message-ID: <20061009180314.51930.qmail@web36815.mail.mud.yahoo.com> Hi Everyone, I have just registered for this mailing list. You know what. This is a really cool mailing list. Everyone is more than willing to help. Thanks a lot. I would like to know how to reply to a particular mail in the mailing list. Thanks. --------------------------------- Get your email and more, right on the new Yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.skytta at iki.fi Mon Oct 9 18:09:01 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 Oct 2006 21:09:01 +0300 Subject: Important - unorphaning packages properly Message-ID: <1160417341.3100.56.camel@viper.local> People, When unorphaning packages, PLEASE take the time to do it correctly. You're expected to update Extras/OrphanedPackages in Wiki (remove the package from the list of orphaned), and owners.list in CVS (make yourself as the initial owner of the package). Read the documentation in Extras/OrphanedPackages in Wiki and ask questions if unsure. Yes, TWO places. Yes, the need to update two places sucks (but people are already working on a package database which should make things easier in the future). All too often, people just don't bother to update either! If updating two things sucks for you, let me assure that doing tracking the omissions plus taking care of the two updates on your and many others behalf is more than "sucks", it's a royal PITA for someone else to take care of. Thanks in advance. From gajownik at gmail.com Mon Oct 9 18:53:46 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Mon, 09 Oct 2006 20:53:46 +0200 Subject: How to reply to the mail in the mailing list In-Reply-To: <20061009180314.51930.qmail@web36815.mail.mud.yahoo.com> References: <20061009180314.51930.qmail@web36815.mail.mud.yahoo.com> Message-ID: <452A9ABA.60603@gmail.com> Dnia 10/09/2006 08:03 PM, U?ytkownik Amit Dey napisa?: > I would like to know how to reply to a particular mail in the mailing list. Maybe you have enabled digest mode? If yes, please disable it ? https://www.redhat.com/mailman/options/fedora-extras-list Regards, Dawid -- ^_* From ville.skytta at iki.fi Mon Oct 9 19:03:31 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 Oct 2006 22:03:31 +0300 Subject: Soon to be marked dead packages In-Reply-To: <20061009171255.GB9892@nostromo.devel.redhat.com> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> <1160339727.3100.31.camel@viper.local> <20061009171255.GB9892@nostromo.devel.redhat.com> Message-ID: <1160420611.3100.81.camel@viper.local> On Mon, 2006-10-09 at 13:12 -0400, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > It was still listed as orphaned in Extras/OrphanedPackages in the Wiki > > and owners.list in CVS - I've fixed them. > > > > Everyone, if you claim something from the orphaned list, don't just push > > rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki > > *and* owners.list in CVS. > > How much work would it be to automate this? AFAIU, it's (the package database) already being worked on. Someone more familiar with it could perhaps post some estimates here? From ville.skytta at iki.fi Mon Oct 9 19:36:31 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 Oct 2006 22:36:31 +0300 Subject: Soon to be marked dead packages - updated list In-Reply-To: <20061007010737.79dd63fc@ludwig-alpha> References: <20061007010737.79dd63fc@ludwig-alpha> Message-ID: <1160422591.3100.94.camel@viper.local> On Sat, 2006-10-07 at 01:07 +0200, Christian Iseli wrote: > The following list of packages will soon (tomorrow-ish) be marked dead > in CVS (to avoid them being branched for FC-6 with no maintainer). Updated list follows. Some packages have been taken care of since the last report, and the CVS branch date has slipped a bit because of the FC slip. The following packages' devel branches are currently expected to be marked as dead tomorrow or on Wednesday unless taken care of before that. If something you're planning to work on is included, don't worry. Just bring it back (through a re-review if appropriate) when it's maintained and ready for public consumption again. ---- alsa-firmware alsa-tools amaya blam camstream cfs doulos-fonts ecore edb edje eet embryo evas fonttools gfontview gnugo gourmet gtkhtml36 gtranslator icmpdn lcdf-typetools lcov libevent libmatchbox MagicPoint mantis nucleo polyxmass-common polyxmass-data polyxmass-doc python-nltk quadkonsole repoml rkhunter rpmDirectoryCheck scim-chinese-standard scribus-templates silky spicctrl straw system-config-control tetex-fontools translate-toolkit ttf2pt1 v2strip zoo From buildsys at fedoraproject.org Mon Oct 9 19:53:58 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 Oct 2006 15:53:58 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-09 Message-ID: <20061009195358.74FA015212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 23 ClanLib-0.8.0-3.fc6 Sprog-0.14-12.fc6 apcupsd-3.12.4-3.fc6 bzr-0.11-1.fc6 bzrtools-0.11.0-1.fc6 cpan2rpm-2.028-2.fc6 gcdmaster-1.2.2-1.fc6 gcin-1.2.7-1.fc6 glom-1.0.7-1.fc6 gnome-phone-manager-0.8-3.fc6 gtkwave-3.0.13-1.fc6 html-xml-utils-3.7-4.fc6 jd-1.8.0-0.1.beta061009.fc6 librsync-0.9.7-8.fc6 listen-0.5-5.beta1.fc6 opensc-0.11.1-5.fc6 ortp-0.11.0-2.fc6 pgadmin3-1.4.3-6.fc6 qcomicbook-0.3.3-5.fc6 sysprof-1.0.3-6.fc6 sysprof-kmod-1.0.3-5.2.6.18_1.2747.fc6 wxMaxima-0.7.0a-3.fc6 yumex-1.1.4-2.0.fc6 Packages built and released for Fedora Extras 5: 14 ClanLib-0.8.0-0.7.RC2.fc5 apcupsd-3.12.4-2.fc5 bzr-0.11-1.fc5 bzrtools-0.11.0-1.fc5 gcdmaster-1.2.2-1.fc5 gcin-1.2.7-1.fc5 gnome-phone-manager-0.8-3.fc5 gtkwave-3.0.13-1.fc5 guiloader-2.8.0-2.fc5 guiloader-c++-2.8.0-2.fc5 jd-1.8.0-0.1.beta061009.fc5 ortp-0.11.0-2.fc5 sysprof-1.0.3-6.fc5 wxMaxima-0.7.0a-3.fc5 Packages built and released for Fedora Extras 4: 3 apcupsd-3.12.4-2.fc4 gcin-1.2.7-1.fc4 gtkwave-3.0.13-1.fc4 Packages built and released for Fedora Extras 3: 1 gcin-1.2.7-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 Oct 9 19:54:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 Oct 2006 15:54:32 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-09 Message-ID: <20061009195432.5B9F915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) From buildsys at fedoraproject.org Mon Oct 9 20:35:21 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 09 Oct 2006 20:35:21 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-09 Message-ID: <20061009203521.24167.2362@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (9 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (9 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (9 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (24 days) plague - 0.4.4.1-2.fc3.noarch (24 days) plague - 0.4.4.1-2.fc4.noarch (24 days) plague - 0.4.4.1-2.fc4.noarch (24 days) plague - 0.4.4.1-2.fc4.noarch (24 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 linphone - 1.2.0-4.fc5.ppc linphone - 1.2.0-4.fc5.x86_64 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.x86_64 mr.ecik AT gmail.com kadu-amarok - 0.5.0-0.8.20060915svn.fc5.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- kadu-amarok-0.5.0-0.8.20060915svn.fc5.x86_64 requires amarok linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libortp.so.2 From fedora at camperquake.de Mon Oct 9 20:37:39 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 9 Oct 2006 22:37:39 +0200 Subject: Soon to be marked dead packages - updated list In-Reply-To: <1160422591.3100.94.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160422591.3100.94.camel@viper.local> Message-ID: <20061009223739.5af2d3ef@lain> Hi. On Mon, 09 Oct 2006 22:36:31 +0300, Ville Skytt? wrote > libevent libevent is in Core. From bugs.michael at gmx.net Mon Oct 9 21:03:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 Oct 2006 23:03:52 +0200 Subject: Soon to be marked dead packages - updated list In-Reply-To: <20061009223739.5af2d3ef@lain> References: <20061007010737.79dd63fc@ludwig-alpha> <1160422591.3100.94.camel@viper.local> <20061009223739.5af2d3ef@lain> Message-ID: <20061009230352.fa5900d8.bugs.michael@gmx.net> On Mon, 9 Oct 2006 22:37:39 +0200, Ralf Ertzinger wrote: > Hi. > > On Mon, 09 Oct 2006 22:36:31 +0300, Ville Skytt? wrote > > > libevent > > libevent is in Core. If you meant to say it has moved from Extras to Core, please clean up "devel" in CVS appropriately. It still exists including the needs.rebuild file. Remove all files and add a "dead.package" file which says package has moved to Core. $ grep libevent owners.list Fedora Extras|libevent|Abstract asynchronous event notification library|redhat-bugzilla at camperquake.de|extras-qa at fedoraproject.org| From giallu at gmail.com Mon Oct 9 22:41:12 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 10 Oct 2006 00:41:12 +0200 Subject: Soon to be marked dead packages - updated list In-Reply-To: <1160422591.3100.94.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160422591.3100.94.camel@viper.local> Message-ID: On 10/9/06, Ville Skytt? wrote: > On Sat, 2006-10-07 at 01:07 +0200, Christian Iseli wrote: > > > The following list of packages will soon (tomorrow-ish) be marked dead > > in CVS (to avoid them being branched for FC-6 with no maintainer). > > Updated list follows. Some packages have been taken care of since the > last report, and the CVS branch date has slipped a bit because of the > FC slip. The following packages' devel branches are currently expected > to be marked as dead tomorrow or on Wednesday unless taken care of > before that. > I just unorphaned mantis From a.badger at gmail.com Tue Oct 10 00:12:16 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Oct 2006 17:12:16 -0700 Subject: Soon to be marked dead packages In-Reply-To: <1160420611.3100.81.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160212952.4255.77.camel@T7.Linux> <1160339727.3100.31.camel@viper.local> <20061009171255.GB9892@nostromo.devel.redhat.com> <1160420611.3100.81.camel@viper.local> Message-ID: <1160439136.5944.8.camel@localhost> On Mon, 2006-10-09 at 22:03 +0300, Ville Skytt? wrote: > On Mon, 2006-10-09 at 13:12 -0400, Bill Nottingham wrote: > > Ville Skytt? (ville.skytta at iki.fi) said: > > > It was still listed as orphaned in Extras/OrphanedPackages in the Wiki > > > and owners.list in CVS - I've fixed them. > > > > > > Everyone, if you claim something from the orphaned list, don't just push > > > rebuilds. Make sure you've updated Extras/OrphanedPackages in Wiki > > > *and* owners.list in CVS. > > > > How much work would it be to automate this? > > AFAIU, it's (the package database) already being worked on. Someone > more familiar with it could perhaps post some estimates here? > The idea is that changes to the packagedb will make changes to the VCS ACLS. Owners.list and the wiki OrphanedPackages would both be phased out. So if a package were orphaned, the ACLs for the VCS might be changed to disallow commits. Someone would have to step up to be the official maintainership for commits to the branch to be reenabled. This functionality is something we want to be inherent to the packageDB but relies on getting the new VCS in place at the same time. Currently we're shooting to have both running in time for FC7t2 but we're still in the prototype phase. The other end of this is creating automated lists of orphaned packages per release like the current, manually driven OrphanedPackages page. This functionality is separate from assigning owners and co-maintainers so it may happen after the first round of the packagedb depending on the amount of time we have for completing it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Oct 10 15:46:09 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 10 Oct 2006 11:46:09 -0400 Subject: Ownership of Fyre Message-ID: <1160495169.13497.1.camel@shuttle.piedmont.com> I'm interested in taking over ownership of the orphaned package Fyre. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Tue Oct 10 19:12:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Oct 2006 15:12:34 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-10 Message-ID: <20061010191235.008F215212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 28 Thunar-0.4.0-0.11.rc1.fc6 abcMIDI-20061005-2.fc6 cogito-0.18-1.fc6 crossvc-1.5.0-3.fc6 fyre-1.0.1-1.fc6 ganymed-ssh2-210-2.fc6 gift-0.11.8.1-6.fc6.1 gnugo-3.6-5.fc6 k3d-0.6.3.1-1.fc6 kadu-0.5.0-0.15.20060915svn.fc6 libglademm24-2.6.3-2.fc6 libsigc++-1.2.7-4.fc6 lilypond-2.8.7-1.fc6 lilypond-doc-2.8.7-1.fc6 mantis-1.0.5-1.fc6 nagios-plugins-snmp-disk-proc-1.0-1.fc6 oorexx-3.1.0-5.fc6 perl-Moose-0.14-1.fc6 python-nltk-1.4.4-2.fc6 python-paramiko-1.6.2-1.fc6 python-telepathy-0.13.3-1.fc6 python-turbocheetah-0.9.5-4.fc6 quarry-0.1.19-2.fc6 ruby-racc-1.4.5-2.fc6 snort-2.6.0.2-2.fc6 ss5-3.5.9-4 wcstools-3.6.6-0.1.beta.fc6 xdg-utils-1.0-1.fc6 Packages built and released for Fedora Extras 5: 22 abcMIDI-20061005-2.fc5 cogito-0.18-1.fc5 crossvc-1.5.0-3.fc5 ganymed-ssh2-210-2.fc5 gift-0.11.8.1-6.fc5 glibmm24-2.8.12-1 gtkmm24-2.8.9-1.fc5 kadu-0.5.0-0.9.20060915svn.fc5 libglademm24-2.6.3-2.fc5 libsigc++-1.2.7-3.fc5 libsmi-0.4.5-2.fc5 lilypond-2.8.7-1.fc5 lilypond-doc-2.8.7-1.fc5 nagios-plugins-snmp-disk-proc-1.0-1.fc5 oorexx-3.1.0-5.fc5 perl-Moose-0.14-1.fc5 python-paramiko-1.6.2-1.fc5 quarry-0.1.19-2.fc5 sipsak-0.9.6-1.fc5 snort-2.6.0.2-2.fc5 wcstools-3.6.6-0.1.beta.fc5 xdg-utils-1.0-1.fc5 Packages built and released for Fedora Extras 4: 8 cogito-0.18-1.fc4 gift-0.11.8.1-6.fc4 libglademm24-2.6.3-1.fc4 libsigc++-1.2.7-2.fc4 python-paramiko-1.6.2-1.fc4 quarry-0.1.19-2.fc4 wcstools-3.6.6-0.1.beta.fc4 xdg-utils-1.0-1.fc4 Packages built and released for Fedora Extras 3: 2 cogito-0.18-1.fc3 quarry-0.1.19-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 Tue Oct 10 19:13:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Oct 2006 15:13:05 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-10 Message-ID: <20061010191305.6616815212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) tzdata FC5-updates > FC6 (0:2006m-2.fc5 > 0:2006j-1.fc6) xsane FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) FC4-updates > FC6 (0:1.02.07-2.0 > 0:1.02.07-1.1) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) tzdata: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2006m-2.fc5 > 0:2006j-1.fc6) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) From wcervini at gmail.com Tue Oct 10 19:36:36 2006 From: wcervini at gmail.com (Walter Cervini <[volp]>) Date: Tue, 10 Oct 2006 15:36:36 -0400 Subject: Drop Packages Message-ID: <1160508996.6970.6.camel@walter.volp.org.ve> Hi list I want to drop two packages from the list perl-Net-SCP & perl-Net-SSH Thanks Walter Cervini (volp) wcervini at gmail.com http://fedora-ve.org/ Linux Counter #353289 Id de Clave GPG/PGP: 72034b40 Fedora User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From buildsys at fedoraproject.org Tue Oct 10 19:55:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 10 Oct 2006 19:55:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-10 Message-ID: <20061010195506.32262.16751@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (10 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (10 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (10 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (25 days) plague - 0.4.4.1-2.fc3.noarch (25 days) plague - 0.4.4.1-2.fc4.noarch (25 days) plague - 0.4.4.1-2.fc4.noarch (25 days) plague - 0.4.4.1-2.fc4.noarch (25 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 linphone - 1.2.0-4.fc5.ppc linphone - 1.2.0-4.fc5.x86_64 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.x86_64 mr.ecik AT gmail.com kadu-amarok - 0.5.0-0.8.20060915svn.fc5.x86_64 (2 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- kadu-amarok-0.5.0-0.8.20060915svn.fc5.x86_64 requires amarok kadu-amarok-0.5.0-0.8.20060915svn.fc5.x86_64 requires kadu = 0:0.5.0-0.8.20060915svn.fc5 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From giallu at gmail.com Tue Oct 10 22:23:50 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 11 Oct 2006 00:23:50 +0200 Subject: reassigning multiple bugs in bugzilla Message-ID: Once I got the ownership of mantis, I search for all its open issues on bugzilla, then I tried to reassign them to myself. The problem was I could select all of them, but trying to apply the modification (owner change) resulted in a error,something like: it does not seem you made any modification. Just to be sure it was not some random permission problem, I tried with just one and that worked. Anyone ever tried this kind of operation? From bugs.michael at gmx.net Tue Oct 10 23:27:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 11 Oct 2006 01:27:06 +0200 Subject: reassigning multiple bugs in bugzilla In-Reply-To: References: Message-ID: <20061011012706.794d949c.bugs.michael@gmx.net> On Wed, 11 Oct 2006 00:23:50 +0200, Gianluca Sforna wrote: > Once I got the ownership of mantis, I search for all its open issues > on bugzilla, then I tried to reassign them to myself. > The problem was I could select all of them, but trying to apply the > modification (owner change) resulted in a error,something like: it > does not seem you made any modification. > > Just to be sure it was not some random permission problem, I tried > with just one and that worked. > > Anyone ever tried this kind of operation? Yes, and there is a bug somewhere. Changing multiple tickets at once works for some types of changes and fails for other types of changes. If you think that adding a comment, while trying to reassign all bugs, is recognised as a modification, I think that leads to unexpected modifications as a side-effect. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 11 12:51:45 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 11 Oct 2006 21:51:45 +0900 Subject: rpms/gnupg2/devel .cvsignore, 1.12, 1.13 gnupg2.spec, 1.50, 1.51 sources, 1.14, 1.15 In-Reply-To: <200610111223.k9BCN8du016885@cvs-int.fedora.redhat.com> References: <200610111223.k9BCN8du016885@cvs-int.fedora.redhat.com> Message-ID: <452CE8E1.2060900@ioa.s.u-tokyo.ac.jp> Rex Dieter (rdieter) wrote: > Author: rdieter > > Update of /cvs/extras/rpms/gnupg2/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16856 > > Modified Files: > .cvsignore gnupg2.spec sources > Log Message: > * Wed Oct 11 2006 Rex Dieter 1.9.92-1 > - 1.9.92 > I get the following error: [root at localhost ~]# yum -y upgrade gnupg2 Loading "installonlyn" plugin Setting up Upgrade Process Setting up repositories Reading repository metadata in from local files Excluding Packages from Livna.org - Fedora Devel Compatible Packages (stable) Finished Excluding Packages from Livna.org - Fedora Compatible Packages (stable) Finished Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for gnupg2 to pack into transaction set. gnupg2-1.9.92-1.fc6.i386. 100% |=========================| 19 kB 00:00 ---> Package gnupg2.i386 0:1.9.92-1.fc6 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: gnupg2 i386 1.9.92-1.fc6 buildsys-extras 2.1 M Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 2.1 M Downloading Packages: (1/1): gnupg2-1.9.92-1.fc 100% |=========================| 2.1 MB 00:24 Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/bin/gpg-zip from install of gnupg2-1.9.92-1.fc6 conflicts with file from package gnupg-1.4.5-4 file /usr/bin/gpgsplit from install of gnupg2-1.9.92-1.fc6 conflicts with file from package gnupg-1.4.5-4 file /usr/share/man/man7/gnupg.7.gz from install of gnupg2-1.9.92-1.fc6 conflicts with file from package gnupg-1.4.5-4 From ndbecker2 at gmail.com Wed Oct 11 13:18:40 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Oct 2006 09:18:40 -0400 Subject: Advice on rpath Message-ID: It seems many (most?) modern apps that install libs will want to hardcode paths using -rpath. It seems this causes rpm builds to fail, e.g.: * 'check-rpaths' is part of 'rpmdevtools'. * ******************************************************************************* ERROR 0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64] [...] In some cases, configure has --disable-rpaths that can fix this. In other cases not. Is it acceptable for fe-extras to ignore this error? AFAICT, this is harmless. What is the motivation to make this an error? From jima at beer.tclug.org Wed Oct 11 13:36:30 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 11 Oct 2006 08:36:30 -0500 (CDT) Subject: reassigning multiple bugs in bugzilla In-Reply-To: References: Message-ID: On Wed, 11 Oct 2006, Gianluca Sforna wrote: > Once I got the ownership of mantis, I search for all its open issues > on bugzilla, then I tried to reassign them to myself. > The problem was I could select all of them, but trying to apply the > modification (owner change) resulted in a error,something like: it > does not seem you made any modification. I've heard people muttering that for some things, you have to add a comment, too; have you tried that? (Not guaranteeing it'll work, I just seem to recall someone saying something about it.) Jima From kevin.kofler at chello.at Wed Oct 11 13:38:40 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Oct 2006 13:38:40 +0000 (UTC) Subject: Advice on rpath References: Message-ID: > ERROR 0001: file '/usr/bin/xapian-tcpsrv' contains a standard > rpath '/usr/lib64' in [/usr/lib64] The problem here is that the program doesn't understand 64-bit multilibs. Rpaths are supposed to be set only for directories which are NOT standard library directories. Unfortunately, the build system used by this program (and all the others having the same issue) does not understand that /usr/lib64 is a standard library directory (or worse, it might just unconditionally put the rpath there). If this is a libtool-based build system, "relibtoolize" with the Fedora libtool (i.e. run "libtoolize") to fix this. If this is a simpler build system, like QMake, CMake, SCons etc., it's usually a one-line fix in the project description. > Is it acceptable for fe-extras to ignore this error? AFAICT, this is > harmless. What is the motivation to make this an error? Well, if you want an official answer, you have to ask the ones who set the policies. (That would probably be the Fedora Packaging Committee in this case.) However, here are some reasons: The rpath is redundant, so it is probably inefficient. It also breaks if some future version of Fedora moves the libs to /usr/lib (i.e. no more multilib), /usr/lib64-oldabi (e.g. if some big GCC ABI change hits), /lib64 (i.e. no more /usr, which might be possible even for NFS setups using some unionfs-type solution) or whatever other location. Kevin Kofler From rdieter at math.unl.edu Wed Oct 11 13:47:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Oct 2006 08:47:14 -0500 Subject: rpms/gnupg2/devel .cvsignore, 1.12, 1.13 gnupg2.spec, 1.50, 1.51 sources, 1.14, 1.15 References: <200610111223.k9BCN8du016885@cvs-int.fedora.redhat.com> <452CE8E1.2060900@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: > Rex Dieter (rdieter) wrote: >> Author: rdieter >> >> Update of /cvs/extras/rpms/gnupg2/devel >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16856 >> >> Modified Files: >> .cvsignore gnupg2.spec sources >> Log Message: >> * Wed Oct 11 2006 Rex Dieter 1.9.92-1 >> - 1.9.92 >> > > I get the following error: > > [root at localhost ~]# yum -y upgrade gnupg2 > Transaction Check Error: file /usr/bin/gpg-zip from install of > gnupg2-1.9.92-1.fc6 conflicts with file from package gnupg-1.4.5-4 > file /usr/bin/gpgsplit from install of gnupg2-1.9.92-1.fc6 conflicts > with file from > package gnupg-1.4.5-4 > file /usr/share/man/man7/gnupg.7.gz from install of gnupg2-1.9.92-1.fc6 > conflicts with > file from package gnupg-1.4.5-4 holy crap, 34!$!#%%^$@#. batman. So much for upstream's claims of dual-installability. I'll fix this up asap. -- Rex From rdieter at math.unl.edu Wed Oct 11 14:05:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Oct 2006 09:05:08 -0500 Subject: Advice on rpath References: Message-ID: Neal Becker wrote: > It seems many (most?) modern apps that install libs will want to hardcode > paths using -rpath. It seems this causes rpm builds to fail, e.g.: > > * 'check-rpaths' is part of 'rpmdevtools'. > * > ******************************************************************************* > ERROR 0001: file '/usr/bin/xapian-tcpsrv' contains a standard > rpath '/usr/lib64' in [/usr/lib64] > [...] > > In some cases, configure has --disable-rpaths that can fix this. In other > cases not. > > Is it acceptable for fe-extras to ignore this error? AFAICT, this is > harmless. What is the motivation to make this an error? It's not exactly harmless, but it's not a deal-breaker either. IMO, it's one of those SHOULD fix items, but not worth moving mountains for... -- Rex From paul at xelerance.com Wed Oct 11 14:44:19 2006 From: paul at xelerance.com (Paul Wouters) Date: Wed, 11 Oct 2006 16:44:19 +0200 (CEST) Subject: rng-tools / rng-utils / core functionality vs extras ? Message-ID: Hi, There was some discussion (caused by me) on hardware RNG and /dev/random and /dev/hw* devices. The conclusion seems to be that the only "valid" way of using hardware random is by using "rngd" to feed /dev/hw* random into /dev/random, but only after FIPS checking, which is done by rngd. This check is essential since the /dev/hw* devices can return very non-random data, so these devices should never be used directly. (openswan 2.4.7 will no longer access those devivces directly) Since I did not find an rng-tools package, I created one for extras, uploaded at ftp://ftp.xelerance.com/rng-tools/ Then I found that rng-utils exist, which seems to be based on the same source, but it has no initscripts at all to launch "rngd" at boot. The question now is, do I submit the initscripts extension as bug to rng-utils, or do I submit an rng-tools package that "obsoletes" rng-utils? Personally, I think this functionality should be in core (and the service pref should be called rngd, not rng-utils). But if rng-utils will not be extended with initscripts, I'd want to have something in Extras that does have a init script. Again, any system with a hardware RNG should be running this daemon or else it will not be able to use hardware RNG at all. Paul From rdieter at math.unl.edu Wed Oct 11 14:37:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Oct 2006 09:37:17 -0500 Subject: rpms/galago-filesystem/devel galago-filesystem.spec,NONE,1.1 References: <200610111426.k9BEQ3Nr000935@cvs-int.fedora.redhat.com> Message-ID: Brian Pepple (bpepple) wrote: > --- NEW FILE galago-filesystem.spec --- > Name: galago-filesystem ... > %description > This package provides some directories which are required by other > packages which comprise the Galago release. ... > %files > %defattr(-,root,root,-) > %dir %{_libdir}/galago Is it just me, but doesn't creating a pkg that owns but a single directory seem kinda silly? -- Rex From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 11 15:02:22 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 12 Oct 2006 00:02:22 +0900 Subject: rpms/gnupg2/devel .cvsignore, 1.12, 1.13 gnupg2.spec, 1.50, 1.51 sources, 1.14, 1.15 In-Reply-To: References: <200610111223.k9BCN8du016885@cvs-int.fedora.redhat.com> <452CE8E1.2060900@ioa.s.u-tokyo.ac.jp> Message-ID: <452D077E.7090108@ioa.s.u-tokyo.ac.jp> Rex Dieter wrote: > Mamoru Tasaka wrote: > >> Rex Dieter (rdieter) wrote: >>> Author: rdieter >>> >>> Update of /cvs/extras/rpms/gnupg2/devel >>>> * Wed Oct 11 2006 Rex Dieter 1.9.92-1 >>> - 1.9.92 >>> >> I get the following error: >> >> [root at localhost ~]# yum -y upgrade gnupg2 > >> Transaction Check Error: file /usr/bin/gpg-zip from install of >> gnupg2-1.9.92-1.fc6 conflicts with file from package gnupg-1.4.5-4 >> file /usr/bin/gpgsplit from install of gnupg2-1.9.92-1.fc6 conflicts >> with file from >> package gnupg-1.4.5-4 > > I'll fix this up asap. > > -- Rex I successfully upgraded to 1.9.92-2.fc6. Thanks. From bpepple at fedoraproject.org Wed Oct 11 15:54:51 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 11 Oct 2006 11:54:51 -0400 Subject: rpms/galago-filesystem/devel galago-filesystem.spec,NONE,1.1 In-Reply-To: References: <200610111426.k9BEQ3Nr000935@cvs-int.fedora.redhat.com> Message-ID: <1160582091.17275.5.camel@shuttle.piedmont.com> On Wed, 2006-10-11 at 09:37 -0500, Rex Dieter wrote: > Is it just me, but doesn't creating a pkg that owns but a single directory > seem kinda silly? No, in this case you are right, since this directory can probably be owned by libgalago. I was thinking of Telepathy which does need to have a separate package for the filesystem. /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 giallu at gmail.com Wed Oct 11 16:06:30 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 11 Oct 2006 18:06:30 +0200 Subject: reassigning multiple bugs in bugzilla In-Reply-To: References: Message-ID: On 10/11/06, Jima wrote: > I've heard people muttering that for some things, you have to add a > comment, too; have you tried that? (Not guaranteeing it'll work, I just > seem to recall someone saying something about it.) > Will try next time: Ville took care of reassigning them in the meanwhile... From ville.skytta at iki.fi Wed Oct 11 16:43:15 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 11 Oct 2006 19:43:15 +0300 Subject: reassigning multiple bugs in bugzilla In-Reply-To: References: Message-ID: <1160584995.5102.0.camel@viper.local> On Wed, 2006-10-11 at 00:23 +0200, Gianluca Sforna wrote: > Once I got the ownership of mantis, I search for all its open issues > on bugzilla, then I tried to reassign them to myself. > The problem was I could select all of them, but trying to apply the > modification (owner change) resulted in a error,something like: it > does not seem you made any modification. [...] > Anyone ever tried this kind of operation? https://bugzilla.redhat.com/199872 From buildsys at fedoraproject.org Wed Oct 11 18:56:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 11 Oct 2006 14:56:47 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-11 Message-ID: <20061011185647.B3210152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 24 amavisd-new-2.4.3-1.fc6 ballbuster-1.0-1.fc6 bidiv-1.5-4.fc6 bitmap-1.0.2-3.fc6 cobbler-0.2.3-1.fc6 eds-feed-0.5.0-5.fc6 galago-filesystem-0.0.1-2.fc6 gentoo-0.11.56-2.fc6 gnupg2-1.9.92-2.fc6 gv-3.6.2-1.fc6 jack-audio-connection-kit-0.102.20-2.0.fc6 koan-0.2.1-1.fc6 libassuan-0.9.3-1.fc6 libgalago-0.5.2-2.fc6 lighttpd-1.4.13-1.fc6 mediawiki-1.8.0-2.fc6 nas-1.8-10.fc6 nethack-vultures-2.1.0-8.fc6 perl-Object-InsideOut-2.06-1.fc6 perl-POE-Component-IRC-5.05-1.fc6 perl-SQL-Library-0.0.3-2.fc6 stellarium-0.8.2-1.fc6 telepathy-feed-0.13-2.fc6 tenr-de-styles-pkg-1.0-2.fc6 Packages built and released for Fedora Extras 5: 18 alsa-oss-1.0.11-1.fc5 eds-feed-0.5.0-2.fc5 gaim-galago-0.5.1-1.fc5 galago-daemon-0.5.1-1.fc5 gentoo-0.11.56-2.fc5 gv-3.6.2-1.fc5 libgalago-0.5.2-2.fc5 listen-0.5-5.beta1.fc5 mirrormagic-2.0.2-2.fc5 nas-1.8-10.fc5 nethack-vultures-2.1.0-8.fc5 perl-Object-InsideOut-2.06-1.fc5 perl-POE-Component-IRC-5.05-1.fc5 python-eyed3-0.6.10-2.fc5 ruby-postgres-0.7.1-4.fc5 scrot-0.8-2.fc5 stellarium-0.8.2-1.fc5 supertuxkart-0.2-3.fc5 Packages built and released for Fedora Extras 4: 2 nas-1.8-10.fc4 nethack-vultures-2.1.0-8.fc4 Packages built and released for Fedora Extras 3: 1 nethack-vultures-2.1.0-8.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 Wed Oct 11 18:57:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 11 Oct 2006 14:57:20 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-11 Message-ID: <20061011185720.B84C4152130@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) From buildsys at fedoraproject.org Wed Oct 11 19:36:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 11 Oct 2006 19:36:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-11 Message-ID: <20061011193644.4074.7138@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (11 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (11 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (11 days) bdpepple AT ameritech.net libgalago-gtk - 0.5.0-2.fc5.i386 libgalago-gtk - 0.5.0-2.fc5.ppc libgalago-gtk - 0.5.0-2.fc5.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (26 days) plague - 0.4.4.1-2.fc3.noarch (26 days) plague - 0.4.4.1-2.fc4.noarch (26 days) plague - 0.4.4.1-2.fc4.noarch (26 days) plague - 0.4.4.1-2.fc4.noarch (26 days) giallu AT gmail.com kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (2 days) linphone - 1.2.0-4.fc5.ppc (2 days) linphone - 1.2.0-4.fc5.x86_64 (2 days) linphone - 1.2.0-7.fc6.i386 (2 days) linphone - 1.2.0-7.fc6.ppc (2 days) linphone - 1.2.0-7.fc6.x86_64 (2 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6smp linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-sysprof-PAE-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libgalago-gtk-0.5.0-2.fc5.ppc requires libgalago.so.2 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libgalago-gtk-0.5.0-2.fc5.x86_64 requires libgalago.so.2()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libgalago-gtk-0.5.0-2.fc5.i386 requires libgalago.so.2 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: giallu AT gmail.com package: kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump package: kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6xen package: kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6 package: kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6PAE package: kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6 package: kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6xen package: kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6kdump package: kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2747.fc6 ====================================================================== New report for: ville.skytta AT iki.fi package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2747.fc6 package: kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc from fedora-extras-development-ppc unresolved deps: kernel-ppc = 0:2.6.18-1.2747.fc6smp package: kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6xen package: kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.18-1.2747.fc6 package: kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6kdump package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6 package: kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6xen package: kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 from fedora-extras-development-i386 unresolved deps: kernel-i586 = 0:2.6.18-1.2747.fc6 package: kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 from fedora-extras-development-i386 unresolved deps: kernel-i686 = 0:2.6.18-1.2747.fc6PAE ====================================================================== New report for: bdpepple AT ameritech.net package: libgalago-gtk - 0.5.0-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libgalago.so.2 package: libgalago-gtk - 0.5.0-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libgalago.so.2()(64bit) package: libgalago-gtk - 0.5.0-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libgalago.so.2 From triad at df.lth.se Wed Oct 11 21:18:11 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 11 Oct 2006 23:18:11 +0200 (CEST) Subject: Advice on rpath In-Reply-To: References: Message-ID: Neal Becker wrote: > In some cases, configure has --disable-rpaths that can fix this. In other > cases not. What Debian does is use chrpath (http://packages.debian.org/stable/utils/chrpath) which simply goes into the binary and change it the hard way. If there is need for it I could take a stab at packaging it. Linus From pertusus at free.fr Wed Oct 11 21:21:10 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 11 Oct 2006 23:21:10 +0200 Subject: Advice on rpath In-Reply-To: References: Message-ID: <20061011212110.GB23049@free.fr> On Wed, Oct 11, 2006 at 11:18:11PM +0200, Linus Walleij wrote: > Neal Becker wrote: > > >In some cases, configure has --disable-rpaths that can fix this. In other > >cases not. > > What Debian does is use chrpath > (http://packages.debian.org/stable/utils/chrpath) > which simply goes into the binary and change it the hard way. > > If there is need for it I could take a stab at packaging it. It seems to be allready packaged (chrpath-0.13-1.1.fc6). -- Pat From ville.skytta at iki.fi Wed Oct 11 21:40:51 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 12 Oct 2006 00:40:51 +0300 Subject: Packages marked as dead In-Reply-To: <1160422591.3100.94.camel@viper.local> References: <20061007010737.79dd63fc@ludwig-alpha> <1160422591.3100.94.camel@viper.local> Message-ID: <1160602851.5102.4.camel@viper.local> On Mon, 2006-10-09 at 22:36 +0300, Ville Skytt? wrote: > On Sat, 2006-10-07 at 01:07 +0200, Christian Iseli wrote: > > > The following list of packages will soon (tomorrow-ish) be marked dead > > in CVS (to avoid them being branched for FC-6 with no maintainer). > > Updated list follows. And here's the final one - these packages' devel branches have been marked as dead in CVS today. ---- alsa-firmware alsa-tools amaya blam camstream cfs doulos-fonts ecore edb edje eet embryo evas fonttools gfontview gourmet gtkhtml36 gtranslator icmpdn lcdf-typetools lcov libevent libmatchbox MagicPoint nucleo polyxmass-common polyxmass-data polyxmass-doc quadkonsole repoml rkhunter rpmDirectoryCheck scim-chinese-standard scribus-templates silky spicctrl straw system-config-control tetex-fontools translate-toolkit ttf2pt1 v2strip zoo From davej at redhat.com Thu Oct 12 01:01:24 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Oct 2006 21:01:24 -0400 Subject: rng-tools / rng-utils / core functionality vs extras ? In-Reply-To: References: Message-ID: <20061012010124.GC14039@redhat.com> On Wed, Oct 11, 2006 at 04:44:19PM +0200, Paul Wouters wrote: > The question now is, do I submit the initscripts extension as bug to rng-utils, > or do I submit an rng-tools package that "obsoletes" rng-utils? The former. Renaming for no good reason is pointless, and just causes confusion. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Oct 12 01:03:02 2006 From: roland at redhat.com (Roland McGrath) Date: Wed, 11 Oct 2006 18:03:02 -0700 (PDT) Subject: Packages marked as dead In-Reply-To: Ville Skyttä's message of Thursday, 12 October 2006 00:40:51 +0300 <1160602851.5102.4.camel@viper.local> Message-ID: <20061012010302.8035F180066@magilla.sf.frob.com> > lcov Sorry if I missed it an earlier list. lcov is not dead. What's wrong with it? From tcallawa at redhat.com Thu Oct 12 04:30:57 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 11 Oct 2006 23:30:57 -0500 Subject: Yet another license question In-Reply-To: <1159899835.3005.4.camel@localhost.localdomain> References: <45218389.6050504@cora.nwra.com> <1159847060.3471.86.camel@localhost.localdomain> <1159899835.3005.4.camel@localhost.localdomain> Message-ID: <1160627457.2619.535.camel@localhost.localdomain> On Tue, 2006-10-03 at 13:23 -0500, Tom 'spot' Callaway wrote: > I'll ask the FSF, and we'll go from their recommendation. Aloha from Hawaii! I'm not really supposed to be reading email on my vacation, but I did note that the FSF replied to my request for licensing consideration. The FSF Licensing Guru isn't sure about this license, and has sent it to Eben and RMS for consideration. If/when we hear back from either/both of them, I'll certainly update this thread. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From ville.skytta at iki.fi Thu Oct 12 06:31:52 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 12 Oct 2006 09:31:52 +0300 Subject: Packages marked as dead In-Reply-To: <20061012010302.8035F180066@magilla.sf.frob.com> References: <20061012010302.8035F180066@magilla.sf.frob.com> Message-ID: <1160634712.5102.6.camel@viper.local> On Wed, 2006-10-11 at 18:03 -0700, Roland McGrath wrote: > > lcov > > Sorry if I missed it an earlier list. lcov is not dead. > What's wrong with it? It's marked as orphaned in owners.list in CVS and http://fedoraproject.org/wiki/Extras/OrphanedPackages and has not been in the devel repository since 19 Sep. From roland at redhat.com Thu Oct 12 07:32:54 2006 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Oct 2006 00:32:54 -0700 (PDT) Subject: Packages marked as dead In-Reply-To: Ville Skyttä's message of Thursday, 12 October 2006 09:31:52 +0300 <1160634712.5102.6.camel@viper.local> Message-ID: <20061012073254.E0FD3180066@magilla.sf.frob.com> > It's marked as orphaned in owners.list in CVS and > http://fedoraproject.org/wiki/Extras/OrphanedPackages and has not been > in the devel repository since 19 Sep. I never stopped being the maintainer for lcov. I was unavoidably out of touch for a few weeks including 19 Sep. I know of no reason why lcov should ever have been marked as no longer maintained by me, or removed. From paul at city-fan.org Thu Oct 12 08:08:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 12 Oct 2006 09:08:08 +0100 Subject: Packages marked as dead In-Reply-To: <20061012073254.E0FD3180066@magilla.sf.frob.com> References: <20061012073254.E0FD3180066@magilla.sf.frob.com> Message-ID: <1160640488.24880.6.camel@metropolis.intra.city-fan.org> On Thu, 2006-10-12 at 00:32 -0700, Roland McGrath wrote: > > It's marked as orphaned in owners.list in CVS and > > http://fedoraproject.org/wiki/Extras/OrphanedPackages and has not been > > in the devel repository since 19 Sep. > > I never stopped being the maintainer for lcov. I was unavoidably out of > touch for a few weeks including 19 Sep. I know of no reason why lcov > should ever have been marked as no longer maintained by me, or removed. Looks like you missed the entire mass rebuild process and appeared to be an AWOL maintainer: http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild Just un-orphan the package and take it back on again. Paul. From roland at redhat.com Thu Oct 12 08:16:04 2006 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Oct 2006 01:16:04 -0700 (PDT) Subject: Packages marked as dead In-Reply-To: Paul Howarth's message of Thursday, 12 October 2006 09:08:08 +0100 <1160640488.24880.6.camel@metropolis.intra.city-fan.org> Message-ID: <20061012081604.43238180066@magilla.sf.frob.com> > Looks like you missed the entire mass rebuild process and appeared to be > an AWOL maintainer: > > http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild > > Just un-orphan the package and take it back on again. It's a noarch package with nothing to be done. I guess I missed some step I was supposed to take to say that inaction was the only necessary action. From giallu at gmail.com Thu Oct 12 08:17:08 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 12 Oct 2006 10:17:08 +0200 Subject: reassigning multiple bugs in bugzilla In-Reply-To: <1160584995.5102.0.camel@viper.local> References: <1160584995.5102.0.camel@viper.local> Message-ID: On 10/11/06, Ville Skytt? wrote: > On Wed, 2006-10-11 at 00:23 +0200, Gianluca Sforna wrote: > > Once I got the ownership of mantis, I search for all its open issues > > on bugzilla, then I tried to reassign them to myself. > > The problem was I could select all of them, but trying to apply the > > modification (owner change) resulted in a error,something like: it > > does not seem you made any modification. > [...] > > Anyone ever tried this kind of operation? > > https://bugzilla.redhat.com/199872 you rock... From paul at city-fan.org Thu Oct 12 09:12:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 12 Oct 2006 10:12:50 +0100 Subject: Packages marked as dead In-Reply-To: <20061012081604.43238180066@magilla.sf.frob.com> References: <20061012081604.43238180066@magilla.sf.frob.com> Message-ID: <452E0712.7010303@city-fan.org> Roland McGrath wrote: >> Looks like you missed the entire mass rebuild process and appeared to be >> an AWOL maintainer: >> >> http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild >> >> Just un-orphan the package and take it back on again. > > It's a noarch package with nothing to be done. I guess I missed some step > I was supposed to take to say that inaction was the only necessary action. Just being a noarch package doesn't mean that there was no reason to rebuild it. One of the goals of the rebuild was to ensure that packages still built in mock with the new reduced buildroots, and that applies to noarch packages too. Paul. From frank-buettner at gmx.net Thu Oct 12 11:59:21 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 13:59:21 +0200 Subject: Last warning don't modify my packages!!! Message-ID: <452E2E19.8000600@gmx.net> Today somebody again has modify one of my maintained packages, without talk about to me. This is the last warning. When some body do it again, I will stop all my activity's for FC extra. When someone find an Bug then open an Bugreport!!! And don't modify my packages!!! From mtasaka at ioa.s.u-tokyo.ac.jp Thu Oct 12 12:13:39 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 12 Oct 2006 21:13:39 +0900 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E2E19.8000600@gmx.net> References: <452E2E19.8000600@gmx.net> Message-ID: <452E3173.3070801@ioa.s.u-tokyo.ac.jp> Frank B?ttner wrote: > Today somebody again has modify one of my maintained packages, without > talk about to me. This is the last warning. When some body do it again, > I will stop all my activity's for FC extra. When someone find an Bug > then open an Bugreport!!! And don't modify my packages!!! > I assume that you are refering to https://www.redhat.com/archives/fedora-extras-commits/2006-October/msg01273.html It seems that Rex Dieter surely opened a bug report and asked you to fix it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207180 about one month ago, and he continued to contact you. However you don't seem to have reacted against this bug report according to bugzilla report. Mamoru Tasaka From denis at poolshark.org Thu Oct 12 12:17:24 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 12 Oct 2006 14:17:24 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E2E19.8000600@gmx.net> References: <452E2E19.8000600@gmx.net> Message-ID: <452E3254.1070207@poolshark.org> Frank B?ttner wrote: > Today somebody again has modify one of my maintained packages, without > talk about to me. This is the last warning. When some body do it again, > I will stop all my activity's for FC extra. When someone find an Bug > then open an Bugreport!!! And don't modify my packages!!! This was brought up before, I personally find this type of extreme sense of ownership disturbing. Package ownership should not translate to absolute exclusive rights. I personally have no problems with people fixing my own bugs :-) as long as they have a good reason for it and make minimal attempt at contacting me. Looks like this was the case here. From fedora at leemhuis.info Thu Oct 12 12:34:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Oct 2006 14:34:19 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E2E19.8000600@gmx.net> References: <452E2E19.8000600@gmx.net> Message-ID: <452E364B.1040408@leemhuis.info> Frank B?ttner schrieb: > Today somebody again has modify one of my maintained packages, without > talk about to me. This is the last warning. When some body do it again, > I will stop all my activity's for FC extra. When someone find an Bug > then open an Bugreport!!! And don't modify my packages!!! We IIRC don't yet have any specific written rules that handle this kind of stuff (anyone interested in working out some rules? FESCo always needs help!). The general practice is that only the maintainer changes his packages normally. I don't like that to much. I think we should give other maintainers who know their job well (read=sponsors,co-maintainers and well know/long term contributors) a bit more freedom to fix small or medium size things in other peoples packages without to much overhead (read=bugzilla). *Especially* if the maintainer doesn't react in time. Sure, errors will happen and there will be some fights over details now and then, but I think the general quality of Extras will improve if we work in a *slightly* more wiki-style approach. CU thl From frank-buettner at gmx.net Thu Oct 12 13:07:35 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 15:07:35 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E3254.1070207@poolshark.org> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> Message-ID: <452E3E17.50004@gmx.net> Denis Leroy schrieb: > Frank B?ttner wrote: >> Today somebody again has modify one of my maintained packages, without >> talk about to me. This is the last warning. When some body do it again, >> I will stop all my activity's for FC extra. When someone find an Bug >> then open an Bugreport!!! And don't modify my packages!!! > > This was brought up before, I personally find this type of extreme sense > of ownership disturbing. Package ownership should not translate to > absolute exclusive rights. I personally have no problems with people > fixing my own bugs :-) as long as they have a good reason for it and > make minimal attempt at contacting me. Looks like this was the case here. > I don't have get any Bug report!! So this was not the case!! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From denis at poolshark.org Thu Oct 12 13:11:51 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 12 Oct 2006 15:11:51 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E3E17.50004@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> Message-ID: <452E3F17.7020208@poolshark.org> Frank B?ttner wrote: > I don't have get any Bug report!! So this was not the case!! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207180 However the bug was assigned to Rex. Did Rex assigned the bug to himself by mistake ? From mtasaka at ioa.s.u-tokyo.ac.jp Thu Oct 12 13:16:01 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 12 Oct 2006 22:16:01 +0900 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E3F17.7020208@poolshark.org> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E3F17.7020208@poolshark.org> Message-ID: <452E4011.802@ioa.s.u-tokyo.ac.jp> Denis Leroy wrote: > Frank B?ttner wrote: >> I don't have get any Bug report!! So this was not the case!! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207180 > > However the bug was assigned to Rex. Did Rex assigned the bug to himself > by mistake ? > As you can see the "Show Bug Activity" of this bug, this bug was surely assigned to Frank at first. But finally Rex assigned this bug to himself to show that he (Rex) fixed this bug report and added CC to Frank. Mamoru From aportal at univ-montp2.fr Thu Oct 12 13:31:42 2006 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 12 Oct 2006 15:31:42 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E3F17.7020208@poolshark.org> References: <452E2E19.8000600@gmx.net> <452E3E17.50004@gmx.net> <452E3F17.7020208@poolshark.org> Message-ID: <200610121531.42191.aportal@univ-montp2.fr> Le jeudi 12 octobre 2006 15:11, Denis Leroy a ?crit?: > Frank B?ttner wrote: > > I don't have get any Bug report!! So this was not the case!! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207180 > > However the bug was assigned to Rex. Did Rex assigned the bug to himself > by mistake ? Rex assigned him the bug when he closed it. -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From triad at df.lth.se Thu Oct 12 13:57:16 2006 From: triad at df.lth.se (Linus Walleij) Date: Thu, 12 Oct 2006 15:57:16 +0200 (CEST) Subject: Advice on rpath In-Reply-To: <20061011212110.GB23049@free.fr> References: <20061011212110.GB23049@free.fr> Message-ID: On Wed, 11 Oct 2006, Patrice Dumas wrote: > It seems to be allready packaged (chrpath-0.13-1.1.fc6). OK then problem solved; when %configure --disable-rpath doesn't do it, add BR chrpath and kick it out with brute force chrpath --delete foo on the culprit. Linus From j.w.r.degoede at hhs.nl Thu Oct 12 14:04:00 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 12 Oct 2006 16:04:00 +0200 Subject: Advice on rpath In-Reply-To: References: <20061011212110.GB23049@free.fr> Message-ID: <452E4B50.5010507@hhs.nl> Linus Walleij wrote: > On Wed, 11 Oct 2006, Patrice Dumas wrote: > >> It seems to be allready packaged (chrpath-0.13-1.1.fc6). > > OK then problem solved; when %configure --disable-rpath doesn't do it, > add BR chrpath and kick it out with brute force chrpath --delete foo on > the culprit. > Why, all that is need is adding the following 2 lines to the spec after %configure, leading to: %configure # Don't use rpath! sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool Now that may not be pretty but IMHO it sure beats doing binary editing after building the binary. Regards, Hans From paul at xelerance.com Thu Oct 12 14:40:36 2006 From: paul at xelerance.com (Paul Wouters) Date: Thu, 12 Oct 2006 16:40:36 +0200 (CEST) Subject: rng-tools / rng-utils / core functionality vs extras ? In-Reply-To: <20061012010124.GC14039@redhat.com> References: <20061012010124.GC14039@redhat.com> Message-ID: On Wed, 11 Oct 2006, Dave Jones wrote: > On Wed, Oct 11, 2006 at 04:44:19PM +0200, Paul Wouters wrote: > > > > The question now is, do I submit the initscripts extension as bug to rng-utils, > > or do I submit an rng-tools package that "obsoletes" rng-utils? > > The former. Renaming for no good reason is pointless, and just causes confusion. Well, argubly the correct name is rng-tools, since that's what the upstreams is called. That's why I hadn't noticed the package to begin with. I'll file a bug report against rng-utils and attach the rng init script, since rng-utils is in Core, where I think it should be. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From rdieter at math.unl.edu Thu Oct 12 14:57:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Oct 2006 09:57:23 -0500 Subject: Last warning don't modify my packages!!! References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> Message-ID: Frank B?ttner wrote: > Denis Leroy schrieb: >> Frank B?ttner wrote: >>> Today somebody again has modify one of my maintained packages, without >>> talk about to me. This is the last warning. When some body do it again, >>> I will stop all my activity's for FC extra. When someone find an Bug >>> then open an Bugreport!!! And don't modify my packages!!! >> >> This was brought up before, I personally find this type of extreme sense >> of ownership disturbing. Package ownership should not translate to >> absolute exclusive rights. I personally have no problems with people >> fixing my own bugs :-) as long as they have a good reason for it and >> make minimal attempt at contacting me. Looks like this was the case here. >> > I don't have get any Bug report!! So this was not the case!! http://bugzilla.redhat.com/207180 Submitted Sep 19, with no response from you. I'm glad to finally hear from you though. (: -- Rex From frank-buettner at gmx.net Thu Oct 12 16:40:53 2006 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Thu, 12 Oct 2006 18:40:53 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> Message-ID: <452E7015.5000209@gmx.net> Rex Dieter schrieb: > Frank B?ttner wrote: > >> Denis Leroy schrieb: >>> Frank B?ttner wrote: >>>> Today somebody again has modify one of my maintained packages, without >>>> talk about to me. This is the last warning. When some body do it again, >>>> I will stop all my activity's for FC extra. When someone find an Bug >>>> then open an Bugreport!!! And don't modify my packages!!! >>> This was brought up before, I personally find this type of extreme sense >>> of ownership disturbing. Package ownership should not translate to >>> absolute exclusive rights. I personally have no problems with people >>> fixing my own bugs :-) as long as they have a good reason for it and >>> make minimal attempt at contacting me. Looks like this was the case here. >>> >> I don't have get any Bug report!! So this was not the case!! > > http://bugzilla.redhat.com/207180 > Submitted Sep 19, with no response from you. > > I'm glad to finally hear from you though. (: > > -- Rex > I don't get any mail!! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From denis at poolshark.org Thu Oct 12 16:42:50 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 12 Oct 2006 18:42:50 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E7015.5000209@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E7015.5000209@gmx.net> Message-ID: <452E708A.4000402@poolshark.org> Frank B?ttner wrote: > Rex Dieter schrieb: >> Frank B?ttner wrote: >> >>> Denis Leroy schrieb: >>>> Frank B?ttner wrote: >>>>> Today somebody again has modify one of my maintained packages, without >>>>> talk about to me. This is the last warning. When some body do it again, >>>>> I will stop all my activity's for FC extra. When someone find an Bug >>>>> then open an Bugreport!!! And don't modify my packages!!! >>>> This was brought up before, I personally find this type of extreme sense >>>> of ownership disturbing. Package ownership should not translate to >>>> absolute exclusive rights. I personally have no problems with people >>>> fixing my own bugs :-) as long as they have a good reason for it and >>>> make minimal attempt at contacting me. Looks like this was the case here. >>>> >>> I don't have get any Bug report!! So this was not the case!! >> http://bugzilla.redhat.com/207180 >> Submitted Sep 19, with no response from you. >> >> I'm glad to finally hear from you though. (: >> >> -- Rex >> > I don't get any mail!! If you could log onto bugzilla.redhat.com and verify your account information there, and make sure the email matches that in owners.list, that would be appreciated. From bugs.michael at gmx.net Thu Oct 12 17:10:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 Oct 2006 19:10:16 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E7015.5000209@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E7015.5000209@gmx.net> Message-ID: <20061012191016.80dc14a0.bugs.michael@gmx.net> On Thu, 12 Oct 2006 18:40:53 +0200, Frank B?ttner wrote: > >> I don't have get any Bug report!! So this was not the case!! > > > > http://bugzilla.redhat.com/207180 > > Submitted Sep 19, with no response from you. > > > > I'm glad to finally hear from you though. (: > > > > -- Rex > > > I don't get any mail!! Have you ever before received mail from bugzilla.redhat.com? If the answer is "no", examine your anti-spam settings and try with a different e-mail address. From david at lovesunix.net Thu Oct 12 17:19:16 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 12 Oct 2006 19:19:16 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E7015.5000209@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E7015.5000209@gmx.net> Message-ID: <1160673556.3597.48.camel@localhost.localdomain> tor, 12 10 2006 kl. 18:40 +0200, skrev Frank B?ttner: > Rex Dieter schrieb: > > Frank B?ttner wrote: > > > >> Denis Leroy schrieb: > >>> Frank B?ttner wrote: > >>>> Today somebody again has modify one of my maintained packages, without > >>>> talk about to me. This is the last warning. When some body do it again, > >>>> I will stop all my activity's for FC extra. When someone find an Bug > >>>> then open an Bugreport!!! And don't modify my packages!!! > >>> This was brought up before, I personally find this type of extreme sense > >>> of ownership disturbing. Package ownership should not translate to > >>> absolute exclusive rights. I personally have no problems with people > >>> fixing my own bugs :-) as long as they have a good reason for it and > >>> make minimal attempt at contacting me. Looks like this was the case here. > >>> > >> I don't have get any Bug report!! So this was not the case!! > > > > http://bugzilla.redhat.com/207180 > > Submitted Sep 19, with no response from you. > > > > I'm glad to finally hear from you though. (: > > > > -- Rex > > > I don't get any mail!! To be perfectly honest, that's hardly Rex' problem is it? - David Nielsen From buildsys at fedoraproject.org Thu Oct 12 17:20:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 Oct 2006 13:20:40 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-12 Message-ID: <20061012172040.9E33015212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 18 abiword-2.4.5-4.fc6 blender-2.42a-3.fc6 crossvc-1.5.0-4.fc6 ejabberd-1.1.2-2.fc6 facter-1.3.5-1.fc6 fcron-3.0.1-17.fc6 gnome-theme-clearlooks-bigpack-0.6-2.fc6 lcov-1.4-2.fc6 libgalago-0.5.2-3.fc6 mediawiki-1.8.1-3.fc6 monotone-0.30-1.fc6 netmask-2.3.8-1.fc6 optipng-0.5.4-3.fc6 perl-PAR-Dist-0.20-1.fc6 qgo-1.5.2-1.fc6 tclabc-1.0.8-1.fc6 telepathy-gabble-0.3.11-1.fc6 util-vserver-0.30.211-1.fc6 Packages built and released for Fedora Extras 5: 12 blender-2.42a-3.fc5 crossvc-1.5.0-4.fc5 ejabberd-1.1.2-2.fc5 facter-1.3.5-1.fc5 fcron-3.0.1-16.fc5 libgalago-0.5.2-3.fc5 libgalago-gtk-0.5.0-3.fc5 monotone-0.30-1.fc5 perl-PAR-Dist-0.20-1.fc5 qt4-4.2.0-1.fc5 sylpheed-claws-2.5.5-1.fc5 tclabc-1.0.8-1.fc5 Packages built and released for Fedora Extras 4: 5 ejabberd-1.1.2-2.fc4 facter-1.3.5-1.fc4 fcron-3.0.1-16.fc4 qt4-4.1.4-11.fc4.2 sylpheed-claws-2.5.5-1.fc4 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 Oct 12 17:21:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 Oct 2006 13:21:09 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-12 Message-ID: <20061012172109.47BC215212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) tclx FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) andreas.bierfert AT lowlatency.de: sylpheed-claws FE4 > FE6 (0:2.5.5-1.fc4 > 0:2.5.3-1.fc6) FE5 > FE6 (0:2.5.5-1.fc5 > 0:2.5.3-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-41.fc5 > 0:2.3-40.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) sylpheed-claws: andreas.bierfert AT lowlatency.de FE4 > FE6 (0:2.5.5-1.fc4 > 0:2.5.3-1.fc6) FE5 > FE6 (0:2.5.5-1.fc5 > 0:2.5.3-1.fc6) tclx: UNKNOWN OWNER (possibly Core package) FC5 > FC6 (0:8.4.0-1.2 > 0:8.4-4) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) From frank-buettner at gmx.net Thu Oct 12 17:38:10 2006 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 19:38:10 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <20061012191016.80dc14a0.bugs.michael@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E7015.5000209@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> Message-ID: <452E7D82.5090806@gmx.net> Michael Schwendt schrieb: > On Thu, 12 Oct 2006 18:40:53 +0200, Frank B?ttner wrote: > >>>> I don't have get any Bug report!! So this was not the case!! >>> http://bugzilla.redhat.com/207180 >>> Submitted Sep 19, with no response from you. >>> >>> I'm glad to finally hear from you though. (: >>> >>> -- Rex >>> >> I don't get any mail!! > > Have you ever before received mail from bugzilla.redhat.com? > > If the answer is "no", examine your anti-spam settings and > try with a different e-mail address. > > Yes I get many messages form bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From dennis at ausil.us Thu Oct 12 17:44:10 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Oct 2006 12:44:10 -0500 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E7D82.5090806@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> Message-ID: <200610121244.11726.dennis@ausil.us> On Thursday 12 October 2006 12:38, Frank B?ttner wrote: > Michael Schwendt schrieb: > > On Thu, 12 Oct 2006 18:40:53 +0200, Frank B?ttner wrote: > >>>> I don't have get any Bug report!! So this was not the case!! > >>> > >>> http://bugzilla.redhat.com/207180 > >>> Submitted Sep 19, with no response from you. > >>> > >>> I'm glad to finally hear from you though. (: > >>> > >>> -- Rex > >> > >> I don't get any mail!! > > > > Have you ever before received mail from bugzilla.redhat.com? > > > > If the answer is "no", examine your anti-spam settings and > > try with a different e-mail address. > > Yes I get many messages form bugzilla. and you get them to what email address? Dennis From mtasaka at ioa.s.u-tokyo.ac.jp Thu Oct 12 17:57:49 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 13 Oct 2006 02:57:49 +0900 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E7D82.5090806@gmx.net> References: <452E2E19.8000600@gmx.net> <452E3254.1070207@poolshark.org> <452E3E17.50004@gmx.net> <452E7015.5000209@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> Message-ID: <452E821D.9080008@ioa.s.u-tokyo.ac.jp> Frank B?ttner wrote: >>> I don't get any mail!! >> Have you ever before received mail from bugzilla.redhat.com? >> >> If the answer is "no", examine your anti-spam settings and >> try with a different e-mail address. >> >> > Yes I get many messages form bugzilla. > I suspect that you came to reject mails from bugzilla by some reason from a time. I can see in bugzilla that you have not reacted to some new bugzilla reports which you should. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199860 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208550 Perhaps your e-mail setting (like anti-spam setting) or so changed. Mamoru From buildsys at fedoraproject.org Thu Oct 12 18:01:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 12 Oct 2006 18:01:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-12 Message-ID: <20061012180126.6345.16873@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (12 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (12 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (12 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (27 days) plague - 0.4.4.1-2.fc3.noarch (27 days) plague - 0.4.4.1-2.fc4.noarch (27 days) plague - 0.4.4.1-2.fc4.noarch (27 days) plague - 0.4.4.1-2.fc4.noarch (27 days) frank-buettner AT gmx.net qt4-qsa - 1.2.1-13.fc5.i386 qt4-qsa - 1.2.1-13.fc5.ppc qt4-qsa - 1.2.1-13.fc5.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (3 days) linphone - 1.2.0-4.fc5.ppc (3 days) linphone - 1.2.0-4.fc5.x86_64 (3 days) linphone - 1.2.0-7.fc6.i386 (3 days) linphone - 1.2.0-7.fc6.ppc (3 days) linphone - 1.2.0-7.fc6.x86_64 (3 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6smp linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-sysprof-PAE-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 qt4-qsa-1.2.1-13.fc5.ppc requires qt4 < 0:4.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) qt4-qsa-1.2.1-13.fc5.x86_64 requires qt4 < 0:4.2 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 qt4-qsa-1.2.1-13.fc5.i386 requires qt4 < 0:4.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: frank-buettner AT gmx.net package: qt4-qsa - 1.2.1-13.fc5.ppc from fedora-extras-5-ppc unresolved deps: qt4 < 0:4.2 package: qt4-qsa - 1.2.1-13.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: qt4 < 0:4.2 package: qt4-qsa - 1.2.1-13.fc5.i386 from fedora-extras-5-i386 unresolved deps: qt4 < 0:4.2 From frank-buettner at gmx.net Thu Oct 12 18:04:52 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 20:04:52 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <200610121244.11726.dennis@ausil.us> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> Message-ID: <452E83C4.1090401@gmx.net> Dennis Gilmore schrieb: > On Thursday 12 October 2006 12:38, Frank B?ttner wrote: >> Michael Schwendt schrieb: >>> On Thu, 12 Oct 2006 18:40:53 +0200, Frank B?ttner wrote: >>>>>> I don't have get any Bug report!! So this was not the case!! >>>>> http://bugzilla.redhat.com/207180 >>>>> Submitted Sep 19, with no response from you. >>>>> >>>>> I'm glad to finally hear from you though. (: >>>>> >>>>> -- Rex >>>> I don't get any mail!! >>> Have you ever before received mail from bugzilla.redhat.com? >>> >>> If the answer is "no", examine your anti-spam settings and >>> try with a different e-mail address. >> Yes I get many messages form bugzilla. > and you get them to what email address? > > Dennis > > The address is ok. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From peter at thecodergeek.com Thu Oct 12 19:09:46 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 12 Oct 2006 12:09:46 -0700 (PDT) Subject: Last warning don't modify my packages!!! In-Reply-To: <452E83C4.1090401@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> Message-ID: <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> Frank B?ttner wrote: >>> Yes I get many messages form bugzilla. >> and you get them to what email address? > The address is ok. The adress may be ok, but are your bugzilla email preferences set to email you about new bugs assigned to you by default? You can view and edit those settings here: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email Hope that helps. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From frank-buettner at gmx.net Thu Oct 12 19:36:18 2006 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 21:36:18 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> Message-ID: <452E9932.70401@gmx.net> Peter Gordon schrieb: > Frank B?ttner wrote: >>>> Yes I get many messages form bugzilla. >>> and you get them to what email address? >> The address is ok. > > The adress may be ok, but are your bugzilla email preferences set to email > you about new bugs assigned to you by default? You can view and edit those > settings here: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email > > Hope that helps. For the other Bugs I get mails. But that is not the topic. The topic is that every body modify packages of other. And that is an very big problem. When that goes forward then it will impossible for maintainers to maintain it packages, because the packages will be every time out of sync:( -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From jima at beer.tclug.org Thu Oct 12 19:46:05 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 12 Oct 2006 14:46:05 -0500 (CDT) Subject: Last warning don't modify my packages!!! In-Reply-To: <452E9932.70401@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> Message-ID: On Thu, 12 Oct 2006, Frank B?ttner wrote: > For the other Bugs I get mails. But that is not the topic. > The topic is that every body modify packages of other. And that is an > very big problem. When that goes forward then it will impossible for > maintainers to maintain it packages, because the packages will be every > time out of sync:( If you don't want people touching your packages, then you need to see and respond to bugs filed against them. (Yes, I periodically check Bugzilla for bugs filed against me, regardless of the fact that email notification should bring them to my attention.) If there hadn't been a bug filed already, then I might be prone to agree with you. Alas, there was, and most people I've heard from agreed with Rex's actions. If you don't care for the cooperative nature of open source software, then I'm not sure what to tell you -- most of us are willing to play well with others. Jima From jwboyer at jdub.homelinux.org Thu Oct 12 19:51:51 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Oct 2006 14:51:51 -0500 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E9932.70401@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> Message-ID: <1160682711.28055.3.camel@zod.rchland.ibm.com> On Thu, 2006-10-12 at 21:36 +0200, Frank B?ttner wrote: > Peter Gordon schrieb: > > Frank B?ttner wrote: > >>>> Yes I get many messages form bugzilla. > >>> and you get them to what email address? > >> The address is ok. > > > > The adress may be ok, but are your bugzilla email preferences set to email > > you about new bugs assigned to you by default? You can view and edit those > > settings here: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email > > > > Hope that helps. > For the other Bugs I get mails. But that is not the topic. > The topic is that every body modify packages of other. And that is an > very big problem. When that goes forward then it will impossible for > maintainers to maintain it packages, because the packages will be every > time out of sync:( Sorry, but you're wrong. A bug report was opened, you failed to respond to it for whatever reason. Do you have a problem with the actual fix that was done? Or are you just griping because someone touched something you maintain? And actually, in this particular case you were lucky. Rex could have just waited a bit longer and then tried to exercise the Orphan policy. That would have really set you off. So in light of the obvious mail problems you're having with bugzilla, and the fact that the fix seems to be _correct_ in this case, I suggest everyone just calm down. No harm was done here, and something got fixed. josh From pertusus at free.fr Thu Oct 12 19:46:53 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Oct 2006 21:46:53 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E9932.70401@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> Message-ID: <20061012194235.GA2358@free.fr> On Thu, Oct 12, 2006 at 09:36:18PM +0200, Frank B?ttner wrote: > For the other Bugs I get mails. But that is not the topic. > The topic is that every body modify packages of other. And that is an > very big problem. When that goes forward then it will impossible for > maintainers to maintain it packages, because the packages will be every > time out of sync:( Currently it is the reverse that I think characterize fedora extras: maintainers avoid touching others packages, except to fix obvious bugs. -- Pat From a.badger at gmail.com Thu Oct 12 19:53:03 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Oct 2006 12:53:03 -0700 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E9932.70401@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> Message-ID: <1160682784.2615.11.camel@localhost> On Thu, 2006-10-12 at 21:36 +0200, Frank B?ttner wrote: > Peter Gordon schrieb: > > Frank B?ttner wrote: > >>>> Yes I get many messages form bugzilla. > >>> and you get them to what email address? > >> The address is ok. > > > > The adress may be ok, but are your bugzilla email preferences set to email > > you about new bugs assigned to you by default? You can view and edit those > > settings here: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email > > > > Hope that helps. > For the other Bugs I get mails. But that is not the topic. > The topic is that every body modify packages of other. And that is an > very big problem. When that goes forward then it will impossible for > maintainers to maintain it packages, because the packages will be every > time out of sync:( That is one problem but it is a small one compared to having end-users downloading broken packages. If others can't get a hold of you through bugzilla then this has to be fixed. A lot of things go through bugzilla including security bugs and the orphaned package process. If you aren't replying to bugzilla and something needs to be fixed, one of the sponsors or other trusted contributors may step up and fix the issue because the impression is the package isn't being maintained. So if you aren't getting bugzilla mails we need to find out why and get that fixed otherwise your packages will continue to be changed by other maintainers who think that you have abandoned your packages without informing anyone. -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 frank-buettner at gmx.net Thu Oct 12 19:57:18 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 21:57:18 +0200 Subject: Global list of used TCP/UDP ports Message-ID: <452E9E1E.90000@gmx.net> Now we have the problem that 2 services use the same port. To fix this and prevent other services to fall in this trap, we need to build an list in FC Extra with port's all in use. So here the first entry for the list: All other maintainer shut add his services to this list. ________________________________ Port Protocol Service 8000 TCP nas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From jwboyer at jdub.homelinux.org Thu Oct 12 20:03:16 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Oct 2006 15:03:16 -0500 Subject: Global list of used TCP/UDP ports In-Reply-To: <452E9E1E.90000@gmx.net> References: <452E9E1E.90000@gmx.net> Message-ID: <1160683396.28055.5.camel@zod.rchland.ibm.com> On Thu, 2006-10-12 at 21:57 +0200, Frank B?ttner wrote: > Now we have the problem that 2 services use the same port. > To fix this and prevent other services to fall in this trap, we need to > build an list in FC Extra with port's all in use. > So here the first entry for the list: > All other maintainer shut add his services to this list. > ________________________________ > Port Protocol Service > 8000 TCP nas This needs to go in a wiki page. Could you add one perhaps? josh From skvidal at linux.duke.edu Thu Oct 12 20:02:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Oct 2006 16:02:37 -0400 Subject: Global list of used TCP/UDP ports In-Reply-To: <452E9E1E.90000@gmx.net> References: <452E9E1E.90000@gmx.net> Message-ID: <1160683357.17593.50.camel@cutter> On Thu, 2006-10-12 at 21:57 +0200, Frank B?ttner wrote: > Now we have the problem that 2 services use the same port. > To fix this and prevent other services to fall in this trap, we need to > build an list in FC Extra with port's all in use. > So here the first entry for the list: > All other maintainer shut add his services to this list. > ________________________________ > Port Protocol Service > 8000 TCP nas I'm pretty sure the IANA trumps us when it comes to port assignment. -sv From garrick at usc.edu Thu Oct 12 20:00:44 2006 From: garrick at usc.edu (Garrick Staples) Date: Thu, 12 Oct 2006 13:00:44 -0700 Subject: Global list of used TCP/UDP ports In-Reply-To: <452E9E1E.90000@gmx.net> References: <452E9E1E.90000@gmx.net> Message-ID: <20061012200043.GU2077@polop.usc.edu> On Thu, Oct 12, 2006 at 09:57:18PM +0200, Frank B?ttner alleged: > Now we have the problem that 2 services use the same port. > To fix this and prevent other services to fall in this trap, we need to > build an list in FC Extra with port's all in use. > So here the first entry for the list: > All other maintainer shut add his services to this list. > ________________________________ > Port Protocol Service > 8000 TCP nas Looks like 8000 is already taken by irdmi!! http://www.iana.org/assignments/port-numbers -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Thu Oct 12 20:03:51 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 12 Oct 2006 15:03:51 -0500 (CDT) Subject: Global list of used TCP/UDP ports In-Reply-To: <452E9E1E.90000@gmx.net> References: <452E9E1E.90000@gmx.net> Message-ID: On Thu, 12 Oct 2006, Frank B?ttner wrote: > Now we have the problem that 2 services use the same port. > To fix this and prevent other services to fall in this trap, we need to > build an list in FC Extra with port's all in use. > So here the first entry for the list: > All other maintainer shut add his services to this list. There's already a mechanism in place that provides this functionality: /etc/services . I have no idea what the process is for getting services added to this file, though. (IANA, as suggested by Seth?) > ________________________________ > Port Protocol Service > 8000 TCP nas This seems like a really awful port choice; 8000 is one of the most commonly-used ports for web servers in cases where port 80 is blocked (by ISPs, typically). My opinion, at least... Jima From berrange at redhat.com Thu Oct 12 20:06:18 2006 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 12 Oct 2006 21:06:18 +0100 Subject: Global list of used TCP/UDP ports In-Reply-To: <20061012200043.GU2077@polop.usc.edu> References: <452E9E1E.90000@gmx.net> <20061012200043.GU2077@polop.usc.edu> Message-ID: <20061012200618.GE6878@redhat.com> On Thu, Oct 12, 2006 at 01:00:44PM -0700, Garrick Staples wrote: > On Thu, Oct 12, 2006 at 09:57:18PM +0200, Frank B?ttner alleged: > > Now we have the problem that 2 services use the same port. > > To fix this and prevent other services to fall in this trap, we need to > > build an list in FC Extra with port's all in use. > > So here the first entry for the list: > > All other maintainer shut add his services to this list. > > ________________________________ > > Port Protocol Service > > 8000 TCP nas > > Looks like 8000 is already taken by irdmi!! > http://www.iana.org/assignments/port-numbers Its also taken by Xen for its Dom0 management daemon. Any list of apps wanting port 8000 is going to be many pages long... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From bugs.michael at gmx.net Thu Oct 12 20:15:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 Oct 2006 22:15:16 +0200 Subject: Last warning don't modify my packages!!! In-Reply-To: References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> Message-ID: <20061012221516.d0110a28.bugs.michael@gmx.net> On Thu, 12 Oct 2006 14:46:05 -0500 (CDT), Jima wrote: > On Thu, 12 Oct 2006, Frank B?ttner wrote: > > For the other Bugs I get mails. But that is not the topic. > > The topic is that every body modify packages of other. And that is an > > very big problem. When that goes forward then it will impossible for > > maintainers to maintain it packages, because the packages will be every > > time out of sync:( > > If you don't want people touching your packages, then you need to see and > respond to bugs filed against them. (Yes, I periodically check Bugzilla > for bugs filed against me, regardless of the fact that email notification > should bring them to my attention.) If there hadn't been a bug filed > already, then I might be prone to agree with you. Alas, there was, and > most people I've heard from agreed with Rex's actions. If you don't care > for the cooperative nature of open source software, then I'm not sure what > to tell you -- most of us are willing to play well with others. However, reformatting of spec files and regrouping BRs is not nice: https://www.redhat.com/archives/fedora-extras-commits/2006-October/msg01273.html This has happened here and maybe has given a false impression, since this can result in more CVS conflicts than necessary. If there's something easy to fix and the packager seems unavailable (after several contact attempts), it is a demonstration of sense of responsibility if a fellow project member applies the fix. Still, that's no excuse for modifying more details than necessary. From jima at beer.tclug.org Thu Oct 12 20:12:31 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 12 Oct 2006 15:12:31 -0500 (CDT) Subject: Last warning don't modify my packages!!! In-Reply-To: <20061012221516.d0110a28.bugs.michael@gmx.net> References: <452E2E19.8000600@gmx.net> <20061012191016.80dc14a0.bugs.michael@gmx.net> <452E7D82.5090806@gmx.net> <200610121244.11726.dennis@ausil.us> <452E83C4.1090401@gmx.net> <3276.65.223.36.19.1160680186.squirrel@thecodergeek.com> <452E9932.70401@gmx.net> <20061012221516.d0110a28.bugs.michael@gmx.net> Message-ID: On Thu, 12 Oct 2006, Michael Schwendt wrote: > However, reformatting of spec files and regrouping BRs is not nice: ... > > If there's something easy to fix and the packager seems unavailable (after > several contact attempts), it is a demonstration of sense of > responsibility if a fellow project member applies the fix. > > Still, that's no excuse for modifying more details than necessary. That I can agree with. Jima From frank-buettner at gmx.net Thu Oct 12 20:17:44 2006 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Thu, 12 Oct 2006 22:17:44 +0200 Subject: Global list of used TCP/UDP ports In-Reply-To: <20061012200618.GE6878@redhat.com> References: <452E9E1E.90000@gmx.net> <20061012200043.GU2077@polop.usc.edu> <20061012200618.GE6878@redhat.com> Message-ID: <452EA2E8.60806@gmx.net> Daniel P. Berrange schrieb: > On Thu, Oct 12, 2006 at 01:00:44PM -0700, Garrick Staples wrote: >> On Thu, Oct 12, 2006 at 09:57:18PM +0200, Frank B?ttner alleged: >>> Now we have the problem that 2 services use the same port. >>> To fix this and prevent other services to fall in this trap, we need to >>> build an list in FC Extra with port's all in use. >>> So here the first entry for the list: >>> All other maintainer shut add his services to this list. >>> ________________________________ >>> Port Protocol Service >>> 8000 TCP nas >> Looks like 8000 is already taken by irdmi!! >> http://www.iana.org/assignments/port-numbers > > Its also taken by Xen for its Dom0 management daemon. Any list of apps wanting > port 8000 is going to be many pages long... > > Regards, > Dan. I think there will be much more services on this port. The idea at this time is first to collect all conflict packages and then try to assign new port to all conflict packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4285 bytes Desc: S/MIME Cryptographic Signature URL: From pertusus at free.fr Thu Oct 12 20:14:11 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Oct 2006 22:14:11 +0200 Subject: desktop files for dockapp apps? Message-ID: <20061012201411.GC2358@free.fr> Hello, Should there be a .desktop, an icon and so on for dockapp apps? When they are used in fluxbox, for example it doesn't make much sense to have one, since they have to be launched by editing .fluxbox/startup. Is it different on other desktops? (on xfce I don't see anything when I launch them...). -- Pat From rdieter at math.unl.edu Thu Oct 12 19:44:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Oct 2006 14:44:51 -0500 Subject: rpms/qt4-qsa/FC-5 qsa-1.2.1-Qt4.2-preview.patch, NONE, 1.1 qt4-qsa.spec, 1.3, 1.4 References: <200610121840.k9CIe34n001128@cvs-int.fedora.redhat.com> Message-ID: Frank B?ttner (frankb) wrote: > Author: frankb > > Update of /cvs/extras/rpms/qt4-qsa/FC-5 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv1106 > > Modified Files: > qt4-qsa.spec > Added Files: > qsa-1.2.1-Qt4.2-preview.patch > Log Message: > - fix build for EMT64 > - Try to bypass the broken paths in the Qt4 package. > Not nice, but no other way until the Qt4 package will be corrected. > - compile QSA with Qt 4.2 > > > qsa-1.2.1-Qt4.2-preview.patch: > > --- NEW FILE qsa-1.2.1-Qt4.2-preview.patch --- > --- qsa-x11-opensource-1.2.1/configure2/configutils.cpp.preview 2006-02-28 > 07:21:15.000000000 -0600 > +++ qsa-x11-opensource-1.2.1/configure2/configutils.cpp 2006-08-01 > 06:34:07.000000000 -0500 @@ -372,6 +372,8 @@ > qtLicense = Universal; > } else if (qtEdition == QLatin1String("OpenSource")) { > qtLicense = GPL; > + } else if (qtEdition == QLatin1String("Preview")) { > + qtLicense = GPL; > } else { > message(QLatin1String("\nQSA is not compatible with your Qt > edition\n")); return false; > > > Index: qt4-qsa.spec > =================================================================== > RCS file: /cvs/extras/rpms/qt4-qsa/FC-5/qt4-qsa.spec,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- qt4-qsa.spec 30 Jul 2006 00:56:35 -0000 1.3 > +++ qt4-qsa.spec 12 Oct 2006 18:40:01 -0000 1.4 > @@ -1,19 +1,28 @@ ... > %define qtdir %(qmake-qt4 -query QT_INSTALL_PREFIX) > -%define qtinc %(qmake-qt4 -query QT_INSTALL_HEADERS) > -%define qtlib %(qmake-qt4 -query QT_INSTALL_LIBS) > + > +# fix the the broken include path > +%define qtinc %{qtdir}/include > +%ifarch x86_64 > +%define qtlib %(qmake-qt4 -query QT_INSTALL_LIBS)/qt4/lib64 > +%else > +%define qtlib %(qmake-qt4 -query QT_INSTALL_LIBS)/qt4/lib > +%endif You're using directories that don't exist and/or won't ever get used here. qt4 now installs-to/uses %_libdir not %_libdir/qt4/%_lib I sent you a qsa-x11-opensource-1.2.1-QT_INSTALL.patch that addresses this awhile back. -- Rex From triad at df.lth.se Thu Oct 12 21:37:12 2006 From: triad at df.lth.se (Linus Walleij) Date: Thu, 12 Oct 2006 23:37:12 +0200 (CEST) Subject: Advice on rpath In-Reply-To: <452E4B50.5010507@hhs.nl> References: <20061011212110.GB23049@free.fr> <452E4B50.5010507@hhs.nl> Message-ID: On Thu, 12 Oct 2006, Hans de Goede wrote: > Why, all that is need is adding the following 2 lines to the spec after > %configure (...) You're right Hans, as always... Given all the stir rpath is causing, can we perhaps put a few words on it in the packaging guidelines, "no rpath, thanks, and here's why and how" type of text. spot, you own that doc, what do you say? Linus From nphilipp at redhat.com Thu Oct 12 21:57:20 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 12 Oct 2006 23:57:20 +0200 Subject: Package EVR problems in FC+FE 2006-10-12 In-Reply-To: <20061012172109.47BC215212E@buildsys.fedoraproject.org> References: <20061012172109.47BC215212E@buildsys.fedoraproject.org> Message-ID: <1160690240.2890.15.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-10-12 at 13:21 -0400, buildsys at fedoraproject.org wrote: > UNKNOWN OWNER (possibly Core package): [...] > xsane > FC5-updates > FC6 (0:0.991-2.fc5 > 0:0.991-1.fc6) this is already in Rawhide CVS, but not yet moved from dist-fc6-HEAD to dist-fc6. Would you please do this? It's a small tested-in-FC5-updates patch to work around %post script error messages. Thanks, 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 nicolas.mailhot at laposte.net Thu Oct 12 21:52:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Oct 2006 23:52:31 +0200 Subject: Global list of used TCP/UDP ports In-Reply-To: <1160683357.17593.50.camel@cutter> References: <452E9E1E.90000@gmx.net> <1160683357.17593.50.camel@cutter> Message-ID: <1160689951.26368.42.camel@rousalka.dyndns.org> Le jeudi 12 octobre 2006 ? 16:02 -0400, seth vidal a ?crit : > On Thu, 2006-10-12 at 21:57 +0200, Frank B?ttner wrote: > > Now we have the problem that 2 services use the same port. > > To fix this and prevent other services to fall in this trap, we need to > > build an list in FC Extra with port's all in use. > > So here the first entry for the list: > > All other maintainer shut add his services to this list. > > ________________________________ > > Port Protocol Service > > 8000 TCP nas > > > I'm pretty sure the IANA trumps us when it comes to port assignment. A lot of ports won't go through IANA, and we should document then in the Fedora /etc/services, if only so : 1. packages do no step on one another's port 2. we can filter them in iptables by name Once upon a time Fedora tried to keep /etc/services small (which forced everyone to use local incompatible assignments) but I think the new aim is to actually document the ports a Fedora user may use (which certainly includes ports used by FC or FE apps) -- Nicolas Mailhot From skvidal at linux.duke.edu Thu Oct 12 23:38:53 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Oct 2006 19:38:53 -0400 Subject: Global list of used TCP/UDP ports In-Reply-To: <1160689951.26368.42.camel@rousalka.dyndns.org> References: <452E9E1E.90000@gmx.net> <1160683357.17593.50.camel@cutter> <1160689951.26368.42.camel@rousalka.dyndns.org> Message-ID: <1160696333.21089.4.camel@cutter> On Thu, 2006-10-12 at 23:52 +0200, Nicolas Mailhot wrote: > Le jeudi 12 octobre 2006 ? 16:02 -0400, seth vidal a ?crit : > > On Thu, 2006-10-12 at 21:57 +0200, Frank B?ttner wrote: > > > Now we have the problem that 2 services use the same port. > > > To fix this and prevent other services to fall in this trap, we need to > > > build an list in FC Extra with port's all in use. > > > So here the first entry for the list: > > > All other maintainer shut add his services to this list. > > > ________________________________ > > > Port Protocol Service > > > 8000 TCP nas > > > > > > I'm pretty sure the IANA trumps us when it comes to port assignment. > > A lot of ports won't go through IANA, and we should document then in the > Fedora /etc/services, if only so : > 1. packages do no step on one another's port > 2. we can filter them in iptables by name > > Once upon a time Fedora tried to keep /etc/services small (which forced > everyone to use local incompatible assignments) but I think the new aim > is to actually document the ports a Fedora user may use (which certainly > includes ports used by FC or FE apps) OO OO - let's push for /etc/services.d/ :) -sv From notting at redhat.com Fri Oct 13 03:50:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Oct 2006 23:50:26 -0400 Subject: Global list of used TCP/UDP ports In-Reply-To: <1160696333.21089.4.camel@cutter> References: <452E9E1E.90000@gmx.net> <1160683357.17593.50.camel@cutter> <1160689951.26368.42.camel@rousalka.dyndns.org> <1160696333.21089.4.camel@cutter> Message-ID: <20061013035026.GB8646@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > OO OO - let's push for /etc/services.d/ Well, since services is handled by nsswitch... http://people.redhat.com/nalin/test/nss_directories-0.6-1.src.rpm HTH, Bill From skvidal at linux.duke.edu Fri Oct 13 03:57:13 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Oct 2006 23:57:13 -0400 Subject: Global list of used TCP/UDP ports In-Reply-To: <20061013035026.GB8646@nostromo.devel.redhat.com> References: <452E9E1E.90000@gmx.net> <1160683357.17593.50.camel@cutter> <1160689951.26368.42.camel@rousalka.dyndns.org> <1160696333.21089.4.camel@cutter> <20061013035026.GB8646@nostromo.devel.redhat.com> Message-ID: <1160711833.21089.6.camel@cutter> On Thu, 2006-10-12 at 23:50 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > OO OO - let's push for /etc/services.d/ > > Well, since services is handled by nsswitch... > > http://people.redhat.com/nalin/test/nss_directories-0.6-1.src.rpm > now, if I could have that for pam_access for /etc/security/access.conf.d/ I'd be all sorts of happy. -sv From wtogami at redhat.com Fri Oct 13 05:37:06 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 13 Oct 2006 14:37:06 +0900 Subject: Last warning don't modify my packages!!! In-Reply-To: <452E364B.1040408@leemhuis.info> References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> Message-ID: <452F2602.5080806@redhat.com> Thorsten Leemhuis wrote: > > Frank B?ttner schrieb: >> Today somebody again has modify one of my maintained packages, without >> talk about to me. This is the last warning. When some body do it again, >> I will stop all my activity's for FC extra. When someone find an Bug >> then open an Bugreport!!! And don't modify my packages!!! > > We IIRC don't yet have any specific written rules that handle this kind > of stuff (anyone interested in working out some rules? FESCo always > needs help!). > > The general practice is that only the maintainer changes his packages > normally. I don't like that to much. I think we should give other > maintainers who know their job well (read=sponsors,co-maintainers and > well know/long term contributors) a bit more freedom to fix small or > medium size things in other peoples packages without to much overhead > (read=bugzilla). *Especially* if the maintainer doesn't react in time. > > Sure, errors will happen and there will be some fights over details now > and then, but I think the general quality of Extras will improve if we > work in a *slightly* more wiki-style approach. > How often do people get upset about modifying each other's packages? It would be a BAD idea if we need ACL's to restricting people to only their own packages. Especially in a volunteer driven community, we need the flexibility and low-overhead of being mostly open. If we get a point where we need more restrictive ACL's by default, then that would be a sad situation. That would mean we don't trust each other as maintainers. In practice things go pretty well under the current system. Generally each maintainer is expected to respect ownership of others. In many cases owners give explicit or even blanket permission to others, "Sure, I trust you to do the right thing." In other cases, maintainers ask for permission before making specific changes. I see this particular case where there was no response to a bug report for a month as perfectly acceptable. The system is not broken, although it could be perhaps codified in a clearer way in the Wiki if it isn't already. Warren Togami wtogami at redhat.com From chris.stone at gmail.com Fri Oct 13 05:59:01 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 12 Oct 2006 22:59:01 -0700 Subject: Last warning don't modify my packages!!! In-Reply-To: <452F2602.5080806@redhat.com> References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> <452F2602.5080806@redhat.com> Message-ID: On 10/12/06, Warren Togami wrote: > How often do people get upset about modifying each other's packages? This is a very silly discussion. First Frank complains that someone modified his package before filing a bug report, then everyone points out a bug report was filed, then Frank persists on insisting there is some kind of problem. I am seriously tempted to just modify Frank's package so he will quit Fedora. Perhaps we will be better off. LOL! ;-) From sankarshan.mukhopadhyay at gmail.com Fri Oct 13 07:05:03 2006 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Fri, 13 Oct 2006 12:35:03 +0530 Subject: Desktop drapes: GNOME wallpaper manager Message-ID: <452F3A9F.8060803@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Desktop drapes is a wallpaper manager application for the gnome desktop. It has features (period) Features like, randomly changing your wallpaper every once in a while, or whenever you fell like it. It can also automaticaly pickup any wallpapers you added to a directory with the ninja magic of inotify. It's written using C# (mono) with the help of Gtk#/Gnome#. http://drapes.mindtouchsoftware.com/ Does this look like a good candidate for FE ? If yes, then will someone take a stab at packaging ? :Sankarshan - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFLzqfXQZpNTcrCzMRAsaeAKC3Wk7BbUssr7ZNxlbU8vpkGAoc8gCfd+bT ulanyDWSk48/i90AokyRdRw= =Rav1 -----END PGP SIGNATURE----- From triad at df.lth.se Fri Oct 13 08:14:37 2006 From: triad at df.lth.se (Linus Walleij) Date: Fri, 13 Oct 2006 10:14:37 +0200 (CEST) Subject: Last warning don't modify my packages!!! In-Reply-To: <452F2602.5080806@redhat.com> References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> <452F2602.5080806@redhat.com> Message-ID: On Fri, 13 Oct 2006, Warren Togami wrote: > How often do people get upset about modifying each other's packages? I always issue "cvs update" before I work on any package, expecting others to intervene if need be. I have no more need of control than in any other CVS repo, that's what it's for, and anyone associated with the Core or Extras is welcome to edit my packages if need be, so take this as an invitation. Just my Euro 0.01... Linus From sundaram at fedoraproject.org Fri Oct 13 11:08:06 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Oct 2006 16:38:06 +0530 Subject: Desktop drapes: GNOME wallpaper manager In-Reply-To: <452F3A9F.8060803@gmail.com> References: <452F3A9F.8060803@gmail.com> Message-ID: <452F7396.7080203@fedoraproject.org> Sankarshan Mukhopadhyay wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Desktop drapes is a wallpaper manager application for the gnome desktop. > It has features (period) Features like, randomly changing your wallpaper > every once in a while, or whenever you fell like it. It can also > automaticaly pickup any wallpapers you added to a directory with the > ninja magic of inotify. It's written using C# (mono) with the help of > Gtk#/Gnome#. > > http://drapes.mindtouchsoftware.com/ > > Does this look like a good candidate for FE ? If yes, then will someone > take a stab at packaging ? There is a similar package at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210467 Rahul From denis at poolshark.org Fri Oct 13 11:43:48 2006 From: denis at poolshark.org (Denis Leroy) Date: Fri, 13 Oct 2006 13:43:48 +0200 Subject: Desktop drapes: GNOME wallpaper manager In-Reply-To: <452F7396.7080203@fedoraproject.org> References: <452F3A9F.8060803@gmail.com> <452F7396.7080203@fedoraproject.org> Message-ID: <452F7BF4.9000804@poolshark.org> Rahul Sundaram wrote: > Sankarshan Mukhopadhyay wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Desktop drapes is a wallpaper manager application for the gnome desktop. >> It has features (period) Features like, randomly changing your wallpaper >> every once in a while, or whenever you fell like it. It can also >> automaticaly pickup any wallpapers you added to a directory with the >> ninja magic of inotify. It's written using C# (mono) with the help of >> Gtk#/Gnome#. >> >> http://drapes.mindtouchsoftware.com/ >> >> Does this look like a good candidate for FE ? If yes, then will someone >> take a stab at packaging ? > > There is a similar package at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210467 There is also wp_tray, already in Extras. But the more the merrier. From fedora at theholbrooks.org Fri Oct 13 15:03:52 2006 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Fri, 13 Oct 2006 10:03:52 -0500 Subject: Last warning don't modify my packages!!! In-Reply-To: References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> <452F2602.5080806@redhat.com> Message-ID: <452FAAD8.6060802@theholbrooks.org> Christopher Stone wrote: > On 10/12/06, Warren Togami wrote: > > I am seriously tempted to just modify Frank's package so he will quit > Fedora. Perhaps we will be better off. LOL! ;-) I'm sure there are plenty of others (including myself) who had the same thought. Thorsten's written a few times lately about his ideal of getting rid of this kind of attitude from package maintainers and I completely agree. As a relatively new member, I can attest that this foreboding 'others-need-not-apply' attitude discourages involvement and more importantly the spirit of a community. I'd much rather see maintainers take the attitude that many have expressed in this thread: "if you need to change something of mine, feel free" Granted, package maintainers (usually) went to all the work of getting their package up-to-snuff for approval and continually monitor upstream's mailing lists and announcements to stay current, and the feeling of ownership and pride is what keeps most of us interested in software in the first place. But keep in mind, this is all Open Source Software, and more than that this is Fedora, whose sole existence is based around _community_ involvement, not individuals who happen to be in the same CVS repository. From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Oct 12 21:21:12 2006 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 12 Oct 2006 22:21:12 +0100 Subject: FC5 tripwire RPM & possible maintainer available. Message-ID: On Tue, Aug 01, 2006 at 11:50:49AM +0100, Kyrian wrote: > The FC5 tripwire RPM seems to be in an 'orphaned' or unknown state > at the moment, as I'm sure you're all aware. Hello Kev. I was the previous maintainer, but gave up for various reasons; including time constraints, and the fact that Tripwire is a bit archaic and out of sync with modern Linux security methods. > Anyways, I've built an FC5 tripwire RPM, although at this stage only > using the backward-compatible gcc 3.2.x RPMS supplied with FC5 to > build it, and requiring the backward compatible accompanying > libraries, which I can contribute back somehow to FC5 extras or > whatever if anyone wants. > > I'm aware that in the longer term it needs some GCC4 patches > applying to the source tree to make it compile and run under native > GCC4, which I can probably do (never done exactly that before > though), and probably needs a version update too if "Tripwire > Software" have provided one under the GPL or other appropriate > license. There has been a new upstream build (2.4.0.1) available since December last year: http://prdownloads.sourceforge.net/tripwire/tripwire-2.4.0.1-src.tar.bz2?download And a patch to enable building against gcc4: http://sourceforge.net/tracker/index.php?func=detail&aid=1450721&group_id=3130&atid=103130 I've also rebuilt the RPMs here: http://slated.org/files/tripwire-2.4.0.1-1.src.rpm http://slated.org/files/tripwire-2.4.0.1-1.i386.rpm http://slated.org/files/tripwire-2.4.0.1-1.x86_64.rpm http://slated.org/files/tripwire-2.4.0.1-1.spec http://slated.org/files/tripwire-2.4.0.1-1.sha1 http://slated.org/files/RPM-GPG-KEY.slated Note, this is *not* a package submission, and I am *not* looking to resume maintainer-ship: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 75ac05e3da040ee21246957069bdb2969d43d608 RPM-GPG-KEY.slated 8c37e5e15818d29b04427ba2916b4176cfda118a tripwire-2.4.0.1-1.i386.rpm f03e6b3277ccb21f73b722b921480168cec0f0db tripwire-2.4.0.1-1.src.rpm d7542728edad4d464688e9cb121b9bc9daf66232 tripwire-2.4.0.1-1.x86_64.rpm 863b3394465977dd38fb61c51997fbe075fd7211 tripwire.spec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLqlgCuO//5UhIKMRAnmhAJ4oWT8XSMwTvel9GMPw5HXBahHH9wCfYJD1 JV+gRqG16wcA650aNEQtgdU= =L3qN -----END PGP SIGNATURE----- > I use tripwire among other stuff regularly on a number of servers, > so it's in my best interests that it remains maintained, and since I > already do a fair bit of opensource stuff variously detailed here: > > http://www.orenet.co.uk/opensource/ > > I guess i'm fairly well placed to become its maintainer, if there's > a vacancy, etc. To be honest, it's a big debatable how useful Tripwire is on a modern Linux system (SELinux et al), especially since it doesn't tie in with RPM, and you can probably achieve the same result with just "rpm -Vva" ... but good luck anyway. -- K. http://slated.org - Slated, Rated & Blogged .---- | Gates' Law: Every 18 months, the speed of software halves. `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.16-1.2133_FC5 22:18:32 up 116 days, 22:35, 3 users, load average: 0.35, 0.92, 0.83 From kevin-fedora-extras at scrye.com Fri Oct 13 18:44:05 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 13 Oct 2006 12:44:05 -0600 (MDT) Subject: Last warning don't modify my packages!!! References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> <452F2602.5080806@redhat.com> <452FAAD8.6060802@theholbrooks.org> Message-ID: <20061013.124405.892655151.kevin@scrye.com> >>>>> "Brandon" == Brandon Holbrook writes: Brandon> Christopher Stone wrote: >> On 10/12/06, Warren Togami wrote: >> >> I am seriously tempted to just modify Frank's package so he will >> quit Fedora. Perhaps we will be better off. LOL! ;-) Brandon> I'm sure there are plenty of others (including myself) who Brandon> had the same thought. Thorsten's written a few times lately Brandon> about his ideal of getting rid of this kind of attitude from Brandon> package maintainers and I completely agree. As a relatively Brandon> new member, I can attest that this foreboding Brandon> 'others-need-not-apply' attitude discourages involvement and Brandon> more importantly the spirit of a community. I'd much rather Brandon> see maintainers take the attitude that many have expressed in Brandon> this thread: "if you need to change something of mine, feel Brandon> free" Brandon> Granted, package maintainers (usually) went to all the work Brandon> of getting their package up-to-snuff for approval and Brandon> continually monitor upstream's mailing lists and Brandon> announcements to stay current, and the feeling of ownership Brandon> and pride is what keeps most of us interested in software in Brandon> the first place. But keep in mind, this is all Open Source Brandon> Software, and more than that this is Fedora, whose sole Brandon> existence is based around _community_ involvement, not Brandon> individuals who happen to be in the same CVS repository. Not to drag this thread out too much longer, but I would like to toss my 2c in as well... I think the change that sparked this thread was good and proper. The maintainer didn't answer a bugzilla query and there were issues that needed to be addressed. Thats fine. I would ask however that people do try and contact the maintainer of a package before just diving in and changing things. There could well be good reasons you are not aware of for the change that you are about to do not being a good idea, ie: - You decide you want to upgrade to the latest version of a package, but the maintainer who follows the upstream list knows this version has serious problems and is waiting for a fixed version. - Your change might break another package that the maintainer knows depends on his package, but you don't realize that. - The change you want to make is minor, and the maintainer is just waiting for some other change to push out a new version. etc... So please email/irc/file bugzilla bug before making changes in others packages. For the record I have no problems with people applying changes to my packages as long as they do so in a sane manner and give me a heads up. ;) Just IMHO. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Oct 14 09:55:17 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Oct 2006 05:55:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-14 Message-ID: <20061014095517.19B5E15212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 31 bygfoot-2.0.1-1.fc6 clisp-2.41-1.fc6 enchant-1.3.0-1.fc6 epiphany-extensions-2.16.0-1 geda-gschem-20060906-3.fc6 gtkmathview-0.7.6-5.fc6 itpp-3.10.5-7.fc6 ktechlab-0.3-5.fc6 ktorrent-2.0.3-3.fc6 libFoundation-1.1.3-10.fc6 libgeda-20060906-3.fc6 libtelepathy-0.0.38-1.fc6 libtunepimp-0.5.2-3.fc6 liferea-1.0.23-3.fc6 listen-0.5-6.beta1.fc6 moodle-1.6.3-1.fc6 musicbox-0.2.3-5.fc6 nsd-2.3.6-1.fc6 perl-Email-Address-1.871-1.fc6 perl-Email-MIME-ContentType-1.011-1.fc6 perl-aliased-0.20-2.fc6 php-pear-Mail-1.1.14-1.fc6 qt4-qsa-1.2.1-18.fc6 rsibreak-0.8.0-1.fc6 sylpheed-claws-2.5.5-1.fc6 sylpheed-claws-plugins-2.5.2-3.fc6 telepathy-gabble-0.3.13-1.fc6 tinyerp-3.4.2-1.fc6 toped-0.8.2-2.fc6 torque-2.1.3-2.fc6 vorbisgain-0.36-1.fc6 Packages built and released for Fedora Extras 5: 27 bygfoot-2.0.1-1.fc5 clisp-2.41-1.fc5 enchant-1.3.0-1.fc5 epiphany-extensions-2.14.1.1-2 geda-gschem-20060906-3.fc5 glom-1.0.7-1.fc5 itpp-3.10.5-7.fc5 ktechlab-0.3-5.fc5 ktorrent-2.0.3-4.fc5 libgeda-20060906-3.fc5 libtunepimp-0.5.2-3.fc5 listen-0.5-6.beta1.fc5 nsd-2.3.6-2.fc5 perl-Email-Address-1.871-1.fc5 perl-Email-MIME-ContentType-1.011-1.fc5 perl-SQL-Library-0.0.3-2.fc5 perl-aliased-0.20-2.fc5 php-pear-Mail-1.1.14-1.fc5 qt4-qsa-1.2.1-16.fc5 rsibreak-0.8.0-1.fc5 sylpheed-claws-plugins-2.5.2-3.fc5 telepathy-feed-0.13-2.fc5 tenr-de-styles-pkg-1.0-2.fc5 tinyerp-3.4.2-1.fc5 toped-0.8.2-2.fc5 torque-2.1.3-2.fc5 util-vserver-0.30.211-1.fc5 Packages built and released for Fedora Extras 4: 3 nsd-2.3.6-2.fc4 tinyerp-3.4.2-1.fc4 torque-2.1.3-2.fc4 Packages built and released for Fedora Extras 3: 1 nsd-2.3.6-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 Oct 14 09:55:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Oct 2006 05:55:46 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-14 Message-ID: <20061014095546.6977215212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) paul AT xelerance.com: nsd FE3 > FE6 (0:2.3.6-2.fc3 > 0:2.3.6-1.fc6) FE4 > FE6 (0:2.3.6-2.fc4 > 0:2.3.6-1.fc6) FE5 > FE6 (0:2.3.6-2.fc5 > 0:2.3.6-1.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) wolters.liste AT gmx.net: ktorrent FE5 > FE6 (0:2.0.3-4.fc5 > 0:2.0.3-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) ktorrent: wolters.liste AT gmx.net FE5 > FE6 (0:2.0.3-4.fc5 > 0:2.0.3-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nsd: paul AT xelerance.com FE3 > FE6 (0:2.3.6-2.fc3 > 0:2.3.6-1.fc6) FE4 > FE6 (0:2.3.6-2.fc4 > 0:2.3.6-1.fc6) FE5 > FE6 (0:2.3.6-2.fc5 > 0:2.3.6-1.fc6) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From buildsys at fedoraproject.org Sat Oct 14 10:35:41 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 14 Oct 2006 10:35:41 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-14 Message-ID: <20061014103541.2959.36500@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (14 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (14 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (14 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (29 days) plague - 0.4.4.1-2.fc3.noarch (29 days) plague - 0.4.4.1-2.fc4.noarch (29 days) plague - 0.4.4.1-2.fc4.noarch (29 days) plague - 0.4.4.1-2.fc4.noarch (29 days) giallu AT gmail.com kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 (3 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 (3 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (3 days) kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 (3 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (3 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 (3 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (3 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (5 days) linphone - 1.2.0-4.fc5.ppc (5 days) linphone - 1.2.0-4.fc5.x86_64 (5 days) linphone - 1.2.0-7.fc6.i386 (5 days) linphone - 1.2.0-7.fc6.ppc (5 days) linphone - 1.2.0-7.fc6.x86_64 (5 days) karlthered AT gmail.com listen - 0.5-6.beta1.fc5.x86_64 listen - 0.5-6.beta1.fc6.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 (3 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (3 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (3 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (3 days) kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (3 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (3 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (3 days) kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (3 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (3 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (3 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6smp linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) listen-0.5-6.beta1.fc6.x86_64 requires /usr/lib/libtunepimp.so.5 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-sysprof-PAE-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) listen-0.5-6.beta1.fc5.x86_64 requires /usr/lib/libtunepimp.so.5 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libetpan.so.6 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libetpan.so.6()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libetpan.so.6 ====================================================================== New report for: karlthered AT gmail.com package: listen - 0.5-6.beta1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/lib/libtunepimp.so.5 package: listen - 0.5-6.beta1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: /usr/lib/libtunepimp.so.5 From tcallawa at redhat.com Fri Oct 13 01:43:29 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:43:29 -0500 Subject: Advice on rpath In-Reply-To: References: <20061011212110.GB23049@free.fr> <452E4B50.5010507@hhs.nl> Message-ID: <1160703809.2619.589.camel@localhost.localdomain> On Thu, 2006-10-12 at 23:37 +0200, Linus Walleij wrote: > On Thu, 12 Oct 2006, Hans de Goede wrote: > > > Why, all that is need is adding the following 2 lines to the spec after > > %configure (...) > > You're right Hans, as always... > > Given all the stir rpath is causing, can we perhaps put a few words on it > in the packaging guidelines, "no rpath, thanks, and here's why and how" > type of text. spot, you own that doc, what do you say? Seems like a lot of solid logic to me. I'll write it up and add it as soon as I'm back on the ground and conscious. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tcallawa at redhat.com Fri Oct 13 01:52:25 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:52:25 -0500 Subject: desktop files for dockapp apps? In-Reply-To: <20061012201411.GC2358@free.fr> References: <20061012201411.GC2358@free.fr> Message-ID: <1160704345.2619.598.camel@localhost.localdomain> On Thu, 2006-10-12 at 22:14 +0200, Patrice Dumas wrote: > Hello, > > Should there be a .desktop, an icon and so on for dockapp apps? When > they are used in fluxbox, for example it doesn't make much sense to > have one, since they have to be launched by editing .fluxbox/startup. > Is it different on other desktops? (on xfce I don't see anything when > I launch them...). IMHO: - desktop files for dockapp apps are not necessary. - icon files for dockapp apps are necessary (don't you see an icon when you're enabling it from the config tool? doesn't it need an icon to let you know its running in the dock?) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tcallawa at redhat.com Fri Oct 13 01:55:00 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:55:00 -0500 Subject: FE-Legal bugzilla tickets In-Reply-To: References: <20061008142329.GB14557@rathann.pekin.waw.pl> Message-ID: <1160704500.2619.601.camel@localhost.localdomain> On Sun, 2006-10-08 at 11:23 -0500, Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > How long does it take to handle the FE-Legal issues? Some of them have been > > stalled for 6 months already... > > The legal peoples' have been pinged, unfortunately, they're also very > busy folks. If it is a licensing issue, I'd be happy to eyeball it and see if it can't be solved by me without wasting lawyer time (or wasting packager time waiting for a lawyer). At this point, I'm getting a bit too familiar with how they rule on such matters. :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tcallawa at redhat.com Fri Oct 13 01:59:33 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:59:33 -0500 Subject: help needed on the gwyddion review In-Reply-To: <20061007213120.GB14728@free.fr> References: <20061007211548.GA14728@free.fr> <883cfe6d0610071426i40485320u2914a808c1c6c63d@mail.gmail.com> <20061007213120.GB14728@free.fr> Message-ID: <1160704773.2619.606.camel@localhost.localdomain> On Sat, 2006-10-07 at 23:31 +0200, Patrice Dumas wrote: > On Sat, Oct 07, 2006 at 05:26:27PM -0400, Michel Salim wrote: > > On 10/7/06, Patrice Dumas wrote: > > >Hello, > > It would make sense (to me, anyway) to have the deprecated modules > > packaged like normal, as you suggested, but perhaps with an ifdef. > > Probably set them to be built by default for now? > > They have to be packaged unconditionnally because the > gwyddion-plugin-examples need them. Lemme make this clear. If the user downloads something in your package/subpackage, and it doesn't work because of a missing dependency (e.g. perl/python/ruby) not present, then you screwed up. Don't assume your users have a sane environment, or even that your users possess the faintest amount of clue. Not having necessary Requires for things is a blocker. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tcallawa at redhat.com Fri Oct 13 02:03:00 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 21:03:00 -0500 Subject: Important - unorphaning packages properly In-Reply-To: <1160417341.3100.56.camel@viper.local> References: <1160417341.3100.56.camel@viper.local> Message-ID: <1160704980.2619.608.camel@localhost.localdomain> On Mon, 2006-10-09 at 21:09 +0300, Ville Skytt? wrote: > People, > > When unorphaning packages, PLEASE take the time to do it correctly. > > You're expected to update Extras/OrphanedPackages in Wiki (remove the > package from the list of orphaned), and owners.list in CVS (make > yourself as the initial owner of the package). Read the documentation > in Extras/OrphanedPackages in Wiki and ask questions if unsure. > > Yes, TWO places. Yes, the need to update two places sucks (but people > are already working on a package database which should make things > easier in the future). All too often, people just don't bother to > update either! > > If updating two things sucks for you, let me assure that doing tracking > the omissions plus taking care of the two updates on your and many > others behalf is more than "sucks", it's a royal PITA for someone else > to take care of. Feel like documenting this process in the wiki, say HowToUnOrphanPackages :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From caillon at redhat.com Sat Oct 14 16:30:22 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 14 Oct 2006 12:30:22 -0400 Subject: desktop files for dockapp apps? In-Reply-To: <20061012201411.GC2358@free.fr> References: <20061012201411.GC2358@free.fr> Message-ID: <4531109E.9080406@redhat.com> Patrice Dumas wrote: > Hello, > > Should there be a .desktop, an icon and so on for dockapp apps? When > they are used in fluxbox, for example it doesn't make much sense to > have one, since they have to be launched by editing .fluxbox/startup. > Is it different on other desktops? (on xfce I don't see anything when > I launch them...). .desktop files are useful for three things: - Applications which need a launcher in the main menu. - Applications which act as an opener for certain MIME types - Applications which need to be started explicitly each session Dockapps are none of the above. (The closest it gets is the third option, but it gets started by the dock itself once added to the dock, not individually). nm-applet and gnome-power-manager both do the third item though because they are not true dockapps. In short, your answer is no. From kevin.kofler at chello.at Sat Oct 14 18:09:43 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 14 Oct 2006 18:09:43 +0000 (UTC) Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-14 References: <20061014103541.2959.36500@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure writes: > package: listen - 0.5-6.beta1.fc6.x86_64 from fedora-extras-development-x86_64 > unresolved deps: > /usr/lib/libtunepimp.so.5 > > package: listen - 0.5-6.beta1.fc5.x86_64 from fedora-extras-5-x86_64 > unresolved deps: > /usr/lib/libtunepimp.so.5 Note the absence of the "()(64bit)" marker. Why does this x86_64 package have a dependency on a 32-bit lib? Something needs fixing here. Kevin Kofler From tibbs at math.uh.edu Sat Oct 14 18:10:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 14 Oct 2006 13:10:24 -0500 Subject: FE-Legal bugzilla tickets In-Reply-To: <1160704500.2619.601.camel@localhost.localdomain> (Tom Callaway's message of "Thu, 12 Oct 2006 20:55:00 -0500") References: <20061008142329.GB14557@rathann.pekin.waw.pl> <1160704500.2619.601.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: TC> If it is a licensing issue, I'd be happy to eyeball it and see if TC> it can't be solved by me without wasting lawyer time (or wasting TC> packager time waiting for a lawyer). Here's an executive summary of the open bugs blocking FE-Legal (damn case-sensitive bugzilla alias lookup). There are indeed a few licensing issues, and a couple of questions about parsing non-patented container formats containing data in some patented format. Which seems obviously OK to me, as otherwise we couldn't package tar or zip. 177134 - mkvtoolnix - deals with encoded data in a specific container format, but does not encode or decode actual data stored within that container (see comment #2). http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177134#c2 178162 - libgeotiff - the data file included in the package has a licensing issue (see comment #2) http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178162#c2 190144 - hevea - the documentation has a licensing issue (see comment #7). http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190144#c7 190343 - VDR - deals with MPEG data from an external source (hardware), but neither encodes nor decodes it (see comment #10). http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190343#c10 191036 - libmp4v2 - parses the mp4 container format. Does not decode actual data stored in the container. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191036 204166 - xeuphoric - emulator with copyrighted ROMs included. Submitter indicates that all copyrights have lapsed with no successor. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204166 205798 - xine-lib - patented stuff has already been stripped from the submitted tarball. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205798 205955 - gdal - same problem as libgeotiff, except that unlike libgeotiff, this package actually needs the data to be useful. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205955 - J< From pertusus at free.fr Sat Oct 14 18:12:53 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 14 Oct 2006 20:12:53 +0200 Subject: desktop files for dockapp apps? In-Reply-To: <1160704345.2619.598.camel@localhost.localdomain> References: <20061012201411.GC2358@free.fr> <1160704345.2619.598.camel@localhost.localdomain> Message-ID: <20061014181252.GA8216@free.fr> On Thu, Oct 12, 2006 at 08:52:25PM -0500, Tom 'spot' Callaway wrote: > On Thu, 2006-10-12 at 22:14 +0200, Patrice Dumas wrote: > > IMHO: > > - desktop files for dockapp apps are not necessary. > - icon files for dockapp apps are necessary (don't you see an icon when > you're enabling it from the config tool? doesn't it need an icon to let > you know its running in the dock?) Which config tool? I don't know one... Where should these icons be put? -- Pat From tibbs at math.uh.edu Sat Oct 14 19:31:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 14 Oct 2006 14:31:25 -0500 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-14 In-Reply-To: (Kevin Kofler's message of "Sat, 14 Oct 2006 18:09:43 +0000 (UTC)") References: <20061014103541.2959.36500@extras64.linux.duke.edu> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> Note the absence of the "()(64bit)" marker. Why does this x86_64 KK> package have a dependency on a 32-bit lib? Something needs fixing KK> here. The issue was an explicit dependency on /usr/lib/libtunepimp.so.5, but it's already been fixed. - J< From tcallawa at redhat.com Sat Oct 14 20:44:18 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 14 Oct 2006 15:44:18 -0500 Subject: desktop files for dockapp apps? In-Reply-To: <20061014181252.GA8216@free.fr> References: <20061012201411.GC2358@free.fr> <1160704345.2619.598.camel@localhost.localdomain> <20061014181252.GA8216@free.fr> Message-ID: <1160858658.2619.714.camel@localhost.localdomain> On Sat, 2006-10-14 at 20:12 +0200, Patrice Dumas wrote: > On Thu, Oct 12, 2006 at 08:52:25PM -0500, Tom 'spot' Callaway wrote: > > On Thu, 2006-10-12 at 22:14 +0200, Patrice Dumas wrote: > > > > IMHO: > > > > - desktop files for dockapp apps are not necessary. > > - icon files for dockapp apps are necessary (don't you see an icon when > > you're enabling it from the config tool? doesn't it need an icon to let > > you know its running in the dock?) > > Which config tool? I don't know one... Where should these icons be put? How do you add a dockapp? Presumably, there is some tool (e.g. to add an item to the GNOME panel, there is a tool to select what I want) which does this. Also, doesn't the app display an icon in the dock when it is running? If the answer to all of these questions is no, then you probably don't need an icon. :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From ville.skytta at iki.fi Sat Oct 14 20:53:32 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 14 Oct 2006 23:53:32 +0300 Subject: rpms/lua/devel .cvsignore, 1.4, 1.5 lua.spec, 1.18, 1.19 sources, 1.6, 1.7 In-Reply-To: <200610142032.k9EKWcSC014321@cvs-int.fedora.redhat.com> References: <200610142032.k9EKWcSC014321@cvs-int.fedora.redhat.com> Message-ID: <1160859212.4207.54.camel@viper.local> On Sat, 2006-10-14 at 13:32 -0700, Hans de Goede wrote: > * Sat Oct 14 2006 Hans de Goede 5.1.1-1 > - New upstream release 5.1.1 > - Fix detection of readline during compile (iow add readline support back) [...] > --- lua.spec 28 Aug 2006 04:24:13 -0000 1.18 > +++ lua.spec 14 Oct 2006 20:32:35 -0000 1.19 > @@ -1,16 +1,14 @@ > Name: lua > -Version: 5.1 > -Release: 7%{?dist} > +Version: 5.1.1 > +Release: 1%{?dist} > Summary: Powerful light-weight programming language > - > Group: Development/Languages > License: MIT [...] > -BuildRequires: readline-devel, ncurses-devel > +BuildRequires: readline-devel ncurses-devel Doesn't linking lua with readline mean that the combined work now falls under the GPL, not MIT? If so, I think it would be good to change the License tag to reflect that. Or if possible, to split the parts that have been linked with readline into a separate GPL licensed subpackage, leaving everything else MIT. Actually maybe even better, look into linking with libedit instead? http://lua-users.org/lists/lua-l/2006-02/msg00472.html From j.w.r.degoede at hhs.nl Sat Oct 14 21:07:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Oct 2006 23:07:07 +0200 Subject: rpms/lua/devel .cvsignore, 1.4, 1.5 lua.spec, 1.18, 1.19 sources, 1.6, 1.7 In-Reply-To: <1160859212.4207.54.camel@viper.local> References: <200610142032.k9EKWcSC014321@cvs-int.fedora.redhat.com> <1160859212.4207.54.camel@viper.local> Message-ID: <4531517B.6020700@hhs.nl> Ville Skytt? wrote: > On Sat, 2006-10-14 at 13:32 -0700, Hans de Goede wrote: > >> * Sat Oct 14 2006 Hans de Goede 5.1.1-1 >> - New upstream release 5.1.1 >> - Fix detection of readline during compile (iow add readline support back) > [...] >> --- lua.spec 28 Aug 2006 04:24:13 -0000 1.18 >> +++ lua.spec 14 Oct 2006 20:32:35 -0000 1.19 >> @@ -1,16 +1,14 @@ >> Name: lua >> -Version: 5.1 >> -Release: 7%{?dist} >> +Version: 5.1.1 >> +Release: 1%{?dist} >> Summary: Powerful light-weight programming language >> - >> Group: Development/Languages >> License: MIT > [...] >> -BuildRequires: readline-devel, ncurses-devel >> +BuildRequires: readline-devel ncurses-devel > > Doesn't linking lua with readline mean that the combined work now falls > under the GPL, not MIT? If so, I think it would be good to change the > License tag to reflect that. Or if possible, to split the parts that > have been linked with readline into a separate GPL licensed subpackage, > leaving everything else MIT. > > Actually maybe even better, look into linking with libedit instead? > http://lua-users.org/lists/lua-l/2006-02/msg00472.html > > Good point, I didn't think about this as lua was linked to readline in the past too, the not linking to readline the last few FE releases actually was a packaging error. Still a good point, I'll look into this. I think the readline is only used/needed for the cmdline interpreter, but I'm not sure. It is currently however also linked into the lib. Regards, Hans From tcallawa at redhat.com Sat Oct 14 22:00:21 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 14 Oct 2006 17:00:21 -0500 Subject: FE-Legal bugzilla tickets In-Reply-To: References: <20061008142329.GB14557@rathann.pekin.waw.pl> <1160704500.2619.601.camel@localhost.localdomain> Message-ID: <1160863221.2619.732.camel@localhost.localdomain> On Sat, 2006-10-14 at 13:10 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway writes: > > TC> If it is a licensing issue, I'd be happy to eyeball it and see if > TC> it can't be solved by me without wasting lawyer time (or wasting > TC> packager time waiting for a lawyer). > > Here's an executive summary of the open bugs blocking FE-Legal (damn > case-sensitive bugzilla alias lookup). There are indeed a few > licensing issues, and a couple of questions about parsing non-patented > container formats containing data in some patented format. Which > seems obviously OK to me, as otherwise we couldn't package tar or zip. > > 177134 - mkvtoolnix - deals with encoded data in a specific container > format, but does not encode or decode actual data stored within that > container (see comment #2). > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177134#c2 Searching the US Patent Office for "demultiplexing" (aka, demuxing) brings up way too many hits for me to comfortably judge this one. Needs to be looked at by RHAT Legal. > 178162 - libgeotiff - the data file included in the package has a > licensing issue (see comment #2) > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178162#c2 IMHO, this is a blocker. > 190144 - hevea - the documentation has a licensing issue (see comment > #7). > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190144#c7 Asked the FSF for clarification. > 190343 - VDR - deals with MPEG data from an external source (hardware), > but neither encodes nor decodes it (see comment #10). > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190343#c10 Should be fine. Lifted FE-Legal. > 191036 - libmp4v2 - parses the mp4 container format. Does not decode > actual data stored in the container. > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191036 Without the codec functionality, and with the id3lib precedence, I think this is OK. Lifted FE-Legal. > 204166 - xeuphoric - emulator with copyrighted ROMs included. > Submitter indicates that all copyrights have lapsed with no > successor. > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204166 Ancient ROMS from long dead companies, maintainer has proven (and I verified) that no one owns or is enforcing copyrights in this specific case. Lifted FE-Legal. > 205798 - xine-lib - patented stuff has already been stripped from the > submitted tarball. > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205798 All good except the liba52 code (not built, but still in tarball). Lifted FE-Legal. > 205955 - gdal - same problem as libgeotiff, except that unlike > libgeotiff, this package actually needs the data to be useful. > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205955 Same blocker as libgeotiff. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From lists at forevermore.net Sun Oct 15 03:15:45 2006 From: lists at forevermore.net (Chris Petersen) Date: Sat, 14 Oct 2006 20:15:45 -0700 Subject: help with comps.xml and lineak-related packages Message-ID: <4531A7E1.6000800@forevermore.net> I honestly just don't know where to file this. It has media plugins, kde plugins, etc., which could be filed in separate areas, but I don't even know where would be best to file the base package (x-base is the closest I can think of). Any ideas/recommendations? -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 tibbs at math.uh.edu Sun Oct 15 04:56:02 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 14 Oct 2006 23:56:02 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras Message-ID: It's an unfortunate fact that our sponsorship process makes things rather difficult for an upstream who would simply like to make their software available in Extras. They don't want to submit multiple packages and they aren't generally interested in doing a lot of extra community work. Some might say that if they're not interested in the community then they shouldn't be a maintainer (with all of the attendant access this brings), but I think that the gift of their software should count for something. Frankly I think that we should encourage upstream software authors to become involved with Extras instead of letting the packages sit endlessly in the purgatory of the FE-NEW queue. One proposed solution to this involves finding an existing Fedora package maintainer to co-maintain the package. This gives the benefits of bringing together someone intimately familiar with the software and someone already familiar with Fedora policies and procedures. I think it's a pretty good idea, but it does require that someone step up to co-maintain. So, would anyone object to trying this out with a couple of packages? To start, is there anyone interested in co-maintaining libssa (A C++ Object-Oriented network library)? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210187 You don't need to be a sponsor, just an existing maintainer. I'll do the sponsorship bit once the package review is complete. - J< From j.w.r.degoede at hhs.nl Sun Oct 15 07:56:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 Oct 2006 09:56:07 +0200 Subject: rpms/lua/devel .cvsignore, 1.4, 1.5 lua.spec, 1.18, 1.19 sources, 1.6, 1.7 In-Reply-To: <1160859212.4207.54.camel@viper.local> References: <200610142032.k9EKWcSC014321@cvs-int.fedora.redhat.com> <1160859212.4207.54.camel@viper.local> Message-ID: <4531E997.5010603@hhs.nl> Hi all, As I already thought only /usr/bin/lua uses readline, so I've patched the package so that only /usr/bin/lua is linked to readline, leaving /usr/lib[64]/liblua-5.1.so readline free and thus avoiding any potential license troubles. Regards, Hans Ville Skytt? wrote: > On Sat, 2006-10-14 at 13:32 -0700, Hans de Goede wrote: > >> * Sat Oct 14 2006 Hans de Goede 5.1.1-1 >> - New upstream release 5.1.1 >> - Fix detection of readline during compile (iow add readline support back) > [...] >> --- lua.spec 28 Aug 2006 04:24:13 -0000 1.18 >> +++ lua.spec 14 Oct 2006 20:32:35 -0000 1.19 >> @@ -1,16 +1,14 @@ >> Name: lua >> -Version: 5.1 >> -Release: 7%{?dist} >> +Version: 5.1.1 >> +Release: 1%{?dist} >> Summary: Powerful light-weight programming language >> - >> Group: Development/Languages >> License: MIT > [...] >> -BuildRequires: readline-devel, ncurses-devel >> +BuildRequires: readline-devel ncurses-devel > > Doesn't linking lua with readline mean that the combined work now falls > under the GPL, not MIT? If so, I think it would be good to change the > License tag to reflect that. Or if possible, to split the parts that > have been linked with readline into a separate GPL licensed subpackage, > leaving everything else MIT. > > Actually maybe even better, look into linking with libedit instead? > http://lua-users.org/lists/lua-l/2006-02/msg00472.html > > From pertusus at free.fr Sun Oct 15 08:28:13 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 15 Oct 2006 10:28:13 +0200 Subject: desktop files for dockapp apps? In-Reply-To: <1160858658.2619.714.camel@localhost.localdomain> References: <20061012201411.GC2358@free.fr> <1160704345.2619.598.camel@localhost.localdomain> <20061014181252.GA8216@free.fr> <1160858658.2619.714.camel@localhost.localdomain> Message-ID: <20061015082813.GB2323@free.fr> On Sat, Oct 14, 2006 at 03:44:18PM -0500, Tom 'spot' Callaway wrote: > How do you add a dockapp? Presumably, there is some tool (e.g. to add an In the case I know and use, fluxbox, one has to hand-edit the start script. I tried WindowMaker and I didn't understood how to do. The menu isn't integretaed with fedora anyway. > item to the GNOME panel, there is a tool to select what I want) which > does this. Also, doesn't the app display an icon in the dock when it is > running? The app is the icon in the dock. So the images it needs are built-in. > If the answer to all of these questions is no, then you probably don't > need an icon. :) I think it is the case as for today. Maybe this could change if a dockapp graphical management application emerges but until then I'd say no need of desktop nor icon. Could it be possible to add this explicitely to the packaging guidelines, please (that it in the desktop section state the exception for dockapps)? -- Pat From pertusus at free.fr Sun Oct 15 08:46:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 15 Oct 2006 10:46:21 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: Message-ID: <20061015084621.GC2323@free.fr> On Sat, Oct 14, 2006 at 11:56:02PM -0500, Jason L Tibbitts III wrote: > It's an unfortunate fact that our sponsorship process makes things > rather difficult for an upstream who would simply like to make their > software available in Extras. They don't want to submit multiple > packages and they aren't generally interested in doing a lot of extra > community work. Some might say that if they're not interested in the > community then they shouldn't be a maintainer (with all of the > attendant access this brings), but I think that the gift of their > software should count for something. Frankly I think that we should > encourage upstream software authors to become involved with Extras > instead of letting the packages sit endlessly in the purgatory of the > FE-NEW queue. After some thinking and looking at some packages, I came to the conclusion that having upstream as primary maintainer in fedora should be avoided if possible. Indeed, there may be conflicts of interest between some upstream goals and best packaging in fedora practices. Having upstream as a co-maintainer should be, however, encouraged, if the upstream author is allready a fedora community member. > One proposed solution to this involves finding an existing Fedora > package maintainer to co-maintain the package. This gives the > benefits of bringing together someone intimately familiar with the > software and someone already familiar with Fedora policies and > procedures. I think it's a pretty good idea, but it does require that > someone step up to co-maintain. To me it would be better if the fedora community member was the primary maintainer, working in cooperation with upstream. I don't think it should be easier for upstream maintainers to be sponsored than for other maintainers. In my opinion we are not that much interested in upstream working on packaging issues, but on bugs and distribution issues. So in my opinion what is really usefull is that upstream is CC'ed to initial reviews and bugs against that package, he doesn't needs to be in the fedora community. He can subscribe to mailing lists if he wants but I can't see what we would gain in having upstream be able to change things in CVS. To put it differently I think it would be better if upstream helped fedora packagers, but not necessarily by being in the community. -- Pat From skvidal at linux.duke.edu Sun Oct 15 13:42:22 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 15 Oct 2006 09:42:22 -0400 Subject: extras-buildsys/utils/pushscript/yum Errors.py, NONE, 1.1 __init__.py, NONE, 1.1 comps.py, NONE, 1.1 config.py, NONE, 1.1 constants.py, NONE, 1.1 depsolve.py, NONE, 1.1 failover.py, NONE, 1.1 logger.py, NONE, 1.1 mdcache.py, NONE, 1.1 mdparser.py, NONE, 1.1 misc.py, NONE, 1.1 packages.py, NONE, 1.1 parser.py, NONE, 1.1 pgpmsg.py, NONE, 1.1 plugins.py, NONE, 1.1 repos.py, NONE, 1.1 sqlitecache.py, NONE, 1.1 sqlitesack.py, NONE, 1.1 transactioninfo.py, NONE, 1.1 update_md.py, NONE, 1.1 In-Reply-To: <200610151230.k9FCUl0D030934@cvs-int.fedora.redhat.com> References: <200610151230.k9FCUl0D030934@cvs-int.fedora.redhat.com> Message-ID: <1160919742.28422.81.camel@cutter> On Sun, 2006-10-15 at 05:30 -0700, Michael Schwendt wrote: > Author: mschwendt > > Update of /cvs/fedora/extras-buildsys/utils/pushscript/yum > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30805/yum > > Added Files: > Errors.py __init__.py comps.py config.py constants.py > depsolve.py failover.py logger.py mdcache.py mdparser.py > misc.py packages.py parser.py pgpmsg.py plugins.py repos.py > sqlitecache.py sqlitesack.py transactioninfo.py update_md.py > Log Message: > Add the patched yum 2.6.1 here, so we remove the dependency on the > system-installed one Michael, This is insane for a couple of reasons: 1. yum 2.6.1 does not play well with the python on rhel4 - that's what's running on extras64 2. you've checked in ALL the code into fedora cvs for this? Cmon - that's just wrong. Revert this and explain what you were trying to fix, maybe I can help. -sv From j.w.r.degoede at hhs.nl Sun Oct 15 15:02:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 Oct 2006 17:02:46 +0200 Subject: Announcing Dribble a new addon repo for Fedora Extras users Message-ID: <45324D96.1000401@hhs.nl> Hi all, Just a quick one-off note to those who may be interested in a new repo called Dribble for Fedora Core + Extras. It provides packages with a focus on fun distributable software, not already found in Core, Extras or Livna for various reasons such as their stricter legal requirements. For example, emulators, additional games and multimedia apps can be included in Dribble. The repo aims to provide support for all 'current' versions of Fedora Core including devel, for i386, ppc and x86_64. Unlike other similar repos, Dribble won't replace, upgrade or obsolete any packages found in Core, Extras or Livna but is intended to work in conjunction with them, obviously Dribble is in no way affiliated with or endorsed by them. Dribble bases its packaging and review process on that of Extras to help provide the same high quality packages as you're used to with Extras. If you're interested in helping out or using Dribble, please have a look at http://dribble.org.uk. Regards, Hans From buildsys at fedoraproject.org Sun Oct 15 15:02:50 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 15 Oct 2006 11:02:50 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-15 Message-ID: <20061015150250.09C0A15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 30 XaraLX-0.7-8.fc6.r1763 aide-0.12-1.fc6 amavisd-new-2.4.3-2.fc6 bcm43xx-fwcutter-005-1.fc6 bsd-games-2.17-15.fc6 cairomm-1.2.2-1.fc6 fbg-0.9-2.fc6 gqview-2.0.2-1.fc6 ktorrent-2.0.3-4.fc6 libpri-1.4.0-2.fc6.beta1 listen-0.5-7.beta1.fc6 lua-5.1.1-2.fc6 manaworld-0.0.21-1.fc6 mediawiki-1.8.2-4.fc6 mod_mono-1.1.18-1.fc6 monodoc-1.1.18-2.fc6 newsx-1.6-6.fc6 opensc-0.11.1-6.fc6 osgal-20060903-1.fc6 pan-0.116-1.fc6 perl-Email-MIME-1.853-1.fc6 perl-Email-MIME-Modifier-1.440-1.fc6 perl-File-BaseDir-0.02-1.fc6 perl-File-DesktopEntry-0.02-1.fc6 perl-File-MimeInfo-0.13-2.fc6 perl-PAR-Dist-0.21-1.fc6 qt4-qsa-1.2.1-19.fc6 rpmlint-0.78-2.fc6 xfce4-datetime-plugin-0.4.0-1.fc6 xsp-1.1.18-1.fc6 Packages built and released for Fedora Extras 5: 16 XaraLX-0.7-8.fc5.r1763 amavisd-new-2.4.3-2.fc5 ballbuster-1.0-1.fc5 bsd-games-2.17-12.fc5 listen-0.5-7.beta1.fc5 manaworld-0.0.21-1.fc5 mod_mono-1.1.18-1.fc5 monodoc-1.1.18-2.fc5 newsx-1.6-6.fc5 ngspice-17-7.fc5 osgal-20060903-1.fc5 perl-Email-MIME-1.853-1.fc5 perl-Email-MIME-Modifier-1.440-1.fc5 perl-PAR-Dist-0.21-1.fc5 rpmlint-0.78-2.fc5 xsp-1.1.18-1.fc5 Packages built and released for Fedora Extras 4: 0 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 Sun Oct 15 15:03:21 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 15 Oct 2006 11:03:21 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-15 Message-ID: <20061015150321.2629315212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) cgoorah AT yahoo.com.au: ngspice FE5 > FE6 (0:17-7.fc5 > 0:17-5.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) paul AT xelerance.com: nsd FE3 > FE6 (0:2.3.6-2.fc3 > 0:2.3.6-1.fc6) FE4 > FE6 (0:2.3.6-2.fc4 > 0:2.3.6-1.fc6) FE5 > FE6 (0:2.3.6-2.fc5 > 0:2.3.6-1.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) ngspice: cgoorah AT yahoo.com.au FE5 > FE6 (0:17-7.fc5 > 0:17-5.fc6) nsd: paul AT xelerance.com FE3 > FE6 (0:2.3.6-2.fc3 > 0:2.3.6-1.fc6) FE4 > FE6 (0:2.3.6-2.fc4 > 0:2.3.6-1.fc6) FE5 > FE6 (0:2.3.6-2.fc5 > 0:2.3.6-1.fc6) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From bugs.michael at gmx.net Sun Oct 15 15:12:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 15 Oct 2006 17:12:31 +0200 Subject: extras-buildsys/utils/pushscript/yum Errors.py, NONE, 1.1 __init__.py, NONE, 1.1 comps.py, NONE, 1.1 config.py, NONE, 1.1 constants.py, NONE, 1.1 depsolve.py, NONE, 1.1 failover.py, NONE, 1.1 logger.py, NONE, 1.1 mdcache.py, NONE, 1.1 mdparser.py, NONE, 1.1 misc.py, NONE, 1.1 packages.py, NONE, 1.1 parser.py, NONE, 1.1 pgpmsg.py, NONE, 1.1 plugins.py, NONE, 1.1 repos.py, NONE, 1.1 sqlitecache.py, NONE, 1.1 sqlitesack.py, NONE, 1.1 transactioninfo.py, NONE, 1.1 update_md.py, NONE, 1.1 In-Reply-To: <1160919742.28422.81.camel@cutter> References: <200610151230.k9FCUl0D030934@cvs-int.fedora.redhat.com> <1160919742.28422.81.camel@cutter> Message-ID: <20061015171231.d87ecad6.bugs.michael@gmx.net> On Sun, 15 Oct 2006 09:42:22 -0400, seth vidal wrote: > On Sun, 2006-10-15 at 05:30 -0700, Michael Schwendt wrote: > > Author: mschwendt > > > > Update of /cvs/fedora/extras-buildsys/utils/pushscript/yum > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30805/yum > > > > Added Files: > > Errors.py __init__.py comps.py config.py constants.py > > depsolve.py failover.py logger.py mdcache.py mdparser.py > > misc.py packages.py parser.py pgpmsg.py plugins.py repos.py > > sqlitecache.py sqlitesack.py transactioninfo.py update_md.py > > Log Message: > > Add the patched yum 2.6.1 here, so we remove the dependency on the > > system-installed one > > Michael, > This is insane for a couple of reasons: > > 1. yum 2.6.1 does not play well with the python on rhel4 - that's what's > running on extras64 > 2. you've checked in ALL the code into fedora cvs for this? Cmon - > that's just wrong. > > > Revert this and explain what you were trying to fix, maybe I can help. The same code has been in production use for a very long time, because it is needed by Extras repoclosure. It's far from insane, because so far it gets the job done, which should be in our best interest. The system's installed yum is 2.6.0 and does not include the "checkForObsolete" feature, which avoids all the false positives in the reports. The multilib support in the push script, which is in production use for several weeks by now (taking care of copying Wine including dependencies), also needs a stable yum API. I've seen API breakage in yum >= 2.9 (as you known from at least one bug report) and want to avoid that any future upgrade of the system's yum causes trouble. Yum is not part of RHEL4. CentOS 4.4, on the other hand, contains only yum 2.4.3, so I have no idea where this 2.6.0 version (and several other rpms, like repoview and createrepo, come from) and whether it might be upgraded suddenly. The one true solution to this would be a guarantee of API stability including the checkForObsolete code and a well-defined and announced window before a planned upgrade of yum. From buildsys at fedoraproject.org Sun Oct 15 15:40:40 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 15 Oct 2006 15:40:40 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-15 Message-ID: <20061015154040.32392.49261@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (15 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (15 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (15 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (30 days) plague - 0.4.4.1-2.fc3.noarch (30 days) plague - 0.4.4.1-2.fc4.noarch (30 days) plague - 0.4.4.1-2.fc4.noarch (30 days) plague - 0.4.4.1-2.fc4.noarch (30 days) giallu AT gmail.com kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 (4 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 (4 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (4 days) kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 (4 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 (4 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (4 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 (4 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (4 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (6 days) linphone - 1.2.0-4.fc5.ppc (6 days) linphone - 1.2.0-4.fc5.x86_64 (6 days) linphone - 1.2.0-7.fc6.i386 (6 days) linphone - 1.2.0-7.fc6.ppc (6 days) linphone - 1.2.0-7.fc6.x86_64 (6 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 (4 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (4 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (4 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (4 days) kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (4 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (4 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (4 days) kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (4 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (4 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (4 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6smp linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-sysprof-PAE-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From tibbs at math.uh.edu Sun Oct 15 17:24:51 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 15 Oct 2006 12:24:51 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061015084621.GC2323@free.fr> (Patrice Dumas's message of "Sun, 15 Oct 2006 10:46:21 +0200") References: <20061015084621.GC2323@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> After some thinking and looking at some packages, I came to the PD> conclusion that having upstream as primary maintainer in fedora PD> should be avoided if possible. I think you've made a distinction between "primary" and other maintainers that does not exist. All maintainers get access. Does it really matter who submits the package for review, or which addresses appear where in owners.list? Does the new package database even attempt to prioritize owners? - J< From pertusus at free.fr Sun Oct 15 18:07:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 15 Oct 2006 20:07:12 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> Message-ID: <20061015180712.GA5424@free.fr> On Sun, Oct 15, 2006 at 12:24:51PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > I think you've made a distinction between "primary" and other > maintainers that does not exist. All maintainers get access. Does it > really matter who submits the package for review, or which addresses > appear where in owners.list? Does the new package database even > attempt to prioritize owners? I don't know but it seems to me that, at least in extras there is a primary maintainer. The one who has his name in owners.list, indeed. -- Pat From tibbs at math.uh.edu Sun Oct 15 18:26:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 15 Oct 2006 13:26:42 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061015180712.GA5424@free.fr> (Patrice Dumas's message of "Sun, 15 Oct 2006 20:07:12 +0200") References: <20061015084621.GC2323@free.fr> <20061015180712.GA5424@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> I don't know but it seems to me that, at least in extras there is PD> a primary maintainer. The one who has his name in owners.list, PD> indeed. And can you quantify a single operational distinction between these maintainers? They all have equal access to CVS and the buildsys. So just what difference do you think it makes? And why do you feel that upstream maintainers need to be in some sort of inferior position with respect to other maintainers? - J< From packages at amiga-hardware.com Sun Oct 15 18:37:17 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 15 Oct 2006 19:37:17 +0100 Subject: new repo Message-ID: <45327FDD.5000204@amiga-hardware.com> Hi, Just a quick one-off note to those who may be interested in a new repo called Dribble for Fedora Core. It provides packages with a focus on fun distributable software, not already found in Core, Extras or Livna for various reasons such as their stricter legal requirements. For example, emulators, additional games and multimedia apps can be included in Dribble. The repo aims to provide support for all 'current' versions of Fedora Core including devel, for i386, ppc and x86_64. Unlike other similar repos, Dribble won't replace, upgrade or obsolete any packages found in Core, Extras or Livna but is intended to work in conjunction with them, obviously Dribble is in no way affiliated with or endorsed by them. Dribble bases its packaging and review process on that of Extras to help provide high quality packages. If you're interested in helping out or using Dribble, please have a look at: http://dribble.org.uk. Cheers -- Ian Chapman. From Axel.Thimm at ATrpms.net Sun Oct 15 19:00:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 15 Oct 2006 21:00:30 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> Message-ID: <20061015190030.GD8727@neu.nirvana> On Sun, Oct 15, 2006 at 12:24:51PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> After some thinking and looking at some packages, I came to the > PD> conclusion that having upstream as primary maintainer in fedora > PD> should be avoided if possible. > > I think you've made a distinction between "primary" and other > maintainers that does not exist. All maintainers get access. Does it > really matter who submits the package for review, or which addresses > appear where in owners.list? Does the new package database even > attempt to prioritize owners? Is this the upcoming model of co-maintainers? I'd prefer the model Patrice assumes, e.g. a primary one and secondary co-maintainers that *should* coordinate their actions with the primary one. Otherwise suddenly all contributors become co-maintainers of everything and we'll get trouble keeping it all in non-chaotic state. To get back to upstream vs fedora experts maintership: Assuming the co-maintainership model would be indeed hierarchical, I agree with Patrice, better to have someone knowing the details in fedora doing the packaging (in consulting with upstream), than having the package experts trying to teach upstream how to package. I guess before considering the relationship of upstream and package maintainers closer one would need to see what the real model of co-maintainership will look like. If this has already been decided on, is there some pointer to wiki/mail that explains it? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Sun Oct 15 18:58:59 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 15 Oct 2006 20:58:59 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015180712.GA5424@free.fr> Message-ID: <20061015185859.GB5424@free.fr> On Sun, Oct 15, 2006 at 01:26:42PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > And can you quantify a single operational distinction between these > maintainers? They all have equal access to CVS and the buildsys. So > just what difference do you think it makes? And why do you feel that > upstream maintainers need to be in some sort of inferior position with > respect to other maintainers? To state it otherwise it seems to me that there is someone who has the last word on changes and I think that it would be better if it wasn't the upstream, in case there are conflicting goals. -- Pat From fedora at leemhuis.info Sun Oct 15 19:25:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Oct 2006 21:25:49 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061015190030.GD8727@neu.nirvana> References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> Message-ID: <45328B3D.6030504@leemhuis.info> Axel Thimm schrieb: > On Sun, Oct 15, 2006 at 12:24:51PM -0500, Jason L Tibbitts III wrote: >>>>>>> "PD" == Patrice Dumas writes: >> PD> After some thinking and looking at some packages, I came to the >> PD> conclusion that having upstream as primary maintainer in fedora >> PD> should be avoided if possible. >> I think you've made a distinction between "primary" and other >> maintainers that does not exist. All maintainers get access. Does it >> really matter who submits the package for review, or which addresses >> appear where in owners.list? Does the new package database even >> attempt to prioritize owners? > > Is this the upcoming model of co-maintainers? Well, that's not written down anywhere and I'm glad it gets discussed. Maybe a bit early, because the technical framework for co-maintainership is still far away.... Anyway: > I'd prefer the model > Patrice assumes, e.g. a primary one and secondary co-maintainers that > *should* coordinate their actions with the primary one. Otherwise > suddenly all contributors become co-maintainers of everything and > we'll get trouble keeping it all in non-chaotic state. I currently prefer a middle ground: There is one primary maintainer -- normally the one that got the packages imported. Both primarly and co-maintainers are free to commit small changes without telling the others (they maybe should wait 24 before building so the other maintainers can veto things). Medium sized or big changes need coordination between all maintainers -- e.g. also the primary maintainer should also ask his co-maintainers for permission (e.g. wait at least 72 hours before building after importing and/or send the others a mails announcing the changes). Well, those are only some rough ideas, but you'll get the idea. But it also depends on how the maintainers of a particular package want to handle it. If one primary maintainers wants full control over his package: okay, then let him if there aren't five other well know packagers that are more friendly. But I don't like such a behavior to much, and it should be the exception and strongly discouraged. > To get back to upstream vs fedora experts maintership: Assuming the > co-maintainership model would be indeed hierarchical, I agree with > Patrice, better to have someone knowing the details in fedora doing > the packaging (in consulting with upstream), than having the package > experts trying to teach upstream how to package. Well, I see no problem to give some upstream developer the primary maintainership of a package in Fedora *if* the upstream developer actually is really interested in Fedora (e.g. he uses it and is aware of the Packaging Guidelines). But that's often not the case. > I guess before considering the relationship of upstream and package > maintainers closer one would need to see what the real model of > co-maintainership will look like. If this has already been decided on, > is there some pointer to wiki/mail that explains it? Thanks! Some stuff is at: http://www.fedoraproject.org/wiki/Extras/Schedule/Comaintainership Cu thl From tibbs at math.uh.edu Sun Oct 15 20:38:29 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 15 Oct 2006 15:38:29 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061015190030.GD8727@neu.nirvana> (Axel Thimm's message of "Sun, 15 Oct 2006 21:00:30 +0200") References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> Is this the upcoming model of co-maintainers? I'd prefer the model AT> Patrice assumes, e.g. a primary one and secondary co-maintainers AT> that *should* coordinate their actions with the primary AT> one. I think it's foolish to attempt to impose that policy across every package. If the various maintainers of a particular package want to make that agreement between each other, that's fine. If the maintainers of a different package don't want to have any kind of primary maintainer, then that's fine to. AT> Otherwise suddenly all contributors become co-maintainers of AT> everything and we'll get trouble keeping it all in non-chaotic AT> state. And yet somehow we have Extras chugging along just fine with exactly that rule, and the only thing to prevent such chaos is the various agreements that maintainers make with each other. - J< From larsbj at gullik.net Sun Oct 15 21:37:52 2006 From: larsbj at gullik.net (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: 15 Oct 2006 23:37:52 +0200 Subject: libtorrent/rtorrent last update bad Message-ID: After the last update rtorrent/libtorrent is not behaving nicely. I am continously seeding the fedora 6 torrents (pre now), but after upgrading to rtorrent-0.6.2-3.fc5 libtorrent-0.10.2-2.fc5 I see massive memory leaks, so severe that after rtorrent has checked the hash for one torrent it quickly stops doing anything since it is unable to allocate/memorymap more memory. USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND larsbj 15 0 3380m 326m 317m S 0.7 32.7 4:33.24 rtorrent This is on a box with 1GB RAM, x86_64. Storage error: [File chunk write error: Cannot allocate memory.] -- Lgb From Axel.Thimm at ATrpms.net Sun Oct 15 21:49:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 15 Oct 2006 23:49:56 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> Message-ID: <20061015214956.GE8727@neu.nirvana> On Sun, Oct 15, 2006 at 03:38:29PM -0500, Jason L Tibbitts III wrote: > AT> Otherwise suddenly all contributors become co-maintainers of > AT> everything and we'll get trouble keeping it all in non-chaotic > AT> state. > > And yet somehow we have Extras chugging along just fine with exactly > that rule, and the only thing to prevent such chaos is the various > agreements that maintainers make with each other. We do? While technically possible it is a rather clear arrangement that one doesn't simply go around changing other people's packages. -- 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 triad at df.lth.se Sun Oct 15 21:54:35 2006 From: triad at df.lth.se (Linus Walleij) Date: Sun, 15 Oct 2006 23:54:35 +0200 (CEST) Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: Message-ID: I'm happily upstream and maintainer for three packages, libnjb, libmtp and gnomad2. Being part of Fedora has increased quality of all three projects, perhaps not much but to some extent. The package review process brings up many issues, and I have the privilege to avoid patching and sending patches upstream, instead I just FixIt(TM) and release a new version. When releasing upstream, the fact that the tarball also survives the build server environment is a good acceptance test that ensures release quality. Being both upstream and contributor is quite unproblematic, always was. And it's not much work at all, once you get into it. Linus From seg at haxxed.com Mon Oct 16 00:57:09 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 15 Oct 2006 19:57:09 -0500 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <45324D96.1000401@hhs.nl> References: <45324D96.1000401@hhs.nl> Message-ID: <1160960230.3084.3.camel@localhost> I'm wondering why Hatari isn't in extras, as there's a fully GPL ROM replacement available. http://emutos.sourceforge.net/en/index.htm -------------- 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 rvinyard at cs.nmsu.edu Mon Oct 16 04:43:33 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sun, 15 Oct 2006 22:43:33 -0600 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: Message-ID: <45330DF5.4020301@cs.nmsu.edu> Linus Walleij wrote: > I'm happily upstream and maintainer for three packages, libnjb, libmtp > and gnomad2. > > Being part of Fedora has increased quality of all three projects, > perhaps not much but to some extent. The package review process brings > up many issues, and I have the privilege to avoid patching and sending > patches upstream, instead I just FixIt(TM) and release a new version. > > When releasing upstream, the fact that the tarball also survives the > build server environment is a good acceptance test that ensures > release quality. > > Being both upstream and contributor is quite unproblematic, always > was. And it's not much work at all, once you get into it. > > Linus > I'll second that. I'm upstream on bit, bitgtkmm, conexus, conexusmm and papyrus. Because I needed cairomm to support papyrus, I packaged it as well. To support another project, clipsmm, I packaged clips. Because I use Fedora as my development platform I also packaged tetex-IEEEtran and adopted (adopted in a way) nqc. I too gained alot of insight on the distribution of the packages (thanks Ralf Corsepius, Michael Schwendt, Paul Johnson, G?rard Milmeister, Jason Tibbitts and everyone else that provided feedback). I think being a part of Fedora Extras has made my upstream packages better, and I think that the Fedora community should encourage, rather that discourage, participation by upstream authors as long as said upstream author's packages meet Fedora standards. --- Rick L. Vinyard, Jr. From chabotc at xs4all.nl Mon Oct 16 06:33:53 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Mon, 16 Oct 2006 08:33:53 +0200 Subject: libtorrent/rtorrent last update bad In-Reply-To: References: Message-ID: <1160980433.2731.5.camel@localhost.localdomain> Hi Lars, The propper place for such bug reports is in bugzilla: http://bugzilla.redhat.com I might miss emails on the mailing lists, but bugzilla reports are hardly ever ignored by anyone :-) I've went ahead and filed a bug for you: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210849 I'll try to reproduce the problem, i haven't had any other reports (accept for positive ones) for the latest updates, but i'll see what i can find out. -- Chris On Sun, 2006-10-15 at 23:37 +0200, Lars Gullik Bj?nnes wrote: > After the last update rtorrent/libtorrent is not behaving nicely. > I am continously seeding the fedora 6 torrents (pre now), but after > upgrading to rtorrent-0.6.2-3.fc5 libtorrent-0.10.2-2.fc5 I see > massive memory leaks, so severe that after rtorrent has checked the > hash for one torrent it quickly stops doing anything since it is > unable to allocate/memorymap more memory. > > USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > larsbj 15 0 3380m 326m 317m S 0.7 32.7 4:33.24 rtorrent > > This is on a box with 1GB RAM, x86_64. > > Storage error: [File chunk write error: Cannot allocate memory.] > > -- > Lgb > From pertusus at free.fr Mon Oct 16 06:35:18 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 16 Oct 2006 08:35:18 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> Message-ID: <20061016063518.GA2339@free.fr> On Sun, Oct 15, 2006 at 03:38:29PM -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > And yet somehow we have Extras chugging along just fine with exactly > that rule, and the only thing to prevent such chaos is the various > agreements that maintainers make with each other. In any case there is one maintainer who has the final word, isn't it? I am referring to the primary maintainer as that person. He hasn't specific rights to enforce anything, since the cvs rights are the same for all, but everybody knows who he is and that he is the primary maintainer. It may happen that sometimes such a person don't exist, typically when a package has been unorphaned by a group of people and there isn't a clear primary maintainer, but it is an exception, and it cannot happen right after a submission (at which time the primary maintainer is the submitter, or the contributor listed in owner.list). -- Pat From j.w.r.degoede at hhs.nl Mon Oct 16 06:54:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Oct 2006 08:54:34 +0200 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1160960230.3084.3.camel@localhost> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> Message-ID: <45332CAA.7020106@hhs.nl> Callum Lerwick wrote: > I'm wondering why Hatari isn't in extras, as there's a fully GPL ROM > replacement available. http://emutos.sourceforge.net/en/index.htm > Its an emulator and in general emulators are not welcomed in Extras unless supported / officially sanctioned by the hardware company who's hardware is being implemented. There are various reasons for this, patent fears, DMCA fears, contributory copyright infringements fears etc. With that said if you can get an ok on this from Legal (or someone equal ) then we (the Dribble crew) will move it to FE. Anything in Dribble which is / can be ok-ed for Extras will be moved there, we strive to complete Extras not compete with Extras. Regards, Hans From sundaram at fedoraproject.org Mon Oct 16 07:06:59 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 16 Oct 2006 12:36:59 +0530 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <45332CAA.7020106@hhs.nl> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> Message-ID: <45332F93.4000204@fedoraproject.org> Hans de Goede wrote: > Its an emulator and in general emulators are not welcomed in Extras > unless supported / officially sanctioned by the hardware company who's > hardware is being implemented. There are various reasons for this, > patent fears, DMCA fears, contributory copyright infringements fears etc. I believe the rule of thumb here is that if we have freely redistributable "data" that runs on these emulators, we can include the emulator in extras. In other words, the question to ask yourself, is there any legal and Free software uses for the emulators? > > With that said if you can get an ok on this from Legal (or someone equal > ) then we (the Dribble crew) will move it to FE. Anything in Dribble > which is / can be ok-ed for Extras will be moved there, we strive to > complete Extras not compete with Extras. You should bring up discussions on a case by case basis to this list. Rahul From j.w.r.degoede at hhs.nl Mon Oct 16 07:52:12 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Oct 2006 09:52:12 +0200 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <45332F93.4000204@fedoraproject.org> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> Message-ID: <45333A2C.3060703@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >> With that said if you can get an ok on this from Legal (or someone equal >> ) then we (the Dribble crew) will move it to FE. Anything in Dribble >> which is / can be ok-ed for Extras will be moved there, we strive to >> complete Extras not compete with Extras. > > You should bring up discussions on a case by case basis to this list. > I understand and agree, but thats going to be a very pain stacking process, so instead I've opted to judge the suitableness of packages for FE myself and if I deem them not suitable package them for another repo like Dribble. What I was trying to say with the above message is that if someone else is willing to have the discussion for a package here and if the outcome is that the package is ok for Extras then I'm more then happy to move it to Extras including putting it through review (again as all packages in dribble are already reviewed). Regards, Hans From adrian at lisas.de Mon Oct 16 11:44:22 2006 From: adrian at lisas.de (Adrian Reber) Date: Mon, 16 Oct 2006 13:44:22 +0200 Subject: devel/common Makefile.common,1.36,1.37 In-Reply-To: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> References: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> Message-ID: <20061016114422.GA2109@lisas.de> On Sun, Oct 15, 2006 at 03:00:32PM -0700, Jeremy Katz wrote: > Index: Makefile.common > =================================================================== > RCS file: /cvs/extras/devel/common/Makefile.common,v > retrieving revision 1.36 > retrieving revision 1.37 > diff -u -r1.36 -r1.37 > --- Makefile.common 12 Jun 2006 15:59:26 -0000 1.36 > +++ Makefile.common 15 Oct 2006 22:00:32 -0000 1.37 > @@ -88,7 +88,7 @@ > CURL ?= $(shell if test -f /usr/bin/curl ; then echo "curl -H Pragma: -O -R -S --fail --show-error" ; fi) > WGET ?= $(shell if test -f /usr/bin/wget ; then echo "wget -nd -m" ; fi) > CLIENT ?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET))) > -PLAGUE_CLIENT ?= /usr/bin/plague-client > +PLAGUE_CLIENT ?= $(which plague-client) This breaks "make build" for me: $ make build build ibmonitor ibmonitor-1_4-1 devel make: build: Command not found make: *** [build] Error 127 If I use "PLAGUE_CLIENT=/usr/bin/plague-client make build" it still works. Adrian From Christian.Iseli at licr.org Mon Oct 16 12:43:16 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 16 Oct 2006 14:43:16 +0200 Subject: CVS Maintenance In-Reply-To: <3237e4410610081644q58b53dccyb4efcc2c26acf5cf@mail.gmail.com> References: <3237e4410610070754r49306617o45c11299de17f405@mail.gmail.com> <20061007224947.49607221@ludwig-alpha> <3237e4410610081644q58b53dccyb4efcc2c26acf5cf@mail.gmail.com> Message-ID: <20061016144316.78ecdb60@ludwig-alpha> On Sun, 8 Oct 2006 18:44:08 -0500, Mike McGrath wrote: > On 10/7/06, Christian Iseli wrote: > > On Sat, 7 Oct 2006 09:54:10 -0500, Mike McGrath wrote: > > > We can certainly wait until FC6 is released but when would be a good > > > time for you guys to have some downtime on CVS? I'm estimating only a > > > few hours, just the Fedora CVS server, not the internal RH one. > > > > How about right before the FC-6 branches are created ? Then the > > branches can be created while the system is quiet and then everything > > gets back online smoothly... > > Doesn't matter to me, when will that happen? AFAIK: when FC6 is ready and jkeating decides to do it... C From andy at smile.org.ua Mon Oct 16 14:15:40 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 16 Oct 2006 17:15:40 +0300 Subject: devel/common Makefile.common,1.36,1.37 In-Reply-To: <20061016114422.GA2109@lisas.de> References: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> <20061016114422.GA2109@lisas.de> Message-ID: <4533940C.9080009@smile.org.ua> Adrian Reber wrote: > This breaks "make build" for me: > > $ make build > build ibmonitor ibmonitor-1_4-1 devel > make: build: Command not found > make: *** [build] Error 127 Try to install which by following command yum install which -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From mmcgrath at fedoraproject.org Mon Oct 16 14:17:28 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 16 Oct 2006 09:17:28 -0500 Subject: devel/common Makefile.common,1.36,1.37 In-Reply-To: <20061016114422.GA2109@lisas.de> References: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> <20061016114422.GA2109@lisas.de> Message-ID: <3237e4410610160717o64c84412n380ff9faea97890f@mail.gmail.com> On 10/16/06, Adrian Reber wrote: > On Sun, Oct 15, 2006 at 03:00:32PM -0700, Jeremy Katz wrote: > > Index: Makefile.common > > =================================================================== > > RCS file: /cvs/extras/devel/common/Makefile.common,v > > retrieving revision 1.36 > > retrieving revision 1.37 > > diff -u -r1.36 -r1.37 > > --- Makefile.common 12 Jun 2006 15:59:26 -0000 1.36 > > +++ Makefile.common 15 Oct 2006 22:00:32 -0000 1.37 > > @@ -88,7 +88,7 @@ > > CURL ?= $(shell if test -f /usr/bin/curl ; then echo "curl -H Pragma: -O -R -S --fail --show-error" ; fi) > > WGET ?= $(shell if test -f /usr/bin/wget ; then echo "wget -nd -m" ; fi) > > CLIENT ?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET))) > > -PLAGUE_CLIENT ?= /usr/bin/plague-client > > +PLAGUE_CLIENT ?= $(which plague-client) > > This breaks "make build" for me: > > $ make build > build ibmonitor ibmonitor-1_4-1 devel > make: build: Command not found > make: *** [build] Error 127 > > If I use "PLAGUE_CLIENT=/usr/bin/plague-client make build" it still works. > > Adrian > This patch should fix it. ############## --- Makefile.common 2006-10-16 09:14:55.000000000 -0500 +++ Makefile.common.orig 2006-10-16 09:15:42.000000000 -0500 @@ -89,7 +89,7 @@ CURL ?= $(shell if test -f /usr/bin/curl ; then echo "curl -H Pragma: -O -R -S --fail --show-error" ; fi) WGET ?= $(shell if test -f /usr/bin/wget ; then echo "wget -nd -m" ; fi) CLIENT ?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET))) -PLAGUE_CLIENT ?= $(shell which plague-client) +PLAGUE_CLIENT ?= $(which plague-client) # RPM with all the overrides in place; you can override this in your # .cvsextrasrc also, to use a default rpm setup From mmcgrath at fedoraproject.org Mon Oct 16 14:19:27 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 16 Oct 2006 09:19:27 -0500 Subject: devel/common Makefile.common,1.36,1.37 In-Reply-To: <3237e4410610160717o64c84412n380ff9faea97890f@mail.gmail.com> References: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> <20061016114422.GA2109@lisas.de> <3237e4410610160717o64c84412n380ff9faea97890f@mail.gmail.com> Message-ID: <3237e4410610160719r3e23f9c9ka8fba01f629b6814@mail.gmail.com> On 10/16/06, Mike McGrath wrote: > On 10/16/06, Adrian Reber wrote: > > On Sun, Oct 15, 2006 at 03:00:32PM -0700, Jeremy Katz wrote: > > > Index: Makefile.common > > > =================================================================== > > > RCS file: /cvs/extras/devel/common/Makefile.common,v > > > retrieving revision 1.36 > > > retrieving revision 1.37 > > > diff -u -r1.36 -r1.37 > > > --- Makefile.common 12 Jun 2006 15:59:26 -0000 1.36 > > > +++ Makefile.common 15 Oct 2006 22:00:32 -0000 1.37 > > > @@ -88,7 +88,7 @@ > > > CURL ?= $(shell if test -f /usr/bin/curl ; then echo "curl -H Pragma: -O -R -S --fail --show-error" ; fi) > > > WGET ?= $(shell if test -f /usr/bin/wget ; then echo "wget -nd -m" ; fi) > > > CLIENT ?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET))) > > > -PLAGUE_CLIENT ?= /usr/bin/plague-client > > > +PLAGUE_CLIENT ?= $(which plague-client) > > > > This breaks "make build" for me: > > > > $ make build > > build ibmonitor ibmonitor-1_4-1 devel > > make: build: Command not found > > make: *** [build] Error 127 > > > > If I use "PLAGUE_CLIENT=/usr/bin/plague-client make build" it still works. > > > > Adrian > > > > This patch should fix it. > oops, actually this: --- Makefile.common.orig 2006-10-16 09:15:42.000000000 -0500 +++ Makefile.common 2006-10-16 09:14:55.000000000 -0500 @@ -89,7 +89,7 @@ CURL ?= $(shell if test -f /usr/bin/curl ; then echo "curl -H Pragma: -O -R -S --fail --show-error" ; fi) WGET ?= $(shell if test -f /usr/bin/wget ; then echo "wget -nd -m" ; fi) CLIENT ?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET))) -PLAGUE_CLIENT ?= $(which plague-client) +PLAGUE_CLIENT ?= $(shell which plague-client) # RPM with all the overrides in place; you can override this in your # .cvsextrasrc also, to use a default rpm setup From katzj at redhat.com Mon Oct 16 14:31:50 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 Oct 2006 10:31:50 -0400 Subject: devel/common Makefile.common,1.36,1.37 In-Reply-To: <3237e4410610160719r3e23f9c9ka8fba01f629b6814@mail.gmail.com> References: <200610152200.k9FM0YaP031604@cvs-int.fedora.redhat.com> <20061016114422.GA2109@lisas.de> <3237e4410610160717o64c84412n380ff9faea97890f@mail.gmail.com> <3237e4410610160719r3e23f9c9ka8fba01f629b6814@mail.gmail.com> Message-ID: <1161009110.27522.0.camel@orodruin.boston.redhat.com> On Mon, 2006-10-16 at 09:19 -0500, Mike McGrath wrote: > > > This breaks "make build" for me: [snip] > oops, actually this: Whoops, yes indeed -- committed Jeremy From fedora at theholbrooks.org Mon Oct 16 15:04:09 2006 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Mon, 16 Oct 2006 10:04:09 -0500 Subject: Review for Horde Message-ID: <45339F69.7090600@theholbrooks.org> Anybody out there have the marbles to finish the review for horde? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189195 I opened it in April, and a bunch have people have submitted some invaluable comments for a few months, but nobody has taken the review and seen it to completion. I feel the package is 99% ready for approval, I just need somebody to sign their name to it :). Thanks in advance! -Brandon From rc040203 at freenet.de Mon Oct 16 15:52:26 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 16 Oct 2006 17:52:26 +0200 Subject: rpms/scanbuttond/devel buttonpressed.sh, NONE, 1.1 initscanner.sh, NONE, 1.1 scanbuttond-0.2.3.diff, NONE, 1.1 scanbuttond.init, NONE, 1.1 scanbuttond.spec, NONE, 1.1 sources, NONE, 1.1 In-Reply-To: <200610161547.k9GFl99C028572@cvs-int.fedora.redhat.com> References: <200610161547.k9GFl99C028572@cvs-int.fedora.redhat.com> Message-ID: <1161013947.14516.26.camel@mccallum.corsepiu.local> On Mon, 2006-10-16 at 08:47 -0700, Parag Ashok Nemade wrote: > Author: paragn > > --- NEW FILE scanbuttond.init --- > #!/bin/bash > # > # Startup script for Scanbuttond > # > # chkconfig: - 98 54 > # description: LISa is a small daemon which is intended to run on \ > # end user systems. It provides something like a \ > # "network neighbourhood", but only relying on the TCP/IP \ > # protocol stack, no smb or whatever.\ > # The information about the hosts in your "neighbourhood" \ > # is provided via TCP port 7741. This description doesn't match to scanbuttond ... seems as if somebody "borrowed" some code without properly hiding the source :) Ralf From buildsys at fedoraproject.org Mon Oct 16 18:29:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 Oct 2006 14:29:12 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-16 Message-ID: <20061016182912.0E45B15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 22 allegro-4.2.0-18.fc6 crystal-1.0.2-1.fc6 gcompris-8.1-1.fc6 ibmonitor-1.4-1 kannel-1.4.1-2.fc6 kmenu-gnome-0.6.0.1-2.fc6 libctl-3.0.2-4.fc6 lirc-0.8.1-0.2.pre2.fc6 ngspice-17-7.fc6 nsd-2.3.6-2.fc6 obmenu-1.0-3.fc6 orage-4.3.99.1-6.fc6 perl-Event-1.07-1.fc6 perl-Gnome2-GConf-1.043-1.fc6 perl-Params-Coerce-0.14-1.fc6 php-eaccelerator-5.1.6_0.9.5-1.fc6 piklab-0.12.1-1.fc6 python-tgfastdata-0.9a6-4.fc6 scanbuttond-0.2.3-7.fc6 scribes-0.2.9.87-3.fc6 ufsparse-2.1.1-1.fc6 zaptel-1.4.0-2.fc6.beta1 Packages built and released for Fedora Extras 5: 18 crystal-1.0.2-1.fc5 em8300-0.16.0-0.2.rc1.fc5 em8300-kmod-0.16.0-0.0.rc1.2.6.18_1.2200.fc5 ginac-1.3.5-1.fc5 kannel-1.4.1-2.fc5 kmenu-gnome-0.6.0.1-2.fc5 libpri-1.4.0-2.fc5.beta1 lighttpd-1.4.13-1.fc5 moodle-1.6.3-1.fc5 obmenu-1.0-3.fc5 perl-Event-1.07-1.fc5 perl-Gnome2-GConf-1.043-1.fc5 perl-Params-Coerce-0.14-1.fc5 php-eaccelerator-5.1.6_0.9.5-1.fc5 piklab-0.12.1-1.fc5 stellarium-0.8.2-1.fc5.2 sysprof-kmod-1.0.3-3.2.6.18_1.2200.fc5 ufsparse-2.1.1-1.fc5 Packages built and released for Fedora Extras 4: 1 moodle-1.6.3-1.fc4 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 Mon Oct 16 18:29:39 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 Oct 2006 14:29:39 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-16 Message-ID: <20061016182939.A424815212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From peter at thecodergeek.com Mon Oct 16 18:48:37 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 16 Oct 2006 11:48:37 -0700 Subject: rpms/gnubiff/devel gnubiff.spec,1.4,1.5 In-Reply-To: <200610161842.k9GIgCYq020398@cvs-int.fedora.redhat.com> References: <200610161842.k9GIgCYq020398@cvs-int.fedora.redhat.com> Message-ID: <4533D405.2060305@thecodergeek.com> Damien Durand (splinux) wrote: > +* Sun Oct 15 2006 Damien Durand - 2.2.2-4 > +- Add perl-XML-Parser in BR Shouldn't this be perl(XML::Parser), and not a hardcoded package name? The reason for this is that (as I understand it) the perl module functionality may be provided by another module or by Perl itself sometime in the future, and therefore RPM would find that it would satisfy the XML::Parser module need, and your spec file would thus need no changing. Is there a policy of sorts on this? Packaging/Perl on the wiki doesn't mention anything to this effect. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Mon Oct 16 19:10:07 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 16 Oct 2006 19:10:07 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-16 Message-ID: <20061016191007.8590.38637@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (16 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (16 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (16 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (31 days) plague - 0.4.4.1-2.fc3.noarch (31 days) plague - 0.4.4.1-2.fc4.noarch (31 days) plague - 0.4.4.1-2.fc4.noarch (31 days) plague - 0.4.4.1-2.fc4.noarch (31 days) giallu AT gmail.com kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i586 (5 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.i686 (5 days) kmod-sysprof - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (5 days) kmod-sysprof-PAE - 1.0.3-5.2.6.18_1.2747.fc6.i686 (5 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.i686 (5 days) kmod-sysprof-kdump - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (5 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.i686 (5 days) kmod-sysprof-xen - 1.0.3-5.2.6.18_1.2747.fc6.x86_64 (5 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (7 days) linphone - 1.2.0-4.fc5.ppc (7 days) linphone - 1.2.0-4.fc5.x86_64 (7 days) linphone - 1.2.0-7.fc6.i386 (7 days) linphone - 1.2.0-7.fc6.ppc (7 days) linphone - 1.2.0-7.fc6.x86_64 (7 days) peter AT thecodergeek.com scribes - 0.2.9.87-3.fc6.noarch scribes - 0.2.9.87-3.fc6.noarch redhat-bugzilla AT linuxnetz.de eggdrop - 1.6.18-2.fc5.i386 eggdrop - 1.6.18-2.fc5.ppc eggdrop - 1.6.18-2.fc5.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 (5 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (5 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (5 days) kmod-em8300 - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (5 days) kmod-em8300-PAE - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (5 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (5 days) kmod-em8300-kdump - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (5 days) kmod-em8300-smp - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc (5 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 (5 days) kmod-em8300-xen - 0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 (5 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6 kmod-em8300-smp-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.ppc requires kernel-ppc = 0:2.6.18-1.2747.fc6smp linphone-1.2.0-7.fc6.ppc requires libortp.so.2 scribes-0.2.9.87-3.fc6.noarch requires python-psyco Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6 kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.x86_64 requires kernel-x86_64 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) scribes-0.2.9.87-3.fc6.noarch requires python-psyco Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-em8300-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-em8300-PAE-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-em8300-kdump-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-em8300-xen-0.16.0-0.3.rc1.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i586 requires kernel-i586 = 0:2.6.18-1.2747.fc6 kmod-sysprof-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6 kmod-sysprof-PAE-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6PAE kmod-sysprof-kdump-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6kdump kmod-sysprof-xen-1.0.3-5.2.6.18_1.2747.fc6.i686 requires kernel-i686 = 0:2.6.18-1.2747.fc6xen linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- eggdrop-1.6.18-2.fc5.ppc requires libdns.so.21 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- eggdrop-1.6.18-2.fc5.x86_64 requires libdns.so.21()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- eggdrop-1.6.18-2.fc5.i386 requires libdns.so.21 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: peter AT thecodergeek.com package: scribes - 0.2.9.87-3.fc6.noarch from fedora-extras-development-ppc unresolved deps: python-psyco package: scribes - 0.2.9.87-3.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: python-psyco ====================================================================== New report for: redhat-bugzilla AT linuxnetz.de package: eggdrop - 1.6.18-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libdns.so.21 package: eggdrop - 1.6.18-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libdns.so.21()(64bit) package: eggdrop - 1.6.18-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libdns.so.21 From peter at thecodergeek.com Mon Oct 16 19:23:06 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 16 Oct 2006 12:23:06 -0700 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-16 In-Reply-To: <20061016191007.8590.38637@extras64.linux.duke.edu> References: <20061016191007.8590.38637@extras64.linux.duke.edu> Message-ID: <4533DC1A.7060502@thecodergeek.com> Fedora Extras repoclosure wrote: > ====================================================================== > New report for: peter AT thecodergeek.com > > package: scribes - 0.2.9.87-3.fc6.noarch from fedora-extras-development-ppc > unresolved deps: > python-psyco > > package: scribes - 0.2.9.87-3.fc6.noarch from fedora-extras-development-x86_64 > unresolved deps: > python-psyco > Oh poop. I completely forgot for a moment that Pysco was x86-only. Sorry about that. I've put that as an %ifarch conditional in 0.2.9.87-4, and that's currently running on the build system. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Mon Oct 16 20:16:51 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Oct 2006 15:16:51 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061016063518.GA2339@free.fr> (Patrice Dumas's message of "Mon, 16 Oct 2006 08:35:18 +0200") References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> In any case there is one maintainer who has the final word, isn't PD> it? Only by agreement, though. There is no infrastructure in place to enforce anything like this. Which is the entirety of my original point: let the arrangements surrounding each package be determined by those involved in the maintenance of that package. You originally said that you did not think upstream developers should be allowed to be "primary maintainers". Going back to that first reply: ----- PD> After some thinking and looking at some packages, I came to the PD> conclusion that having upstream as primary maintainer in fedora PD> should be avoided if possible. ----- I object to this as a general rule. Not only is there no way to enforce this except by agreement, but it is simply not possible to reasonably make that generalization and I also find it to take a rather dim view of the potentially enormous contributions which could be made by upstream developers if we could only get them interested. Let the maintenance of individual packages be dictated by the maintainers of those packages in the way that best suits the situation. So, is there anyone interested in co-maintaining libssa, or one of the other packages from upstream developers awaiting sponsorship? (I think Kevin/nirik has a list of those somewhere; perhaps he'd be so kind as to post it.) - J< From tcallawa at redhat.com Mon Oct 16 22:18:50 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 16 Oct 2006 17:18:50 -0500 Subject: Advice on rpath In-Reply-To: <1160703809.2619.589.camel@localhost.localdomain> References: <20061011212110.GB23049@free.fr> <452E4B50.5010507@hhs.nl> <1160703809.2619.589.camel@localhost.localdomain> Message-ID: <1161037130.14932.129.camel@localhost.localdomain> On Thu, 2006-10-12 at 20:43 -0500, Tom 'spot' Callaway wrote: > On Thu, 2006-10-12 at 23:37 +0200, Linus Walleij wrote: > > On Thu, 12 Oct 2006, Hans de Goede wrote: > > > > > Why, all that is need is adding the following 2 lines to the spec after > > > %configure (...) > > > > You're right Hans, as always... > > > > Given all the stir rpath is causing, can we perhaps put a few words on it > > in the packaging guidelines, "no rpath, thanks, and here's why and how" > > type of text. spot, you own that doc, what do you say? > > Seems like a lot of solid logic to me. I'll write it up and add it as > soon as I'm back on the ground and conscious. Added an rpath section to PackagingGuidelines. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jthorne at layer7tech.com Mon Oct 16 22:49:32 2006 From: jthorne at layer7tech.com (Jay Thorne) Date: Mon, 16 Oct 2006 15:49:32 -0700 Subject: Is there any reason amarok is no longer in the fc5 yum listing Message-ID: <1161038972.5573.18.camel@bones.l7tech.com> But its in the directories for fc5 updates just fine. -- Jay W Thorne, Development Manager, Layer 7 t: 604 681 9377 x 228 From paul at xelerance.com Tue Oct 17 04:28:31 2006 From: paul at xelerance.com (Paul Wouters) Date: Tue, 17 Oct 2006 06:28:31 +0200 (CEST) Subject: not in fedorabugs group, so i can't assign FE-REVIEW's to me Message-ID: Hi, I think that my old paul at xtdnet.nl bugzilla account might be in the 'fedorabugs' instead of paul at xelerance.com, so I cannot assign FE-REVIEW to myself. Is there someone who can update this for me? Thanks, Paul From tibbs at math.uh.edu Tue Oct 17 04:32:37 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Oct 2006 23:32:37 -0500 Subject: not in fedorabugs group, so i can't assign FE-REVIEW's to me In-Reply-To: (Paul Wouters's message of "Tue, 17 Oct 2006 06:28:31 +0200 (CEST)") References: Message-ID: >>>>> "PW" == Paul Wouters writes: PW> I think that my old paul at xtdnet.nl bugzilla account might be in PW> the 'fedorabugs' instead of paul at xelerance.com, so I cannot assign PW> FE-REVIEW to myself. Is there someone who can update this for me? What's your ID in the Fedora account system? (stupid list reply-to; sorry) - J< From tibbs at math.uh.edu Tue Oct 17 04:40:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Oct 2006 23:40:18 -0500 Subject: not in fedorabugs group, so i can't assign FE-REVIEW's to me In-Reply-To: (Jason L. Tibbitts, III's message of "Mon, 16 Oct 2006 23:32:37 -0500") References: Message-ID: OK, it looks like it's "paul", and as far as I can tell, the email address is the one you prefer but you have not applied for fedorabugs access. Do so and I'll approve it. (This goes for anyone else: if you have cvsextras access, you are welcome to apply for fedorabugs access so that you can assign tickets to yourself. Perhaps for doing much-needed reviews.) - J< From wtogami at redhat.com Tue Oct 17 06:22:51 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 17 Oct 2006 15:22:51 +0900 Subject: Last warning don't modify my packages!!! In-Reply-To: <452FAAD8.6060802@theholbrooks.org> References: <452E2E19.8000600@gmx.net> <452E364B.1040408@leemhuis.info> <452F2602.5080806@redhat.com> <452FAAD8.6060802@theholbrooks.org> Message-ID: <453476BB.4020802@redhat.com> Brandon Holbrook wrote: > Christopher Stone wrote: >> On 10/12/06, Warren Togami wrote: >> >> I am seriously tempted to just modify Frank's package so he will quit >> Fedora. Perhaps we will be better off. LOL! ;-) I am a little offended that misquoting has misattributed this quote to me. I find this attitude to be unnecessarily disrespectful. While the original problem was clearly an error, it was not necessary to further poke fun in this way. Warren Togami wtogami at redhat.com From sankarshan.mukhopadhyay at gmail.com Tue Oct 17 09:42:15 2006 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Tue, 17 Oct 2006 15:12:15 +0530 Subject: Desktop drapes: GNOME wallpaper manager In-Reply-To: <452F7396.7080203@fedoraproject.org> References: <452F3A9F.8060803@gmail.com> <452F7396.7080203@fedoraproject.org> Message-ID: <4534A577.6060002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > There is a similar package at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210467 Hmm.. although I must say that the description "This tool enables your Gnome desktop to have different wallpapers for different workspaces or virtual desktops." is kind of ambiguous. Thanks for the pointer :Sankarshan - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFNKV3XQZpNTcrCzMRAqUqAJ0U4Yku4TI5g2UTTBzQ4aFjpT6QKgCfVBYi Xz512JRG2pgpl2NiV0i2psQ= =xxnm -----END PGP SIGNATURE----- From seg at haxxed.com Tue Oct 17 10:32:35 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 17 Oct 2006 05:32:35 -0500 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <45333A2C.3060703@hhs.nl> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> Message-ID: <1161081156.8931.29.camel@localhost.localdomain> On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote: > What I was trying to say with the above message is that if someone else > is willing to have the discussion for a package here and if the outcome > is that the package is ok for Extras then I'm more then happy to move it > to Extras including putting it through review (again as all packages in > dribble are already reviewed). I'll do it! (I used various Atari STs from 1987 to 1997...) On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote: > I believe the rule of thumb here is that if we have freely > redistributable "data" that runs on these emulators, we can include the > emulator in extras. In other words, the question to ask yourself, is > there any legal and Free software uses for the emulators? Since there's GPL ROMs available[1], and the commonly used FreeMiNT kernel is apparently a mix of GPL and BSD[2], and most anything open source has been ported, and even packaged into RPMs[3], seems to me any Atari ST series emulator should be okay in Extras. ARAnyM can even run Linux/68k[4]. Anyone disagree? Do we need a FESCo blessing? [1] http://emutos.sourceforge.net/en/index.htm [2] http://sparemint.atariforge.net/cgi-bin/cvsweb/freemint/COPYING?rev=1.2&content-type=text/x-cvsweb-markup [3] http://sparemint.atariforge.net/sparemint/ [4] http://wiki.aranym.org/manual#linuxm68k_on_aranym -------------- 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 Tue Oct 17 15:08:47 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 17 Oct 2006 10:08:47 -0500 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1161081156.8931.29.camel@localhost.localdomain> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> Message-ID: <1161097727.3997.34.camel@localhost.localdomain> On Tue, 2006-10-17 at 05:32 -0500, Callum Lerwick wrote: > On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote: > > What I was trying to say with the above message is that if someone else > > is willing to have the discussion for a package here and if the outcome > > is that the package is ok for Extras then I'm more then happy to move it > > to Extras including putting it through review (again as all packages in > > dribble are already reviewed). > > I'll do it! (I used various Atari STs from 1987 to 1997...) > > On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote: > > I believe the rule of thumb here is that if we have freely > > redistributable "data" that runs on these emulators, we can include the > > emulator in extras. In other words, the question to ask yourself, is > > there any legal and Free software uses for the emulators? > > > Since there's GPL ROMs available[1], and the commonly used FreeMiNT > kernel is apparently a mix of GPL and BSD[2], and most anything open > source has been ported, and even packaged into RPMs[3], seems to me any > Atari ST series emulator should be okay in Extras. ARAnyM can even run > Linux/68k[4]. > > Anyone disagree? Do we need a FESCo blessing? No disagreement here. This is fine for Fedora. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From a.badger at gmail.com Tue Oct 17 15:35:09 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 17 Oct 2006 08:35:09 -0700 Subject: Meeting Summary 10-12-2006 Message-ID: <1161099309.8507.1.camel@localhost> = 2006 October 12 FESCo Meeting = Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings == Attending == * thl * bpepple * abadger1999 * tibbs * rdieter * scop * dgilmore (late) * jwb (late) == Summary == === Mass Rebuild === * All done. === EPEL === * Branching of the CVS Repository is waiting on jeremy to have time. === Packaging Committee Report === * Ruby Provides should now be versioned like so: "Provides: ruby(Foo) = Version" * Alternative method to disable GConf schema install "%configure --disable-schemas-install" * Packages must not modify anything outside of %buildroot, %_builddir, and temporary locations (/tmp /var/tmp $TMPDIR %{_tmppath}) === FESCo Summaries === * Last two meetings weren't completed. thl has posted logs. Thanks thl! === Approve kmods === * zaptel is waiting on upstream to get a chance to discuss it. === New Extras Policy === * A package that's been orphaned for more than three months must be re-reviewed on resubmission. === comps.xml === * Waiting on jeremy. * jeremy has to get FC6 out the door before he has time to work on other things. === Misc === ==== Multiply owned directories script ==== * Could checkin to status-report-scripts on http://cvs.fedora.redhat.com/viewcvs/?root=fedora or could wait until the new VCS. ==== Maintainer Responsibility: Fixing other People's Packages ==== * For the specific case of nas, rdieter did the right thing. * Communication is necessary before fixing things in others packages. * A bugzilla bug is the best way to satisfy that requirement. * Sponsors and other trusted people could perhaps fix things in cvs and ask the maintainer to rebuild. If there's no reply by a certain time, the non-maintainers can build. * There should be a list of these "trusted people" somewhere. * Changes should be limited to what is necessary to fix the problem at hand, not cleaning up the aesthetics of the spec file. === Maintainer Responsibility: How Long to Maintain === * http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy * Would be better for people to add their arguments to the wiki page rather than scattered around the mailing list. * How many releases does Extras support is the fundamental question. Two popular possibilities: 1. As long as Core including Legacy 2. As long as Core excluding Legacy (or on a per package basis once it hits Legacy) * The end user experience is better if everything is supported in the same way for the same length of time. * Packagers should have a say in how long they have to support a package for. * Core officially does not support legacy releases; instead The Legacy Project does that. One way of looking at it is that Extras should not officially support legacy releases either, some other Fedora sub-project should. * If a package is orphaned in legacy releases it would be marked unmaintained (and available for orphaned pickup). * We cannot "force" maintainers to maintain for legacy releases. If there is not massive buy-in from the Extras maintainers, it won't work to require them to fix things for legacy releases. * Supporting legacy releases is hard work that takes away from work that could be done on the current release instead. * The Legacy Project feels too overworked to try supporting Extras as well. But if Legacy has problems attracting manpower is Extras any better equipped to motivate people to do it or is supporting legacy releases so unglamorous that we won't be able to get people interested in doing it either. * If maintainers may or may not support their packages on legacy releases we need a flag to tell which packages are not supported. Proposals: * Revive tibbs's idea to place a file in the CVS repository (similar to dead.package). * Have maintainers reassign bug reports to the security Response Team mailing list if they are not going to deal with them on legacy releases. * Would be great to automate this but that might have to wait for the packageDB. * Reassign bugs to an FEN-orphan user when the package goes Legacy and the maintainer isn't going to maintain it for those releases. * The Security Team doesn't want to have all Legacy work dumped on them but may be willing to work on some packages and maintainers interested in Legacy work on others. * Possibly Extras on legacy releases (and Core Legacy?) could cherrypick releases to support. Like FE3 and FE5 but skip FE4. Should be brought up with f13 and the Legacy Project folks to see what they think about it. ==== EVR Problems ==== * To ensure packages upgrade successfully when FC6 comes out, EVR's listed in the daily mailing list report need to be fixed before the release. == Log == {{{ (10:00:30) thl has changed the topic to: FESCO Meeting -- init (10:00:50) thl: hi everybody; who's around? how long will the packaging committee meeting last? (10:00:56) ***bpepple is here. (10:01:38) ***abadger1999 is here (10:01:51) ***mmcgrath is here (10:01:59) tibbs: packaging committee is just wrapping up. (10:02:05) ***rdieter is here (10:02:38) thl has changed the topic to: FESCO Meeting -- M{ae}ss-Rebuild (10:02:43) thl: let's start slowly (10:03:00) thl: I think we can consider the M{ae}ss-Rebuild finished? scop? (10:03:38) ***scop arrives (10:03:42) scop: yep (10:04:09) thl: k, I'll remove it from the shedule soon (10:04:20) thl has changed the topic to: FESCO Meeting -- Enterprise Extras (10:04:40) thl: branching in CVS and the initial stepps couldn't start (10:04:45) mmcgrath: any word on that? (10:04:48) mmcgrath: I haven't heard anything. (10:05:15) thl: there are some things that need to be sorted out first (10:05:30) mmcgrath: got'cha (10:05:33) thl: mmcgrath, yes, I got in contact with jeremy today; we'll sorting this out (10:05:43) mmcgrath: danke (10:05:52) mmcgrath: so for now should I just wait to hear back from you? (10:05:52) thl: I hope that will get solved quickly (10:06:05) thl: so I assume there isn't anything else to discuss now (10:06:08) thl: mmcgrath, yes (10:06:18) ***thl will move on soon (10:06:39) thl has changed the topic to: FESCO Meeting -- Use comps.xml properly (10:06:49) thl: dgilmore, no progress? (10:07:02) thl: I'll move that down on the schedule (10:07:17) thl has changed the topic to: FESCO Meeting -- Packaging Committee Report (10:07:25) thl: scop, abadger1999, tibbs ? (10:07:27) tibbs: Actual progress! (10:07:37) abadger1999: :-) (10:08:20) scop: Provides: ruby(something) to be changed to Provides: ruby(something) = VERSION (10:08:40) tibbs: Sorry, I'm furiously scrolling back. (10:08:52) scop: alternative way to disable gconf schema install being added to scriptletsnippets (--disable-$something, I forgot) (10:09:20) scop: consider it an error if a package build modifies something outside of %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) (10:09:41) bpepple: scop: --disable-schemas-install (10:09:49) scop: bpepple, thanks (10:09:56) scop: that's it unless I forgot something (10:10:00) ***nirik suggests someone mail the list of changes (perhaps with links to wiki pages where they changed) to the extras list? (10:10:13) bpepple: nirik: +1 (10:10:17) thl: nirik +1 (10:10:17) tibbs: Yes, this will be done. (10:10:32) tibbs: But we only finished voting something like two minutes ago. (10:10:43) thl: btw, there were no summaries from the past two FESCo meetings either iirc :-/ (10:10:58) jima: if anyone needs logs, i have them. (10:11:07) abadger1999: Hmm.. Warren was grabbing the one two ago. (10:11:21) thl: abadger1999, can you write todays log again? (10:11:28) thl: abadger1999, I'll put the other two in the wiki (10:11:31) abadger1999: I can get last weeks (just finishing a busy two weeks) (10:11:41) devrimgunduz [n=Devrim] entered the room. (10:11:43) abadger1999: thl: Or you can get last weeks :-) (10:11:46) rdieter: Last thing voted on in packaging: (10:11:48) abadger1999: yes I can start again (10:11:49) rdieter: Build scripts of packages (%prep, %build, %install and %check) may only alter files under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) (10:12:02) thl: abadger1999, start with today (10:12:17) abadger1999: thl: k (10:12:33) thl: I'll put the old two in the wiki without summaries -- if someone writes them good, if not, well, that sucks, but that's life now and then (10:12:52) thl has changed the topic to: FESCO Meeting -- approve kmod's (10:13:05) thl: I think we postpone zaptel even more (10:13:11) thl: two further weeks? (10:13:11) bpepple: thl: +1 (10:13:19) thl: nirik ? (10:13:22) nirik: yeah, at least until after they have a chance to talk about it internally... (10:13:38) rdieter: thl: +1 (10:13:41) nphilipp left the room (quit: "Leaving"). (10:13:46) thl: I got no other request for kmods in extras (10:13:50) thl: so let's move on (10:14:03) scop: one thing related to kmods (10:14:14) ***thl waits (10:14:14) scop: the thinkpad stuff may be resurrected soonish (10:14:34) scop: a couple of people have pinged me about them, but no progress so far due to time constraints (10:14:59) scop: do we want to re-evaluate/review it, or is it just a matter of unorphaning? (10:15:14) scop: (it = thinkpad-kmod*) (10:15:20) thl: hmmmm (10:15:42) thl: good question; what do we enforce normally for packages that are orphaned? re-review iirc (10:15:52) scop: nope (10:15:56) drpixel [n=drpixel] entered the room. (10:16:02) abadger1999: Normal is just unorphan (10:16:43) rdieter: +1 for normal unorphan process (10:16:45) scop: thinkpad stuff is more than orphaned though, IIRC it hasn't been shipped in a long time (10:16:49) ***thl wonders if we shound at least re-review packages if they are orphaned for a long time (10:16:49) jima: isn't a re-review a good idea if there's a big version jump involved? (10:17:03) rdieter: ok, good point. (10:17:11) bpepple: I think a re-review would be a good thing. (10:17:12) scop: I'm afraid in this case there's not a big jump (10:17:16) abadger1999: jima: It is. So far we've left it up to the new packager to decide.... (10:17:26) ***jima nods (10:17:30) thl: re-review for packages that are orhaned for more than 3 month? (10:17:37) thl: months (10:17:49) abadger1999: What if there's been only a bugfix release in that time? (10:18:00) abadger1999: release(s) (10:18:09) scop: actually, it may be that the thinkpad stuff has *never* been shipped in FE (10:18:12) rdieter: then the (re)review should be easy. (: (10:18:17) abadger1999: :-) (10:18:21) scop: so definitely a re-review for it (10:18:21) thl: abadger1999, well, we need to set a point somewhere; I think 3 months are fair (10:18:27) ***jima was thinking the same thing as rdieter (10:18:39) bpepple: thl: +1, sounds good. (10:18:39) abadger1999: We could base off of upstream release version instead (10:18:56) rdieter: +1 for cutoff, 3 mos sounds reasonable (10:18:59) abadger1999: (Just an alternative. I don't care either way.) (10:19:19) tibbs: I think everything should get re-reviewed periodically, but I know we don't have the manpower for it. (10:19:35) thl: so once again: re-review after 3 moths orphaned: +1 (10:19:38) tibbs: I think three months is reasonable for an orphaned package. (10:19:40) tibbs: +1 (10:19:44) abadger1999: +1 (10:19:45) scop: 3months++ (10:20:36) thl: btw, this brings us to a another point: is this FESCo area? OR PAckaging Committee? (10:20:47) scop: fesco (10:20:52) tibbs: This is fesco policy. (10:20:57) thl: btw, no one yelled, so I consider 3 months settled (10:21:32) thl: agreed; but some Extras policys live in the Packaging/ part of the wiki (10:21:45) thl: should we change that to make such stuff more clear? (10:22:21) thl: or do we simply continue to ignore it? (10:22:31) scop: thl, do you have some specific examples in mind? (10:22:50) thl: scop, no, just an impression I got (10:23:09) thl: let's forget about it (10:23:12) thl: and move on (10:23:22) dgilmore: sorry im late (10:23:35) thl has changed the topic to: FESCO Meeting -- misc (10:23:55) scop: yep (I think Packaging/ is fairly well clear of Extras specifics) (10:23:56) thl: dgilmore, any news on the comps stuff? (10:24:12) dgilmore: thl: not yet i need to get some of jeremy's time (10:24:20) thl: k (10:24:40) jeremy: dgilmore: hopefully, my time starts to exist again the beginning of the week (10:24:46) thl: so, where to continue? (10:24:50) ***rdieter feels a bit sorry for Jeremy these days. (10:24:58) thl: we visited all the important point on the schedule (10:25:03) dgilmore: jeremy: :) (10:25:21) thl: we still have the AWOL enhancement (10:25:22) thl: http://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers?action=recall&rev=2 (10:25:31) jeremy: speaking of the beginning of next week, my current thinking is to do the extras branch dance then. I'll send mail when I have a more firm date (10:25:39) thl: but I suspect nearly nobody knows the details (10:25:46) thl: so let's look at it next week (10:25:56) thl: jeremy, thx (10:26:08) dgilmore: jeremy: cool i have all the buildsys stuff mostly ready to go just waiting on cvs branching (10:26:17) thl: jeremy, some people want to build some stuff after the branch dance and before FC6 release (10:26:30) thl: jeremy, so early Monday would be really a good time (10:26:42) jeremy: thl: for fc6 or devel? (10:26:45) thl: and the mirrors need time to sync, too (10:26:57) thl: jeremy, they want to build stuff for fc6 iirc (10:27:23) scop: yep, things like smart and apt config packages (10:27:24) jeremy: thl: okay. since there won't be a "new" rawhide until probably the day after fc6 availability (maybe day of. we'll see how coordinated I can get :) (10:27:43) tibbs: I would like to get the bits for generating the multiply owned and unowned directory reports checked in somewhere. (10:28:14) jeremy: dgilmore: I'll try to sync with you about the buildsys stuff later this afternoon. /me is multiple meeting'ing at the moment tibbs tibbs|h (10:28:29) thl: tibbs, http://cvs.fedora.redhat.com/viewcvs/?root=fedora ? (10:28:42) dgilmore: jeremy: :) ping me when you have time (10:29:05) thl: tibbs, there all those stuff live afaics (10:29:10) abadger1999: tibbs: that would be the place. Do any of those projects look like the right place? (10:29:38) abadger1999: Or do you need a new project in there? (10:29:50) Eitch left the room (quit: Remote closed the connection). (10:30:00) tibbs: Hmm, it doesn't really fit into any of those, but a generic tools directory might not be a bad idea. (10:30:01) Eitch [n=hugo] entered the room. (10:30:12) tibbs: Unfortunately there's already a 'tools' module under fedora-security. (10:30:29) tibbs: That confused me a bit. The structure isn't completely regular. (10:30:36) abadger1999: I was thinking maybe status-report-scripts (10:30:47) scop: my .02?: just drop it somewhere in the "fedora" root, and let's see about reorganizing if/when the scm changes sometime (10:30:54) thl: scop, +1 (10:31:00) bpepple: scop: +1 (10:31:39) dgilmore: +1 (10:31:48) thl: k, seems settled (10:32:03) thl: so where to continue today? (10:32:03) sylvinus left the room (quit: Remote closed the connection). (10:32:08) thl: Comaintainership (10:32:13) thl: Package Database (10:32:20) thl: Feature support in Extras (10:32:27) thl: MISC -long term (10:32:30) bpepple: Maintainer Responsibilities? (10:32:39) thl: "If there's something to be fixed and someone wants to fix it, then fix, it" (10:33:10) thl has changed the topic to: FESCO Meeting -- Maintainer Responsibilities (10:33:12) abadger1999: But what about if there's something to fix and no one wants to fix it? (10:33:29) dgilmore: abadger1999: find someone to fix it (10:33:34) thl: Proposal (from the wiki): Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight. (10:33:41) dgilmore: i think rdieter did the right thing with nas (10:33:48) scop: me too (10:33:50) bpepple: dgilmore: +1 (10:33:59) thl has changed the topic to: FESCO Meeting -- If there's something to be fixed and someone wants to fix it, then fix, it (10:34:10) thl: yes, rdieter did the right thing (10:34:14) ***nirik thinks communication is very important... people shouldn't just go update/fix something without talking to the maintainer... there might be some reason they haven't yet done so. (10:34:17) ***jima (rabble) agrees (10:34:35) jima: nirik: that should have been addressed on the open bug. (10:34:43) bpepple: nirik: I agree. As long as they try to contact the maintainer I have no problem with it. (10:34:44) nirik: yes. Agreed. (10:34:51) schlobinux left the room (quit: "Leaving."). (10:35:14) jima: nirik: but yes, as (someone?) said on the list, there should have been a best-effort attempt to contact the owner (which there was). (10:35:19) nirik: I think we want to make sure not to say: "go to town and fix whatever you like in any package without talking to the maintainer" (10:35:19) thl: I don't think each and everything has to go trough the maintainer/bugzilla (10:35:23) dgilmore: bugzilla is the most appropritae place for communications whith package issues if a maintainer does nothing due to whatever reasons then things are covered (10:35:45) bpepple: dgilmore: +1 (10:35:57) thl: I'd really like to see something like this: sponsors and opther trusted people are check in changes and ask the maintainer to build them (10:36:10) dgilmore: maintainers should ensure they get bugzilla mail (10:36:16) rdieter: dgilmore: +1 (10:36:56) jima: thl: or co-maintainers can kick off builds? (10:36:58) thl: s/are check/are free to check/ (10:37:15) rdieter: co-maintainers: +1 (10:37:20) jwb: +1 (10:37:21) thl: jima, co-maintainership is the proper framework to solve this problem imho (10:37:24) ***jwb has been here for a while (10:37:30) dgilmore: thl sure but if a maintainer has made no response then trusted person should build (10:37:42) thl: dgilmore, agreed (10:37:44) bpepple: dgilmore: +1 (10:37:48) nirik: yeah, co-maintainership would be great... basically sponsors and other trusted people are co-maintainers to all packages. ;) (10:38:12) dgilmore: nirik: yup (10:38:33) thl: well, I'll try to write down an easy policy that we can use until co-maintianership is in place (10:38:38) nirik: I just want to make sure we don't get people rushing into changes on packages they don't know much about... (10:39:15) thl: anything else regardingthis topic? (10:39:23) delero: one reservation: "sponsors and other trusted people" limit their changes to things that are well agreed upon. i.e. dont fix things considered somewhat controversial (like the rpath issue) (10:39:37) thl: delero, agreed (10:40:03) ***rdieter didn't know rpath was controversial. (10:40:12) abadger1999: neither did I... (10:40:19) delero: rdieter: it's not, but not everyone agrees on the perfect way to fix it (10:40:22) ***thl would like to get rid of somewhat controversial (like the rpath issue) (10:40:30) nirik: there should also be a list of "sponsors and other trusted people" if there is going to be a policy allowing them to do things. ;) (10:40:31) ***thl would like to get rid of rpath's (10:40:34) dgilmore: rdieter: it shouldnt be there should be no use of it (10:40:51) scop: anyway, changes done by others should be limited to absolute minimum in order to fix the problem at hand, no while-at-it stuff (10:41:07) ***nirik agrees with scop (10:41:07) thl: let's stop here (10:41:07) abadger1999: scop: +1 (10:41:10) tibbs: It's all about common courtesy. (10:41:13) thl: I'll write something up (10:41:15) rdieter: and common-sense. (10:41:15) tibbs: We shouldn't try to overlegislate. (10:41:20) thl: and we can discus sit in the next meeting (10:41:34) ***thl types to fast today (10:41:34) bpepple: thl: sounds good. (10:41:47) scop: thl missed the "h" (10:42:01) abadger1999: thl: what about the other side of Maintainer Responsibility:: http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy (10:42:22) thl has changed the topic to: FESCO Meeting -- Maintainer Responsibilities (10:42:28) thl: scop, ;) (10:42:30) tibbs: Everyone is still welcome to add their arguments to that page. (10:42:53) thl: tibbs, I think that's really needed before we can discuss this further (10:43:15) thl: but I think we shound't mix those two things to much (10:43:26) thl: only where it's needed (10:43:38) abadger1999: I can add to the page, but I've also sent my arguments to the mailing list... (10:43:48) abadger1999: thl: I agree. They are two separate issues. (10:44:16) thl: well, then this is your homework for the next week: work on http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy so we have something to discuss next week (10:44:30) abadger1999: thl: :-) Will do (10:44:34) rdieter: is this going to be on the test? (10:44:38) thl: that'S probably better then taking here now (10:44:42) thl: rdieter, no ;-) (10:44:55) thl: rdieter, but well, I'd really like if more poeple could partipiate in the wiki (10:45:14) tibbs: We are really going to have to sit down and decide how many releases extras supports. It is an absolutely fundamental question. (10:45:21) thl: so we all know the same basics when we discuss stuff in the meetings tibbs tibbs|h (10:45:32) thl: mailing list discussions are also important (10:45:41) thl: but stuff get's lost in the noise there quickly (10:45:52) thl: that's why I think these pages in the wiki are imporatant (10:45:52) abadger1999: tibbs: I definitely agree. (10:46:01) jwb: tibbs, what exactly do you mean? (10:46:15) thl: tibbs, there IMHO is not much to discuss (10:46:25) thl: tibbs, I think we have to maintain it as long as core (10:46:29) thl: inkluding legacy (10:46:33) tibbs: jwb: "How long to maintain?" in the wiki page under discussion. (10:46:45) thl: especially as "core and extras" will merge soon (as everybody says) (10:46:54) abadger1999: thl: I very strongly dissent. (10:46:55) tibbs: Well, it's the "including legacy" part that some seem to disagree with. (10:46:57) jwb: thl, that's exactly what i thought too (10:47:27) scop: I disagree with "including legacy" too (10:47:40) tibbs: "including legacy" is what was told to me when I first signed on. I was unaware until recently that there were dissenting opinions there. (10:47:41) abadger1999: thl: If Core and Extras merge, then legacy would take over Extras legacy as well (j/k) (10:47:49) dgilmore: we owe it to the users to support until end of legacy (10:47:52) bpepple: I disagree with "including legacy" also. (10:48:24) abadger1999: We owe it to the packagers to give them the choice (10:48:25) tibbs: The problem is, if extras really isn't a second class citizen, it needs to not act like it and actually support the full release timeline. (10:48:29) thl: hey, a really controversial topic :) (10:48:37) abadger1999: thl: Yep ;-) (10:48:40) Eitch left the room (quit: Read error: 60 (Operation timed out)). (10:48:49) bpepple: abadger1999: +1 (10:48:52) thl: abadger1999, we need the pacakge database for it IMHO (10:48:54) cweyl: abadger1999++. let the packagers choose. (10:48:55) rdieter: There's a *reason* why core (officially) dropped legacy support, and why the legacy team was created. (10:49:36) nirik: if someone chooses not to maintain their packages for legacy, then what? they are deleted? people who have it installed are out of luck? (10:49:58) rdieter: not deleted, effectively unmaintained though. (10:50:19) thl: rdieter, that's IMHO not a big problem as long as security stuff get's fixed (10:50:33) jwb: it makes the packages available under orphans too (10:50:34) tibbs: And who is going to do that if the maintainer won't bother? (10:50:39) jwb: someone else (10:50:46) thl: and security fixes are not needed that often (10:50:58) thl: tibbs, the security sig can jump in (10:50:59) rdieter: doesn't matter really, the issue is the same, core doesn't support legacy releases, neither should Extras (officially) (10:51:38) nirik: there are currently 24 open/new/assisgned bugs against fc3 extras packages... and 72 against fc4. (10:51:39) thl: rdieter, well, we IMHO need to maintain a common look and feel to the outside (10:51:40) abadger1999: nirik: That's part of the question. Do we have Extras Legacy to pick up those pieces? Are they simply orphaned? Do we "force" (and how exactly do we do that?) the primary maintainers to fix the Legacy releases as well? (10:51:40) rdieter: if maintainers want to help out legacy-team/project and and continue support for legacy releases, fine... (10:52:06) thl: rdieter, so either suppport all (Core and Extras) only for s short time; or both for longer (Legacy and Extras) (10:52:16) jwb: forcing anyone to do it won't work (10:52:39) rdieter: thl: yeah, Core+Extras for supported releases, legacy-team/project gets everything else. (10:52:53) thl: rdieter, they are overloaded already afaik (10:53:02) abadger1999: jwb: +1. If Extras maintainers are to do it, we need massive buy-in from them. (10:53:03) nirik: IIRC legacy doesn't want to maintain extras legacy too. (10:53:03) tibbs: Oh, sure, just try telling that to the legacy folks. (10:53:05) rdieter: right, *for a reason*. (10:53:06) thl: so this will not work and we can drop it right from the start afaics (10:53:15) rdieter: supporting legacy, frankly, sucks. (10:53:29) jwb: i think we're making this too hard (10:53:38) rdieter: and it's hard work, taking away from good work that can be done on *current* releases. (10:53:38) thl: jwb, +1 (10:53:45) bpepple: jwb: agreed. (10:53:54) tibbs: Then how to make it easy? (10:54:13) dgilmore: rdieter: but its not that time consuming here and there to fix and test a security fix (10:54:14) rdieter: imo, Easy = Extras doesn't (officially anyway) support legacy, period. (10:54:17) jwb: thl, that's the 1,000,000 dollar question (10:54:20) jwb: er, tibbs (10:54:39) ***dgilmore guesses that there are many many security bugs in extras that are unknown (10:54:43) jwb: rdieter, ok.. but nothing should _prevent_ _other_ people from doing so (10:54:51) rdieter: dgilmore: fine, if a maintainer *wants* to support/help-out legacy, fine, but it shouldn't be forced policy (imo) (10:55:02) bpepple: rdieter: +1 (10:55:05) thl: dgilmore, I thought we have security SIG to prevent that? (10:55:05) tibbs: If we're going to say that maintainers aren't expected to help maintain old releases, then there needs to be a way to indicate that. (10:55:13) dgilmore: rdieter: it should be strongly encouraged tibbs tibbs|h (10:55:25) dgilmore: thl: we do (10:55:31) tibbs: I proposed a flag in each unmaintained branch in CVS, but that was discouraged. (10:55:45) rdieter: dgilmore: +1 fine, but I oppose making legacy support mandatory/obligatory (10:55:50) gregdek_gone is now known as gregdek (10:55:52) abadger1999: tibbs: Perhaps for now we could have a mailing list that maintainers can set bugzilla reports to? (10:56:07) dgilmore: thl: im not saying just legacy extras but current also. not many of the smaller oss projects get security audits (10:56:11) jwb: abadger1999, i like that idea (10:56:17) scop: I think the security SIG is quite seriously in need of more manpower, btw, not only for legacy issues (10:56:20) abadger1999: So if I don't want to maintain FC3 but a security bug is open for that release, I reassign to that mailing list? (10:56:20) tibbs: You can't set bugzilla destinations separately per release, can you? And if you can, how do we tap into that? (10:56:24) nirik: how about reassign all bugs to a 'feN-orphan' when it goes to legacy, and then if people want to step in they can? (10:56:41) scop: s/security sig/security response team/ (10:56:52) dgilmore: scop: +1 (10:57:07) thl: nirik, I think packages in legacy supported dists don't need any bugfixes (10:57:15) thl: only in case of security issues (10:57:37) thl: and that's normally not to much work afaics (10:57:47) dgilmore: abadger1999: extras security issues should get CC'd to fedora-security-list redhat.com (10:58:24) nirik: so maintainers could close WONTFIX any bug report, if it's security they fix it, or cc the security list to look at it? (10:59:07) dgilmore: they should CC the security list and say they dont want to fix it so its known someone needs to do it (10:59:14) thl: nirik, I think that roughtly how it should work (10:59:19) rdieter: yup. tibbs tibbs|h (10:59:38) abadger1999: dgilmore, scop, tibbs: ISTR the security team didn't want to handle legacy. Is that correct? Does that apply? (11:00:06) tibbs: The point is that the security team doesn't want to be the only people doing legacy work. (11:00:15) scop: speaking for myself, *I* have no interest in legacy (11:00:20) dgilmore: abadger1999: where did you get that idea? (11:00:25) tibbs: It exists to help maintainers with security stuff. (11:00:40) thl: abadger1999, there was somebody who wanted to work in the security team to maintain FE3 (11:00:42) tibbs: Not to fix all of the security issues in Extras. (11:00:47) thl: otherwise we had EOL'ed it last june (11:00:49) rdieter: scop: I don't think many do... (including me either, frankly) (11:00:53) abadger1999: dgilmore: I guess from scop and tibbs :-) (11:00:53) dgilmore: abadger1999: im mostly intrested in legacy as far as extras goes as i support Extras for Aurora Linux (11:01:11) dgilmore: abadger1999: that is extras security (11:01:46) ***nirik sees the security list is low traffic and subscribes. (11:02:15) dgilmore: thl: it was I who wanted FE3 to continue support (11:02:22) thl: dgilmore, I know ;-) (11:02:39) thl: well, I'll try to prepare a mail on this topic and will send it to the list (11:02:47) dgilmore: but honestly i dont have alot of intrest in FE4 as Aurora doesnt have a FC-4 build (11:02:54) dgilmore: but it will have a FC6 build (11:02:55) thl: we can revisits this topic then next week (11:03:11) abadger1999: Maybe we should cherrypick releases? (11:03:31) abadger1999: FE3 is a supported legacy platform, FE4 is not? (11:03:40) abadger1999: (Would have to coordinate with regular Legacy though) (11:03:46) thl: abadger1999, that would we a good solution for core, too (11:04:11) nirik: or the suggestion on the security list of only fixing HIGH/CRITICAL vulnerabilities. (11:04:18) thl: abadger1999, let's talk with f13 about that aftger FC6 is finished (11:04:20) nirik: leaving the more minor stuff alone. (11:04:26) abadger1999: thl: k (11:05:01) thl has changed the topic to: FESCO Meeting -- fee dsicussion (11:05:11) thl: anything else we shound discuss? (11:05:15) jima: how much is the fee? (11:05:18) thl has changed the topic to: FESCO Meeting -- free dsicussion (11:05:32) thl: stupid me again :-/ (11:05:34) scop: how free is the dsicussion? (11:05:39) ***scop ducks (11:05:46) jima: scop: hey now, you're just beating a dead horse ;) (11:05:48) dgilmore: scop: as free as you want it to be (11:05:49) ***thl hits scop with a stick (11:05:53) jwb: scop, free as in speech ;) (11:05:56) ***scop screams (11:06:09) nirik: are all the EVR problems going to get fixed before fc6 is out? (11:06:12) dgilmore: scop: put some clothes on :D (11:06:35) delero: itpp approved! (11:06:50) tibbs: Are the EVR problems actually being reported to the core folks? (11:07:04) ***nirik was wondering that too. (11:07:27) nirik: mozilla at least would need to be fixed in legacy (11:07:33) tibbs: I think they probably aren't, becuase the fixes are so easy and yet haven't been done. (11:07:50) tibbs: Honestly the FC5 > FC6 ones really do need to get fixed. (11:07:54) nirik: delero: ed will be happy to hear that. ;) (11:08:24) rdieter: gotta run, lunch is calling... (11:08:26) tibbs: But I fear it's too late to fix them. (11:08:36) abadger1999: I think ?jima gave f13 heads up about the Core packages (11:08:43) thl: seem we need somebody from core that looks at the EVR problems mail now and then to poke the proper people (11:08:45) abadger1999: rdieter: See you later (11:08:58) thl: rdieter, cu (11:09:12) rdieter is now known as rdieter_away (11:09:35) jima: abadger1999: correct. (11:09:42) thl: anything else? (11:09:53) scop: it'd be nice to have a "bugger" script that would file bugs instead of/ in addition to list spams for the upgrade paths and other things (11:09:54) thl: otherwise I'd say we close the meeting for today (11:09:57) jima: err, i gave f13 a heads-up about packages tagged fc5 (11:10:08) thl: scop, that would be the best (11:10:13) jima: he resolved one of the two, last i checked. (11:10:28) dgilmore: thl: i think we are done (11:10:35) mspevack left the room (quit: "Leaving"). (11:10:36) ***thl will close the meeting in 30 (11:10:39) tibbs: scop: I could generate about 10000 bugs that way. (11:10:43) ***jima still sees perl-PDL-2.4.2-4.fc5.1.ppc.rpm (11:10:49) scop: tibbs, ;) (11:10:52) ***thl will close the meeting in 15 (11:11:08) thl: -- Mark -- Meeting end }}} -------------- 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-fedora-extras at scrye.com Tue Oct 17 18:36:32 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Tue, 17 Oct 2006 12:36:32 -0600 (MDT) Subject: Co-maintainers to assist upstreams with their packages in Extras References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> Message-ID: <20061017.123632.484476945.kevin@scrye.com> >>>>> "Jason" == Jason L Tibbitts, writes: ...snipp... Jason> So, is there anyone interested in co-maintaining libssa, or one Jason> of the other packages from upstream developers awaiting Jason> sponsorship? (I think Kevin/nirik has a list of those Jason> somewhere; perhaps he'd be so kind as to post it.) I did write up a list of all the people with review requests blocking FE-NEEDSPONSOR the other day. Mostly to figure out who I should take a closer look at to sponsor... Not sure if it's usefull to anyone, but you can find it at: http://www.scrye.com/~kevin/fedora-extras/sponsors-report-2006-10-14 There are a number of people on the list that have submitted a single package, and have had no activity adding to other reviews. Some of them are upstream for the package they have submitted. From just one package and no other activity it's very hard to decide to sponsor these people, as they may well be 'fire and forget' type submitters. 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 pertusus at free.fr Tue Oct 17 18:44:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 17 Oct 2006 20:44:34 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> Message-ID: <20061017184434.GA2478@free.fr> On Mon, Oct 16, 2006 at 03:16:51PM -0500, Jason L Tibbitts III wrote: > > Only by agreement, though. There is no infrastructure in place to > enforce anything like this. Agreed. It is just what is commonly done. > ----- > PD> After some thinking and looking at some packages, I came to the > PD> conclusion that having upstream as primary maintainer in fedora > PD> should be avoided if possible. > ----- > > I object to this as a general rule. Not only is there no way to > enforce this except by agreement, but it is simply not possible to > reasonably make that generalization and I also find it to take a > rather dim view of the potentially enormous contributions which could > be made by upstream developers if we could only get them interested. Ok, my statement was a bit too much. To state it in a more sensible manner, the extras community should really make sure that the upstream maintainers maintaining their package in fedora extras do it in a manner suitable for fedora and not with upstream objectives. -- Pat From buildsys at fedoraproject.org Tue Oct 17 20:59:41 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Oct 2006 16:59:41 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-17 Message-ID: <20061017205941.1801F15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 47 R-2.4.0-1.fc6 R-mAr-1.1-7.fc6 R-waveslim-1.5-5.fc6 R-wavethresh-2.2-5.fc6 TurboGears-1.0b1-1.fc6 abcMIDI-20061015-1.fc6 blender-2.42a-4.fc6 contact-lookup-applet-0.15-1.fc6 cpanspec-1.69.1-1.fc6 eggdrop-1.6.18-3.fc6 em8300-kmod-0.16.0-0.3.rc1.2.6.18_1.2798.fc6 gdmap-0.7.5-6.fc6 glipper-0.89-5.fc6 gnonlin-0.10.5-3 gnubiff-2.2.2-4.fc6 gossip-0.18-1.fc6 konversation-1.0.1-2.fc6 libsexymm-0.1.9-1.fc6 mISDN-0-1.cvs20061010.fc6 nethack-3.4.3-12.fc6 netlabel_tools-0.17-5.fc6 openct-0.6.9-3.fc6 openpbx-1.2-1.rc1.svn1979.fc6 perl-BerkeleyDB-0.31-2.fc6 perl-CPANPLUS-0.076-1.fc6 perl-Curses-1.15-1.fc6 perl-File-BOM-0.14-1.fc6 perl-HTML-Mason-1.34-1.fc6 php-pear-DB-QueryTool-1.0.3-1.fc6 php-pear-XML-Beautifier-1.1-1.fc6 php-pear-XML-Util-1.1.1-1.fc6 poker-engine-1.0.19-1.fc6 poker-eval-133.0-1.fc6 pygpgme-0.1-2.fc6 python-sexy-0.1.9-1.fc6 python-turbocheetah-0.9.5-5.fc6 rpy-0.4.6-13.fc6 scanbuttond-0.2.3-9.fc6 scribes-0.2.9.88-1.fc6 soundconverter-0.9.2-1.fc6 sysprof-kmod-1.0.3-5.2.6.18_1.2798.fc6 tagtool-0.12.2-9.fc6 tetex-unicode-0-7.20041017.fc6 torque-2.1.3-3.fc6 vdr-1.4.3-3.fc6 wallpapoz-0.3-1.fc6 yadex-1.7.0-6.fc6 Packages built and released for Fedora Extras 5: 21 OpenEXR-1.2.2-8.fc5 R-2.4.0-1.fc5 R-mAr-1.1-7.fc5 R-waveslim-1.5-5.fc5 R-wavethresh-2.2-5.fc5 abcMIDI-20061015-1.1.fc5 blender-2.42a-4.fc5 cpanspec-1.69.1-1.fc5 eggdrop-1.6.18-3.fc5 konversation-1.0.1-2.fc5 libctl-3.0.2-4.fc5 mantis-1.0.5-1.fc5.1 nethack-3.4.3-10.fc5 poker-engine-1.0.19-1.fc5 poker-eval-133.0-1.fc5 rpy-0.4.6-13.fc5 soundconverter-0.9.2-1.fc5 tetex-unicode-0-7.20041017.fc5 vdr-1.4.3-3.fc5 yadex-1.7.0-5.fc5 zaptel-1.4.0-2.fc5.beta1 Packages built and released for Fedora Extras 4: 8 OpenEXR-1.2.2-8.fc4 R-2.4.0-1.fc4 R-mAr-1.1-7.fc4 R-waveslim-1.5-5.fc4 cpanspec-1.69.1-1.fc4 eggdrop-1.6.18-3.fc4 rpy-0.4.6-13.fc4 soundconverter-0.9.2-1.fc4 Packages built and released for Fedora Extras 3: 1 OpenEXR-1.2.2-8.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 Oct 17 21:00:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Oct 2006 17:00:12 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-17 Message-ID: <20061017210012.A94E015212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) gemi AT bluewin.ch: abcMIDI FE5 > FE6 (0:20061015-1.1.fc5 > 0:20061015-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- abcMIDI: gemi AT bluewin.ch FE5 > FE6 (0:20061015-1.1.fc5 > 0:20061015-1.fc6) anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From buildsys at fedoraproject.org Tue Oct 17 21:40:43 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 17 Oct 2006 21:40:43 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-17 Message-ID: <20061017214043.23137.97514@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (17 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (17 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (17 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (32 days) plague - 0.4.4.1-2.fc3.noarch (32 days) plague - 0.4.4.1-2.fc4.noarch (32 days) plague - 0.4.4.1-2.fc4.noarch (32 days) plague - 0.4.4.1-2.fc4.noarch (32 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (8 days) linphone - 1.2.0-4.fc5.ppc (8 days) linphone - 1.2.0-4.fc5.x86_64 (8 days) linphone - 1.2.0-7.fc6.i386 (8 days) linphone - 1.2.0-7.fc6.ppc (8 days) linphone - 1.2.0-7.fc6.x86_64 (8 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From wcervini at fedoraproject.org Tue Oct 17 21:42:11 2006 From: wcervini at fedoraproject.org (Walter Cervini) Date: Tue, 17 Oct 2006 17:42:11 -0400 Subject: claim for orphan packages In-Reply-To: <20061015160017.35A2273252@hormel.redhat.com> References: <20061015160017.35A2273252@hormel.redhat.com> Message-ID: <1161121331.3261.10.camel@walter.volp.org.ve> Hi Friends. My name is Walter Cervini, and i'm interesting to maintain two orphan package. Perl-Net-SSH Perl-Net-SCP I think are easy for my to maintein this packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From sodarock at gmail.com Tue Oct 17 22:02:39 2006 From: sodarock at gmail.com (John Villalovos) Date: Tue, 17 Oct 2006 15:02:39 -0700 Subject: Plague documentation? Message-ID: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> Is there any better documentation available about Plague then what is on the Wiki? I am trying to set it up and the wiki says that the README is no longer valid. So I don't really know how to set it up. I was going to try using Plague to rebuild a whole bunch of SRPMS. Any pointers would be greatly appreciated. Thanks, John From steve at silug.org Wed Oct 18 00:29:54 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 17 Oct 2006 19:29:54 -0500 Subject: claim for orphan packages In-Reply-To: <1161121331.3261.10.camel@walter.volp.org.ve> References: <20061015160017.35A2273252@hormel.redhat.com> <1161121331.3261.10.camel@walter.volp.org.ve> Message-ID: <20061018002954.GA2110@osiris.silug.org> On Tue, Oct 17, 2006 at 05:42:11PM -0400, Walter Cervini wrote: > My name is Walter Cervini, and i'm interesting to maintain two orphan > package. > Perl-Net-SSH > Perl-Net-SCP Have you already gone through the whole sponsorship/new account process? If not, you need to look here: http://fedoraproject.org/wiki/Extras/Contributors I was planning on picking up both of those so they aren't removed, but I'd be happy to play CVS proxy for you while you go through the official procedure, assuming you haven't already. (If you have, I wouldn't mind being a co-maintainer on those packages.) I'm not a sponsor, but I'm sure a track record in bugzilla would look really good for a potential sponsor... If those two packages still show up as orphaned in owners.list tomorrow, I'll take them. (I'm also going to pick up perl-Chart, perl-HTML-Template-Expr, perl-String-ShellQuote, and perl-XML-XQL if nobody beats me to them. Feel free to beat me to them. This is your last chance. :-) 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 dcbw at redhat.com Wed Oct 18 00:34:51 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 17 Oct 2006 20:34:51 -0400 Subject: Plague documentation? In-Reply-To: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> Message-ID: <1161131691.2663.0.camel@localhost.localdomain> On Tue, 2006-10-17 at 15:02 -0700, John Villalovos wrote: > Is there any better documentation available about Plague then what is > on the Wiki? > > I am trying to set it up and the wiki says that the README is no > longer valid. So I don't really know how to set it up. > > I was going to try using Plague to rebuild a whole bunch of SRPMS. > > Any pointers would be greatly appreciated. Hmm, at least for plague 0.4 the README file should be just about right. Some bits have changed for 0.5, but 0.5 isn't in Fedora Extras at all. Dan > Thanks, > John > From rvinyard at cs.nmsu.edu Wed Oct 18 03:01:35 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Tue, 17 Oct 2006 21:01:35 -0600 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061017184434.GA2478@free.fr> References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017184434.GA2478@free.fr> Message-ID: <4535990F.4070100@cs.nmsu.edu> Patrice Dumas wrote: > On Mon, Oct 16, 2006 at 03:16:51PM -0500, Jason L Tibbitts III wrote: > >> ----- >> PD> After some thinking and looking at some packages, I came to the >> PD> conclusion that having upstream as primary maintainer in fedora >> PD> should be avoided if possible. >> ----- >> >> I object to this as a general rule. Not only is there no way to >> enforce this except by agreement, but it is simply not possible to >> reasonably make that generalization and I also find it to take a >> rather dim view of the potentially enormous contributions which could >> be made by upstream developers if we could only get them interested. >> > > Ok, my statement was a bit too much. To state it in a more sensible > manner, the extras community should really make sure that the upstream > maintainers maintaining their package in fedora extras do it in a manner > suitable for fedora and not with upstream objectives. > > Call me naive, but I still don't see why you're assuming that upstream maintainers have objectives that are, in general, at odds with the Fedora project. From pertusus at free.fr Wed Oct 18 06:53:59 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 18 Oct 2006 08:53:59 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <4535990F.4070100@cs.nmsu.edu> References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017184434.GA2478@free.fr> <4535990F.4070100@cs.nmsu.edu> Message-ID: <20061018065359.GA2321@free.fr> On Tue, Oct 17, 2006 at 09:01:35PM -0600, Rick L Vinyard Jr wrote: > > > Call me naive, but I still don't see why you're assuming that upstream > maintainers have objectives that are, in general, at odds with the > Fedora project. Not in general, but it does happen. -- Pat From j.w.r.degoede at hhs.nl Wed Oct 18 08:09:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Oct 2006 10:09:03 +0200 Subject: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1161097727.3997.34.camel@localhost.localdomain> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> Message-ID: <4535E11F.7040402@hhs.nl> Tom 'spot' Callaway wrote: > On Tue, 2006-10-17 at 05:32 -0500, Callum Lerwick wrote: >> On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote: >>> What I was trying to say with the above message is that if someone else >>> is willing to have the discussion for a package here and if the outcome >>> is that the package is ok for Extras then I'm more then happy to move it >>> to Extras including putting it through review (again as all packages in >>> dribble are already reviewed). >> I'll do it! (I used various Atari STs from 1987 to 1997...) >> >> On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote: >>> I believe the rule of thumb here is that if we have freely >>> redistributable "data" that runs on these emulators, we can include the >>> emulator in extras. In other words, the question to ask yourself, is >>> there any legal and Free software uses for the emulators? >> >> Since there's GPL ROMs available[1], and the commonly used FreeMiNT >> kernel is apparently a mix of GPL and BSD[2], and most anything open >> source has been ported, and even packaged into RPMs[3], seems to me any >> Atari ST series emulator should be okay in Extras. ARAnyM can even run >> Linux/68k[4]. >> >> Anyone disagree? Do we need a FESCo blessing? > > No disagreement here. This is fine for Fedora. > Okay, I've contacted the Dribble maintainer and he will submit it to FE (as time permits he is rather busy atm). Since he isn't an FE contributer yet I'll sponsor him (he will also be packaging and submitting the GPL ROMs and FreeMiNT). Regards, Hans From giallu at gmail.com Wed Oct 18 09:09:28 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 18 Oct 2006 11:09:28 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061017.123632.484476945.kevin@scrye.com> References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017.123632.484476945.kevin@scrye.com> Message-ID: On 10/17/06, Kevin Fenzi wrote: > There are a number of people on the list that have submitted a single > package, and have had no activity adding to other reviews. Some of > them are upstream for the package they have submitted. From just one > package and no other activity it's very hard to decide to sponsor > these people, as they may well be 'fire and forget' type submitters. Despite of this, I think there is some added value in an upstream maintaner willing to work also on the packaging side. We should find a way to make sure we don't waste this value. So, it seems to me there are 2 kind of upstream maintainers: 1. those willing to be also Fedora packagers (also for their deps or other stuff) 2. those just interested in getting their package in extras The former is already covered by the current procedure (submit / find a sponsor / become contributor) For the latter, we could maintain a list (along the lines of the WishList page) where interested upstreams can add their project and look for a maintainer. Once a maintaner is found and the package imported, they could be listed as co-maintaner for the project BUT only if we can put in place a restriction to where they could commit (e.g: only whre they are listed as co-maintaners). This should not be so hard with CVS (cvs_acls) or any other SCM we may use in the future. just my 0.02 Gianluca From bugzilla at redhat.com Wed Oct 18 09:26:32 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:26:32 -0400 Subject: [Bug 166481] Review Request: ngrep - network grep In-Reply-To: Message-ID: <200610180926.k9I9QWPF001808@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: ngrep - network grep https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166481 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: network grep|Review Request: ngrep - | |network grep ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 05:26 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 09:28:13 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:28:13 -0400 Subject: [Bug 167253] Review Request: cernlib - CERN library and associated binaries In-Reply-To: Message-ID: <200610180928.k9I9SDSb001942@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: cernlib - CERN library and associated binaries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167253 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: CERN library|Review Request: cernlib - |and associated binaries |CERN library and associated | |binaries ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 05:28 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 09:31:21 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:31:21 -0400 Subject: [Bug 166481] Review Request: ngrep - network grep In-Reply-To: Message-ID: <200610180931.k9I9VLeo002287@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: ngrep - network grep https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166481 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- |fedora-package- |list at redhat.com |review 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 bugzilla at redhat.com Wed Oct 18 09:33:15 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:33:15 -0400 Subject: [Bug 167253] Review Request: cernlib - CERN library and associated binaries In-Reply-To: Message-ID: <200610180933.k9I9XFQV002520@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: cernlib - CERN library and associated binaries https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167253 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- |fedora-package- |list at redhat.com |review 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 bugzilla at redhat.com Wed Oct 18 09:41:10 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:41:10 -0400 Subject: [Bug 168032] Review Request: gnome-applet-timer - Gnome Timer Applet In-Reply-To: Message-ID: <200610180941.k9I9fAYR003490@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: gnome-applet-timer - Gnome Timer Applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168032 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: Gnome Timer |Review Request: gnome- |Applet |applet-timer - Gnome Timer | |Applet ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 05:40 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 09:42:37 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 05:42:37 -0400 Subject: [Bug 168032] Review Request: gnome-applet-timer - Gnome Timer Applet In-Reply-To: Message-ID: <200610180942.k9I9gbWZ003710@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: gnome-applet-timer - Gnome Timer Applet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168032 Christian.Iseli at licr.org 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. From triad at df.lth.se Wed Oct 18 11:18:05 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 18 Oct 2006 13:18:05 +0200 (CEST) Subject: Plague documentation? In-Reply-To: <1161131691.2663.0.camel@localhost.localdomain> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> Message-ID: On Tue, 17 Oct 2006, Dan Williams wrote: > Hmm, at least for plague 0.4 the README file should be just about right. > Some bits have changed for 0.5, but 0.5 isn't in Fedora Extras at all. Dan, what'd be nice to have a few words about in the beginning of the README would be some words about the overall concept and intended use of Plague, whether it is general to any extent or very Fedora/Red Hat-specific. Also some words sbout its history, why it was written and so on. I've been under the impression that you created Plague some while ago as a replacement for Red Hats build system which was proprietary, but I don't even know if I remember that part correctly... Linus From dcbw at redhat.com Wed Oct 18 11:57:39 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 18 Oct 2006 07:57:39 -0400 Subject: Plague documentation? In-Reply-To: References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> Message-ID: <1161172659.2767.1.camel@localhost.localdomain> On Wed, 2006-10-18 at 13:18 +0200, Linus Walleij wrote: > On Tue, 17 Oct 2006, Dan Williams wrote: > > > Hmm, at least for plague 0.4 the README file should be just about right. > > Some bits have changed for 0.5, but 0.5 isn't in Fedora Extras at all. > > Dan, what'd be nice to have a few words about in the beginning of the > README would be some words about the overall concept and intended use of > Plague, whether it is general to any extent or very Fedora/Red > Hat-specific. Good point. > Also some words sbout its history, why it was written and so on. I've been > under the impression that you created Plague some while ago as a > replacement for Red Hats build system which was proprietary, but I don't > even know if I remember that part correctly... There was some confusion about that; but it was actually created as a build system for Fedora Extras specifically, because beehive (the old RH buildsys) was on life-support and had major issues, brew wasn't ready yet, and brew wasn't necessarily appropriate for Extras at the time anyway. Dan > Linus > From bugzilla at redhat.com Wed Oct 18 12:41:47 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:41:47 -0400 Subject: [Bug 169973] Review Request: python-clientform - ClientForm In-Reply-To: Message-ID: <200610181241.k9ICflKY015428@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: python-clientform - ClientForm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169973 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: ClientForm |Review Request: python- | |clientform - ClientForm ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 08:41 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 12:42:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:42:54 -0400 Subject: [Bug 169973] Review Request: python-clientform - ClientForm In-Reply-To: Message-ID: <200610181242.k9ICgs71015483@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: python-clientform - ClientForm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169973 Christian.Iseli at licr.org 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. From bugzilla at redhat.com Wed Oct 18 12:44:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:44:45 -0400 Subject: [Bug 170995] Review Request: system-config-control - System Control Center In-Reply-To: Message-ID: <200610181244.k9ICijSA015718@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: system-config-control - System Control Center https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170995 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: System |Review Request: system- |Control Center (system- |config-control - System |config-control) |Control Center QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 08:44 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 12:51:12 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:51:12 -0400 Subject: [Bug 172428] Review Request: acpitool - A command line ACPI client for Linux In-Reply-To: Message-ID: <200610181251.k9ICpCcs016363@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: acpitool - A command line ACPI client for Linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172428 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: A command |Review Request: acpitool - A |line ACPI client for Linux |command line ACPI client for | |Linux QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 08:50 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 12:53:59 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:53:59 -0400 Subject: [Bug 172521] Review Request: tetex-tex4ht - Translates TeX and LaTeX into HTML or XML+MathML In-Reply-To: Message-ID: <200610181253.k9ICrxMe016643@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: tetex-tex4ht - Translates TeX and LaTeX into HTML or XML+MathML https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172521 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: TeX4ht - |Review Request: tetex-tex4ht |Translates TeX and LaTeX |- Translates TeX and LaTeX |into HTML or XML+MathML |into HTML or XML+MathML QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 08:53 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 12:57:17 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 08:57:17 -0400 Subject: [Bug 173368] Review Request: planet In-Reply-To: Message-ID: <200610181257.k9ICvHXo017006@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: planet https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173368 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: planetplanet|Review Request: planet QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 08:57 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:07:22 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:07:22 -0400 Subject: [Bug 174240] Review Request: artwiz-aleczapka-fonts In-Reply-To: Message-ID: <200610181307.k9ID7MSe018160@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: artwiz-aleczapka-fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174240 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: artwiz- |Review Request: artwiz- |aleczapka |aleczapka-fonts QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:07 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:09:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:09:07 -0400 Subject: [Bug 174266] Review Request: libgsf113 - GNOME Structured File library 1.13 In-Reply-To: Message-ID: <200610181309.k9ID972C018321@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: libgsf113 - GNOME Structured File library 1.13 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174266 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: GNOME |Review Request: libgsf113 - |Structured File library 1.13|GNOME Structured File | |library 1.13 QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:08 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:12:54 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:12:54 -0400 Subject: [Bug 178142] Review Request: jakarta-commons-cli - Jakarta Commons CLI In-Reply-To: Message-ID: <200610181312.k9IDCsmN018688@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: jakarta-commons-cli - Jakarta Commons CLI https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178142 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: Jakarta |Review Request: jakarta- |Commons CLI |commons-cli - Jakarta | |Commons CLI QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:12 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:14:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:14:33 -0400 Subject: [Bug 179708] Review Request: dap-freeform_handler - FreeForm data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200610181314.k9IDEXC0018806@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: dap-freeform_handler - FreeForm data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179708 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: |Review Request: dap- |freeform_handler - FreeForm |freeform_handler - FreeForm |data handler for the OPeNDAP|data handler for the OPeNDAP |Data server |Data server QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:14 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:15:45 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:15:45 -0400 Subject: [Bug 179709] Review Request: dap-hdf4_handler - HDF4 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200610181315.k9IDFjZC018903@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: dap-hdf4_handler - HDF4 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179709 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: hdf4_handler|Review Request: dap- |- HDF4 data handler for the |hdf4_handler - HDF4 data |OPeNDAP Data server |handler for the OPeNDAP Data | |server QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:15 EST ------- Normalize summary field for easy parsing -- 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 Oct 18 13:16:53 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 18 Oct 2006 09:16:53 -0400 Subject: [Bug 179710] Review Request: dap-netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server In-Reply-To: Message-ID: <200610181316.k9IDGrAf018977@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: dap-netcdf_handler - NetCDF 3 data handler for the OPeNDAP Data server https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179710 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 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: |Review Request: dap- |netcdf_handler - NetCDF 3 |netcdf_handler - NetCDF 3 |data handler for the OPeNDAP|data handler for the OPeNDAP |Data server |Data server QAContact|dkl at redhat.com |fedora-package- | |review at redhat.com CC|fedora-extras- | |list at redhat.com | ------- Additional Comments From Christian.Iseli at licr.org 2006-10-18 09:16 EST ------- Normalize summary field for easy parsing -- 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 jima at beer.tclug.org Wed Oct 18 13:42:35 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 18 Oct 2006 08:42:35 -0500 (CDT) Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017.123632.484476945.kevin@scrye.com> Message-ID: On Wed, 18 Oct 2006, Gianluca Sforna wrote: > On 10/17/06, Kevin Fenzi wrote: >> There are a number of people on the list that have submitted a single >> package, and have had no activity adding to other reviews. Some of >> them are upstream for the package they have submitted. From just one >> package and no other activity it's very hard to decide to sponsor >> these people, as they may well be 'fire and forget' type submitters. > > Despite of this, I think there is some added value in an upstream > maintaner willing to work also on the packaging side. We should find a > way to make sure we don't waste this value. > > So, it seems to me there are 2 kind of upstream maintainers: > 1. those willing to be also Fedora packagers (also for their deps or > other stuff) > 2. those just interested in getting their package in extras > > The former is already covered by the current procedure (submit / find > a sponsor / become contributor) > > For the latter, we could maintain a list (along the lines of the > WishList page) where interested upstreams can add their project and > look for a maintainer. +1, I agree with this approach. I strongly suspect Patrice was thinking more of the latter and probably not at all about the former type (of which there are clearly a few). > Once a maintaner is found and the package imported, they could be > listed as co-maintaner for the project BUT only if we can put in place > a restriction to where they could commit (e.g: only whre they are > listed as co-maintaners). > This should not be so hard with CVS (cvs_acls) or any other SCM we may > use in the future. This doesn't seem like a bad idea, but I'm not totally convinced that upstream needs CVS access in all cases. That still requires them to not make any changes to the package that would go against the Packaging Guidelines (etc), and therefore they'd need to keep track of what's in those guidelines. I can certainly understand why they might not be totally up to speed on that, if their only goal is to have their package in Extras. I don't think I'd care to memorize every distro's policies just to have my package included (and not piss them off). :-) That aside, I fully support the idea of upstream having open communication with a single (or specific group of) contributor. I'm just not so sure all of them should be making changes directly. Jima From Christian.Iseli at licr.org Wed Oct 18 13:43:48 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 18 Oct 2006 15:43:48 +0200 Subject: Noisy Bugzilla Message-ID: <20061018154348.7acd8a75@ludwig-alpha> Hi folks, Sorry for the bugzilla noise. It should be over now. C From pertusus at free.fr Wed Oct 18 14:20:38 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 18 Oct 2006 16:20:38 +0200 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017.123632.484476945.kevin@scrye.com> Message-ID: <20061018142038.GC2331@free.fr> On Wed, Oct 18, 2006 at 08:42:35AM -0500, Jima wrote: > On Wed, 18 Oct 2006, Gianluca Sforna wrote: > >For the latter, we could maintain a list (along the lines of the > >WishList page) where interested upstreams can add their project and > >look for a maintainer. > > +1, I agree with this approach. I strongly suspect Patrice was thinking > more of the latter and probably not at all about the former type (of which > there are clearly a few). Indeed, it is the kind of examples I had in mind. However I still think that anytime an upstream maintainer is also a fedora package maintainer, there is a risk that he forget the differences between both. It won't happen everytime, but we should be carefull. This danger certainly disappears for maintainers with deep involvment in extras. > This doesn't seem like a bad idea, but I'm not totally convinced that > upstream needs CVS access in all cases. That still requires them to not I agree. In my opinion what is interesting for upstream is to be in CC for the bugs (including submission), and later to communicate, but I don't think cvs access for them is needed. -- Pat From Axel.Thimm at ATrpms.net Wed Oct 18 14:56:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Oct 2006 16:56:34 +0200 Subject: Plague documentation? In-Reply-To: <1161172659.2767.1.camel@localhost.localdomain> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> <1161172659.2767.1.camel@localhost.localdomain> Message-ID: <20061018145634.GA24252@neu.nirvana> On Wed, Oct 18, 2006 at 07:57:39AM -0400, Dan Williams wrote: > There was some confusion about that; but it was actually created as a > build system for Fedora Extras specifically, because beehive (the old RH > buildsys) was on life-support and had major issues, brew wasn't ready > yet, and brew wasn't necessarily appropriate for Extras at the time > anyway. And a look into the cristal ball (aka your best guess on future development)? E.g. what will the future relation of brew and plaque be under assumption that some further integration between FC and FE will happen. Will one tool surpass the other? Or complement? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Wed Oct 18 15:01:13 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 18 Oct 2006 17:01:13 +0200 Subject: FE Package Status of Oct 18, 2006 Message-ID: <20061018170113.4ee1409a@ludwig-alpha> Hi folks, Here is the overdue package status report... I stopped using the PackagesNoLongerInDevel wiki page, and also the bzId_pkg.txt file from the UsefulScripts page. There are some more cleanup to do in BZ tickets to get a cleaner report... There's also some cleanup to be done in the comps.xml.in file wrt the section "Packages listed in comps-fe6 but not available". We also appear to miss quite a few owners.list entries... Cheers, C ---- FE Package Status of Oct 18, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2429 packages - 122 orphans - 14 packages not available in extras devel or release bdpepple at ameritech dot net galago-filesystem cweyl at alumni dot drew dot edu perl-GStreamer ed at eh3 dot com harminv fitzsim at redhat dot com MegaMek i at stingr dot net rpld matthias at rpmforge dot net SDL_pango miker5slow at grandecom dot net pekwm paul at all-the-johnsons dot co dot uk xeuphoric paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at all-the-johnsons dot co dot uk gtksharp pertusus at free dot fr ivman raven at pmail dot pl gaim-gadugadu rpm at greysector dot net oki4linux - 5 packages not available in extras devel but present in release andreas at bawue dot net ddrescue cweyl at alumni dot drew dot edu gaim-gaym gemi at bluewin dot ch TeXmacs ghenry at suretecsystems dot com john michel dot salim at gmail dot com grhino - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=203864,209870 tripwire fedora at theholbrooks.org prozilla kushaldas at gmail.com - 13 packages present in the development repo which have no owners entry SDL_Pango crossvc gtk-sharp itpp ktechlab libpaper libpri mISDN openpbx php-pecl-Fileinfo pygpgme system-switch-im toped - 25 orphaned packages, yet available in extras devel FreeWnn aspell-mi buildbot doctorj duplicity fltk gdk-pixbuf gnofract4d gnome-password-generator gnome-themes-extras gurlchecker imlib leafpad libedit lostirc pam_mount pam_mysql pam_script perl-Chart perl-Net-SCP perl-Net-SSH perl-String-ShellQuote perl-XML-XQL python-cvstoys screem - 43 packages that moved to core FE-ACCEPT packages stats: - 1451 accepted, closed package reviews - 24 accepted, closed package reviews not in repo - 12 accepted, closed package reviews not in owners - 10 accepted, open package reviews older than 4 weeks; - 7 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 85 open tickets - 19 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks - 4 closed tickets FE-NEW packages stats: - 138 open tickets - 17 tickets with no activity in eight weeks - 23 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 44 open tickets - 3 tickets with no activity in eight weeks - 3 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks - 1 tickets with no activity in four weeks OPEN-BUGS packages stats: - 248 open tickets - 102 tickets with no activity in eight weeks - 50 tickets with no activity in four weeks CVS stats: - 2429 packages with a devel directory - 11 packages with no owners entry SDL_Pango gtk-sharp itpp ktechlab libpaper libpri mISDN openpbx php-pecl-Fileinfo pygpgme toped - 189 packages were dropped from extras Maintainers stats: - 226 maintainers - 1 inactive maintainers with open bugs - 3 inactive maintainers Dropped FC packages: - 283 packages were dropped from core since FC 1 Comps.xml files stats: - 817 packages in comps-fe6 file - 448 packages missing from comps-fe6 file - 34 packages in comps-fe6 but not in repo - 669 packages in comps-fe5 file - 548 packages missing from comps-fe5 file - 25 packages in comps-fe5 but not in repo From denis at poolshark.org Wed Oct 18 16:30:27 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 18 Oct 2006 18:30:27 +0200 Subject: Tracking gnome.org projects Message-ID: <453656A3.8040809@poolshark.org> Does anyone have a good trick to track file releases from projects hosted on gnome.org ? SourceForge has convenient RSS feeds for their file releases, but several packages I maintain are hosted on ftp.gnome.org... From david at lovesunix.net Wed Oct 18 16:57:13 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 18 Oct 2006 18:57:13 +0200 Subject: Tracking gnome.org projects In-Reply-To: <453656A3.8040809@poolshark.org> References: <453656A3.8040809@poolshark.org> Message-ID: <1161190633.27272.37.camel@price> ons, 18 10 2006 kl. 18:30 +0200, skrev Denis Leroy: > Does anyone have a good trick to track file releases from projects > hosted on gnome.org ? SourceForge has convenient RSS feeds for their > file releases, but several packages I maintain are hosted on > ftp.gnome.org... This might be helpful: http://mail.gnome.org/mailman/listinfo/ftp-release-list - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From david at lovesunix.net Wed Oct 18 16:59:24 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 18 Oct 2006 18:59:24 +0200 Subject: Tracking gnome.org projects In-Reply-To: <1161190633.27272.37.camel@price> References: <453656A3.8040809@poolshark.org> <1161190633.27272.37.camel@price> Message-ID: <1161190764.27272.39.camel@price> ons, 18 10 2006 kl. 18:57 +0200, skrev David Nielsen: > ons, 18 10 2006 kl. 18:30 +0200, skrev Denis Leroy: > > Does anyone have a good trick to track file releases from projects > > hosted on gnome.org ? SourceForge has convenient RSS feeds for their > > file releases, but several packages I maintain are hosted on > > ftp.gnome.org... > > > This might be helpful: > > http://mail.gnome.org/mailman/listinfo/ftp-release-list > > - David Nielsen Or even better, the RSS feed: http://ftp.gnome.org/pub/GNOME/LATEST.xml - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From dcbw at redhat.com Wed Oct 18 18:06:25 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 18 Oct 2006 14:06:25 -0400 Subject: Plague documentation? In-Reply-To: <20061018145634.GA24252@neu.nirvana> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> <1161172659.2767.1.camel@localhost.localdomain> <20061018145634.GA24252@neu.nirvana> Message-ID: <1161194785.6024.0.camel@localhost.localdomain> On Wed, 2006-10-18 at 16:56 +0200, Axel Thimm wrote: > On Wed, Oct 18, 2006 at 07:57:39AM -0400, Dan Williams wrote: > > There was some confusion about that; but it was actually created as a > > build system for Fedora Extras specifically, because beehive (the old RH > > buildsys) was on life-support and had major issues, brew wasn't ready > > yet, and brew wasn't necessarily appropriate for Extras at the time > > anyway. > > And a look into the cristal ball (aka your best guess on future > development)? E.g. what will the future relation of brew and plaque be > under assumption that some further integration between FC and FE will > happen. Will one tool surpass the other? Or complement? Brew does some pretty neat stuff; but it doesn't try to cover a more distributed use-case. In the future, I'd like to see a more brew-based tool into which we add the features we like in plague. Dan > Thanks! From buildsys at fedoraproject.org Wed Oct 18 18:16:30 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 18 Oct 2006 14:16:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-18 Message-ID: <20061018181630.0F21B15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 20 R-hdf5-1.6.4-2.fc6 clamav-0.88.5-1.fc6 cobbler-0.2.7-1.fc6 genius-0.7.6.1-3.fc6 git-1.4.2.4-1.fc6 gtkwave-3.0.14-1.fc6 harminv-1.3.1-8.fc6 kbibtex-0.1.5-1.fc6 libassuan-0.9.3-2.fc6 luma-2.3-8.fc6 oki4linux-2.1gst-1.fc6 pekwm-0.1.5-5.fc6 perl-HTML-Mason-1.35-1.fc6 perl-IO-All-0.36-1.fc6 perl-IPC-Cmd-0.32-1.fc6 perl-Object-Accessor-0.32-1.fc6 prboom-2.4.6-1.fc6 python-basemap-0.9.3-1.fc6 python-myghty-1.1-2.fc6 wine-0.9.23-1.fc6 Packages built and released for Fedora Extras 5: 14 R-hdf5-1.6.4-2.fc5 cobbler-0.2.7-1.fc5 ghdl-0.25-0.73svn.0.fc5 git-1.4.2.4-1.fc5 gtkwave-3.0.14-1.fc5 kbibtex-0.1.5-1.fc5 koan-0.2.2-1.fc5 perl-File-BaseDir-0.02-1.fc5 perl-File-DesktopEntry-0.02-1.fc5 perl-File-MimeInfo-0.13-2.fc5 rpld-1.8-0.1.beta1.fc5 tagtool-0.12.2-7.fc5 wine-0.9.23-1.fc5 yumex-1.0.3-3.0.fc5 Packages built and released for Fedora Extras 4: 4 R-hdf5-1.6.4-2.fc4 git-1.4.2.4-1.fc4 gtkwave-3.0.14-1.fc4 kbibtex-0.1.5-1.fc4 Packages built and released for Fedora Extras 3: 2 git-1.4.2.4-1.fc3 jasper-1.701.0-15.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 Wed Oct 18 18:16:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 18 Oct 2006 14:16:59 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-18 Message-ID: <20061018181659.73ED715212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) gemi AT bluewin.ch: abcMIDI FE5 > FE6 (0:20061015-1.1.fc5 > 0:20061015-1.fc6) mdehaan AT redhat.com: koan FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- abcMIDI: gemi AT bluewin.ch FE5 > FE6 (0:20061015-1.1.fc5 > 0:20061015-1.fc6) anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) koan: mdehaan AT redhat.com FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From sodarock at gmail.com Wed Oct 18 18:51:00 2006 From: sodarock at gmail.com (John Villalovos) Date: Wed, 18 Oct 2006 11:51:00 -0700 Subject: Plague documentation? In-Reply-To: <1161131691.2663.0.camel@localhost.localdomain> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> Message-ID: <5e61b72f0610181151m4491e84ah842a22e0725cbae3@mail.gmail.com> Okay. Well I have run into some hiccups regarding the README. Example: In plague-builder usage it doesn't know about the fact that it uses a config file now and not command line arguments. But I am trying it out and I have the plague-server running and plague-builder running. And even enqued a job with plague-client which the plague-server accepted. Unfortunately the builder isn't doing anything :( Question 1: Does it matter what gets started first in regards to plague-builder and plague-server? I start plague-server and I get this: # plague-server 127.0.0.1 Using database engine sqlite. Builders: ------------------------------------------------------------------------------------------ http://127.0.0.1:8888 unavailable Build Server accepting requests on localhost:8887. 1 (mach): Restarting '/home/mockbuild/mach-0.9.0-1.fc5.src.rpm' on target 'fedora-5-core' And then running plague-builder I get this: # plague-builder -c plague-builder.cfg Binding to address '' with arches: [i386,i486,i586,i686,athlon] Not quite sure what ports everything should be on so I went with the defaults. Any help would be appreciated. Also I see mention of something called brew. Is this a replacement for Plague? If so is it stable? Is it better than plague? Thanks, John From buildsys at fedoraproject.org Wed Oct 18 18:59:24 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 18 Oct 2006 18:59:24 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-18 Message-ID: <20061018185924.22925.59037@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (18 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (18 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (18 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (33 days) plague - 0.4.4.1-2.fc3.noarch (33 days) plague - 0.4.4.1-2.fc4.noarch (33 days) plague - 0.4.4.1-2.fc4.noarch (33 days) plague - 0.4.4.1-2.fc4.noarch (33 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (9 days) linphone - 1.2.0-4.fc5.ppc (9 days) linphone - 1.2.0-4.fc5.x86_64 (9 days) linphone - 1.2.0-7.fc6.i386 (9 days) linphone - 1.2.0-7.fc6.ppc (9 days) linphone - 1.2.0-7.fc6.x86_64 (9 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From sodarock at gmail.com Wed Oct 18 19:03:20 2006 From: sodarock at gmail.com (John Villalovos) Date: Wed, 18 Oct 2006 12:03:20 -0700 Subject: Plague documentation? In-Reply-To: <5e61b72f0610181151m4491e84ah842a22e0725cbae3@mail.gmail.com> References: <5e61b72f0610171502p78128209ke951f0b266d65583@mail.gmail.com> <1161131691.2663.0.camel@localhost.localdomain> <5e61b72f0610181151m4491e84ah842a22e0725cbae3@mail.gmail.com> Message-ID: <5e61b72f0610181203x48c71419se7fad70a8fc43d9c@mail.gmail.com> On 10/18/06, John Villalovos wrote: > I start plague-server and I get this: > # plague-server 127.0.0.1 > Using database engine sqlite. > > Builders: > ------------------------------------------------------------------------------------------ > http://127.0.0.1:8888 > unavailable > > Build Server accepting requests on localhost:8887. > > 1 (mach): Restarting '/home/mockbuild/mach-0.9.0-1.fc5.src.rpm' on > target 'fedora-5-core' > > And then running plague-builder I get this: > # plague-builder -c plague-builder.cfg > Binding to address '' with arches: [i386,i486,i586,i686,athlon] > > Not quite sure what ports everything should be on so I went with the defaults. Okay. I figured out that in my builder config file I needed to specify 127.0.0.1 since everything else was bound to localhost. I have a build running right now. I'm hopeful :) John From tibbs at math.uh.edu Wed Oct 18 20:55:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 18 Oct 2006 15:55:59 -0500 Subject: Co-maintainers to assist upstreams with their packages in Extras In-Reply-To: <20061018142038.GC2331@free.fr> (Patrice Dumas's message of "Wed, 18 Oct 2006 16:20:38 +0200") References: <20061015084621.GC2323@free.fr> <20061015190030.GD8727@neu.nirvana> <20061016063518.GA2339@free.fr> <20061017.123632.484476945.kevin@scrye.com> <20061018142038.GC2331@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> However I still think that anytime an upstream maintainer is also PD> a fedora package maintainer, there is a risk that he forget the PD> differences between both. There is always a risk that any maintainer could stop following the guidelines or otherwise act in some antisocial way; I don't think upstream developers would be any more prone to this than anyone else. The community should always be aware of the potential for this kind of problem. - J< From pertusus at free.fr Thu Oct 19 08:36:19 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 19 Oct 2006 10:36:19 +0200 Subject: recipes for bugzilla activity Message-ID: <20061019083619.GB28826@free.fr> Hello, I know that some people use nice reporting 'tools' (maybe just clever urls) to gather information about somebody activity on bugzilla, and it may be very usefull for example for decision about sponsoring, or to check activity of a maintainer who don't answer a particular bug and so on. I think it could be nice to have something on the wiki for such recipes, and a least link it from http://fedoraproject.org/wiki/Extras/SponsorProcess -- Pat From giallu at gmail.com Thu Oct 19 10:01:50 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 19 Oct 2006 12:01:50 +0200 Subject: recipes for bugzilla activity In-Reply-To: <20061019083619.GB28826@free.fr> References: <20061019083619.GB28826@free.fr> Message-ID: On 10/19/06, Patrice Dumas wrote: > Hello, > > I know that some people use nice reporting 'tools' (maybe just clever urls) > to gather information about somebody activity on bugzilla, and it may be > very usefull for example for decision about sponsoring, or to check activity > of a maintainer who don't answer a particular bug and so on. I think > it could be nice to have something on the wiki for such recipes, and a least > link it from > > http://fedoraproject.org/wiki/Extras/SponsorProcess I am pretty sure there are also other useful bugzilla recipes out there; maybe we could start something like: http://fedoraproject.org/wiki/Extras/BugzillaRecipes ? From notting at redhat.com Thu Oct 19 16:36:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Oct 2006 12:36:05 -0400 Subject: recipes for bugzilla activity In-Reply-To: <20061019083619.GB28826@free.fr> References: <20061019083619.GB28826@free.fr> Message-ID: <20061019163605.GA22273@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > I know that some people use nice reporting 'tools' (maybe just clever urls) > to gather information about somebody activity on bugzilla, and it may be > very usefull for example for decision about sponsoring, or to check activity > of a maintainer who don't answer a particular bug and so on. I think > it could be nice to have something on the wiki for such recipes, and a least > link it from Something like http://bugzilla.gnome.org/page.cgi?id=points.html? Bill From j.w.r.degoede at hhs.nl Thu Oct 19 18:41:41 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Oct 2006 20:41:41 +0200 Subject: State of multilib development Message-ID: <4537C6E5.3040704@hhs.nl> Hi all, I already send this message to fedora-devel-list at redhat.com a couple of days ago, but I didn't get much reaction (accept from Dennis, thanks Dennis), so I'm sending it here now hoping to get some more discussion on the mentioned issues. --- Yesterday I tried to build i386 rpms on my x86_64 using the new multilib-devel packages instead of resorting to an i386 chroot. Although we have come a long way to making this possible there are still a few issues which makes doing this very hard: 1) gcc ignores setarch ====================== "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64 system as expected however, "setarch i386 gcc -o hello helloworld.c" also creates an x86_64 elf file instead of an i386 one, to get an i386 one I must do: "gcc -m32 -o hello helloworld.c". This is unfortunate, because even though rpmbuild adds -m32 to the *FLAGS environment variables things still don't for many packages, because they for example often ignore LDFLAGS, thus not specifying -m32 when linking, causing things to fail. I personally would expect setarch i386 gcc -o hello helloworld.c" to create an i386 elf binary, I haven't filed a bug for this though, because I believe the current behavior is intended, unfortunate but intended. A work around is to create shell script wrappers for gcc, g++ and ld which always add -m32, put these somewhere outside the standard $PATH and add the location to PATH when you want to build i386 binaries. 2) rpmbuild ignores setarch =========================== "setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo, I know "rpmbuild --target i386" works better but still has issues, for example libdir is still set to /usr/lib64, this is already in bugzilla. I however still believe that rpmbuild should change its default build target when using setarch and should call setarch itself when called with --target, shall I BZ this? 3) pkgconfig ignores setarch ============================ I thought that pkgconfig was supposed to get this right and hence it was used to implement verious replacement foo-config scripts, but pkgconfig doesn't get this right. When testing I had only libpng-devel.i386 installed not the x86_64 version: --- [hans at shalem ~]$ pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found --- Behaves as expected, since it searches /usr/lib64/pkgconfig where there is no libpng.pc --- [hans at shalem ~]$ setarch i386 pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found [hans at shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc -> libpng12.pc --- Does not behave as expected, it should search /usr/lib/pkgconfig and find libpng.pc This can be worked around by doing a "export PKG_CONFIG_PATH=/usr/lib/pkgconfig" Shall I BZ this? 4) rpmbuild lets x86_64 packages satisfy BR's when building for i386 ==================================================================== The subject says most of it, when doing an rpmbuild --target=i386 I don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel . I know things aren't that easy because with something like BR: desktop-file-utils, the x86_64 version will do fine. Suggestion: make rpmbuild check the arch of BR's who's name ends with -devel. This will still have a few exceptions, but will be a big improvement in general. BZ? 5) xxx-devel.arch should require xxx.arch not just xxx ====================================================== When I install libXt-devel.i386 I expect it to drag in libXt.i386 and not to be happy with the already installed libXt.x86_64 . This will also stop some polution with i386 packages of x86_64 system, because currently we have the following scenario: libXt-1.0.2-3.fc6.x86_64 is installed Users does "yum install libXt-devel.x86_64" Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64, which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the x86_64 version of libXt and as an added bonus also install the i386 version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64 Once more if people agree with me here I'll put this in bugzilla. Let me know what you think & Regards, Hans -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From triad at df.lth.se Thu Oct 19 19:35:42 2006 From: triad at df.lth.se (Linus Walleij) Date: Thu, 19 Oct 2006 21:35:42 +0200 (CEST) Subject: State of multilib development In-Reply-To: <4537C6E5.3040704@hhs.nl> References: <4537C6E5.3040704@hhs.nl> Message-ID: Hi Hans, I think these issues are highly important, because they prepare us for the 64bit future. However I think the audience is small and that is why so few comments arrives. I'll do my best, though I'm a i386 owner, sadly. First, is the rest of the world we live in really aware of setarch or is that perceieved as some RedHat weirdo thing that they never heard of? Then we'll have to evangelize it. Secondly, are there other things that setarch could/should do apart from just altering the output of uname -m as it does today? If there is, it'll sure turn up in the suggested bugzilla tickets... In any case I think setarch has a clear use in not only cross-building, cross-packaging, cross-installing i386, x86_64 or PPC, it should also have a place in embedded development as for ARM etc. On Thu, 19 Oct 2006, Hans de Goede wrote: [GCC] > I personally would expect setarch i386 gcc -o hello helloworld.c" to > create an i386 elf binary, I haven't filed a bug for this though, > because I believe the current behavior is intended, unfortunate but > intended. Why? I would file a bug and let the GCC developers decide on how to handle this. Better file one too many than one to few bugs is my stance. "Please get the default arch as from uname -m" is just fine, isn't it? [rpmbuild] > I however still believe that rpmbuild should change its default build > target when using setarch and should call setarch itself when called > with --target, shall I BZ this? Since both setarch and --target seems to be required there is something fishy. Why tell the tool the same thing twice? I think you're right and the bug should be filed. [pkgconfig] > Shall I BZ this? Yes, I think so. [rpmbuild again, but worse bug] > Suggestion: make rpmbuild check the arch of BR's who's name ends with > -devel. > (...) > This will still have a few exceptions, but will be a big improvement in > general. BZ? Yes. [yum] > xxx-devel.arch should require xxx.arch not just xxx > When I install libXt-devel.i386 I expect it to drag in libXt.i386 and > not to be happy with the already installed libXt.x86_64 . > (...) > Once more if people agree with me here I'll put this in bugzilla. I agree, this is more serious than the build tool issues, since it affects end-users badly. Isn't the idea that i386 should be used as a fallback on x86_64 if and only if no x86_64 package can be found? That's atleast what I see as consensus. So that's how yum should operate, right? Linus From buildsys at fedoraproject.org Thu Oct 19 19:37:42 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Oct 2006 15:37:42 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-19 Message-ID: <20061019193742.D46D815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 26 MegaMek-0.30.11-1.fc6 aalib-1.4.0-0.11.rc5.fc6 abcMIDI-20061015-2.fc6 anjuta-2.0.2-8.fc6 bwidget-1.8.0-1.fc6 clement-2.1-210.fc6 cobbler-0.2.8-1.fc6 comix-3.6.1-1.fc6 galeon-2.0.3-3.fc6 glom-1.2.0-2.fc6 gnupg2-1.9.93-1.fc6 libetpan-0.47-1.fc6 munin-1.2.5-1.fc6 openpbx-1.2-2.rc1.svn1984.fc6 perl-Calendar-Simple-1.17-1.fc6 perl-Error-0.17007-1.fc6 perl-Math-Pari-2.010708-1.fc6 perl-Params-Util-0.21-1.fc6 perl-WWW-Myspace-0.59-1.fc6 rpld-1.8-0.1.beta1.fc6 ser2net-2.3-3.fc6 soundconverter-0.9.3-1.fc6 svn2cl-0.8-1.fc6 telepathy-gabble-0.4.0-1.fc6 viaideinfo-0.4-1.fc6 zaptel-1.4.0-3.fc6.beta2 Packages built and released for Fedora Extras 5: 20 bwidget-1.8.0-1.fc5 clamav-0.88.5-1.fc5 cobbler-0.2.8-1.fc5 comix-3.6.1-1.fc5 genius-0.7.6.1-3.fc5 glom-1.2.0-1.fc5 harminv-1.3.1-8.fc5 libetpan-0.47-1.fc5 naim-0.11.8.2.1-1.fc5 perl-Calendar-Simple-1.17-1.fc5 perl-Math-Pari-2.010708-1.fc5 perl-Params-Util-0.21-1.fc5 perl-WWW-Myspace-0.59-1.fc5 php-pear-DB-QueryTool-1.0.3-1.fc5 php-pear-XML-Beautifier-1.1-1.fc5 php-pear-XML-Util-1.1.1-1.fc5 ser2net-2.3-3.fc5 svn2cl-0.8-1.fc5 wallpapoz-0.3-1.fc5 zaptel-1.4.0-3.fc5.beta2 Packages built and released for Fedora Extras 4: 5 libetpan-0.47-1.fc4 perl-Calendar-Simple-1.17-1.fc4 perl-Math-Pari-2.010708-1.fc4 perl-Params-Util-0.21-1.fc4 ser2net-2.3-3.fc4 Packages built and released for Fedora Extras 3: 1 libetpan-0.47-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 Oct 19 19:38:13 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Oct 2006 15:38:13 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-19 Message-ID: <20061019193813.427DB15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) mdehaan AT redhat.com: koan FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) koan: mdehaan AT redhat.com FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From dlutter at redhat.com Thu Oct 19 19:47:09 2006 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 19 Oct 2006 12:47:09 -0700 Subject: Buildroots for RHEL Message-ID: <1161287229.17073.34.camel@localhost.localdomain> Hi all, I just noticed that http://buildsys.fedoraproject.org/buildgroups/ now has buildgroups for RHEL; alas, at least for RHEL4, they are broken. When trying to use them, I ran into two problems: 1. the buildsys-build rpm does not pull in python; that's actually two problems: A. rpmbuild complains that 'el' is not a valid macro name, and ignores the conditionals in the specfile that should add a dependency on python, (filed as bz#211511) B. the buildsys site has old RPM's. Who maintains that ? 2. buildsys-macros depends on rpmdevtools, which does not exist for RHEL. A patch against the specfile from [1] is attached; it removes the use of rpmdevtools completely. Where are the specfiles for buildsys-macros maintained ? Couldn't find them in CVS. David [1] http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/buildsys-macros-4-3.el4.src.rpm -------------- next part -------------- A non-text attachment was scrubbed... Name: buildsys-build.patch Type: text/x-patch Size: 1655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no-rpmdevtools.patch Type: text/x-patch Size: 1186 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Oct 19 19:50:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Oct 2006 15:50:49 -0400 Subject: Buildroots for RHEL In-Reply-To: <1161287229.17073.34.camel@localhost.localdomain> References: <1161287229.17073.34.camel@localhost.localdomain> Message-ID: <1161287449.8201.12.camel@cutter> On Thu, 2006-10-19 at 12:47 -0700, David Lutterkort wrote: > Hi all, > > I just noticed that http://buildsys.fedoraproject.org/buildgroups/ now > has buildgroups for RHEL; alas, at least for RHEL4, they are broken. > > When trying to use them, I ran into two problems: > 1. the buildsys-build rpm does not pull in python; that's actually > two problems: > A. rpmbuild complains that 'el' is not a valid macro name, > and ignores the conditionals in the specfile that should > add a dependency on python, (filed as bz#211511) > B. the buildsys site has old RPM's. Who maintains that ? > 2. buildsys-macros depends on rpmdevtools, which does not exist for > RHEL. A patch against the specfile from [1] is attached; it > removes the use of rpmdevtools completely. Where are the > specfiles for buildsys-macros maintained ? Couldn't find them in > CVS. > 1. buildsys-list is better for this 2. spec for buildsys-macros are in the mock package. -sv From ville.skytta at iki.fi Thu Oct 19 19:56:41 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 19 Oct 2006 22:56:41 +0300 Subject: Buildroots for RHEL In-Reply-To: <1161287229.17073.34.camel@localhost.localdomain> References: <1161287229.17073.34.camel@localhost.localdomain> Message-ID: <1161287801.3229.4.camel@viper.local> On Thu, 2006-10-19 at 12:47 -0700, David Lutterkort wrote: > 2. buildsys-macros depends on rpmdevtools, which does not exist for > RHEL. A patch against the specfile from [1] is attached; it > removes the use of rpmdevtools completely. I'd suggest rolling a rpmdevtools package for RHEL instead of just dropping the dependency. The scriptlets used from rpmdevtools (only one in FE at the moment, though) are there to catch security issues. From garrick at usc.edu Thu Oct 19 19:57:02 2006 From: garrick at usc.edu (Garrick Staples) Date: Thu, 19 Oct 2006 12:57:02 -0700 Subject: Fedora Extras Package Build Report 2006-10-19 In-Reply-To: <20061019193742.D46D815212E@buildsys.fedoraproject.org> References: <20061019193742.D46D815212E@buildsys.fedoraproject.org> Message-ID: <20061019195702.GC2077@polop.usc.edu> > zaptel-1.4.0-3.fc6.beta2 > zaptel-1.4.0-3.fc5.beta2 Aren't these nvrs incorrectly formed? They should be 1.4.0-0.3.beta2.%{?dist} -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Thu Oct 19 20:09:52 2006 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 19 Oct 2006 13:09:52 -0700 Subject: Buildroots for RHEL In-Reply-To: <1161287801.3229.4.camel@viper.local> References: <1161287229.17073.34.camel@localhost.localdomain> <1161287801.3229.4.camel@viper.local> Message-ID: <1161288592.17073.36.camel@localhost.localdomain> On Thu, 2006-10-19 at 22:56 +0300, Ville Skytt? wrote: > On Thu, 2006-10-19 at 12:47 -0700, David Lutterkort wrote: > > > 2. buildsys-macros depends on rpmdevtools, which does not exist for > > RHEL. A patch against the specfile from [1] is attached; it > > removes the use of rpmdevtools completely. > > I'd suggest rolling a rpmdevtools package for RHEL instead of just > dropping the dependency. The scriptlets used from rpmdevtools (only one > in FE at the moment, though) are there to catch security issues. That adds another RPM though that needs to be added to create a RHEL buildroot (besides buildsys-build and buildsys-macros) I'll try and look into that. David From dlutter at redhat.com Thu Oct 19 20:12:09 2006 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 19 Oct 2006 13:12:09 -0700 Subject: Buildroots for RHEL In-Reply-To: <1161287449.8201.12.camel@cutter> References: <1161287229.17073.34.camel@localhost.localdomain> <1161287449.8201.12.camel@cutter> Message-ID: <1161288729.17073.39.camel@localhost.localdomain> On Thu, 2006-10-19 at 15:50 -0400, seth vidal wrote: > On Thu, 2006-10-19 at 12:47 -0700, David Lutterkort wrote: > > Hi all, > > > > I just noticed that http://buildsys.fedoraproject.org/buildgroups/ now > > has buildgroups for RHEL; alas, at least for RHEL4, they are broken. > > > > When trying to use them, I ran into two problems: > > 1. the buildsys-build rpm does not pull in python; that's actually > > two problems: > > A. rpmbuild complains that 'el' is not a valid macro name, > > and ignores the conditionals in the specfile that should > > add a dependency on python, (filed as bz#211511) > > B. the buildsys site has old RPM's. Who maintains that ? > > 2. buildsys-macros depends on rpmdevtools, which does not exist for > > RHEL. A patch against the specfile from [1] is attached; it > > removes the use of rpmdevtools completely. Where are the > > specfiles for buildsys-macros maintained ? Couldn't find them in > > CVS. > > > > 1. buildsys-list is better for this Ok. Had no idea that list existed (it's not announced on https://www.redhat.com/mailman/listinfo/) > 2. spec for buildsys-macros are in the mock package. No. buildsys-build.spec is, buildsys-macros.spec isn't. David From ville.skytta at iki.fi Thu Oct 19 20:15:47 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 19 Oct 2006 23:15:47 +0300 Subject: Fedora Extras Package Build Report 2006-10-19 In-Reply-To: <20061019195702.GC2077@polop.usc.edu> References: <20061019193742.D46D815212E@buildsys.fedoraproject.org> <20061019195702.GC2077@polop.usc.edu> Message-ID: <1161288947.3229.20.camel@viper.local> On Thu, 2006-10-19 at 12:57 -0700, Garrick Staples wrote: > > zaptel-1.4.0-3.fc6.beta2 > > zaptel-1.4.0-3.fc5.beta2 > > Aren't these nvrs incorrectly formed? Yes, they're against the guidelines, but it can't be fixed without an Epoch bump before the next upstream version following 1.4.0 which is definitely not worth it. And as long as there's something to the left of the non-numeric version part that can override it in the release tag (in this case, "3" trumps "beta2"), the issue is very much cosmetic - all it means is that when the final non-beta version is out, its release tag can't start from 1%{?dist}. From skvidal at linux.duke.edu Thu Oct 19 20:16:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Oct 2006 16:16:15 -0400 Subject: Buildroots for RHEL In-Reply-To: <1161288729.17073.39.camel@localhost.localdomain> References: <1161287229.17073.34.camel@localhost.localdomain> <1161287449.8201.12.camel@cutter> <1161288729.17073.39.camel@localhost.localdomain> Message-ID: <1161288975.8201.19.camel@cutter> On Thu, 2006-10-19 at 13:12 -0700, David Lutterkort wrote: > On Thu, 2006-10-19 at 15:50 -0400, seth vidal wrote: > > On Thu, 2006-10-19 at 12:47 -0700, David Lutterkort wrote: > > > Hi all, > > > > > > I just noticed that http://buildsys.fedoraproject.org/buildgroups/ now > > > has buildgroups for RHEL; alas, at least for RHEL4, they are broken. > > > > > > When trying to use them, I ran into two problems: > > > 1. the buildsys-build rpm does not pull in python; that's actually > > > two problems: > > > A. rpmbuild complains that 'el' is not a valid macro name, > > > and ignores the conditionals in the specfile that should > > > add a dependency on python, (filed as bz#211511) > > > B. the buildsys site has old RPM's. Who maintains that ? > > > 2. buildsys-macros depends on rpmdevtools, which does not exist for > > > RHEL. A patch against the specfile from [1] is attached; it > > > removes the use of rpmdevtools completely. Where are the > > > specfiles for buildsys-macros maintained ? Couldn't find them in > > > CVS. > > > > > > > 1. buildsys-list is better for this > > Ok. Had no idea that list existed (it's not announced on > https://www.redhat.com/mailman/listinfo/) > > > 2. spec for buildsys-macros are in the mock package. > > No. buildsys-build.spec is, buildsys-macros.spec isn't. oh - buildsys-macros is in the buildgroups dir,umm, here. http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ I don't think it is checked in anywhere, actually. it should be. -sv From buildsys at fedoraproject.org Thu Oct 19 20:24:16 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 19 Oct 2006 20:24:16 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-19 Message-ID: <20061019202416.30339.95419@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (19 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (19 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (19 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (34 days) plague - 0.4.4.1-2.fc3.noarch (34 days) plague - 0.4.4.1-2.fc4.noarch (34 days) plague - 0.4.4.1-2.fc4.noarch (34 days) plague - 0.4.4.1-2.fc4.noarch (34 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (10 days) linphone - 1.2.0-4.fc5.ppc (10 days) linphone - 1.2.0-4.fc5.x86_64 (10 days) linphone - 1.2.0-7.fc6.i386 (10 days) linphone - 1.2.0-7.fc6.ppc (10 days) linphone - 1.2.0-7.fc6.x86_64 (10 days) matthias AT rpmforge.net php-eaccelerator - 5.1.4_0.9.5-1.fc5.i386 php-eaccelerator - 5.1.4_0.9.5-1.fc5.ppc php-eaccelerator - 5.1.4_0.9.5-1.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 syck-php - 0.55-9.fc5.ppc syck-php - 0.55-9.fc5.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 php-eaccelerator-5.1.4_0.9.5-1.fc5.ppc requires php = 0:5.1.4 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) php-eaccelerator-5.1.4_0.9.5-1.fc5.x86_64 requires php = 0:5.1.4 syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 php-eaccelerator-5.1.4_0.9.5-1.fc5.i386 requires php = 0:5.1.4 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-9.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.4 package: syck-php - 0.55-9.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.4 ====================================================================== New report for: matthias AT rpmforge.net package: php-eaccelerator - 5.1.4_0.9.5-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.4 package: php-eaccelerator - 5.1.4_0.9.5-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.4 package: php-eaccelerator - 5.1.4_0.9.5-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.4 From dennis at ausil.us Thu Oct 19 21:07:35 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 19 Oct 2006 16:07:35 -0500 Subject: Buildroots for RHEL In-Reply-To: <1161287229.17073.34.camel@localhost.localdomain> References: <1161287229.17073.34.camel@localhost.localdomain> Message-ID: <200610191607.36323.dennis@ausil.us> On Thursday 19 October 2006 14:47, David Lutterkort wrote: > Hi all, > > I just noticed that http://buildsys.fedoraproject.org/buildgroups/ now > has buildgroups for RHEL; alas, at least for RHEL4, they are broken. > > When trying to use them, I ran into two problems: > 1. the buildsys-build rpm does not pull in python; that's actually > two problems: > A. rpmbuild complains that 'el' is not a valid macro name, > and ignores the conditionals in the specfile that should > add a dependency on python, (filed as bz#211511) > B. the buildsys site has old RPM's. Who maintains that ? > 2. buildsys-macros depends on rpmdevtools, which does not exist for > RHEL. A patch against the specfile from [1] is attached; it > removes the use of rpmdevtools completely. Where are the > specfiles for buildsys-macros maintained ? Couldn't find them in > CVS. as part of EPEL my intention was to put a rpmdevtools package in in the buildroot first then build it in the buildsys. you should be able to get around this by putting rpmdevtools into your repo and everything else should work. Dennis From jeff at ocjtech.us Thu Oct 19 21:22:17 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 19 Oct 2006 16:22:17 -0500 Subject: Fedora Extras Package Build Report 2006-10-19 In-Reply-To: <1161288947.3229.20.camel@viper.local> References: <20061019193742.D46D815212E@buildsys.fedoraproject.org> <20061019195702.GC2077@polop.usc.edu> <1161288947.3229.20.camel@viper.local> Message-ID: <1161292937.6942.10.camel@lt21223.campus.dmacc.edu.> On Thu, 2006-10-19 at 23:15 +0300, Ville Skytt? wrote: > On Thu, 2006-10-19 at 12:57 -0700, Garrick Staples wrote: > > > zaptel-1.4.0-3.fc6.beta2 > > > zaptel-1.4.0-3.fc5.beta2 > > > > Aren't these nvrs incorrectly formed? > > Yes, they're against the guidelines, but it can't be fixed without an > Epoch bump before the next upstream version following 1.4.0 which is > definitely not worth it. And as long as there's something to the left > of the non-numeric version part that can override it in the release tag > (in this case, "3" trumps "beta2"), the issue is very much cosmetic - > all it means is that when the final non-beta version is out, its release > tag can't start from 1%{?dist}. Erp... soo many guidelines, too few working braincells. Yeah, I has just planned on bumping the initial integer with each new release (beta or non beta). Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Fri Oct 20 03:19:37 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 19 Oct 2006 22:19:37 -0500 Subject: Buildsys Downtime Message-ID: <200610192219.38921.dennis@ausil.us> On Monday October 23 at 10am EST cvs write access and the extras build system will be disabled. this will allow for CVS to be branched for fc6 and for the buildsys to have fc6 configs deployed. Downtime will be approximately 3 hours. Ill send a notification before it goes down and again when its back up Your understanding and paitence is appreciated. -- Dennis Gilmore, RHCE Proud Australian From michel.salim at gmail.com Fri Oct 20 22:27:05 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 20 Oct 2006 18:27:05 -0400 Subject: Package naming query Message-ID: <883cfe6d0610201527q63ca4ba6waa673748504cb2f9@mail.gmail.com> I'm working on packaging libopensync-plugin-syncml and its dependencies, and came across libwbxml: http://libwbxml.aymerick.com:8080/wiki/Download The website refers to it consistently as libwbxml, but the tarball itself is called wbxml2 (despite the link to it being 'libwbxml v0.9.2'). SuSE also has this package and called it wbxml2. It seems that wbxml2 is a temporary name, since there was wbxml, an older version, that links against libxml2 instead of expat. So I'm tending to go with libwbxml, but there's the "keep compatibility with other distros" clause in the packaging guideline. Advice? Thanks in advance.. -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From buildsys at fedoraproject.org Sat Oct 21 00:39:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 Oct 2006 20:39:12 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-20 Message-ID: <20061021003912.E177D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 37 audacious-1.1.2-2.fc6 chkrootkit-0.47-1.fc6 cyphesis-0.5.10-1.fc6 dnsmasq-2.34-1.fc6 eclipse-gef-3.2.1-2.fc6 enemies-of-carlotta-1.2.2-3.fc6 eris-1.3.11-9.fc6 fontforge-20061019-1.fc6 gcin-1.2.8-1.fc6 koffice-1.6.0-1.fc6 kst-1.3.1-1.fc6 lat-1.2.1.1-1.fc6 libmtp-0.0.21-1.fc6 libopensync-0.19-1.fc6 libopensync-plugin-evolution2-0.19-1.fc6 libopensync-plugin-file-0.19-1.fc6 libopensync-plugin-gpe-0.19-1.fc6 libopensync-plugin-irmc-0.19-1.fc6 libopensync-plugin-kdepim-0.19-1.fc6 libopensync-plugin-palm-0.19-1.fc6 libopensync-plugin-python-0.19-1.fc6 liferea-1.0.24-1.fc6 listen-0.5-8.beta1.fc6 multisync-0.90.19-1.fc6 ntfs-3g-0-0.3.20070920.fc6 perl-Alien-wxWidgets-0.23-1.fc6 perl-Cache-Mmap-0.09-1.fc6 perl-Email-MIME-1.855-1.fc6 perl-Email-Simple-1.995-1.fc6 perl-HTML-Template-Expr-0.07-3.fc6 quilt-0.46-1.fc6 scribes-templates-20061017-2.fc6 skstream-0.3.6-1.fc6 stellarium-0.8.2-2.fc6 sylpheed-claws-2.5.6-1.fc6 sylpheed-claws-plugins-2.5.2-4.fc6 tcllib-1.9-1.fc6 Packages built and released for Fedora Extras 5: 25 aalib-1.4.0-0.11.rc5.fc5 chkrootkit-0.47-1.fc5 dnsmasq-2.34-1.fc5 fontforge-20061019-1.fc5 gcin-1.2.8-1.fc5 libmtp-0.0.21-1.fc5 libopensync-0.19-1.fc5 libopensync-plugin-evolution2-0.19-1.fc5 libopensync-plugin-file-0.19-1.fc5 libopensync-plugin-gpe-0.19-1.fc5 libopensync-plugin-kdepim-0.19-1.fc5 libopensync-plugin-palm-0.19-1.fc5 libopensync-plugin-python-0.19-1.fc5 liferea-1.0.24-1.fc5 listen-0.5-8.beta1.fc5 multisync-0.90.19-1.fc5 munin-1.2.5-1.fc5 ntfs-3g-0-0.3.20070920.fc5 pekwm-0.1.5-5.fc5 perl-Email-MIME-1.855-1.fc5 perl-Email-Simple-1.995-1.fc5 sylpheed-claws-2.5.6-1.fc5 sylpheed-claws-plugins-2.5.2-4.fc5 tcllib-1.9-1.fc5 viaideinfo-0.4-1.fc5 Packages built and released for Fedora Extras 4: 12 chkrootkit-0.47-1.fc4 gcin-1.2.8-1.fc4 libopensync-0.19-1.fc4 libopensync-plugin-evolution2-0.19-1.fc4 libopensync-plugin-file-0.19-1.fc4 libopensync-plugin-gpe-0.19-1.fc4 libopensync-plugin-irmc-0.19-1.fc4 libopensync-plugin-kdepim-0.19-1.fc4 libopensync-plugin-palm-0.19-1.fc4 libopensync-plugin-python-0.19-1.fc4 multisync-0.90.19-1.fc4 sylpheed-claws-2.5.6-1.fc4 Packages built and released for Fedora Extras 3: 6 gcin-1.2.8-1.fc3 libopensync-0.19-1.fc3 libopensync-plugin-evolution2-0.19-1.fc3 libopensync-plugin-file-0.19-1.fc3 libopensync-plugin-palm-0.19-1.fc3 libopensync-plugin-python-0.19-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 Oct 21 00:39:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 Oct 2006 20:39:44 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-20 Message-ID: <20061021003944.5F85915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) mdehaan AT redhat.com: koan FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) koan: mdehaan AT redhat.com FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From chris.stone at gmail.com Sat Oct 21 00:41:23 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Oct 2006 17:41:23 -0700 Subject: Package naming query In-Reply-To: <883cfe6d0610201527q63ca4ba6waa673748504cb2f9@mail.gmail.com> References: <883cfe6d0610201527q63ca4ba6waa673748504cb2f9@mail.gmail.com> Message-ID: On 10/20/06, Michel Salim wrote: > I'm working on packaging libopensync-plugin-syncml and its > dependencies, and came across libwbxml: > > http://libwbxml.aymerick.com:8080/wiki/Download > > The website refers to it consistently as libwbxml, but the tarball > itself is called wbxml2 (despite the link to it being 'libwbxml > v0.9.2'). SuSE also has this package and called it wbxml2. > > It seems that wbxml2 is a temporary name, since there was wbxml, an > older version, that links against libxml2 instead of expat. So I'm > tending to go with libwbxml, but there's the "keep compatibility with > other distros" clause in the packaging guideline. > > Advice? Thanks in advance.. I think it would be okay as long as you add a "Provides" to keep compatibility with other distros. From buildsys at fedoraproject.org Sat Oct 21 01:20:58 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 21 Oct 2006 01:20:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-20 Message-ID: <20061021012058.17866.56914@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (20 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (20 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (20 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (35 days) plague - 0.4.4.1-2.fc3.noarch (35 days) plague - 0.4.4.1-2.fc4.noarch (35 days) plague - 0.4.4.1-2.fc4.noarch (35 days) plague - 0.4.4.1-2.fc4.noarch (35 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (11 days) linphone - 1.2.0-4.fc5.ppc (11 days) linphone - 1.2.0-4.fc5.x86_64 (11 days) linphone - 1.2.0-7.fc6.i386 (11 days) linphone - 1.2.0-7.fc6.ppc (11 days) linphone - 1.2.0-7.fc6.x86_64 (11 days) matthias AT rpmforge.net php-eaccelerator - 5.1.4_0.9.5-1.fc5.i386 php-eaccelerator - 5.1.4_0.9.5-1.fc5.ppc php-eaccelerator - 5.1.4_0.9.5-1.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 syck-php - 0.55-9.fc5.ppc syck-php - 0.55-9.fc5.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 php-eaccelerator-5.1.4_0.9.5-1.fc5.ppc requires php = 0:5.1.4 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) php-eaccelerator-5.1.4_0.9.5-1.fc5.x86_64 requires php = 0:5.1.4 syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 php-eaccelerator-5.1.4_0.9.5-1.fc5.i386 requires php = 0:5.1.4 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From eamitdey at yahoo.com Sat Oct 21 02:20:47 2006 From: eamitdey at yahoo.com (Amit Dey) Date: Fri, 20 Oct 2006 19:20:47 -0700 (PDT) Subject: How to do Graphics Programming Message-ID: <20061021022047.74853.qmail@web36809.mail.mud.yahoo.com> I have Fedora Core 5 Installed. I would like to know how to start graphics programming. What are the packages i need to download ( if at all ). But I would prefer to do opengl programming based on the libraries already provided with fedora core 5. can anyone giveme links about how to start opengl programming with only opengl library ( I mean no mesa, no glut ). --------------------------------- Get your email and more, right on the new Yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.salim at gmail.com Sat Oct 21 04:14:36 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 21 Oct 2006 00:14:36 -0400 Subject: Package naming query In-Reply-To: References: <883cfe6d0610201527q63ca4ba6waa673748504cb2f9@mail.gmail.com> Message-ID: <883cfe6d0610202114x4724a612jc14e8af3a48b9ad4@mail.gmail.com> On 10/20/06, Christopher Stone wrote: > > > > It seems that wbxml2 is a temporary name, since there was wbxml, an > > older version, that links against libxml2 instead of expat. So I'm > > tending to go with libwbxml, but there's the "keep compatibility with > > other distros" clause in the packaging guideline. > > > > Advice? Thanks in advance.. > > I think it would be okay as long as you add a "Provides" to keep > compatibility with other distros. > Sounds like a good approach, I'll do that. Thanks! -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From seg at haxxed.com Sat Oct 21 09:51:56 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 21 Oct 2006 04:51:56 -0500 Subject: How to do Graphics Programming In-Reply-To: <20061021022047.74853.qmail@web36809.mail.mud.yahoo.com> References: <20061021022047.74853.qmail@web36809.mail.mud.yahoo.com> Message-ID: <1161424316.11175.14.camel@max.booze> On Fri, 2006-10-20 at 19:20 -0700, Amit Dey wrote: > But I would prefer to do opengl programming based on the libraries > already provided with fedora core 5. can anyone giveme links about how > to start opengl programming with only opengl library ( I mean no mesa, > no glut ). > > ______________________________________________________________________ Kind of off topic for this list, but the OpenGL API does not cover window management, you *have* to use some other API to get a window open. Either raw Xlib/GLX, or SDL or a toolkit like GTK/ QT/FLTK/wxWidgets. If you're looking to just do some game-style 3D, SDL is your best bet. Otherwise, if you need some GUI around it look into a toolkit. Raw Xlib/GLX is... unnecessary. (GLUT is rather archaic and unmaintained, SDL is a much better and maintained alternative.) -------------- 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 Sat Oct 21 11:22:44 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 21 Oct 2006 12:22:44 +0100 Subject: exclude arch for PPC64 Message-ID: <1161429764.3709.50.camel@T7.Linux> Hi, I keep hitting the same problem when trying to import Xeuphoric into FE in the the PPC 64 bit platform is not supported (none of the 64 bit architectures are currently). What tag do I need to put into the spec to exclude ppc64? TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 alberto.chiodi at gmail.com Sat Oct 21 13:31:14 2006 From: alberto.chiodi at gmail.com (Alberto Chiodi) Date: Sat, 21 Oct 2006 15:31:14 +0200 Subject: Clamav packages and compatibility problems Message-ID: <453A2122.4060302@gmail.com> Good morning I'm an italian end user of Fedora Core 5 and I have problems to update my sistem with yum about clamav packages. I have had the same problem 5-6 (?) months ago when I was a user of Fedora Core 4 and yum tried to upgrade my sistem from 0.88.3 version to 0.88.4 version of clamav packages. Now it's the time for a new upgrade (from the 0.88.4 to 0.88.5 version of clamav) and yum reproposed me questions that seems the same, so I 've decided to solve my doubts and I thinks that now it's a good idea write to you. There is a little problem about extras' rpms and a relevant (?) problem of compatibility between extras' repo and dries' repo, specifically between: http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/linux/5/i386/dries/RPMS/ http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/ My sistem: A notebook with Fedora Core 5 sistem (upgraded from Fc4 with an upgrade by fc5 .iso dvd and yum). I actually use kernel-2.6.18-1.2200.fc5.i686 with Gnome desktop. My actual clamav packages situation: clamav-0.88.4-1.fc5.rf.i386 clamav-data-0.88.4-1.fc5.i386 clamav-db-0.88.4-1.fc5.rf.i386 clamav-lib-0.88.4-1.fc5.i386 clamav-update-0.88.4-1.fc5.i386 clamd-0.88.4-1.fc5.rf.i386 clamtk-2.24-1.fc.noarch As we can see it's a mix of extras' and dries' packages. **************************************************************************************** **************************************************************************************** First little problem: When yum tries to update clamav packages produces this answer: --> Processing Dependency: clamav = 0.88.4-1.fc5.rf for package: clamd --> Finished Dependency Resolution Error: Missing Dependency: clamav = 0.88.4-1.fc5.rf is needed by package clamd and yum ends its work. Clamd is the clamav daemon and it's actually updated only by dries' repo. But "actually" dries' repo is still stop at 0.88.4 version, so I cannot update my clamav sistem without its daemon. So: Please, can you insert in your packages list the clamd daemon too? **************************************************************************************** **************************************************************************************** Second (big?) problem: When I was an user of Fc4 (in the same situation) I decided to remove 0.88.3 version of clamd daemon and I upgraded my clamav packages to 0.88.4 version with yum. At that time my clamav group of packages was only formed of extras' rpms. I waited for the new version of clamd. (two or three weeks :-( ) When it arrived (only on dries' repo) I tried to install it with yum. Yum worked well, but yum required me to change the extras' version of "clamav" package (the "base" package) with dries' version of the same rpm. Yum installed me also the "db" package for solving dependence of the new ".rf" clamav rpm. I thought that it was the same database of extras' "data" package but for security I decided to use both of them. From that time to now (after the upgrade at FC5).....and still now all seems work well. Now I'm here in the same situation that I've still reported, a new version of clamav: the 0.88.5, the same problem about clamd and specially a new substitution of the "clamav-0.88.4-1.fc5.rf.i386" package with the new 0.88.5 version.... but extras' version!!! Ah.... yum wants upgrade only clamav-data packages, not clamav-db package (a dries' rpm) So: I don't want to repeat the experience to remove clamd and wait for it from dries' repo, and also I don't want to wait for a new substitution of extras' version of clamav (base) package with the same version of dries' rpm (and relatives upgrade of "db" dries' version of the database). I want ask to you: What difference are there between "data" and "db" clamav packages? Is there any incompatibility with these two repos, that is: is there a problem of compatibility between this repos, like that between livna's repo and fedora's repo? I don't read anything about this problem on the net. Can you say me any news about these problems? ................. Best regards Alberto Chiodi -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.wickert at nurfuerspam.de Sat Oct 21 13:42:41 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 21 Oct 2006 15:42:41 +0200 Subject: devel package for only two symlinks? Message-ID: <1161438161.8756.12.camel@hal9000.local.lan> According to the reviewing guidelines: - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. But I doubt this doesn't make much sense for symlinks, does it? > ls -l /usr/lib/libfax* > lrwxrwxrwx 1 root root 24 21. Okt 01:43 /usr/lib/libfaxserver.so -> libfaxserver.so.4.3.0.11 > -rwxr-xr-x 1 root root 522520 20. Okt 23:52 /usr/lib/libfaxserver.so.4.3.0.11 > lrwxrwxrwx 1 root root 22 21. Okt 01:43 /usr/lib/libfaxutil.so -> libfaxutil.so.4.3.0.11 > -rwxr-xr-x 1 root root 477344 20. Okt 23:52 /usr/lib/libfaxutil.so.4.3.0.11 Chris -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From pertusus at free.fr Sat Oct 21 14:08:39 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 21 Oct 2006 16:08:39 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161438161.8756.12.camel@hal9000.local.lan> References: <1161438161.8756.12.camel@hal9000.local.lan> Message-ID: <20061021140839.GA2259@free.fr> On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > According to the reviewing guidelines: > - MUST: If a package contains library files with a suffix (e.g. > libfoo.so.1.1), then library files that end in .so (without suffix) must > go in a -devel package. > > But I doubt this doesn't make much sense for symlinks, does it? It makes only sense for symlinks... The .so symlinks pointing to the libraries to be linked against. In any case the .so are only usefull when linking, and in that case there also should be header files. If there are no header file, in most cases in doesn't make sense to package the .so, since nothing links against the library. If something dlopens the library, then .so files are needed, but in that case they shouldn't be in a directory searched for by the linker. > > ls -l /usr/lib/libfax* > > lrwxrwxrwx 1 root root 24 21. Okt 01:43 /usr/lib/libfaxserver.so -> libfaxserver.so.4.3.0.11 > > -rwxr-xr-x 1 root root 522520 20. Okt 23:52 /usr/lib/libfaxserver.so.4.3.0.11 > > lrwxrwxrwx 1 root root 22 21. Okt 01:43 /usr/lib/libfaxutil.so -> libfaxutil.so.4.3.0.11 > > -rwxr-xr-x 1 root root 477344 20. Okt 23:52 /usr/lib/libfaxutil.so.4.3.0.11 -- Pat From christoph.wickert at nurfuerspam.de Sat Oct 21 14:20:18 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 21 Oct 2006 16:20:18 +0200 Subject: devel package for only two symlinks? In-Reply-To: <20061021140839.GA2259@free.fr> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> Message-ID: <1161440419.8756.23.camel@hal9000.local.lan> Am Samstag, den 21.10.2006, 16:08 +0200 schrieb Patrice Dumas: > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > > > But I doubt this doesn't make much sense for symlinks, does it? > > It makes only sense for symlinks... Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel package for these two symlinks. I read your answer an a "yes". Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From rc040203 at freenet.de Sat Oct 21 14:22:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Oct 2006 16:22:51 +0200 Subject: devel package for only two symlinks? In-Reply-To: <20061021140839.GA2259@free.fr> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> Message-ID: <1161440571.19139.35.camel@mccallum.corsepiu.local> On Sat, 2006-10-21 at 16:08 +0200, Patrice Dumas wrote: > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > According to the reviewing guidelines: > > - MUST: If a package contains library files with a suffix (e.g. > > libfoo.so.1.1), then library files that end in .so (without suffix) must > > go in a -devel package. > > > > But I doubt this doesn't make much sense for symlinks, does it? > If something dlopens the library, then .so files are needed, In this generality such a statement is not correct. Which files a dlopen opens is an implementation detail of application/library conventions and diverges largely between packages. It sometimes the files being dlopened are named "*.so", but not always. Theoretically it can be any name. Good designs don't use '*.so'. Ralf From rc040203 at freenet.de Sat Oct 21 14:23:46 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Oct 2006 16:23:46 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161440419.8756.23.camel@hal9000.local.lan> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440419.8756.23.camel@hal9000.local.lan> Message-ID: <1161440627.19139.37.camel@mccallum.corsepiu.local> On Sat, 2006-10-21 at 16:20 +0200, Christoph Wickert wrote: > Am Samstag, den 21.10.2006, 16:08 +0200 schrieb Patrice Dumas: > > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > > > > > But I doubt this doesn't make much sense for symlinks, does it? > > > > It makes only sense for symlinks... > > Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel > package for these two symlinks. I read your answer an a "yes". If these libs are libraries: yes, definitely. Ralf From pertusus at free.fr Sat Oct 21 14:21:06 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 21 Oct 2006 16:21:06 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161440419.8756.23.camel@hal9000.local.lan> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440419.8756.23.camel@hal9000.local.lan> Message-ID: <20061021142106.GB2259@free.fr> > > Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel > package for these two symlinks. I read your answer an a "yes". Yes, because it makes sure that one cannot link against the library unless the -devel package is installed. Otherwise a dependency of a non-devel package and the package itself may bring in library that can be linked against. -- Pat From pertusus at free.fr Sat Oct 21 14:23:10 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 21 Oct 2006 16:23:10 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161440571.19139.35.camel@mccallum.corsepiu.local> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440571.19139.35.camel@mccallum.corsepiu.local> Message-ID: <20061021142310.GC2259@free.fr> On Sat, Oct 21, 2006 at 04:22:51PM +0200, Ralf Corsepius wrote: > On Sat, 2006-10-21 at 16:08 +0200, Patrice Dumas wrote: > > > If something dlopens the library, then .so files are needed, > In this generality such a statement is not correct. You're perfectly right, I should have said that when something dlopens it may be possible that some .so files are needed. -- Pat From wolfy at nobugconsulting.ro Sat Oct 21 15:27:46 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Sat, 21 Oct 2006 18:27:46 +0300 Subject: Clamav packages and compatibility problems In-Reply-To: <453A2122.4060302@gmail.com> References: <453A2122.4060302@gmail.com> Message-ID: <453A3C72.9010900@nobugconsulting.ro> On 10/21/2006 04:31 PM, Alberto Chiodi wrote: > Good morning > > I'm an italian end user of Fedora Core 5 and I have problems to update > my sistem with yum about clamav packages. > I have had the same problem 5-6 (?) months ago when I was a user of > Fedora Core 4 and yum tried to upgrade my sistem from 0.88.3 version > to 0.88.4 version of clamav packages. > Now it's the time for a new upgrade (from the 0.88.4 to 0.88.5 version > of clamav) and yum reproposed me questions that seems the same, so I > 've decided to solve my doubts and I thinks that now it's a good idea > write to you. > There is a little problem about extras' rpms and a relevant (?) > problem of compatibility between extras' repo and dries' repo, > specifically between: > http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/linux/5/i386/dries/RPMS/ > http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/ > > My sistem: > A notebook with Fedora Core 5 sistem (upgraded from Fc4 with an > upgrade by fc5 .iso dvd and yum). > I actually use kernel-2.6.18-1.2200.fc5.i686 with Gnome desktop. > My actual clamav packages situation: > > clamav-0.88.4-1.fc5.rf.i386 > clamav-data-0.88.4-1.fc5.i386 > clamav-db-0.88.4-1.fc5.rf.i386 > clamav-lib-0.88.4-1.fc5.i386 > clamav-update-0.88.4-1.fc5.i386 > clamd-0.88.4-1.fc5.rf.i386 > clamtk-2.24-1.fc.noarch > > As we can see it's a mix of extras' and dries' packages. > > **************************************************************************************** > **************************************************************************************** > First little problem: > > When yum tries to update clamav packages produces this answer: > > --> Processing Dependency: clamav = 0.88.4-1.fc5.rf for package: clamd > --> Finished Dependency Resolution > Error: Missing Dependency: clamav = 0.88.4-1.fc5.rf is needed by > package clamd > and yum ends its work. > > Clamd is the clamav daemon and it's actually updated only by dries' repo. Fortunately, you are wrong :) Please see my comments below . > But "actually" dries' repo is still stop at 0.88.4 version, so I > cannot update my clamav sistem without its daemon. The strange part is that the source rpm has been updated Oct 16th. No idea why the binaries are not yet included for this version > So: Please, can you insert in your packages list the clamd daemon too? It is.... in clamav-server. > > **************************************************************************************** > **************************************************************************************** > Second (big?) problem: > > When I was an user of Fc4 (in the same situation) I decided to remove > 0.88.3 version of clamd daemon and I upgraded my clamav packages to > 0.88.4 version with yum. > At that time my clamav group of packages was only formed of extras' rpms. > I waited for the new version of clamd. (two or three weeks :-( ) > When it arrived (only on dries' repo) I tried to install it with yum. > Yum worked well, but yum required me to change the extras' version of > "clamav" package (the "base" package) with dries' version of the same rpm. > Yum installed me also the "db" package for solving dependence of the > new ".rf" clamav rpm. > I thought that it was the same database of extras' "data" package but > for security I decided to use both of them. > >From that time to now (after the upgrade at FC5).....and still now > all seems work well. > Now I'm here in the same situation that I've still reported, a new > version of clamav: the 0.88.5, the same problem about clamd and > specially a new substitution of the "clamav-0.88.4-1.fc5.rf.i386" > package with the new 0.88.5 version.... but extras' version!!! > Ah.... yum wants upgrade only clamav-data packages, not clamav-db > package (a dries' rpm) > So: I don't want to repeat the experience to remove clamd and wait for > it from dries' repo, and also I don't want to wait for a new > substitution of extras' version of clamav (base) package with the same > version of dries' rpm (and relatives upgrade of "db" dries' version of > the database). > > I want ask to you: > What difference are there between "data" and "db" clamav packages? > Is there any incompatibility with these two repos, that is: is there a > problem of compatibility between this repos, like that between livna's > repo and fedora's repo? > I don't read anything about this problem on the net. > Can you say me any news about these problems? > ................. > > Best regards > > Alberto Chiodi Take it with a bit of salt, but I suggest you only use the packages from extras. The reason is that, as you have already noticed, the two versions are differently organized, but overlap partially. Each one of them provides all the needed pieces of information, but the one in extras is [of course :) ] closer to the standard way in which RH/FC packages are /should be organized. In your case, IF you actually need it, clamd is provided by the clamav-server package. From alberto.chiodi at gmail.com Sat Oct 21 16:20:08 2006 From: alberto.chiodi at gmail.com (Alberto Chiodi) Date: Sat, 21 Oct 2006 18:20:08 +0200 Subject: Clamav packages and compatibility problems In-Reply-To: <453A3C72.9010900@nobugconsulting.ro> References: <453A2122.4060302@gmail.com> <453A3C72.9010900@nobugconsulting.ro> Message-ID: <453A48B8.7060302@gmail.com> lonely wolf wrote: > > It is.... in clamav-server. Ok.... thank's a lot.... :-D ....................................... > Take it with a bit of salt, but I suggest you only use the packages > from extras. > The reason is that, as you have already noticed, the two versions are > differently organized, but overlap partially. Each one of them > provides all the needed pieces of information, but the one in extras > is [of course :) ] closer to the standard way in which RH/FC packages > are /should be organized. > In your case, IF you actually need it, clamd is provided by the > clamav-server package. > Ok.... I'll do so. Excuse me, if I have used improperly this "professional" list, but I thought that it was a general problem not only an end-user problem. I use Fedora from three years. I have learned to use unix/linux (Fedora core) during my thesis work in Brera Astronomy Observatory and now I use it in my private notebook. On the net I discovered and use many useful instructions for install and use Fedora sistem. Particularly this site: http://stanton-finley.net/fedora_core_5_installation_notes.html ....a site that I think many end-user known very well. From this site I learned notices about Fedora repo's problem (Livna's repos, Atrpm's repos versus other repos....) Also in this site (like in fedora's forum) I've learned about use of yum and about compatibility with fedora core's repo. Like many and many others end-users. So I don't expect to have "stable" problems with identical group of packages of different but "recommended" repos. (Naturally I don't think that Mr. Finley or others want damage Fedora group or their users) I think that actually there is too confusion on this side. Linux has still many distributions.... if now we see also the multiplication of version of the same packages in the same distributions..... ............I don't write any more!!! I only say that I DON'T want use Windows XP that I HAVE HAD to buy with my notebook. I'm gratefully to you for your answer and to the other partecipant at the list for your ospitality. Hi Alberto Chiodi -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Sat Oct 21 16:27:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 Oct 2006 18:27:48 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161440627.19139.37.camel@mccallum.corsepiu.local> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440419.8756.23.camel@hal9000.local.lan> <1161440627.19139.37.camel@mccallum.corsepiu.local> Message-ID: <20061021182748.4e26be6c.bugs.michael@gmx.net> On Sat, 21 Oct 2006 16:23:46 +0200, Ralf Corsepius wrote: > On Sat, 2006-10-21 at 16:20 +0200, Christoph Wickert wrote: > > Am Samstag, den 21.10.2006, 16:08 +0200 schrieb Patrice Dumas: > > > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > > > > > > > But I doubt this doesn't make much sense for symlinks, does it? > > > > > > It makes only sense for symlinks... > > > > Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel > > package for these two symlinks. I read your answer an a "yes". > > If these libs are libraries: yes, definitely. Where's the API then? Unless I misread Christoph's question, there are _only_ two symlinks, but not headers. In that case, something is broken terribly. In case this is a library without a public API, it doesn't make sense to put the .so symlinks into a separate -devel package. It must be examined whether the .so "names" are needed at run-time, e.g. for dlopen. So, what package is this about? From otaylor at redhat.com Sat Oct 21 17:27:33 2006 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 21 Oct 2006 13:27:33 -0400 Subject: Putting the mugshot client in fedora-extras Message-ID: <1161451653.18331.41.camel@huygens.localdomain> So, for a while we've been thinking about adding the client software for Mugshot (http://mugshot.org) to fedora-extras. Both the client and server are GPL software, so the client is definitely within the scope of fedora-extras. We see various advantages to us and our users from having it there: - Building our Fedora Core packages within a real build system, rather than on an ad-hoc basis. - Providing packages for multiple architectures. - Providing packages for multiple distributions (the client requires firefox-devel or hacks to build, so right now FC6 is the only target, but FC7 will be along soon enough.) *however* - updates are more of a challenge, because we're still changing things rapidly and the client software is tightly coupled to the server software; when we add new features, there is often both a client part and a server part. The way handle this currently is that when the client connects to the server, it queries the server for the current client version, and when appropriate, offers the user a chance to download a new RPM and install it via system-install-packages. If we put the client software into the FE build system before the corresponding server version is pushed to the production servers, then some users would get upgraded via yum to the new client software before the push of the server software. Since the server backend for new client features isn't there yet, the client will likely misbehave in weird ways. On the other hand, if we wait until after the server push to put the software into the build system, there will a considerable lag before the new client versions are available; we won't be able to offer our users an immediate upgrade to the new version. This is a bit better than the previous situation ... we try to make old clients work with new servers, but still the user experience isn't what we want. Some ideas that occur to me for handling the situation: - We could try to time the server push to coincide with when the packages appear in the fedora-extras - that is, we get the client ready, we get the server ready, we put the client version into the build system, and we sit on our browsers reload button, and when the software appears on download.fedora.redhat.com, we do the server upgrade. (There is an obvious conceptual problem here that this only works when there is one such build system - we couldn't do it for both Fedora Extras and Ubuntu Universe, say!) Does the daily update of the repository occur at a predictable time? - If we could simply get the mugshot client excluded from the creation of the fedora-extras yum repository metadata, then we could build packages ahead of time, and later offer them through our current upgrade process. (or through our own yum repository.) Would it be completely ridiculous to ask that createrepo be run for the FE repository with --exclude=mugshot* ? Do people have other ideas about how it could work? Thanks! - Owen From christoph.wickert at nurfuerspam.de Sat Oct 21 18:01:59 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 21 Oct 2006 20:01:59 +0200 Subject: devel package for only two symlinks? In-Reply-To: <20061021182748.4e26be6c.bugs.michael@gmx.net> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440419.8756.23.camel@hal9000.local.lan> <1161440627.19139.37.camel@mccallum.corsepiu.local> <20061021182748.4e26be6c.bugs.michael@gmx.net> Message-ID: <1161453719.8756.27.camel@hal9000.local.lan> Am Samstag, den 21.10.2006, 18:27 +0200 schrieb Michael Schwendt: > On Sat, 21 Oct 2006 16:23:46 +0200, Ralf Corsepius wrote: > > > On Sat, 2006-10-21 at 16:20 +0200, Christoph Wickert wrote: > > > Am Samstag, den 21.10.2006, 16:08 +0200 schrieb Patrice Dumas: > > > > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > > > > > > > > > But I doubt this doesn't make much sense for symlinks, does it? > > > > > > > > It makes only sense for symlinks... > > > > > > Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel > > > package for these two symlinks. I read your answer an a "yes". > > > > If these libs are libraries: yes, definitely. > > Where's the API then? > > Unless I misread Christoph's question, there are _only_ two symlinks, > but not headers. In that case, something is broken terribly. > > In case this is a library without a public API, it doesn't make sense > to put the .so symlinks into a separate -devel package. It must be examined > whether the .so "names" are needed at run-time, e.g. for dlopen. > > So, what package is this about? It's from the hylafax review, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188542 Christoph -- Please do not send private messages to this address, it is not being monitored. Bitte keine pers?nlichen Nachrichten an diese Adresse senden, sie wird nicht ?berwacht. From bugs.michael at gmx.net Sat Oct 21 19:03:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 Oct 2006 21:03:13 +0200 Subject: devel package for only two symlinks? In-Reply-To: <1161453719.8756.27.camel@hal9000.local.lan> References: <1161438161.8756.12.camel@hal9000.local.lan> <20061021140839.GA2259@free.fr> <1161440419.8756.23.camel@hal9000.local.lan> <1161440627.19139.37.camel@mccallum.corsepiu.local> <20061021182748.4e26be6c.bugs.michael@gmx.net> <1161453719.8756.27.camel@hal9000.local.lan> Message-ID: <20061021210313.6d2fe9b8.bugs.michael@gmx.net> On Sat, 21 Oct 2006 20:01:59 +0200, Christoph Wickert wrote: > Am Samstag, den 21.10.2006, 18:27 +0200 schrieb Michael Schwendt: > > On Sat, 21 Oct 2006 16:23:46 +0200, Ralf Corsepius wrote: > > > > > On Sat, 2006-10-21 at 16:20 +0200, Christoph Wickert wrote: > > > > Am Samstag, den 21.10.2006, 16:08 +0200 schrieb Patrice Dumas: > > > > > On Sat, Oct 21, 2006 at 03:42:41PM +0200, Christoph Wickert wrote: > > > > > > > > > > > > But I doubt this doesn't make much sense for symlinks, does it? > > > > > > > > > > It makes only sense for symlinks... > > > > > > > > Yeah, sorry, I know. What i wanted to ask is: Do we really need a devel > > > > package for these two symlinks. I read your answer an a "yes". > > > > > > If these libs are libraries: yes, definitely. > > > > Where's the API then? > > > > Unless I misread Christoph's question, there are _only_ two symlinks, > > but not headers. In that case, something is broken terribly. > > > > In case this is a library without a public API, it doesn't make sense > > to put the .so symlinks into a separate -devel package. It must be examined > > whether the .so "names" are needed at run-time, e.g. for dlopen. > > > > So, what package is this about? > > It's from the hylafax review, > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188542 Oh, hylafax indeed. Then you must include them in the main package, because "rpm --query --requires hylafax" lists them. The SONAME of the library files does not contain a version (search the build log for "soname"). Hylafax is linked against "libfaxutil.so" and "libfaxserver.so" and requires them at run-time. It is an upstream bug (well, misconception) that the *.so symlinks point to versioned library file names, which are not accessed directly. [It is also not good that the non-versioned *.so libraries are installed into run-time linker's default search path and use a generic name that is not in "hylafax" namespace. Any "libfaxutil-devel" package would conflict with the *.so links in "hylafax" even if it used a much lower/higher library version.] From chris.stone at gmail.com Sat Oct 21 19:24:37 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 21 Oct 2006 12:24:37 -0700 Subject: exclude arch for PPC64 In-Reply-To: <1161429764.3709.50.camel@T7.Linux> References: <1161429764.3709.50.camel@T7.Linux> Message-ID: On 10/21/06, Paul wrote: > Hi, > > I keep hitting the same problem when trying to import Xeuphoric into FE > in the the PPC 64 bit platform is not supported (none of the 64 bit > architectures are currently). > > What tag do I need to put into the spec to exclude ppc64? > > TTFN > > Paul Does ExcludeArch: ppc64 work? From paul at all-the-johnsons.co.uk Sat Oct 21 19:35:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 21 Oct 2006 20:35:23 +0100 Subject: exclude arch for PPC64 In-Reply-To: References: <1161429764.3709.50.camel@T7.Linux> Message-ID: <1161459323.3709.74.camel@T7.Linux> On Sat, 2006-10-21 at 12:24 -0700, Christopher Stone wrote: > Does ExcludeArch: ppc64 work? No. That's what I'm currently using. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 packages at amiga-hardware.com Sat Oct 21 20:01:40 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 21 Oct 2006 21:01:40 +0100 Subject: exclude arch for PPC64 In-Reply-To: <1161459323.3709.74.camel@T7.Linux> References: <1161429764.3709.50.camel@T7.Linux> <1161459323.3709.74.camel@T7.Linux> Message-ID: <453A7CA4.9020306@amiga-hardware.com> Paul wrote: > On Sat, 2006-10-21 at 12:24 -0700, Christopher Stone wrote: > >> Does ExcludeArch: ppc64 work? > > No. That's what I'm currently using. Looking at the rpm configs, it makes lots of references to ppc64, so I think it *should* work. Why it isn't though, I dunno. There's also ppc64pseries and ppc64iseries -- Ian Chapman. From paul at all-the-johnsons.co.uk Sat Oct 21 20:03:12 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 21 Oct 2006 21:03:12 +0100 Subject: exclude arch for PPC64 In-Reply-To: <453A7CA4.9020306@amiga-hardware.com> References: <1161429764.3709.50.camel@T7.Linux> <1161459323.3709.74.camel@T7.Linux> <453A7CA4.9020306@amiga-hardware.com> Message-ID: <1161460992.3709.76.camel@T7.Linux> On Sat, 2006-10-21 at 21:01 +0100, Ian Chapman wrote: > Paul wrote: > > On Sat, 2006-10-21 at 12:24 -0700, Christopher Stone wrote: > > > >> Does ExcludeArch: ppc64 work? > > > > No. That's what I'm currently using. > > Looking at the rpm configs, it makes lots of references to ppc64, so I > think it *should* work. Why it isn't though, I dunno. I've got to file something else into BZ, I'll stick that one in as well. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Sat Oct 21 20:08:40 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Oct 2006 15:08:40 -0500 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161451653.18331.41.camel@huygens.localdomain> References: <1161451653.18331.41.camel@huygens.localdomain> Message-ID: <1161461320.608.11.camel@vader.jdub.homelinux.org> On Sat, 2006-10-21 at 13:27 -0400, Owen Taylor wrote: > So, for a while we've been thinking about adding the client software > for Mugshot (http://mugshot.org) to fedora-extras. Both the client > and server are GPL software, so the client is definitely within the > scope of fedora-extras. We see various advantages to us and our users > from having it there: > > - Building our Fedora Core packages within a real build system, rather > than on an ad-hoc basis. > > - Providing packages for multiple architectures. > > - Providing packages for multiple distributions (the client requires > firefox-devel or hacks to build, so right now FC6 is the only target, > but FC7 will be along soon enough.) > > *however* - updates are more of a challenge, because we're still > changing things rapidly and the client software is tightly coupled to > the server software; when we add new features, there is often both a > client part and a server part. > > The way handle this currently is that when the client connects to the > server, it queries the server for the current client version, and > when appropriate, offers the user a chance to download a new RPM and > install it via system-install-packages. > > If we put the client software into the FE build system before the > corresponding server version is pushed to the production servers, then > some users would get upgraded via yum to the new client software before > the push of the server software. Since the server backend for new > client features isn't there yet, the client will likely misbehave > in weird ways. > > On the other hand, if we wait until after the server push to put the > software into the build system, there will a considerable lag before > the new client versions are available; we won't be able to offer our > users an immediate upgrade to the new version. This is a bit better > than the previous situation ... we try to make old clients work with > new servers, but still the user experience isn't what we want. > > Some ideas that occur to me for handling the situation: > > - We could try to time the server push to coincide with when the > packages appear in the fedora-extras - that is, we get the > client ready, we get the server ready, we put the client version > into the build system, and we sit on our browsers reload button, > and when the software appears on download.fedora.redhat.com, > we do the server upgrade. > > (There is an obvious conceptual problem here that this only works > when there is one such build system - we couldn't do it for both > Fedora Extras and Ubuntu Universe, say!) > > Does the daily update of the repository occur at a predictable > time? > > - If we could simply get the mugshot client excluded from the > creation of the fedora-extras yum repository metadata, then we > could build packages ahead of time, and later offer them through our > current upgrade process. (or through our own yum repository.) > > Would it be completely ridiculous to ask that createrepo be run > for the FE repository with --exclude=mugshot* ? > > Do people have other ideas about how it could work? Add a handshake to both the server and the client for features. The client says "do you support ?", the server says "wtf is ?", the client then disables it at runtime. That way you don't have to worry about newer clients acting in weird ways. Or maybe I'm missing where that would be very hard to do... josh From peter at thecodergeek.com Sat Oct 21 20:29:46 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 21 Oct 2006 13:29:46 -0700 (PDT) Subject: rpms/libburn/devel .cvsignore, 1.2, 1.3 libburn.spec, 1.2, 1.3 sources, 1.3, 1.4 In-Reply-To: <200610211941.k9LJfgO6003037@cvs-int.fedora.redhat.com> References: <200610211941.k9LJfgO6003037@cvs-int.fedora.redhat.com> Message-ID: <1498.207.233.85.229.1161462586.squirrel@thecodergeek.com> Jesse Keating wrote: [...] > -Source0: %{name}-%{version}svn.tar.gz > +Source0: %{name}-%{version}.tar.gz Now that's an actual release from their site, this should be a fully-qualified URL to the source tarball from upstream, right? Source0: http://libburn-download.pykix.org/releases/%{name}-%{version}.tar.gz ...or something similar. Thanks, Jesse. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From bugs.michael at gmx.net Sat Oct 21 21:32:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 Oct 2006 23:32:19 +0200 Subject: RFC: Junk in Fedora Extras Message-ID: <20061021233219.23b1c35a.bugs.michael@gmx.net> So far, we have been running "repomanage" on the Fedora Extras repository trees to get rid of old package releases automatically. In development, we keep only the latest release, for older trees we keep at most two releases. However, occasionally I've run into obsolete/orphaned sub-packages where the packager changed the BuildArch or deleted a sub-package without asking the repository staff to delete old package releases manually. It can also happen that the package removal requests, which are processed by humans, lead to incomplete removal of packages, when e.g. "debuginfo" packages are not removed or version-information was misleading. The resulting obsolete package releases live in the repository forever, as repomanage will never decide to delete them. As a solution, I've looked into porting my old Perl rpm-expire script to Python -- I've lost the script in the single place where it was running and have only recovered an early prototype I'm not satisfactory with. The technique is based on this: * We build from src.rpm packages. * For all binary rpms there must be a corresponding src.rpm. * The src.rpm name is in the %{sourcerpm} header of a binary rpm. * If the src.rpm for a binary rpm in the repository does not exist, where does the binary rpm come from? --> We delete it! * Instead of expiring arbitrary packages based on "number of pkgs found", we expire only src.rpms and clean up the binary rpms based on whether their src.rpms still exist. Running a quick hack of this on the current FE repositories, it creates a long list of "lost souls" as appended below. I've checked a few already and so far could not find any false positives. Of course, letting such a script remove these packages automatically actually, will require a few good sanity checks, so run-time errors don't empty the entire repository. ;) [...] This is the full list of binary rpms, which do not have a corresponding src.rpm in the repository: Expiring (keep = 1): /extras/development/SRPMS Skipping em8300-kmod Skipping sysprof-kmod Pruning: /extras/development/ppc Macaulay2-0.9.8-0.3.cvs20060327.fc6.ppc.rpm clearlooks-0.5-1.ppc.rpm dhcp-forwarder-0.7-7.fc5.ppc.rpm dhcp-forwarder-sysv-0.7-7.fc5.ppc.rpm dietlibc-0.29-4.fc5.ppc.rpm gnome-applet-netmon-0.4-3.ppc.rpm gnome-theme-clearlooks-0.5-3.ppc.rpm gprolog-1.2.19-5.fc6.ppc.rpm gprolog-docs-1.2.19-5.fc6.ppc.rpm gprolog-examples-1.2.19-5.fc6.ppc.rpm pessulus-2.16.0-4.fc6.ppc.rpm ip-sentinel-0.12-5.fc5.ppc.rpm ip-sentinel-sysv-0.12-5.fc5.ppc.rpm libc-client2004g-2004g-6.fc6.ppc.rpm cobbler-0.1.1-8.fc6.noarch.rpm python-simpletal-3.12-1.ppc.rpm perl-Alien-wxWidgets-0.21-1.fc6.noarch.rpm util-vserver-build-0.30.208-1.fc5.ppc.rpm util-vserver-0.30.208-1.fc5.ppc.rpm util-vserver-devel-0.30.208-1.fc5.ppc.rpm util-vserver-core-0.30.208-1.fc5.ppc.rpm util-vserver-legacy-0.30.208-1.fc5.ppc.rpm util-vserver-lib-0.30.208-1.fc5.ppc.rpm util-vserver-sysv-0.30.208-1.fc5.ppc.rpm Macaulay2-debuginfo-0.9.8-0.3.cvs20060327.fc6.ppc.rpm clearlooks-debuginfo-0.5-1.ppc.rpm dhcp-forwarder-debuginfo-0.7-7.fc5.ppc.rpm dietlibc-debuginfo-0.29-4.fc5.ppc.rpm gnome-applet-netmon-debuginfo-0.4-3.ppc.rpm gnome-theme-clearlooks-debuginfo-0.5-3.ppc.rpm gprolog-debuginfo-1.2.19-5.fc6.ppc.rpm db4o-debuginfo-5.5-8.fc6.ppc.rpm ip-sentinel-debuginfo-0.12-5.fc5.ppc.rpm python-psyco-debuginfo-1.4-1.ppc.rpm python-simpletal-debuginfo-3.12-1.ppc.rpm util-vserver-debuginfo-0.30.208-1.fc5.ppc.rpm perl-Alien-wxWidgets-debuginfo-0.21-3.fc6.ppc.rpm Pruning: /extras/development/x86_64 pessulus-2.16.0-4.fc6.x86_64.rpm libc-client2004g-2004g-6.fc6.x86_64.rpm perl-Unicode-Map8-0.12-7.fc5.x86_64.rpm perl-Unicode-MapUTF8-1.09-6.fc5.noarch.rpm perl-Alien-wxWidgets-0.21-1.fc6.noarch.rpm db4o-debuginfo-5.5-8.fc6.x86_64.rpm perl-Unicode-Map8-debuginfo-0.12-7.fc5.x86_64.rpm perl-Alien-wxWidgets-debuginfo-0.21-3.fc6.x86_64.rpm Pruning: /extras/development/i386 pessulus-2.16.0-4.fc6.i386.rpm libc-client2004g-2004g-6.fc6.i386.rpm perl-Alien-wxWidgets-0.21-1.fc6.noarch.rpm db4o-debuginfo-5.5-8.fc6.i386.rpm perl-Alien-wxWidgets-debuginfo-0.21-3.fc6.i386.rpm Expiring (keep = 2): /extras/5/SRPMS Skipping em8300-kmod Skipping sysprof-kmod Pruning: /extras/5/ppc apmud-1.0.0-1.ppc.rpm perl-Alien-wxWidgets-0.21-1.fc5.noarch.rpm lat-1.0.6-1.fc5.noarch.rpm nabi-0.14-4.ppc.rpm python-reportlab-1.20-1.fc4.ppc.rpm qof-docs-0.6.4-3.fc5.ppc.rpm scim-bridge-gtkimm-0.1.12-1.fc5.ppc.rpm clearlooks-0.5-1.ppc.rpm dhcp-forwarder-0.7-7.fc5.ppc.rpm dhcp-forwarder-sysv-0.7-7.fc5.ppc.rpm dietlibc-0.29-4.fc5.ppc.rpm gnome-applet-netmon-0.4-3.ppc.rpm gnome-theme-clearlooks-0.5-3.ppc.rpm ip-sentinel-0.12-5.fc5.ppc.rpm ip-sentinel-sysv-0.12-5.fc5.ppc.rpm libc-client2004g-2004g-4.fc5.2.ppc.rpm python-simpletal-3.12-1.ppc.rpm util-vserver-0.30.208-1.fc5.ppc.rpm util-vserver-build-0.30.208-1.fc5.ppc.rpm util-vserver-core-0.30.208-1.fc5.ppc.rpm util-vserver-devel-0.30.208-1.fc5.ppc.rpm util-vserver-legacy-0.30.208-1.fc5.ppc.rpm util-vserver-lib-0.30.208-1.fc5.ppc.rpm util-vserver-sysv-0.30.208-1.fc5.ppc.rpm scim-bridge-gtkimm-0.1.12-1.fc5.1.ppc.rpm php-eaccelerator-5.1.4_0.9.5-1.fc5.ppc.rpm R-mAr-debuginfo-1.1-3.fc5.ppc.rpm abicheck-debuginfo-1.2-5.ppc.rpm apmud-debuginfo-1.0.0-1.ppc.rpm ikvm-debuginfo-0.22-5.fc5.ppc.rpm ikvm-debuginfo-0.22-7.fc5.ppc.rpm nabi-debuginfo-0.14-4.ppc.rpm perl-Alien-wxWidgets-debuginfo-0.21-2.fc5.ppc.rpm python-reportlab-debuginfo-1.20-1.fc4.ppc.rpm clearlooks-debuginfo-0.5-1.ppc.rpm dhcp-forwarder-debuginfo-0.7-7.fc5.ppc.rpm dietlibc-debuginfo-0.29-4.fc5.ppc.rpm gnome-applet-netmon-debuginfo-0.4-3.ppc.rpm gnome-theme-clearlooks-debuginfo-0.5-3.ppc.rpm ip-sentinel-debuginfo-0.12-5.fc5.ppc.rpm python-psyco-debuginfo-1.4-1.ppc.rpm python-simpletal-debuginfo-3.12-1.ppc.rpm util-vserver-debuginfo-0.30.208-1.fc5.ppc.rpm php-eaccelerator-debuginfo-5.1.4_0.9.5-1.fc5.ppc.rpm Pruning: /extras/5/x86_64 perl-Alien-wxWidgets-0.21-1.fc5.noarch.rpm kphone-4.2-6.fc5.x86_64.rpm lvcool-1.0.0-1.x86_64.rpm qof-docs-0.6.4-3.fc5.x86_64.rpm scim-bridge-gtkimm-0.1.12-1.fc5.x86_64.rpm tpb-0.6.3-2.x86_64.rpm lat-1.0.6-1.fc5.noarch.rpm amaya-8.5-2.x86_64.rpm libc-client2004g-2004g-4.fc5.2.x86_64.rpm perl-Unicode-Map8-0.12-7.fc5.x86_64.rpm soundtracker-0.6.7-3.x86_64.rpm scim-bridge-gtkimm-0.1.12-1.fc5.1.x86_64.rpm php-eaccelerator-5.1.4_0.9.5-1.fc5.x86_64.rpm R-mAr-debuginfo-1.1-3.fc5.x86_64.rpm abicheck-debuginfo-1.2-5.x86_64.rpm ikvm-debuginfo-0.22-5.fc5.x86_64.rpm ikvm-debuginfo-0.22-7.fc5.x86_64.rpm kphone-debuginfo-4.2-6.fc5.x86_64.rpm lvcool-debuginfo-1.0.0-1.x86_64.rpm maxima-debuginfo-5.9.1-4.fc5.x86_64.rpm perl-Alien-wxWidgets-debuginfo-0.21-2.fc5.x86_64.rpm tpb-debuginfo-0.6.3-2.x86_64.rpm amaya-debuginfo-8.5-2.x86_64.rpm perl-Unicode-Map8-debuginfo-0.12-7.fc5.x86_64.rpm soundtracker-debuginfo-0.6.7-3.x86_64.rpm php-eaccelerator-debuginfo-5.1.4_0.9.5-1.fc5.x86_64.rpm Pruning: /extras/5/i386 perl-Alien-wxWidgets-0.21-1.fc5.noarch.rpm lat-1.0.6-1.fc5.noarch.rpm qof-docs-0.6.4-3.fc5.i386.rpm scim-bridge-gtkimm-0.1.12-1.fc5.i386.rpm libc-client2004g-2004g-4.fc5.2.i386.rpm scim-bridge-gtkimm-0.1.12-1.fc5.1.i386.rpm php-eaccelerator-5.1.4_0.9.5-1.fc5.i386.rpm R-mAr-debuginfo-1.1-3.fc5.i386.rpm abicheck-debuginfo-1.2-5.i386.rpm ikvm-debuginfo-0.22-5.fc5.i386.rpm ikvm-debuginfo-0.22-7.fc5.i386.rpm maxima-debuginfo-5.9.1-4.fc5.i386.rpm perl-Alien-wxWidgets-debuginfo-0.21-2.fc5.i386.rpm php-eaccelerator-debuginfo-5.1.4_0.9.5-1.fc5.i386.rpm Expiring (keep = 2): /extras/4/SRPMS Pruning: /extras/4/ppc check-0.9.3-1.fc4.ppc.rpm php-mmcache-5.0.4_2.4.6-8.fc4.ppc.rpm php-eaccelerator-5.0.4_0.9.4-2.fc4.ppc.rpm nabi-0.14-4.ppc.rpm php-eaccelerator-5.0.4_0.9.4-1.fc4.ppc.rpm php-mmcache-5.0.4_2.4.6-7.fc4.ppc.rpm python-simpletal-3.12-1.ppc.rpm R-mAr-debuginfo-1.1-3.fc4.ppc.rpm abicheck-debuginfo-1.2-5.ppc.rpm nabi-debuginfo-0.14-4.ppc.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-1.fc4.ppc.rpm php-mmcache-debuginfo-5.0.4_2.4.6-7.fc4.ppc.rpm python-psyco-debuginfo-1.4-1.ppc.rpm python-simpletal-debuginfo-3.12-1.ppc.rpm php-mmcache-debuginfo-5.0.4_2.4.6-8.fc4.ppc.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-2.fc4.ppc.rpm Pruning: /extras/4/x86_64 amaya-8.5-2.x86_64.rpm check-0.9.3-1.fc4.x86_64.rpm php-eaccelerator-5.0.4_0.9.4-1.fc4.x86_64.rpm php-mmcache-5.0.4_2.4.6-7.fc4.x86_64.rpm soundtracker-0.6.7-3.x86_64.rpm php-mmcache-5.0.4_2.4.6-8.fc4.x86_64.rpm php-eaccelerator-5.0.4_0.9.4-2.fc4.x86_64.rpm tpb-0.6.3-2.x86_64.rpm R-mAr-debuginfo-1.1-3.fc4.x86_64.rpm abicheck-debuginfo-1.2-5.x86_64.rpm amaya-debuginfo-8.5-2.x86_64.rpm maxima-debuginfo-5.9.1-4.fc4.x86_64.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-1.fc4.x86_64.rpm php-mmcache-debuginfo-5.0.4_2.4.6-7.fc4.x86_64.rpm soundtracker-debuginfo-0.6.7-3.x86_64.rpm tpb-debuginfo-0.6.3-2.x86_64.rpm php-mmcache-debuginfo-5.0.4_2.4.6-8.fc4.x86_64.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-2.fc4.x86_64.rpm Pruning: /extras/4/i386 check-0.9.3-1.fc4.i386.rpm php-eaccelerator-5.0.4_0.9.4-1.fc4.i386.rpm php-mmcache-5.0.4_2.4.6-7.fc4.i386.rpm php-mmcache-5.0.4_2.4.6-8.fc4.i386.rpm php-eaccelerator-5.0.4_0.9.4-2.fc4.i386.rpm R-mAr-debuginfo-1.1-3.fc4.i386.rpm abicheck-debuginfo-1.2-5.i386.rpm maxima-debuginfo-5.9.1-4.fc4.i386.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-1.fc4.i386.rpm php-mmcache-debuginfo-5.0.4_2.4.6-7.fc4.i386.rpm php-mmcache-debuginfo-5.0.4_2.4.6-8.fc4.i386.rpm php-eaccelerator-debuginfo-5.0.4_0.9.4-2.fc4.i386.rpm Expiring (keep = 2): /extras/3/SRPMS Pruning: /extras/3/x86_64 check-0.9.3-1.fc3.x86_64.rpm ghc-doc-6.4-1.fc3.x86_64.rpm ghc64-6.4-1.fc3.x86_64.rpm ghc64-prof-6.4-1.fc3.x86_64.rpm libtidy-0.99.0-2.20040916.x86_64.rpm libtidy-devel-0.99.0-2.20040916.x86_64.rpm plone-2.1-0.1.alpha2.fc3.noarch.rpm python-reportlab-1.19-2.x86_64.rpm revelation-0.3.4-1.noarch.rpm torcs-data-cars-Patwo-Design-1.2.2-1.noarch.rpm tidy-0.99.0-2.20040916.x86_64.rpm torcs-data-cars-kcendra-gt-1.2.2-1.noarch.rpm torcs-data-cars-VM-1.2.2-1.noarch.rpm torcs-data-cars-kcendra-roadsters-1.2.2-1.noarch.rpm torcs-data-cars-kcendra-sport-1.2.2-1.noarch.rpm torque-localhost-2.1.0p0-2.fc3.x86_64.rpm abicheck-debuginfo-1.2-3.x86_64.rpm maxima-debuginfo-5.9.1-4.fc3.x86_64.rpm python-reportlab-debuginfo-1.19-2.x86_64.rpm tidy-debuginfo-0.99.0-2.20040916.x86_64.rpm Pruning: /extras/3/i386 allegro-4.0.3-7.i386.rpm allegro-devel-4.0.3-7.i386.rpm allegro-tools-4.0.3-7.i386.rpm check-0.9.3-1.fc3.i386.rpm epydoc-2.1-2.i386.rpm ghc-doc-6.4-1.fc3.i386.rpm ghc64-6.4-1.fc3.i386.rpm ghc64-prof-6.4-1.fc3.i386.rpm gnome-vfsmm26-2.6.1-1.i386.rpm gnome-vfsmm26-devel-2.6.1-1.i386.rpm libgnomemm26-devel-2.6.0-1.i386.rpm libgnomemm26-2.6.0-1.i386.rpm libgnomeuimm26-devel-2.6.0-1.i386.rpm libgnomeuimm26-2.6.0-1.i386.rpm plone-2.1-0.1.alpha2.fc3.noarch.rpm revelation-0.3.4-1.noarch.rpm torcs-data-cars-kcendra-roadsters-1.2.2-1.noarch.rpm torcs-data-cars-Patwo-Design-1.2.2-1.noarch.rpm torcs-data-cars-VM-1.2.2-1.noarch.rpm torcs-data-cars-kcendra-gt-1.2.2-1.noarch.rpm torcs-data-cars-kcendra-sport-1.2.2-1.noarch.rpm torque-localhost-2.1.0p0-2.fc3.i386.rpm wxGTK-2.4.2-7.i386.rpm wxGTK-common-2.4.2-7.i386.rpm wxGTK-common-devel-2.4.2-7.i386.rpm wxGTK-devel-2.4.2-7.i386.rpm wxGTK-gl-2.4.2-7.i386.rpm wxGTK-stc-2.4.2-7.i386.rpm wxGTK-xrc-2.4.2-7.i386.rpm wxGTK2-2.4.2-7.i386.rpm wxGTK2-devel-2.4.2-7.i386.rpm wxGTK2-gl-2.4.2-7.i386.rpm wxGTK2-stc-2.4.2-7.i386.rpm wxGTK2-xrc-2.4.2-7.i386.rpm xtide-2.8-1.i386.rpm abicheck-debuginfo-1.2-3.i386.rpm allegro-debuginfo-4.0.3-7.i386.rpm epydoc-debuginfo-2.1-2.i386.rpm gnome-vfsmm26-debuginfo-2.6.1-1.i386.rpm libgnomemm26-debuginfo-2.6.0-1.i386.rpm libgnomeuimm26-debuginfo-2.6.0-1.i386.rpm maxima-debuginfo-5.9.1-4.fc3.i386.rpm wxGTK-debuginfo-2.4.2-7.i386.rpm xtide-debuginfo-2.8-1.i386.rpm From otaylor at redhat.com Sat Oct 21 21:39:50 2006 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 21 Oct 2006 17:39:50 -0400 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161461320.608.11.camel@vader.jdub.homelinux.org> References: <1161451653.18331.41.camel@huygens.localdomain> <1161461320.608.11.camel@vader.jdub.homelinux.org> Message-ID: <1161466790.18331.57.camel@huygens.localdomain> On Sat, 2006-10-21 at 15:08 -0500, Josh Boyer wrote: > On Sat, 2006-10-21 at 13:27 -0400, Owen Taylor wrote: > > So, for a while we've been thinking about adding the client software > > for Mugshot (http://mugshot.org) to fedora-extras. Both the client > > and server are GPL software, so the client is definitely within the > > scope of fedora-extras. We see various advantages to us and our users > > from having it there: [...] > > *however* - updates are more of a challenge, because we're still > > changing things rapidly and the client software is tightly coupled to > > the server software; when we add new features, there is often both a > > client part and a server part. [...] > > Do people have other ideas about how it could work? > > Add a handshake to both the server and the client for features. The > client says "do you support ?", the server says "wtf is ?", > the client then disables it at runtime. > > That way you don't have to worry about newer clients acting in weird > ways. Or maybe I'm missing where that would be very hard to do... It's certainly possible to spend more effort at making new clients work well with older servers and older clients work well with newer servers, but it's not necessarily work we want to prioritize at the moment... there are only four coders on the team at the moment total :-) Just to give an example of what is involved - in the release we are rolling out next week, we've switched the way we do notifications to the user - from: http://developer.mugshot.org/wiki/Image:Link_Swarm_Bubble_Join_Chat_or_Ignore_1.gif To: http://developer.mugshot.org/wiki/Image:Stacker_Browse_Window.jpg The notifications aren't just displayed different on the client, they are based on different elements sent from the server over XMPP: the stacker now sends updates to a "stack" of notifications rather than just sending individual events. So, to make the new client work with the old server, we'd have to either try to come up with some sort of faked up stack on the client side, or leave all the old bubble display code around in parallel to the new code. Plus there is the issue that the client changes may not make a lot of sense to users until the accompanying web site design is also pushed live. While most updates aren't that drastic, the extra compatibility work at each release still seems like an excessively hard way to deal with the possibility of clients leaking out to users via yum before we are ready. - Owen From bugs.michael at gmx.net Sat Oct 21 22:15:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Oct 2006 00:15:02 +0200 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161451653.18331.41.camel@huygens.localdomain> References: <1161451653.18331.41.camel@huygens.localdomain> Message-ID: <20061022001502.5508e48c.bugs.michael@gmx.net> On Sat, 21 Oct 2006 13:27:33 -0400, Owen Taylor wrote: > - We could try to time the server push to coincide with when the > packages appear in the fedora-extras - that is, we get the > client ready, we get the server ready, we put the client version > into the build system, and we sit on our browsers reload button, > and when the software appears on download.fedora.redhat.com, > we do the server upgrade. > > (There is an obvious conceptual problem here that this only works > when there is one such build system - we couldn't do it for both > Fedora Extras and Ubuntu Universe, say!) > > Does the daily update of the repository occur at a predictable > time? No. It happens when somebody logs in and starts the push script. Further, the packages are pushed to download.fedoraproject.org first and then are synced to download.fedora.redhat.com automatically without a chance to influence when that happens. Somebody other than me would need to tell when and how often that happens. > - If we could simply get the mugshot client excluded from the > creation of the fedora-extras yum repository metadata, then we > could build packages ahead of time, and later offer them through our > current upgrade process. (or through our own yum repository.) > > Would it be completely ridiculous to ask that createrepo be run > for the FE repository with --exclude=mugshot* ? Excluding them from the metadata would be possible, since createrepo is run from within a wrapper script (unless somebody runs it directly ;). But it would also exclude them from repoclosure tests and hide them in repoview. This could be considered a bug if a package in the repository is "not available" via yum and other package tools. > Do people have other ideas about how it could work? They could be excluded at a lower level, so they never make it into the FE repository, but could be mirrored from the needsign repository by you. That way you could control better which versions to keep. E.g. if you made two consecutive releases to fix bugs, that would throw out older releases from the FE repository. From ellson at research.att.com Sat Oct 21 22:16:25 2006 From: ellson at research.att.com (John Ellson) Date: Sat, 21 Oct 2006 18:16:25 -0400 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161466790.18331.57.camel@huygens.localdomain> References: <1161451653.18331.41.camel@huygens.localdomain> <1161461320.608.11.camel@vader.jdub.homelinux.org> <1161466790.18331.57.camel@huygens.localdomain> Message-ID: <453A9C39.4000704@research.att.com> Owen Taylor wrote: > >>> *however* - updates are more of a challenge, because we're still >>> changing things rapidly and the client software is tightly coupled to >>> the server software; when we add new features, there is often both a >>> client part and a server part. >>> > [...] > > >>> Do people have other ideas about how it could work >>> Welcome to the world of distributed computing in which software updates can not be done atomically. Even certain large telcos have had problems with this. How about running multiple servers, one for each supported but incompatible version of the client software? You could use a common primary server/URL with redirects to the version-specific server. John From tcallawa at redhat.com Sat Oct 21 22:38:41 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 21 Oct 2006 17:38:41 -0500 Subject: exclude arch for PPC64 In-Reply-To: <1161429764.3709.50.camel@T7.Linux> References: <1161429764.3709.50.camel@T7.Linux> Message-ID: <1161470321.2909.186.camel@localhost.localdomain> On Sat, 2006-10-21 at 12:22 +0100, Paul wrote: > Hi, > > I keep hitting the same problem when trying to import Xeuphoric into FE > in the the PPC 64 bit platform is not supported (none of the 64 bit > architectures are currently). > > What tag do I need to put into the spec to exclude ppc64? AFAIK, FE isn't building for ppc64, only ppc. If you're getting build failures on ppc, then ExcludeArch: ppc. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jwboyer at jdub.homelinux.org Sun Oct 22 00:22:17 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Oct 2006 19:22:17 -0500 Subject: exclude arch for PPC64 In-Reply-To: <1161470321.2909.186.camel@localhost.localdomain> References: <1161429764.3709.50.camel@T7.Linux> <1161470321.2909.186.camel@localhost.localdomain> Message-ID: <1161476537.3139.1.camel@vader.jdub.homelinux.org> On Sat, 2006-10-21 at 17:38 -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-10-21 at 12:22 +0100, Paul wrote: > > Hi, > > > > I keep hitting the same problem when trying to import Xeuphoric into FE > > in the the PPC 64 bit platform is not supported (none of the 64 bit > > architectures are currently). > > > > What tag do I need to put into the spec to exclude ppc64? > > AFAIK, FE isn't building for ppc64, only ppc. If you're getting build > failures on ppc, then ExcludeArch: ppc. But that excludes ppc32, which we do build and shouldn't have problems if I read the original problem description correctly. Paul, do you have logs I can look at? I've got access to a ppc32 machine and can try building on it if you'd like. josh From otaylor at redhat.com Sun Oct 22 02:04:44 2006 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 21 Oct 2006 22:04:44 -0400 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <20061022001502.5508e48c.bugs.michael@gmx.net> References: <1161451653.18331.41.camel@huygens.localdomain> <20061022001502.5508e48c.bugs.michael@gmx.net> Message-ID: <1161482684.13040.22.camel@localhost.localdomain> On Sun, 2006-10-22 at 00:15 +0200, Michael Schwendt wrote: [...] > On Sat, 21 Oct 2006 13:27:33 -0400, Owen Taylor wrote: > > - If we could simply get the mugshot client excluded from the > > creation of the fedora-extras yum repository metadata, then we > > could build packages ahead of time, and later offer them through our > > current upgrade process. (or through our own yum repository.) > > > > Would it be completely ridiculous to ask that createrepo be run > > for the FE repository with --exclude=mugshot* ? > > Excluding them from the metadata would be possible, since createrepo is > run from within a wrapper script (unless somebody runs it directly ;). But > it would also exclude them from repoclosure tests and hide them in > repoview. This could be considered a bug if a package in the repository is > "not available" via yum and other package tools. > > > Do people have other ideas about how it could work? > > They could be excluded at a lower level, so they never make it into the FE > repository, but could be mirrored from the needsign repository by you. > That way you could control better which versions to keep. E.g. if you made > two consecutive releases to fix bugs, that would throw out older releases > from the FE repository. Is there an overview somewhere of how the process of getting from the build system to the FE repository works? What you say about excluding the packages from the FE repository entirely sounds right to me, but I'm not really sure what I'd be asking for to enable that :-) Thanks, - Owen From jkeating at redhat.com Sun Oct 22 03:03:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 21 Oct 2006 23:03:22 -0400 Subject: rpms/libburn/devel .cvsignore, 1.2, 1.3 libburn.spec, 1.2, 1.3 sources, 1.3, 1.4 In-Reply-To: <1498.207.233.85.229.1161462586.squirrel@thecodergeek.com> References: <200610211941.k9LJfgO6003037@cvs-int.fedora.redhat.com> <1498.207.233.85.229.1161462586.squirrel@thecodergeek.com> Message-ID: <200610212303.22553.jkeating@redhat.com> On Saturday 21 October 2006 16:29, Peter Gordon wrote: > Now that's an actual release from their site, this should be a > fully-qualified URL to the source tarball from upstream, right? > > Source0: > http://libburn-download.pykix.org/releases/%{name}-%{version}.tar.gz > > ...or something similar. Thanks, Jesse. Good catch. I knew I forgot something (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garrick at usc.edu Sun Oct 22 04:54:45 2006 From: garrick at usc.edu (Garrick Staples) Date: Sat, 21 Oct 2006 21:54:45 -0700 Subject: Something wrong with ppc builder? Message-ID: <20061022045445.GM2077@polop.usc.edu> My builds today have all failed with repo setup errors on ppc. I'm trying to get some security fixes for TORQUE built. http://buildsys.fedoraproject.org/logs/fedora-development-extras/20074-torque-2.1.5-1.fc6/ppc/root.log Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-ppc-core-09f4de7c11006c111042c2afeb5f4bf865fe1455/root install buildsys-build file:///pub/fedora/linux/core/development/ppc/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/core/development/ppc/os/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. Error: failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Cleaning up... -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Oct 22 05:02:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Oct 2006 07:02:23 +0200 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061021233219.23b1c35a.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> Message-ID: <453AFB5F.6000405@hhs.nl> Michael Schwendt wrote: > So far, we have been running "repomanage" on the Fedora Extras repository > trees to get rid of old package releases automatically. In development, we > keep only the latest release, for older trees we keep at most two > releases. > > However, occasionally I've run into obsolete/orphaned sub-packages where > the packager changed the BuildArch or deleted a sub-package without asking > the repository staff to delete old package releases manually. It can also > happen that the package removal requests, which are processed by humans, > lead to incomplete removal of packages, when e.g. "debuginfo" packages are > not removed or version-information was misleading. > > The resulting obsolete package releases live in the repository forever, as > repomanage will never decide to delete them. > > As a solution, I've looked into porting my old Perl rpm-expire script to > Python -- I've lost the script in the single place where it was running > and have only recovered an early prototype I'm not satisfactory with. > > The technique is based on this: > > * We build from src.rpm packages. > > * For all binary rpms there must be a corresponding src.rpm. > > * The src.rpm name is in the %{sourcerpm} header of a binary rpm. > > * If the src.rpm for a binary rpm in the repository does not exist, > where does the binary rpm come from? --> We delete it! > > * Instead of expiring arbitrary packages based on "number of pkgs found", > we expire only src.rpms and clean up the binary rpms based on whether > their src.rpms still exist. > > Running a quick hack of this on the current FE repositories, it creates a > long list of "lost souls" as appended below. I've checked a few already > and so far could not find any false positives. Of course, letting such a > script remove these packages automatically actually, will require a few > good sanity checks, so run-time errors don't empty the entire > repository. ;) > Sounds like a good plan, but what about huge disttag-less noarch packages which get copied over from dist to dist? Regards, Hans From dennis at ausil.us Sun Oct 22 05:02:24 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 22 Oct 2006 00:02:24 -0500 Subject: Something wrong with ppc builder? In-Reply-To: <20061022045445.GM2077@polop.usc.edu> References: <20061022045445.GM2077@polop.usc.edu> Message-ID: <200610220002.25431.dennis@ausil.us> On Saturday 21 October 2006 11:54 pm, Garrick Staples wrote: > My builds today have all failed with repo setup errors on ppc. I'm > trying to get some security fixes for TORQUE built. > The problem is that the nfs mount for repo tree doesnt want to mount. Im looking into it -- Dennis Gilmore, RHCE Proud Australian From jamatos at fc.up.pt Sat Oct 21 21:34:35 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 21 Oct 2006 22:34:35 +0100 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061021233219.23b1c35a.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> Message-ID: <200610212234.36517.jamatos@fc.up.pt> On Saturday 21 October 2006 22:32, Michael Schwendt wrote: > This is the full list of binary rpms, which do not have a corresponding > src.rpm in the repository: All of these files should be deleted, the resulting debuginfo package is empty and so useless. R-mAr-debuginfo (for FC5 and FC4 for all archs) -- Jos? Ab?lio From bugs.michael at gmx.net Sun Oct 22 09:34:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Oct 2006 11:34:33 +0200 Subject: RFC: Junk in Fedora Extras In-Reply-To: <453AFB5F.6000405@hhs.nl> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> <453AFB5F.6000405@hhs.nl> Message-ID: <20061022113433.012be38c.bugs.michael@gmx.net> On Sun, 22 Oct 2006 07:02:23 +0200, Hans de Goede wrote: > Sounds like a good plan, but what about huge disttag-less noarch packages which get copied over from dist to dist? > Copies, whether hardlinks or really plain copies, still have a copied src.rpm in the "SRPMS" repository, too. Whether this is true for all copied noarch rpms so far, we'll see. From bugs.michael at gmx.net Sun Oct 22 09:34:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Oct 2006 11:34:36 +0200 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161482684.13040.22.camel@localhost.localdomain> References: <1161451653.18331.41.camel@huygens.localdomain> <20061022001502.5508e48c.bugs.michael@gmx.net> <1161482684.13040.22.camel@localhost.localdomain> Message-ID: <20061022113436.4a9b5590.bugs.michael@gmx.net> On Sat, 21 Oct 2006 22:04:44 -0400, Owen Taylor wrote: > > They could be excluded at a lower level, so they never make it into the FE > > repository, but could be mirrored from the needsign repository by you. > > That way you could control better which versions to keep. E.g. if you made > > two consecutive releases to fix bugs, that would throw out older releases > > from the FE repository. > > Is there an overview somewhere of how the process of getting from the > build system to the FE repository works? What you say about excluding > the packages from the FE repository entirely sounds right to me, but > I'm not really sure what I'd be asking for to enable that :-) Well, I would add some lines of code at the right place where currently there is only a "TODO" reminder comment. The push script then can black-list entire build jobs based on their src.rpm package %{name}. How long to keep them in the needsign repository is another question, but not hard to solve. The "needsign" queue directories are here: http://buildsys.fedoraproject.org/plague-results/ Every package "name" has its own small tree of sub-directories for every build-job's results. In the release process, packages from there are copied, signed, installed in the right locations and synced to the public master repository at http://fedoraproject.org/extras/ From paul at all-the-johnsons.co.uk Sun Oct 22 09:30:43 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 22 Oct 2006 10:30:43 +0100 Subject: exclude arch for PPC64 In-Reply-To: <1161476537.3139.1.camel@vader.jdub.homelinux.org> References: <1161429764.3709.50.camel@T7.Linux> <1161470321.2909.186.camel@localhost.localdomain> <1161476537.3139.1.camel@vader.jdub.homelinux.org> Message-ID: <1161509443.3709.79.camel@T7.Linux> Hi, > Paul, do you have logs I can look at? I've got access to a ppc32 > machine and can try building on it if you'd like. I've had it build happily on a ppc32 without any problems and the src.rpm should be out on tonights spin of Extras (called xeuphoric). It seems odd that I'd need ppc as it really should be ppc64 (which follows x86_64) TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 Sun Oct 22 11:52:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Oct 2006 13:52:14 +0200 Subject: hammer3 build server causes trouble Message-ID: <20061022135214.8a1eb2f7.bugs.michael@gmx.net> hammer3 doesn't want to leave status "running/prepping". From mr.ecik at gmail.com Sun Oct 22 12:06:14 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 22 Oct 2006 14:06:14 +0200 Subject: Is there any Python interface to Red Hat's bugzilla? Message-ID: <668bb39a0610220506u581540f2p8d14aad14c651609@mail.gmail.com> Hi! Since recently I am working at simple version tracking system. In my opinion it would be great if it could send information about new version to bugzilla. I'm looking for some nice Python interface to bugzilla because I don't know how bugzilla's working. I found something like pybugz (http://www.liquidx.net/pybugz/) which is designed as gentoo bugzilla interface, but I have problems to rewrite it to Red Hat's bugzilla (maybe someone could help me?). Also, I found bugzilla-submit script but its functionality is insufficient. If someone know any other Python bugzilla interface, I'll be glad. Please let me know, if you want to know something about that version tracking system. Thanks in advance Micha?. From otaylor at redhat.com Sun Oct 22 13:39:38 2006 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 22 Oct 2006 09:39:38 -0400 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <20061022113436.4a9b5590.bugs.michael@gmx.net> References: <1161451653.18331.41.camel@huygens.localdomain> <20061022001502.5508e48c.bugs.michael@gmx.net> <1161482684.13040.22.camel@localhost.localdomain> <20061022113436.4a9b5590.bugs.michael@gmx.net> Message-ID: <1161524378.18185.2.camel@huygens.home.fishsoup.net> On Sun, 2006-10-22 at 11:34 +0200, Michael Schwendt wrote: > On Sat, 21 Oct 2006 22:04:44 -0400, Owen Taylor wrote: > > > > They could be excluded at a lower level, so they never make it into the FE > > > repository, but could be mirrored from the needsign repository by you. > > > That way you could control better which versions to keep. E.g. if you made > > > two consecutive releases to fix bugs, that would throw out older releases > > > from the FE repository. > > > > Is there an overview somewhere of how the process of getting from the > > build system to the FE repository works? What you say about excluding > > the packages from the FE repository entirely sounds right to me, but > > I'm not really sure what I'd be asking for to enable that :-) > > Well, I would add some lines of code at the right place where currently > there is only a "TODO" reminder comment. The push script then can > black-list entire build jobs based on their src.rpm package %{name}. How > long to keep them in the needsign repository is another question, but not > hard to solve. > > The "needsign" queue directories are here: > > http://buildsys.fedoraproject.org/plague-results/ > > Every package "name" has its own small tree of sub-directories for every > build-job's results. > > In the release process, packages from there are copied, signed, > installed in the right locations and synced to the public master > repository at http://fedoraproject.org/extras/ Hmm ... ideally the diversion would occur after the signing step, so that resulting packages would be signed as Fedora Extras packages. is that practical? - Owen From jwboyer at jdub.homelinux.org Sun Oct 22 14:16:27 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 22 Oct 2006 09:16:27 -0500 Subject: exclude arch for PPC64 In-Reply-To: <1161509443.3709.79.camel@T7.Linux> References: <1161429764.3709.50.camel@T7.Linux> <1161470321.2909.186.camel@localhost.localdomain> <1161476537.3139.1.camel@vader.jdub.homelinux.org> <1161509443.3709.79.camel@T7.Linux> Message-ID: <1161526587.3139.8.camel@vader.jdub.homelinux.org> On Sun, 2006-10-22 at 10:30 +0100, Paul wrote: > Hi, > > > Paul, do you have logs I can look at? I've got access to a ppc32 > > machine and can try building on it if you'd like. > > I've had it build happily on a ppc32 without any problems and the > src.rpm should be out on tonights spin of Extras (called xeuphoric). It > seems odd that I'd need ppc as it really should be ppc64 (which follows > x86_64) That's what I'm saying... you can't use ExcludeArch: ppc because that is for ppc32 _and_ ppc64. For the vast majority of applications, building as ppc64 makes no sense so ppc is used instead. So, I'd need to see logs of it failing on ppc64 because as far as I know, Extras doesn't even build ppc64 packages so you shouldn't even be having a problem... josh From fedora at leemhuis.info Sun Oct 22 14:40:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Oct 2006 16:40:01 +0200 Subject: build kmods for ppc64 (was: Re: exclude arch for PPC64) In-Reply-To: <1161526587.3139.8.camel@vader.jdub.homelinux.org> References: <1161429764.3709.50.camel@T7.Linux> <1161470321.2909.186.camel@localhost.localdomain> <1161476537.3139.1.camel@vader.jdub.homelinux.org> <1161509443.3709.79.camel@T7.Linux> <1161526587.3139.8.camel@vader.jdub.homelinux.org> Message-ID: <453B82C1.6080602@leemhuis.info> Josh Boyer schrieb: > [...] > So, I'd need to see logs of it failing on ppc64 because as far as I > know, Extras doesn't even build ppc64 packages so you shouldn't even be > having a problem... Side note: We should at least build the kmods for PPC64. That's possible in mock, but we don't support that on our builders ATM. I don't even know if it's possible at all in current plague without building all the other stuff for ppc64, too. CU thl From bugs.michael at gmx.net Sun Oct 22 16:50:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Oct 2006 18:50:14 +0200 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <1161524378.18185.2.camel@huygens.home.fishsoup.net> References: <1161451653.18331.41.camel@huygens.localdomain> <20061022001502.5508e48c.bugs.michael@gmx.net> <1161482684.13040.22.camel@localhost.localdomain> <20061022113436.4a9b5590.bugs.michael@gmx.net> <1161524378.18185.2.camel@huygens.home.fishsoup.net> Message-ID: <20061022185014.33c1f5e6.bugs.michael@gmx.net> On Sun, 22 Oct 2006 09:39:38 -0400, Owen Taylor wrote: > Hmm ... ideally the diversion would occur after the signing step, so > that resulting packages would be signed as Fedora Extras packages. > is that practical? With a few changes in the code, yes. Most of it is available already, since the code learnt how to publish entire build-jobs rather than individual rpms. It's just that we don't sign directly in the needsign repository, because the repository would be locked longer (waiting for the pass-phrase to be entered), the metadata would need to be recreated, too, and any file permission issues (or other problems) would cause pending build jobs to fail. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 22 17:00:00 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 23 Oct 2006 02:00:00 +0900 Subject: Something wrong with ppc builder? In-Reply-To: <200610220002.25431.dennis@ausil.us> References: <20061022045445.GM2077@polop.usc.edu> <200610220002.25431.dennis@ausil.us> Message-ID: <453BA390.5070606@ioa.s.u-tokyo.ac.jp> Dennis Gilmore wrote: > On Saturday 21 October 2006 11:54 pm, Garrick Staples wrote: >> My builds today have all failed with repo setup errors on ppc. I'm >> trying to get some security fixes for TORQUE built. >> > The problem is that the nfs mount for repo tree doesnt want to mount. Im > looking into it Well, ppc build failure seems to be continuing now. Mamoru Tasaka From dennis at ausil.us Sun Oct 22 17:15:49 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 22 Oct 2006 12:15:49 -0500 Subject: Something wrong with ppc builder? In-Reply-To: <453BA390.5070606@ioa.s.u-tokyo.ac.jp> References: <20061022045445.GM2077@polop.usc.edu> <200610220002.25431.dennis@ausil.us> <453BA390.5070606@ioa.s.u-tokyo.ac.jp> Message-ID: <200610221215.50211.dennis@ausil.us> On Sunday 22 October 2006 12:00 pm, Mamoru Tasaka wrote: > Dennis Gilmore wrote: > > On Saturday 21 October 2006 11:54 pm, Garrick Staples wrote: > >> My builds today have all failed with repo setup errors on ppc. I'm > >> trying to get some security fixes for TORQUE built. > > > > The problem is that the nfs mount for repo tree doesnt want to mount. > > Im looking into it > > Well, ppc build failure seems to be continuing now. > > Mamoru Tasaka Im waiting to hear back from Red Hats Infrastructure team as to what is causing the problem. It is something none of Fedora Infrastructure team has any control over. -- Dennis Gilmore, RHCE Proud Australian From dennis at ausil.us Sun Oct 22 17:16:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 22 Oct 2006 12:16:53 -0500 Subject: hammer3 build server causes trouble In-Reply-To: <20061022135214.8a1eb2f7.bugs.michael@gmx.net> References: <20061022135214.8a1eb2f7.bugs.michael@gmx.net> Message-ID: <200610221216.54297.dennis@ausil.us> On Sunday 22 October 2006 6:52 am, Michael Schwendt wrote: > hammer3 doesn't want to leave status "running/prepping". Ill look at it but my guess it has something to do with the nfs mounts which is causing the problems with the ppc builders -- Dennis Gilmore, RHCE Proud Australian From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 22 23:10:13 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 23 Oct 2006 08:10:13 +0900 Subject: hammer3 build server causes trouble In-Reply-To: <200610221216.54297.dennis@ausil.us> References: <20061022135214.8a1eb2f7.bugs.michael@gmx.net> <200610221216.54297.dennis@ausil.us> Message-ID: <453BFA55.1050107@ioa.s.u-tokyo.ac.jp> Dennis Gilmore wrote: > On Sunday 22 October 2006 6:52 am, Michael Schwendt wrote: >> hammer3 doesn't want to leave status "running/prepping". > Ill look at it but my guess it has something to do with the nfs mounts > which is causing the problems with the ppc builders Well, rebuilding jd for FE-devel/5 succeeded for all archs 3 minutes ago. Mamoru From wolters.liste at gmx.net Sun Oct 22 23:35:43 2006 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 23 Oct 2006 01:35:43 +0200 Subject: RPM Message-ID: <200610230135.52023.wolters.liste@gmx.net> Hi, I stumbled over bug #174307 [1] which deals with the fact that the current version of rpm included in Fedora Core (even version 6) is somewhat outdated. This is a bit confusing since I thought every package here should be as close as possible to upstream. Also, it is strange because the package maintainer didn't even show up on that bug report once - I'm not sure about the reasons, but that definitely does not shed the best light at a person maintaining a real core package of Fedora Core - but maybe I just missed something. Additionally there are hardly any information available why this problem even exists - since no one responsible reacted the only source of information is a post on the bugzilla-e-mail-list [2] explaining that Red hat does not like the suggestion feature of the new rpm version - and that Red Hat thinks about forking rpm. Both sounds a bit odd - first, why is this new feature such a problem? I can't see the disadvantages, please point them out. Second, we have rules, so if you do not like a feature, forbid its usage by rule - why the need for a fork? Does anyone has some more information about this topic? Especially the reasons, why for example suggestions are evil and forking is the only solution, would be helpful. Maybe I'm just looking at it with the wrong perspective :) Roland PS: There is another, but useless source of information: [3] Also the topic was discussed at the fab meetings in July[4] and August, however there are no real information about what the probably actually is or what was discussed. [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 [2]https://www.redhat.com/archives/fedora-advisory-board/2006-July/msg00024.html [3]http://www.fedoraproject.org/wiki/rpm-devel [4]http://www.fedoraproject.org/wiki/Board/Meetings/2006-07-18 -- Ich steh' im Wald - schmei? einer mit Brotkrumen! -- praekon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Oct 22 23:34:01 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 22 Oct 2006 18:34:01 -0500 Subject: Failed Builds Last 24 hours Message-ID: <200610221834.02181.dennis@ausil.us> Hi all, Access to the file server has been restored. can you please run plague-client requeue there is no need to bump the release. if you do not know your job number please check http://buildsys.fedoraproject.org/build-status/failed.psp for the job number Thanks for your paitence -- Dennis Gilmore, RHCE Proud Australian From peter at thecodergeek.com Sun Oct 22 23:41:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 22 Oct 2006 16:41:53 -0700 Subject: Failed Builds Last 24 hours In-Reply-To: <200610221834.02181.dennis@ausil.us> References: <200610221834.02181.dennis@ausil.us> Message-ID: <453C01C1.8060803@thecodergeek.com> Dennis Gilmore wrote: > Access to the file server has been restored. can you please run > > plague-client requeue Thanks for the update and quick fix, Dennis. My viaideinfo build just went through fine. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ngaywood at une.edu.au Mon Oct 23 00:59:48 2006 From: ngaywood at une.edu.au (Norman Gaywood) Date: Mon, 23 Oct 2006 10:59:48 +1000 Subject: RPM In-Reply-To: <200610230135.52023.wolters.liste@gmx.net> References: <200610230135.52023.wolters.liste@gmx.net> Message-ID: <20061023005948.GC816@lilith.cluster> On Mon, Oct 23, 2006 at 01:35:43AM +0200, Roland Wolters wrote: > [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 > [2]https://www.redhat.com/archives/fedora-advisory-board/2006-July/msg00024.html > [3]http://www.fedoraproject.org/wiki/rpm-devel > [4]http://www.fedoraproject.org/wiki/Board/Meetings/2006-07-18 Another article and discussion of interest is "Who maintains RPM?", posted in August 2006. http://lwn.net/Articles/196523/ -- Norman Gaywood, Systems Administrator University of New England, Armidale, NSW 2351, Australia Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dominik at greysector.net Mon Oct 23 01:36:06 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 03:36:06 +0200 Subject: RPM In-Reply-To: <200610230135.52023.wolters.liste@gmx.net> References: <200610230135.52023.wolters.liste@gmx.net> Message-ID: <20061023013606.GA2721@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 01:35, Roland Wolters wrote: [...] > PS: There is another, but useless source of information: [3] > Also the topic was discussed at the fab meetings in July[4] and August, > however there are no real information about what the probably actually is > or what was discussed. > > [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 > [2]https://www.redhat.com/archives/fedora-advisory-board/2006-July/msg00024.html > [3]http://www.fedoraproject.org/wiki/rpm-devel Why do you say [3] is useless? I think it sums up the current state pretty well. > [4]http://www.fedoraproject.org/wiki/Board/Meetings/2006-07-18 Looks like there was no followup. I wonder why? What's the hold-up? I'd like to see rpm-4.4.7 in the next Fedora release, too. I've had many talks with Jeff (the author of RPM) in #rpm at irc.freenode.net and I don't understand all the bad blood between some Fedora Core developers and him. Even if there were some problems in the past, I wish both sides would put them aside and work together. Best regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tcallawa at redhat.com Mon Oct 23 02:08:11 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 22 Oct 2006 21:08:11 -0500 Subject: RPM In-Reply-To: <20061023013606.GA2721@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <20061023013606.GA2721@rathann.pekin.waw.pl> Message-ID: <1161569291.2909.322.camel@localhost.localdomain> On Mon, 2006-10-23 at 03:36 +0200, Dominik 'Rathann' Mierzejewski wrote: > I'd like to see rpm-4.4.7 in the next Fedora release, too. I've had many > talks with Jeff (the author of RPM) in #rpm at irc.freenode.net and I don't > understand all the bad blood between some Fedora Core developers and him. > Even if there were some problems in the past, I wish both sides would put > them aside and work together. Jeff has said that his intentions are to take rpm in a direction that would make life as painful for "Red Hat" as possible. It is difficult to overcome a hostile upstream which is consistently negative and unhelpful in all channels of communication. With that said, I'd still like to see what the Board thinks the long term direction of package management is in Fedora. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From lists-gawain at felicity-group.com Mon Oct 23 02:02:54 2006 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Mon, 23 Oct 2006 12:02:54 +1000 Subject: Webspace for a package review Message-ID: <1161568974.3091.24.camel@legolas.felicity.net.au> As I mentioned on the -devel list[1] last night, I am packaging Firefox 2 as a parallel installable package. In reply thl suggested that I submit it to Extras. I have the package ready but at 41MiB in size, I don't have sufficient space available on my ISP's web server. Is there anywhere available for situations like this or can someone kindly offer me somewhere to put it? Kind thanks, Gawain [1] https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00582.html From peter at thecodergeek.com Mon Oct 23 02:11:50 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 22 Oct 2006 19:11:50 -0700 Subject: Webspace for a package review In-Reply-To: <1161568974.3091.24.camel@legolas.felicity.net.au> References: <1161568974.3091.24.camel@legolas.felicity.net.au> Message-ID: <453C24E6.1010605@thecodergeek.com> Gawain Lynch wrote: > I have the package ready but at 41MiB in size, I don't have sufficient > space available on my ISP's web server. Is there anywhere available for > situations like this or can someone kindly offer me somewhere to put it? I can loan you a a bunch of web/FTP space on my hosting. Should I email you off-list with the login details? :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From dominik at greysector.net Mon Oct 23 02:28:56 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 04:28:56 +0200 Subject: RPM In-Reply-To: <1161569291.2909.322.camel@localhost.localdomain> References: <200610230135.52023.wolters.liste@gmx.net> <20061023013606.GA2721@rathann.pekin.waw.pl> <1161569291.2909.322.camel@localhost.localdomain> Message-ID: <20061023022856.GB9079@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 04:08, Tom 'spot' Callaway wrote: > On Mon, 2006-10-23 at 03:36 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > I'd like to see rpm-4.4.7 in the next Fedora release, too. I've had many > > talks with Jeff (the author of RPM) in #rpm at irc.freenode.net and I don't > > understand all the bad blood between some Fedora Core developers and him. > > Even if there were some problems in the past, I wish both sides would put > > them aside and work together. > > Jeff has said that his intentions are to take rpm in a direction that > would make life as painful for "Red Hat" as possible. Did he? I don't believe that. I will ask him personally. > It is difficult to > overcome a hostile upstream which is consistently negative and unhelpful > in all channels of communication. I don't find him negative and unhelpful. Quite the contrary. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From lists-gawain at felicity-group.com Mon Oct 23 02:02:54 2006 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Mon, 23 Oct 2006 12:02:54 +1000 Subject: Webspace for a package review Message-ID: <1161568974.3091.24.camel@legolas.felicity.net.au> As I mentioned on the -devel list[1] last night, I am packaging Firefox 2 as a parallel installable package. In reply thl suggested that I submit it to Extras. I have the package ready but at 41MiB in size, I don't have sufficient space available on my ISP's web server. Is there anywhere available for situations like this or can someone kindly offer me somewhere to put it? Kind thanks, Gawain [1] https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00582.html From n3npq at mac.com Mon Oct 23 04:16:53 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 00:16:53 -0400 Subject: RPM Message-ID: <9E08433F-7099-4A9B-9135-1596EB8B1131@mac.com> On Monday, 23 October 2006 at 04:08, Tom 'spot' Callaway wrote: > Jeff has said that his intentions are to take rpm in a direction that > would make life as painful for "Red Hat" as possible. It is difficult to > overcome a hostile upstream which is consistently negative and unhelpful > in all channels of communication. Enough. Your comments are slanderous and inappropriate, and you're a liar. What gives you the right to put words in my mouth in public? Either cite your source, and make whatever connection to Fedora Extras, and Red Hat, and FL/OSS or whatever, from that cited source. Or apologize publically. 73 de Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Mon Oct 23 06:57:30 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 23 Oct 2006 08:57:30 +0200 Subject: RPM In-Reply-To: <9E08433F-7099-4A9B-9135-1596EB8B1131@mac.com> References: <9E08433F-7099-4A9B-9135-1596EB8B1131@mac.com> Message-ID: On 10/23/06, Jeff Johnson wrote: > > On Monday, 23 October 2006 at 04:08, Tom 'spot' Callaway wrote: > > Jeff has said that his intentions are to take rpm in a direction that > > would make life as painful for "Red Hat" as possible. It is difficult to > > overcome a hostile upstream which is consistently negative and unhelpful > > in all channels of communication. > > Enough. > > Your comments are slanderous and inappropriate, and you're a liar. > > What gives you the right to put words in my mouth in public? > > Either cite your source, and make whatever connection to Fedora Extras, > and Red Hat, and FL/OSS or whatever, from that cited source. > > Or apologize publically. > Ouch! we just come out of last week's flame war, and here is the next one... From oliver at linux-kernel.at Mon Oct 23 07:36:50 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 23 Oct 2006 09:36:50 +0200 Subject: Webspace for a package review In-Reply-To: <1161568974.3091.24.camel@legolas.felicity.net.au> References: <1161568974.3091.24.camel@legolas.felicity.net.au> Message-ID: <453C7112.6060908@linux-kernel.at> Am 2006-10-23 04:02, Gawain Lynch schrieb: > As I mentioned on the -devel list[1] last night, I am packaging Firefox > 2 as a parallel installable package. In reply thl suggested that I > submit it to Extras. > > I have the package ready but at 41MiB in size, I don't have sufficient > space available on my ISP's web server. Is there anywhere available for > situations like this or can someone kindly offer me somewhere to put it? Feel free to use ftp://ftp.linux-kernel.at/uploads/ -of PS: Let me know as soon as you don't need it any longer... From lists-gawain at felicity-group.com Mon Oct 23 07:49:34 2006 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Mon, 23 Oct 2006 17:49:34 +1000 Subject: Webspace for a package review In-Reply-To: <453C7112.6060908@linux-kernel.at> References: <1161568974.3091.24.camel@legolas.felicity.net.au> <453C7112.6060908@linux-kernel.at> Message-ID: <1161589774.8570.2.camel@legolas.felicity.net.au> On Mon, 2006-10-23 at 09:36 +0200, Oliver Falk wrote: > Am 2006-10-23 04:02, Gawain Lynch schrieb: > > As I mentioned on the -devel list[1] last night, I am packaging Firefox > > 2 as a parallel installable package. In reply thl suggested that I > > submit it to Extras. > > > > I have the package ready but at 41MiB in size, I don't have sufficient > > space available on my ISP's web server. Is there anywhere available for > > situations like this or can someone kindly offer me somewhere to put it? > > Feel free to use ftp://ftp.linux-kernel.at/uploads/ Hi Oliver, Thank you kindly. Peter Gordon has already given me some space to play with. If you are keen to play with the SRPM they can be found at http://gawain.thecodergeek.com/ just be sure to use a separate firefox profile. Take care, Gawain From tian at c-sait.net Mon Oct 23 08:56:39 2006 From: tian at c-sait.net (Christian Jodar) Date: Mon, 23 Oct 2006 10:56:39 +0200 (CEST) Subject: Where should go Perl libraries files? Message-ID: <37999.83.145.93.226.1161593799.squirrel@83.145.93.226> Hello, During the review of a new package that I submitted [1], there was an issue with the Perl libraries used by the package. The problem is that this package contains some libraries that are provided as .pm files. So they are not binary files and are platform-independant. The question is now: Where should go these files? According to packaging guidelines [2], we should refer to FHS for this. In these guidelines [3], /usr/lib should be used for "object files, libraries, and internal binaries". Then we have some libraries here, so they could go in /usr/lib. But the 22nd note [4] says that "Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share". And this could be applied also to the .pm files. Here we could be lost... When reading the 23rd note, we find an example of files that could be in a subdirectory of /usr/lib: "For example, the perl5 subdirectory for Perl 5 modules and libraries". And this applies directly to the problem we have here. So I'd think that .pm files could be in the lib directories (and that's where the upstream application wants to find them). But I may be wrong. In any cases, I think this should be explicitely written somewhere on the Wiki. Thank you for your comments, Christian Jodar. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211726 [2] http://fedoraproject.org/wiki/Packaging/Guidelines#head-e1c5548cbbe551c7a43d375c524ab2ea0188557e [3] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1389 [5] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 From oliver at linux-kernel.at Mon Oct 23 09:38:18 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 23 Oct 2006 11:38:18 +0200 Subject: Webspace for a package review In-Reply-To: <1161589774.8570.2.camel@legolas.felicity.net.au> References: <1161568974.3091.24.camel@legolas.felicity.net.au> <453C7112.6060908@linux-kernel.at> <1161589774.8570.2.camel@legolas.felicity.net.au> Message-ID: <453C8D8A.6060102@linux-kernel.at> Am 2006-10-23 09:49, Gawain Lynch schrieb: > On Mon, 2006-10-23 at 09:36 +0200, Oliver Falk wrote: >> Am 2006-10-23 04:02, Gawain Lynch schrieb: >>> As I mentioned on the -devel list[1] last night, I am packaging Firefox >>> 2 as a parallel installable package. In reply thl suggested that I >>> submit it to Extras. >>> >>> I have the package ready but at 41MiB in size, I don't have sufficient >>> space available on my ISP's web server. Is there anywhere available for >>> situations like this or can someone kindly offer me somewhere to put it? >> Feel free to use ftp://ftp.linux-kernel.at/uploads/ > > Hi Oliver, > > Thank you kindly. Peter Gordon has already given me some space to play > with. OK. Fine. Maybe I missed that posting... > If you are keen to play with the SRPM they can be found at > http://gawain.thecodergeek.com/ just be sure to use a separate firefox > profile. For sure I'll take a look! Best, Oliver From oliver at linux-kernel.at Mon Oct 23 11:19:12 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 23 Oct 2006 13:19:12 +0200 Subject: Webspace for a package review In-Reply-To: <453C8D8A.6060102@linux-kernel.at> References: <1161568974.3091.24.camel@legolas.felicity.net.au> <453C7112.6060908@linux-kernel.at> <1161589774.8570.2.camel@legolas.felicity.net.au> <453C8D8A.6060102@linux-kernel.at> Message-ID: <453CA530.6030104@linux-kernel.at> Am 2006-10-23 11:38, Oliver Falk schrieb: > Am 2006-10-23 09:49, Gawain Lynch schrieb: >> On Mon, 2006-10-23 at 09:36 +0200, Oliver Falk wrote: >>> Am 2006-10-23 04:02, Gawain Lynch schrieb: >>>> As I mentioned on the -devel list[1] last night, I am packaging Firefox >>>> 2 as a parallel installable package. In reply thl suggested that I >>>> submit it to Extras. >>>> >>>> I have the package ready but at 41MiB in size, I don't have sufficient >>>> space available on my ISP's web server. Is there anywhere available >>>> for >>>> situations like this or can someone kindly offer me somewhere to put >>>> it? >>> Feel free to use ftp://ftp.linux-kernel.at/uploads/ >> >> Hi Oliver, >> >> Thank you kindly. Peter Gordon has already given me some space to play >> with. > > OK. Fine. Maybe I missed that posting... > > > If you are keen to play with the SRPM they can be found at >> http://gawain.thecodergeek.com/ just be sure to use a separate firefox >> profile. > > For sure I'll take a look! Builds fine and works like a charm ('til now). :-) -of From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 23 11:39:59 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 23 Oct 2006 13:39:59 +0200 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061021233219.23b1c35a.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> Message-ID: <20061023133959.1baf433a@python3.es.egwn.lan> Michael Schwendt wrote : > * If the src.rpm for a binary rpm in the repository does not exist, > where does the binary rpm come from? --> We delete it! > > * Instead of expiring arbitrary packages based on "number of pkgs found", > we expire only src.rpms and clean up the binary rpms based on whether > their src.rpms still exist. Seems like the right approach to me, since the addition and removal of binary sub-packages is something which is impossible to reliably manage without looking at the source packages they came from. I'll all for it, let's just care about the source packages and let all the binaries get cleaned up based on those. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.06 0.06 0.02 From wolters.liste at gmx.net Mon Oct 23 12:11:33 2006 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 23 Oct 2006 14:11:33 +0200 Subject: RPM In-Reply-To: <20061023005948.GC816@lilith.cluster> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> Message-ID: <200610231411.38687.wolters.liste@gmx.net> Once upon a time Norman Gaywood wrote: > On Mon, Oct 23, 2006 at 01:35:43AM +0200, Roland Wolters wrote: > Another article and discussion of interest is "Who maintains RPM?", > posted in August 2006. > > http://lwn.net/Articles/196523/ > Thanks, that explains some bits. Roland -- "Es gibt ein Leben nach dem Tod!" - "Nicht f?r dich, wenn du mich weiter nervst!" -- nach Final Destination -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wolters.liste at gmx.net Mon Oct 23 12:13:43 2006 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 23 Oct 2006 14:13:43 +0200 Subject: RPM In-Reply-To: <20061023013606.GA2721@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <20061023013606.GA2721@rathann.pekin.waw.pl> Message-ID: <200610231413.43706.wolters.liste@gmx.net> Once upon a time Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 01:35, Roland Wolters wrote: > [...] > > >[3]http://www.fedoraproject.org/wiki/rpm-devel > > Why do you say [3] is useless? I think it sums up the current state pretty > well. > It is useless in hte way that it does not list the contra side: I wanted to get an overview of both sides. Roland -- H?tte der Sch?pfer in Ankh-Morpork gesagt: "Es werde Licht!", w?re er von den B?rgern sofort mit der Frage "In welcher Farbe?" unterbrochen worden. -- Terry Pratchett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wolters.liste at gmx.net Mon Oct 23 12:15:45 2006 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 23 Oct 2006 14:15:45 +0200 Subject: RPM In-Reply-To: <1161569291.2909.322.camel@localhost.localdomain> References: <200610230135.52023.wolters.liste@gmx.net> <20061023013606.GA2721@rathann.pekin.waw.pl> <1161569291.2909.322.camel@localhost.localdomain> Message-ID: <200610231415.46112.wolters.liste@gmx.net> Once upon a time Tom 'spot' Callaway wrote: > On Mon, 2006-10-23 at 03:36 +0200, Dominik 'Rathann' Mierzejewski wrote: > > I'd like to see rpm-4.4.7 in the next Fedora release, too. I've had many > > talks with Jeff (the author of RPM) in #rpm at irc.freenode.net and I don't > > understand all the bad blood between some Fedora Core developers and him. > > Even if there were some problems in the past, I wish both sides would put > > them aside and work together. > > Jeff has said that his intentions are to take rpm in a direction that > would make life as painful for "Red Hat" as possible. It is difficult to > overcome a hostile upstream which is consistently negative and unhelpful > in all channels of communication. > Do you have a public source for that? Anyway, that doesn't explian why there is no reaction from Red Hat about the current state. The mentioned bug report was filled by a normal member of Fedora Extras - and no one has reponded. Roland -- meinem Geist geht es gut.. er schwebt wie immer ?ber den Dingen.. ... also auch ?ber mir... -- Smilyface -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n3npq at mac.com Mon Oct 23 12:37:07 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 08:37:07 -0400 Subject: Fwd: RPM References: <1161605037.2909.336.camel@localhost.localdomain> Message-ID: <04BC2659-3C20-44E4-9EA8-102340062210@mac.com> Begin forwarded message: > From: Tom 'spot' Callaway > Date: October 23, 2006 8:03:57 AM EDT > To: n3npq at mac.com > Subject: Re: RPM > > On Mon, 2006-10-23 at 00:16 -0400, Jeff Johnson wrote: > >> Either cite your source, and make whatever connection to Fedora >> Extras, >> and Red Hat, and FL/OSS or whatever, from that cited source. >> > Jun 08 18:40:45 jbj_ and i can't wait until the RHAT tatoo finally > wears off. F*ck y'all! RH nearly cost me my marriage, and put me on a > cardio ward for 15 hours. I will do *everything* in my power to get > even. > > ***** > Perhaps I misinterpreted "*everything*". > > Taking this offlist unless you feel a need to drag this public again. > > ~spot > -- > Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 > > "We must not confuse dissent with disloyalty. We must remember always > that accusation is not proof and that conviction depends upon evidence > and due process of law. We will not walk in fear, one of another. We > will not be driven by fear into an age of unreason, if we dig deep in > our history and our doctrine, and remember that we are not descended > from fearful men -- not from men who feared to write, to speak, to > associate and to defend causes that were, for the moment, unpopular." > -- Edward R. Murrow, March 9, 1954 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n3npq at mac.com Mon Oct 23 12:37:40 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 08:37:40 -0400 Subject: Fwd: RPM References: Message-ID: Begin forwarded message: > From: Jeff Johnson > Date: October 23, 2006 8:23:46 AM EDT > To: Tom 'spot' Callaway > Subject: Re: RPM > > > On Oct 23, 2006, at 8:03 AM, Tom 'spot' Callaway wrote: > >> On Mon, 2006-10-23 at 00:16 -0400, Jeff Johnson wrote: >> >>> Either cite your source, and make whatever connection to Fedora >>> Extras, >>> and Red Hat, and FL/OSS or whatever, from that cited source. >>> >> Jun 08 18:40:45 jbj_ and i can't wait until the RHAT tatoo finally >> wears off. F*ck y'all! RH nearly cost me my marriage, and put me on a >> cardio ward for 15 hours. I will do *everything* in my power to get >> even. >> >> ***** >> Perhaps I misinterpreted "*everything*". >> > > Perhaps covers many many sins. The context was bz #119185, and you > thought the kuro5hin fiction was so "funny" that you had to share > your humor > with me in May. > > I think you're a sick geek sociopath incapable of human > understanding or empathy. > > I was deeply insulted at your "funny". > >> Taking this offlist unless you feel a need to drag this public again. >> > > We've had what, 2 interactions in 2 years, and you claim expertise > on my intents? > > Mention my name again, and I will go public again. > > Now fuck off forever. This is personal. > >> ~spot >> -- >> Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: >> 93054260 >> >> "We must not confuse dissent with disloyalty. We must remember always >> that accusation is not proof and that conviction depends upon >> evidence >> and due process of law. We will not walk in fear, one of another. We >> will not be driven by fear into an age of unreason, if we dig deep in >> our history and our doctrine, and remember that we are not descended >> from fearful men -- not from men who feared to write, to speak, to >> associate and to defend causes that were, for the moment, unpopular." >> -- Edward R. Murrow, March 9, 1954 >> > > You might read your own signature some time. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n3npq at mac.com Mon Oct 23 12:37:57 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 08:37:57 -0400 Subject: Fwd: RPM References: <30C4296B-0F7A-4369-B6EA-D62C2266847D@mac.com> Message-ID: <323C73F5-F367-4265-9BB9-77371708FF9C@mac.com> Begin forwarded message: > From: Jeff Johnson > Date: October 23, 2006 8:29:38 AM EDT > To: Tom 'spot' Callaway > Subject: Re: RPM > > Please forward my reply to fedora-extras-list. > > Or I will. > > You still have made no connection between my private IRC comment > and whether Fedora > uses rpm-4.4.7. > > 73 de Jeff > > On Oct 23, 2006, at 8:03 AM, Tom 'spot' Callaway wrote: > >> On Mon, 2006-10-23 at 00:16 -0400, Jeff Johnson wrote: >> >>> Either cite your source, and make whatever connection to Fedora >>> Extras, >>> and Red Hat, and FL/OSS or whatever, from that cited source. >>> >> Jun 08 18:40:45 jbj_ and i can't wait until the RHAT tatoo finally >> wears off. F*ck y'all! RH nearly cost me my marriage, and put me on a >> cardio ward for 15 hours. I will do *everything* in my power to get >> even. >> >> ***** >> Perhaps I misinterpreted "*everything*". >> >> Taking this offlist unless you feel a need to drag this public again. >> >> ~spot >> -- >> Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: >> 93054260 >> >> "We must not confuse dissent with disloyalty. We must remember always >> that accusation is not proof and that conviction depends upon >> evidence >> and due process of law. We will not walk in fear, one of another. We >> will not be driven by fear into an age of unreason, if we dig deep in >> our history and our doctrine, and remember that we are not descended >> from fearful men -- not from men who feared to write, to speak, to >> associate and to defend causes that were, for the moment, unpopular." >> -- Edward R. Murrow, March 9, 1954 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Mon Oct 23 12:40:46 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 23 Oct 2006 07:40:46 -0500 Subject: Fwd: RPM In-Reply-To: <04BC2659-3C20-44E4-9EA8-102340062210@mac.com> References: <1161605037.2909.336.camel@localhost.localdomain> <04BC2659-3C20-44E4-9EA8-102340062210@mac.com> Message-ID: <1161607246.2909.343.camel@localhost.localdomain> On Mon, 2006-10-23 at 08:37 -0400, Jeff Johnson wrote: > Taking this offlist unless you feel a need to drag this public again. Apparently, this individual (whose name I have been ever so politely asked not to use again) feels that his point is better proven by continuing to flame back and forth. I'm done with this thread, because I think my original point has been made. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From Jochen at herr-schmitt.de Mon Oct 23 14:33:09 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 23 Oct 2006 16:33:09 +0200 Subject: How to rename a cvs module Message-ID: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I maintain a package, which was renamed from lincvs into crossvc. Now I will ask what is the best practice to rename a cvs module in Fedora Extras. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRTzSrE9gByurcX4MEQKWMQCg6AQo/zQFV7hpITtcpR7u5JoDP7IAoL40 7aZzymzGU222ft+gZPTdr33s =w4BM -----END PGP SIGNATURE----- From giallu at gmail.com Mon Oct 23 14:38:31 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 23 Oct 2006 16:38:31 +0200 Subject: How to rename a cvs module In-Reply-To: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> References: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> Message-ID: On 10/23/06, Jochen Schmitt wrote: > I maintain a package, which was renamed from lincvs into crossvc. > > Now I will ask what is the best practice to rename a cvs module > in Fedora Extras. > It should be covered in http://fedoraproject.org/wiki/Extras/PackageEndOfLife From pertusus at free.fr Mon Oct 23 14:39:17 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Oct 2006 16:39:17 +0200 Subject: How to rename a cvs module In-Reply-To: References: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> Message-ID: <20061023143917.GD2280@free.fr> On Mon, Oct 23, 2006 at 04:38:31PM +0200, Gianluca Sforna wrote: > On 10/23/06, Jochen Schmitt wrote: > > >I maintain a package, which was renamed from lincvs into crossvc. > > > >Now I will ask what is the best practice to rename a cvs module > >in Fedora Extras. > > > > It should be covered in > http://fedoraproject.org/wiki/Extras/PackageEndOfLife It covers one half of the issue, that is removing the old module, to create the new one, I think it should be in http://fedoraproject.org/wiki/Extras/CVSSyncNeeded and I can see that you allready edited it ;-) -- Pat From garrick at usc.edu Mon Oct 23 14:53:25 2006 From: garrick at usc.edu (Garrick Staples) Date: Mon, 23 Oct 2006 07:53:25 -0700 Subject: Where should go Perl libraries files? In-Reply-To: <37999.83.145.93.226.1161593799.squirrel@83.145.93.226> References: <37999.83.145.93.226.1161593799.squirrel@83.145.93.226> Message-ID: <20061023145325.GN2077@polop.usc.edu> On Mon, Oct 23, 2006 at 10:56:39AM +0200, Christian Jodar alleged: > Hello, > > During the review of a new package that I submitted [1], there was an issue > with the Perl libraries used by the package. The problem is that this package > contains some libraries that are provided as .pm files. So they are not binary > files and are platform-independant. > > The question is now: Where should go these files? > > According to packaging guidelines [2], we should refer to FHS for this. In > these guidelines [3], /usr/lib should be used for "object files, libraries, > and internal binaries". Then we have some libraries here, so they could go in > /usr/lib. > > But the 22nd note [4] says that "Miscellaneous architecture-independent > application-specific static files and subdirectories must be placed in > /usr/share". And this could be applied also to the .pm files. > > Here we could be lost... > > When reading the 23rd note, we find an example of files that could be in a > subdirectory of /usr/lib: "For example, the perl5 subdirectory for Perl 5 > modules and libraries". And this applies directly to the problem we have here. > > So I'd think that .pm files could be in the lib directories (and that's where > the upstream application wants to find them). But I may be wrong. In any > cases, I think this should be explicitely written somewhere on the Wiki. > > Thank you for your comments, > > Christian Jodar. > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211726 > [2] > http://fedoraproject.org/wiki/Packaging/Guidelines#head-e1c5548cbbe551c7a43d375c524ab2ea0188557e > [3] > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA > [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1389 > [5] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 I'd say in /usr/lib/perl5, as a subpackage. I can possibly imagine /usr/share as acceptable, but within Fedora package management, a subpackage in /usr/lib/perl5 is the most correct. -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Oct 23 14:57:23 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 23 Oct 2006 09:57:23 -0500 Subject: Buildsys Downtime In-Reply-To: <200610192219.38921.dennis@ausil.us> References: <200610192219.38921.dennis@ausil.us> Message-ID: <200610230957.23544.dennis@ausil.us> On Thursday 19 October 2006 22:19, Dennis Gilmore wrote: > On Monday October 23 at 10am EST cvs write access and the extras build > system will be disabled. this will allow for CVS to be branched for fc6 > and for the buildsys to have fc6 configs deployed. > > Downtime will be approximately 3 hours. > Ill send a notification before it goes down and again when its back up > > Your understanding and paitence is appreciated. Buildsys is now down. Ill let you know when its back up -- Dennis Gilmore, RHCE Proud Australian From mattdm at mattdm.org Mon Oct 23 14:58:46 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 10:58:46 -0400 Subject: Fwd: RPM In-Reply-To: References: Message-ID: <20061023145846.GA8818@jadzia.bu.edu> On Mon, Oct 23, 2006 at 08:37:40AM -0400, Jeff Johnson wrote: > >From: Jeff Johnson > >To: Tom 'spot' Callaway [...] > >Now fuck off forever. This is personal. If it's so personal, can we _please_ keep it off this list? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Oct 23 15:01:36 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 11:01:36 -0400 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> Message-ID: <20061023150136.GB8818@jadzia.bu.edu> On Fri, Sep 15, 2006 at 05:13:12PM -0600, Stephen John Smoogen wrote: > Sure.. however for Enterprise stuff... there are different > expectations for what is wanted than the latest and greatest. I was > trying to get some discussion before people start having to fix the > engines after the airplane is in the air.. I agree that it's essential to stop the free-for-all package churn that Extras goes through. It's pretty impressive, but an enterprise extras can't have 100+ packages updating every week. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pertusus at free.fr Mon Oct 23 14:57:32 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Oct 2006 16:57:32 +0200 Subject: Where should go Perl libraries files? In-Reply-To: <37999.83.145.93.226.1161593799.squirrel@83.145.93.226> References: <37999.83.145.93.226.1161593799.squirrel@83.145.93.226> Message-ID: <20061023145732.GF2280@free.fr> On Mon, Oct 23, 2006 at 10:56:39AM +0200, Christian Jodar wrote: > Hello, > > During the review of a new package that I submitted [1], there was an issue > with the Perl libraries used by the package. The problem is that this package > contains some libraries that are provided as .pm files. So they are not binary > files and are platform-independant. > > The question is now: Where should go these files? My opinion is the following: * If these are perl modules, then they should go below /usr/lib/perl5, below %{perl_vendorlib}/ rpm --eval %{perl_vendorlib} /usr/lib/perl5/vendor_perl/5.8.8 * if it is code internal to the application which happens to be in .pm files it should go below %_datadir (for example in %_datadir/myapp/Module.pm). It the .pm are in fact configuration (for example in those files user definied constants or user defined hooks are set) they should go in %_sysconfdir/myapp/ConfModule.pm. I hope that someday %{perl_vendorlib}/ will be moved to something like /usr/share/perl5/vendor_perl/5.8.8 -- Pat From buildsys at fedoraproject.org Mon Oct 23 15:10:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 23 Oct 2006 11:10:59 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-23 Message-ID: <20061023151059.3822D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 27 GtkAda-2.8.0-6.fc6 asymptote-1.15-1.fc6 autogen-5.8.7-1.fc6 dejavu-fonts-2.11-1.fc6 fluxbox-0.9.15.1-3.fc6 gtk-gnutella-0.96.2-1.fc6 jd-1.8.0-0.1.cvs061022.fc6 koffice-langpack-1.6.0-1.fc6 magicor-0.1-2.fc6 moodle-1.6.3-2.fc6 ntfsprogs-1.13.1-3.fc6 perl-Alien-wxWidgets-0.24-1.fc6 perl-HTTP-Server-Simple-0.23-1.fc6 perl-Log-Log4perl-1.07-1.fc6 perl-POE-Component-Client-HTTP-0.79-1.fc6 perl-POE-Component-IRC-5.07-1.fc6 perl-PadWalker-1.1-1.fc6 perl-Wx-0.59-1.fc6 pulseaudio-0.9.5-2.fc6 qt4-4.2.1-1.fc6 thewidgetfactory-0.2.1-2.fc6 torque-2.1.5-1.fc6 viaideinfo-0.4-3.fc6 vkeybd-0.1.17a-1.fc6 wine-docs-0.9.23-1.fc6 xeuphoric-0.18.2-6.fc6 yumex-1.1.5-2.0.fc6 Packages built and released for Fedora Extras 5: 26 GtkAda-2.8.0-6.fc5 asymptote-1.15-1.fc5 autogen-5.8.7-1.fc5 dejavu-fonts-2.11-1.fc5 dvdisaster-0.70.2-1.fc5 fbg-0.9-2.fc5 fluxbox-0.9.15.1-2.fc5 gtk-gnutella-0.96.2-1.fc5 jd-1.8.0-0.1.cvs061022.fc5 koffice-1.6.0-1.fc5 koffice-langpack-1.6.0-1.fc5 kst-1.3.1-1.fc5 libpqxx-2.6.8-1.fc5 moodle-1.6.3-2.fc5 ntfsprogs-1.13.1-3.fc5 perl-Alien-wxWidgets-0.24-1.fc5 perl-Log-Log4perl-1.07-1.fc5 perl-POE-Component-Client-HTTP-0.79-1.fc5 perl-POE-Component-IRC-5.07-1.fc5 perl-Wx-0.59-1.fc5 php-extras-5.1.6-1.fc5 pulseaudio-0.9.5-2.fc5 qt4-4.2.1-1.fc5 torque-2.1.5-1.fc5 viaideinfo-0.4-2.fc5 wine-docs-0.9.23-1.fc5 Packages built and released for Fedora Extras 4: 12 asymptote-1.15-1.fc4 clamav-0.88.5-1.fc4 fluxbox-0.9.15.1-2.fc4 koffice-1.6.0-1.fc4 koffice-langpack-1.6.0-1.fc4 libpqxx-2.6.8-1.fc4 mantis-0.19.4-2.fc4 moodle-1.6.3-2.fc4 qt4-4.1.5-1.fc4 torque-2.1.5-1.fc4 wine-0.9.23-1.fc4 wine-docs-0.9.23-1.fc4 Packages built and released for Fedora Extras 3: 6 clamav-0.88.5-1.fc3 fluxbox-0.9.15.1-2.fc3 python-reportlab-1.20-3.fc3.1 torque-2.1.5-1.fc3 wine-0.9.23-1.fc3 wine-docs-0.9.23-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 Oct 23 15:11:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 23 Oct 2006 11:11:29 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-23 Message-ID: <20061023151129.89D9A15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) dmitry AT butskoy.name: dvdisaster FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) mdehaan AT redhat.com: koan FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) paul AT city-fan.org: perl-String-CRC32 FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) dvdisaster: dmitry AT butskoy.name FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) koan: mdehaan AT redhat.com FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) perl-String-CRC32: paul AT city-fan.org FE3 > FC5-updates (0:1.4-1.fc3 > 0:1.4-1.FC5) FE4 > FC5-updates (0:1.4-1.fc4 > 0:1.4-1.FC5) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) From rdieter at math.unl.edu Mon Oct 23 15:18:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Oct 2006 10:18:27 -0500 Subject: Initial Proposal for doing Enterprise Extras References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Fri, Sep 15, 2006 at 05:13:12PM -0600, Stephen John Smoogen wrote: >> Sure.. however for Enterprise stuff... there are different >> expectations for what is wanted than the latest and greatest. I was >> trying to get some discussion before people start having to fix the >> engines after the airplane is in the air.. > > I agree that it's essential to stop the free-for-all package churn that > Extras goes through. It's pretty impressive, but an enterprise extras > can't have 100+ packages updating every week. Offhand, I couldn't disagree more. You mean you'd rather live with the bugs that those 100+ package updates fix? No thanks. If you don't want the churn, then don't update your el4 boxen. -- Rex From notting at redhat.com Mon Oct 23 15:22:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Oct 2006 11:22:35 -0400 Subject: Putting the mugshot client in fedora-extras In-Reply-To: <20061022001502.5508e48c.bugs.michael@gmx.net> References: <1161451653.18331.41.camel@huygens.localdomain> <20061022001502.5508e48c.bugs.michael@gmx.net> Message-ID: <20061023152235.GB24360@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > No. It happens when somebody logs in and starts the push script. > > Further, the packages are pushed to download.fedoraproject.org first and > then are synced to download.fedora.redhat.com automatically without a > chance to influence when that happens. Somebody other than me would need > to tell when and how often that happens. The cron job from d.fp.o to d.f.r.c runs hourly, IIRC. Bill From notting at redhat.com Mon Oct 23 15:31:07 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Oct 2006 11:31:07 -0400 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> Message-ID: <20061023153107.GB24288@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Offhand, I couldn't disagree more. You mean you'd rather live with the bugs > that those 100+ package updates fix? No thanks. If you don't want the > churn, then don't update your el4 boxen. So, you're requiring the user to explicitly browse the updates for security vs. non-security fixes, for example? Bill From tibbs at math.uh.edu Mon Oct 23 15:32:56 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 23 Oct 2006 10:32:56 -0500 Subject: Is there any Python interface to Red Hat's bugzilla? In-Reply-To: <668bb39a0610220506u581540f2p8d14aad14c651609@mail.gmail.com> (Micha's message of "Sun, 22 Oct 2006 14:06:14 +0200") References: <668bb39a0610220506u581540f2p8d14aad14c651609@mail.gmail.com> Message-ID: >>>>> "M" == Micha writes: M> I'm looking for some nice Python interface to bugzilla because I M> don't know how bugzilla's working. Bugzilla supports xmlrpc; Christian Iseli has a python script that you could start with named "fileBZ" in the status-report-scripts module of Fedora CVS. http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora - J< From pertusus at free.fr Mon Oct 23 15:45:01 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Oct 2006 17:45:01 +0200 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <20061023150136.GB8818@jadzia.bu.edu> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> Message-ID: <20061023154501.GD12135@free.fr> On Mon, Oct 23, 2006 at 11:01:36AM -0400, Matthew Miller wrote: > On Fri, Sep 15, 2006 at 05:13:12PM -0600, Stephen John Smoogen wrote: > > Sure.. however for Enterprise stuff... there are different > > expectations for what is wanted than the latest and greatest. I was > > trying to get some discussion before people start having to fix the > > engines after the airplane is in the air.. > > I agree that it's essential to stop the free-for-all package churn that > Extras goes through. It's pretty impressive, but an enterprise extras can't > have 100+ packages updating every week. I don't think that there are so much updates on a given installation. There are many specialized packages in extras, and there is no reason that 100 updates in extras should translate to 100 updates on a real setup. I agree that for enterprise stuff update should be avoided, but as more and more packages enter fedora extras, there will be more and more updates for fedora extras as a whole which don't mean more and more updates for the users. In the long term there will be many updates even if it is only to track serious bugs or very needed functionalities. -- Pat From buildsys at fedoraproject.org Mon Oct 23 15:50:39 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 23 Oct 2006 15:50:39 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-23 Message-ID: <20061023155039.13381.69449@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (23 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (23 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (23 days) dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (38 days) plague - 0.4.4.1-2.fc3.noarch (38 days) plague - 0.4.4.1-2.fc4.noarch (38 days) plague - 0.4.4.1-2.fc4.noarch (38 days) plague - 0.4.4.1-2.fc4.noarch (38 days) gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch showimg-pgsql - 0.9.5-10.fc4.i386 showimg-pgsql - 0.9.5-10.fc4.ppc showimg-pgsql - 0.9.5-10.fc4.x86_64 showimg-pgsql - 0.9.5-10.fc5.i386 showimg-pgsql - 0.9.5-10.fc5.ppc showimg-pgsql - 0.9.5-10.fc5.x86_64 gemi AT bluewin.ch audacity - 1.2.3-1.i386 ghenry AT suretecsystems.com pgadmin3 - 1.0.2-3.i386 j.w.r.degoede AT hhs.nl bochs - 2.1.1-1.i386 scorched3d - 37.2-1.i386 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (14 days) linphone - 1.2.0-4.fc5.ppc (14 days) linphone - 1.2.0-4.fc5.x86_64 (14 days) linphone - 1.2.0-7.fc6.i386 (14 days) linphone - 1.2.0-7.fc6.ppc (14 days) linphone - 1.2.0-7.fc6.x86_64 (14 days) mattdm AT mattdm.org wxPythonGTK2 - 2.4.2.4-4.i386 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (4 days) syck-php - 0.55-9.fc5.ppc (4 days) syck-php - 0.55-9.fc5.x86_64 (4 days) paul AT all-the-johnsons.co.uk autogen - 5.8.7-1.fc5.i386 autogen - 5.8.7-1.fc5.ppc autogen - 5.8.7-1.fc5.x86_64 autogen - 5.8.7-1.fc6.i386 autogen - 5.8.7-1.fc6.ppc autogen - 5.8.7-1.fc6.x86_64 paul AT city-fan.org smbldap-tools - 0.9.2-3.fc6.noarch Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.ppc requires libopts.so.24 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.x86_64 requires libopts.so.24()(64bit) linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) smbldap-tools-0.9.2-3.fc6.noarch requires perl(Unicode::MapUTF8) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.i386 requires libopts.so.24 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc5.ppc requires libopts.so.24 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- autogen-5.8.7-1.fc5.x86_64 requires libopts.so.24()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- autogen-5.8.7-1.fc5.i386 requires libopts.so.24 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- audacity-1.2.3-1.i386 requires libwx_gtk-2.4.so.0(WXGTK_2.4) audacity-1.2.3-1.i386 requires libwx_gtk-2.4.so.0 bochs-2.1.1-1.i386 requires libwx_gtk2-2.4.so.0(WXGTK2_2.4) bochs-2.1.1-1.i386 requires libwx_gtk2-2.4.so.0 pgadmin3-1.0.2-3.i386 requires libwx_gtk2_xrc-2.4.so.0(WXGTK2_2.4) pgadmin3-1.0.2-3.i386 requires libwx_gtk2_stc-2.4.so.0(WXGTK2_2.4) pgadmin3-1.0.2-3.i386 requires libwx_gtk2-2.4.so.0(WXGTK2_2.4) pgadmin3-1.0.2-3.i386 requires libwx_gtk2-2.4.so.0 pgadmin3-1.0.2-3.i386 requires libwx_gtk2_xrc-2.4.so.0 pgadmin3-1.0.2-3.i386 requires libwx_gtk2_stc-2.4.so.0 plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 scorched3d-37.2-1.i386 requires libwx_gtk2-2.4.so.0(WXGTK2_2.4) scorched3d-37.2-1.i386 requires libwx_gtk2-2.4.so.0 wxPythonGTK2-2.4.2.4-4.i386 requires libwx_gtk2-2.4.so.0(WXGTK2_2.4) wxPythonGTK2-2.4.2.4-4.i386 requires libwx_gtk2_gl-2.4.so.0 wxPythonGTK2-2.4.2.4-4.i386 requires libwx_gtk2-2.4.so.0 wxPythonGTK2-2.4.2.4-4.i386 requires libwx_gtk2_gl-2.4.so.0(WXGTK2_2.4) ====================================================================== New report for: ghenry AT suretecsystems.com package: pgadmin3 - 1.0.2-3.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2_xrc-2.4.so.0(WXGTK2_2.4) libwx_gtk2_stc-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0 libwx_gtk2_xrc-2.4.so.0 libwx_gtk2_stc-2.4.so.0 ====================================================================== New report for: gemi AT bluewin.ch package: audacity - 1.2.3-1.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk-2.4.so.0(WXGTK_2.4) libwx_gtk-2.4.so.0 ====================================================================== New report for: paul AT all-the-johnsons.co.uk package: autogen - 5.8.7-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libopts.so.24 package: autogen - 5.8.7-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libopts.so.24()(64bit) package: autogen - 5.8.7-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libopts.so.24 package: autogen - 5.8.7-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libopts.so.24 package: autogen - 5.8.7-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libopts.so.24()(64bit) package: autogen - 5.8.7-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libopts.so.24 ====================================================================== New report for: mattdm AT mattdm.org package: wxPythonGTK2 - 2.4.2.4-4.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2_gl-2.4.so.0 libwx_gtk2-2.4.so.0 libwx_gtk2_gl-2.4.so.0(WXGTK2_2.4) ====================================================================== New report for: paul AT city-fan.org package: smbldap-tools - 0.9.2-3.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Unicode::MapUTF8) ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: libortp.so.2 ====================================================================== New report for: j.w.r.degoede AT hhs.nl package: scorched3d - 37.2-1.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0 package: bochs - 2.1.1-1.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-10.fc5.ppc from fedora-extras-5-ppc unresolved deps: libpqxx-2.6.7.so package: perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: perl(Unicode::Map8) package: showimg-pgsql - 0.9.5-10.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libpqxx-2.6.7.so()(64bit) package: showimg-pgsql - 0.9.5-10.fc5.i386 from fedora-extras-5-i386 unresolved deps: libpqxx-2.6.7.so package: showimg-pgsql - 0.9.5-10.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpqxx-2.6.7.so package: showimg-pgsql - 0.9.5-10.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpqxx-2.6.7.so()(64bit) package: showimg-pgsql - 0.9.5-10.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpqxx-2.6.7.so From n3npq at mac.com Mon Oct 23 15:52:31 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 11:52:31 -0400 Subject: RPM In-Reply-To: <20061023145846.GA8818@jadzia.bu.edu> References: <20061023145846.GA8818@jadzia.bu.edu> Message-ID: <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> On Oct 23, 2006, at 10:58 AM, Matthew Miller wrote: > On Mon, Oct 23, 2006 at 08:37:40AM -0400, Jeff Johnson wrote: >>> From: Jeff Johnson >>> To: Tom 'spot' Callaway > [...] >>> Now fuck off forever. This is personal. > > If it's so personal, can we _please_ keep it off this list? > > Where does the personal stop and the private begin? That's the issue. The reasons for FC not upgrading to rpm-4.4.7 are quite complicated and are deeply snarled in my personal affairs. E.g. the Fedora Advisory Board aoppears incapable of deciding package management issues without involving me by name. I want my name and privacy back, and have taken the steps to do so this morning. Fedora really needs to figure out what they want to do with package management without invoking my name. I'm one person, and certainly not preventing anyone from doing anything they wish. But apologies for too much information. I'm not part of any Fedora project ... 73 de Jeff From mmcgrath at fedoraproject.org Mon Oct 23 15:54:17 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 23 Oct 2006 10:54:17 -0500 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <20061023153107.GB24288@nostromo.devel.redhat.com> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023153107.GB24288@nostromo.devel.redhat.com> Message-ID: <3237e4410610230854k4b44d4c2p6fc42cc44bc9fa39@mail.gmail.com> On 10/23/06, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > Offhand, I couldn't disagree more. You mean you'd rather live with the bugs > > that those 100+ package updates fix? No thanks. If you don't want the > > churn, then don't update your el4 boxen. > > So, you're requiring the user to explicitly browse the updates for > security vs. non-security fixes, for example? > > Bill > This is a tricky topic to discuss because the answer isn't so clear. On the one hand we should hold the EPEL packages to a high standard because that just comes along with being 'enterprise'. On the other hand, we should assume our users will be knowledgeable professionals who, if need be, have their own policies and procedures in place to update packages and would therefore find broken packages before they make it into production environments. Its hard to find that line where we start trusting the user to make the right decision for their environment. /2 cents -Mike From fedora at camperquake.de Mon Oct 23 16:05:51 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Oct 2006 18:05:51 +0200 Subject: Is there any Python interface to Red Hat's bugzilla? In-Reply-To: References: <668bb39a0610220506u581540f2p8d14aad14c651609@mail.gmail.com> Message-ID: <20061023180551.7455906c@banea.int.addix.net> Hi. On Mon, 23 Oct 2006 10:32:56 -0500, Jason L Tibbitts III wrote: > Bugzilla supports xmlrpc; Christian Iseli has a python script that you > could start with named "fileBZ" in the status-report-scripts module of > Fedora CVS. Is this XML-RPC interface documented somewhere, though? It does not support introspection, at least from my attempts at it, and it seems to be a completely different beast than the bugzilla.org XML-RPC interface. Which is also quite undocumented. From mr.ecik at gmail.com Mon Oct 23 16:08:10 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 23 Oct 2006 18:08:10 +0200 Subject: Is there any Python interface to Red Hat's bugzilla? In-Reply-To: References: <668bb39a0610220506u581540f2p8d14aad14c651609@mail.gmail.com> Message-ID: <668bb39a0610230908k5b309fe5p6fb30fa64ae60c99@mail.gmail.com> 2006/10/23, Jason L Tibbitts III : > Bugzilla supports xmlrpc; Christian Iseli has a python script that you > could start with named "fileBZ" in the status-report-scripts module of > Fedora CVS. > http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora > Thanks for advice, but I've already managed that. My tracking upstream system will be released within week. Regards. Micha?. From mattdm at mattdm.org Mon Oct 23 16:11:50 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 12:11:50 -0400 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> Message-ID: <20061023161150.GA12129@jadzia.bu.edu> On Mon, Oct 23, 2006 at 10:18:27AM -0500, Rex Dieter wrote: > Offhand, I couldn't disagree more. You mean you'd rather live with the bugs > that those 100+ package updates fix? No thanks. If you don't want the > churn, then don't update your el4 boxen. Many of them are new versions, minor fixes, and packaging rearrangements. In many cases, they're as likely to introduce bugs as solve them. And, a general principle in "enterprise" is that it's better to live with the bugs you know you've got than risk new ones that may be worse. If there's a security problem and you've got no choice, you sometimes have to bite the bullet, but otherwise, it's nice to have a known schedule for these sorts of changes. If there's some other way to separate out the security fixes from the general churn (which, again, is a negative word but clearly the result of an impressive and positive project) in a pragmatic way, that'd be fine too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Jochen at herr-schmitt.de Mon Oct 23 16:31:53 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 23 Oct 2006 18:31:53 +0200 Subject: How to rename a cvs module In-Reply-To: <20061023143917.GD2280@free.fr> References: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> <20061023143917.GD2280@free.fr> Message-ID: <0MKxQS-1Gc2iR0ll1-0004fz@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 23 Oct 2006 16:39:17 +0200, you wrote: >It covers one half of the issue, that is removing the old module, to >create the new one, I think it should be in >http://fedoraproject.org/wiki/Extras/CVSSyncNeeded >and I can see that you allready edited it ;-) Yes, but I have the feeling, that this request was not fullfill until now. Best Regars: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRTzuek9gByurcX4MEQK4GQCfaHyOEth6wKBL8VXW8OEfTUsngxgAoKZZ 9aXj4weS1+6Jn6qkJBPOKGdz =AccF -----END PGP SIGNATURE----- From rdieter at math.unl.edu Mon Oct 23 16:40:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Oct 2006 11:40:02 -0500 Subject: Initial Proposal for doing Enterprise Extras References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023161150.GA12129@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Mon, Oct 23, 2006 at 10:18:27AM -0500, Rex Dieter wrote: >> Offhand, I couldn't disagree more. You mean you'd rather live with the >> bugs >> that those 100+ package updates fix? No thanks. If you don't want the >> churn, then don't update your el4 boxen. > > Many of them are new versions, minor fixes, and packaging rearrangements. > In many cases, they're as likely to introduce bugs as solve them. Ah ha! I just someone was going to say that. fedora-extras-testing to the rescue! -- Rex From rdieter at math.unl.edu Mon Oct 23 16:42:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Oct 2006 11:42:36 -0500 Subject: Initial Proposal for doing Enterprise Extras References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023153107.GB24288@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >> Offhand, I couldn't disagree more. You mean you'd rather live with the >> bugs >> that those 100+ package updates fix? No thanks. If you don't want the >> churn, then don't update your el4 boxen. > > So, you're requiring the user to explicitly browse the updates for > security vs. non-security fixes, for example? For iteration 1 of enterprise extras, yes. I have yet to see a reasonable alternative: every proposal I've seen so far adds unreasonable bureaucracy and/or administrative overhead. -- Rex From buildsys at fedoraproject.org Mon Oct 23 16:48:53 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 23 Oct 2006 16:48:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-10-23 Message-ID: <20061023164853.13577.86832@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (38 days) plague - 0.4.4.1-2.fc3.noarch (38 days) Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From j.w.r.degoede at hhs.nl Mon Oct 23 17:15:44 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Oct 2006 19:15:44 +0200 Subject: Broken dependencies in Fedora Extras _3_ due to missing wkgtk Message-ID: <453CF8C0.1070704@hhs.nl> Hi, Someone or something has caused libwx_gtk2-2.4.so.0 to gone missing from FE-3. Regards, Hans -------- Original Message -------- Subject: Broken dependencies in Fedora Extras - 2006-10-23 Date: Mon, 23 Oct 2006 15:50:39 -0000 From: Fedora Extras repoclosure To: j.w.r.degoede at hhs.nl This is an automated mail created by an experimental script. Your following packages in the repository contain broken dependencies: package: scorched3d - 37.2-1.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0 package: bochs - 2.1.1-1.i386 from fedora-extras-3-i386 unresolved deps: libwx_gtk2-2.4.so.0(WXGTK2_2.4) libwx_gtk2-2.4.so.0 From j.w.r.degoede at hhs.nl Mon Oct 23 17:18:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Oct 2006 19:18:57 +0200 Subject: Broken dependencies in Fedora Extras _3_ due to missing wkgtk In-Reply-To: <453CF8C0.1070704@hhs.nl> References: <453CF8C0.1070704@hhs.nl> Message-ID: <453CF981.8070809@hhs.nl> Oops, never mind I just got a message from Micheal to ignore these messages. Regards, Hans Hans de Goede wrote: > Hi, > > Someone or something has caused libwx_gtk2-2.4.so.0 to gone missing from > FE-3. > > Regards, > > Hans > > > -------- Original Message -------- > Subject: Broken dependencies in Fedora Extras - 2006-10-23 > Date: Mon, 23 Oct 2006 15:50:39 -0000 > From: Fedora Extras repoclosure > To: j.w.r.degoede at hhs.nl > > This is an automated mail created by an experimental script. > Your following packages in the repository contain broken dependencies: > > package: scorched3d - 37.2-1.i386 from fedora-extras-3-i386 > unresolved deps: > libwx_gtk2-2.4.so.0(WXGTK2_2.4) > libwx_gtk2-2.4.so.0 > > package: bochs - 2.1.1-1.i386 from fedora-extras-3-i386 > unresolved deps: > libwx_gtk2-2.4.so.0(WXGTK2_2.4) > libwx_gtk2-2.4.so.0 > > From paul at city-fan.org Mon Oct 23 17:12:36 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Oct 2006 18:12:36 +0100 Subject: Broken dependencies in Fedora Extras _3_ due to missing wkgtk In-Reply-To: <453CF8C0.1070704@hhs.nl> References: <453CF8C0.1070704@hhs.nl> Message-ID: <453CF804.3030300@city-fan.org> Hans de Goede wrote: > Someone or something has caused libwx_gtk2-2.4.so.0 to gone missing from > FE-3. That looks like something that was mentioned in the earlier "RFC: Junk in Fedora Extras" thread. The packages in the repo must have had no matching SRPM. Paul. From fedora at leemhuis.info Mon Oct 23 17:15:25 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Oct 2006 19:15:25 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) Message-ID: <453CF8AD.1010800@leemhuis.info> Hi all! we had some discussion one or two weeks ago (and some others earlier) when touching other peoples packages in CVS might is okay in Fedora Extras. FESCo worked on a policy for that. Here it is (directly from the wiki at http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing ), please comment: ---- With the current CVS-Layout each packager can modify all packages. This will probably change in the future with the next Version Control System (VCS) and a proper ACL scheme, but for now this document tries to lay down which contributor is allowed to touch which packages for now. = Who is allowed to modify which packages = Normally the maintainer that is listed as first maintainer in [http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&view=markup owners.list] of a package is the only one who modifies the package or gives other permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package. Bugzilla is normally the best way to contact the package maintainer or to send him patches and suggestions. But there are certain exceptions where the maintainer has to accept that other packagers will modify his packages. Those exception are described in detail below -- it mostly boils down to this: If * a packager doesn't fix important bugs in time * if there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package * the changes are quite minor or considered as a general cleanup to a lot of packages then [#ExperiencedPackagers experienced Extras packagers] are allowed to fix stuff in other peoples packages. == Examples and detailed explanations == This is section will try to explain above rules in more detail. It will never be able to cover all things that might arise in Fedora Extras, but it should give everyone some idea how to lay out the above rules. === Inactive Packager === The packager normally should keep track of his packages; that means: * respond in bugs reported in bugzilla; especially fast if it's a serious problem like a security issue * fix your stuff without explicit poking if it is mentioned in the problem reports somewhere -- that includes: * looking at the [:Extras/PackageStatus: Package Status] pages in the wiki now and then * fix EVR problems if they get mentioned in the problem reports on the fedora-extras-list * fix dependency issues (including those in the devel repo) -- the script sends problems to both the maintainer and the list * participate in mass-rebuilds If the packager doesn't keep track of those items, then other experiences packagers are free to fix stuff for him. It's impossible to set a timeframe when a contributor should step forward to fix stuff because that depends on how bad the problem that need fixing actually is. But some examples: * security problems: * Important stuff should be fixed as quickly if possible -- waiting one day for the maintainer to show up and step in to fix a issue that got reported to him is considered enough * not that important problems should be dealt with quickly, too -- waiting for 2-7 days (depending how bad the issue is) is considered enough * bugs need similar treatment like security problems: * Important stuff (data corruption for users) should be fixed as quick if possible -- waiting one day is considered enough here, too * harmful, but not that bad bugs that might hurt users -- waiting for 2-14 days (depending how bad the issue is) is considered enough * annoying, but not that harmful bugs -- waiting for 21 days is considered enough Some notes: * If you are a packager and offline due to vacation, traveling or other issues for longer time periods (for example five days or longer) please announce that in the wiki on the [:Vacation: proper Page]. Other in this case don't have to wait for you to fix stuff (e.g. if a Security Fix needs to be applied) or know that they don't have to expect an answer before your return. * Inactive actually really means inactive -- if the maintainer responded once in a bug report, but felt silent afterwards try to ping him again, maybe he has just forgotten about this bug. Or there might be some good reason why he hasn't yet committed the provided fix. * if you committed changes to another package wait some hours if possible (normally 24 or 48) before you actually build the updated package. That leaves some time for the maintainer to wake up ;-) * experienced packagers should limit their changes to other people packages to things that are well agreed upon. i.e. don't fix things considered somewhat controversial or a matter of style === Minor, general or cleanup changes === Sometimes there are situations where it's simply a lot easier to fix stuff directly in cvs than via bugzilla and the proper maintainers. So much easier that we should leave this path open. These situations shouldn't arise that often. Some examples of situations were bypassing the proper maintained is considered fine: * support for a new architecture -- that often requires that a lot of packages need adjustments or patches that packagers often can't even test themself. Getting all those modifications in via bugzilla is a lot of annoying work, so these things can be fixed directly in the devel branch of cvs without contacting the individual maintainers if the general effort was announced beforehand. A SIG should handle the stuff and continue with normal operations after the initial porting efforts are finished. * small fixes or adjustments for new or modified packaging guidelines can be done directly in CVS after being announced some days in advance. * mass rebuilds [[Anchor(ExperiencedPackagers)]] === Definition of the term "Experienced packagers" === As experienced packagers count: * The release manager(s) (we don't have such a position yet, but we'll probably have one sooner or later) * FESCo members * Sponsors * Especially the QA and Security SIGs * the SIG that's handling the area in which the package or the fix is needed. But * the SIG has to exists for at least two months and needs to have shown activity in the past two months * the member is and experienced Extras packager and around for at least four months and member of the SIG for at least one month ---- That's it. CU thl From dominik at greysector.net Mon Oct 23 17:18:31 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 19:18:31 +0200 Subject: RPM In-Reply-To: <200610231413.43706.wolters.liste@gmx.net> References: <200610230135.52023.wolters.liste@gmx.net> <20061023013606.GA2721@rathann.pekin.waw.pl> <200610231413.43706.wolters.liste@gmx.net> Message-ID: <20061023171831.GA5303@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 14:13, Roland Wolters wrote: > Once upon a time Dominik 'Rathann' Mierzejewski wrote: > > On Monday, 23 October 2006 at 01:35, Roland Wolters wrote: > > [...] > > > > >[3]http://www.fedoraproject.org/wiki/rpm-devel > > > > Why do you say [3] is useless? I think it sums up the current state pretty > > well. > > > It is useless in hte way that it does not list the contra side: I wanted to > get an overview of both sides. Why do you think there are any downsides to upgrading to 4.4.7? I've read the Changelog between 4.4.2 and .7 and nothing jumped at me. Granted, I'm only a packager, not rpm developer. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Oct 23 17:25:16 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 19:25:16 +0200 Subject: RPM In-Reply-To: <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> References: <20061023145846.GA8818@jadzia.bu.edu> <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> Message-ID: <20061023172516.GB5303@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 17:52, Jeff Johnson wrote: > > On Oct 23, 2006, at 10:58 AM, Matthew Miller wrote: > > >On Mon, Oct 23, 2006 at 08:37:40AM -0400, Jeff Johnson wrote: > >>>From: Jeff Johnson > >>>To: Tom 'spot' Callaway > >[...] > >>>Now fuck off forever. This is personal. > > > >If it's so personal, can we _please_ keep it off this list? > > > > > > Where does the personal stop and the private begin? That's the issue. > > The reasons for FC not upgrading to rpm-4.4.7 are quite complicated > and are > deeply snarled in my personal affairs. E.g. the Fedora Advisory Board > aoppears incapable of deciding package management issues without > involving me by name. > > I want my name and privacy back, and have taken the steps to do so > this morning. > > Fedora really needs to figure out what they want to do with package > management > without invoking my name. I'm one person, and certainly not > preventing anyone > from doing anything they wish. > > But apologies for too much information. I'm not part of any Fedora > project ... I propose that everyone involved steps back and takes a deep breath. If some people (like Tom and Jeff) cannot deal with each other without name calling then they shouldn't. Frankly, I'm not interested in those past personal issues, I only care about improving Fedora's packaging tools. So, let me ask again: what *technical* issues prevent rpm-4.4.7 from being adopted in fc-devel/fc7? An analysis of potential problems has already been done and link posted earlier in this thread. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mattdm at mattdm.org Mon Oct 23 17:30:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 13:30:07 -0400 Subject: Broken dependencies in Fedora Extras _3_ due to missing wkgtk In-Reply-To: <453CF8C0.1070704@hhs.nl> References: <453CF8C0.1070704@hhs.nl> Message-ID: <20061023173007.GA15761@jadzia.bu.edu> On Mon, Oct 23, 2006 at 07:15:44PM +0200, Hans de Goede wrote: > Someone or something has caused libwx_gtk2-2.4.so.0 to gone missing from > FE-3. > Regards, I elected to not upgrade wxGTK in Fedora Extras 3 to 2.6, but did so in FE4 and on. This is probably the root of the confusion. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Mon Oct 23 17:20:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Oct 2006 19:20:46 +0200 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <3237e4410610230854k4b44d4c2p6fc42cc44bc9fa39@mail.gmail.com> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023153107.GB24288@nostromo.devel.redhat.com> <3237e4410610230854k4b44d4c2p6fc42cc44bc9fa39@mail.gmail.com> Message-ID: <1161624046.7722.7.camel@rousalka.dyndns.org> Le lundi 23 octobre 2006 ? 10:54 -0500, Mike McGrath a ?crit : > This is a tricky topic to discuss because the answer isn't so clear. > On the one hand we should hold the EPEL packages to a high standard > because that just comes along with being 'enterprise'. On the other > hand, we should assume our users will be knowledgeable professionals On the other hand, "entreprise" often translates in underpaid contractors with little or no clue. There's a reason "entreprises" are willing to pay a huge premium for "gold support" ? it ensures they don't need expensive "knowledgeable professionals" -- Nicolas Mailhot From seg at haxxed.com Mon Oct 23 17:50:32 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 23 Oct 2006 12:50:32 -0500 Subject: RPM In-Reply-To: <20061023005948.GC816@lilith.cluster> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> Message-ID: <1161625832.16747.8.camel@max.booze> On Mon, 2006-10-23 at 10:59 +1000, Norman Gaywood wrote: > Another article and discussion of interest is "Who maintains RPM?", > posted in August 2006. > > http://lwn.net/Articles/196523/ After reading that, and especially this[1], can we *PLEASE* put our foot down, show some balls, take the lead, show some initiative, and fork the "Fedora Package Manager"? Jeff Johnson isn't fit to maintain Evolution. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 -------------- 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 abo at kth.se Mon Oct 23 17:41:41 2006 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Oct 2006 19:41:41 +0200 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <20061023150136.GB8818@jadzia.bu.edu> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> Message-ID: <1161625301.8592.132.camel@home.alexander.bostrom.net> m?n 2006-10-23 klockan 11:01 -0400 skrev Matthew Miller: > It's pretty impressive, but an enterprise extras can't > have 100+ packages updating every week. Just having access to a large repository of packages for RHEL would be very valuable for me, even if there was no policy of only doing security updates. The alternative right now is for me to backport packages from Fedora Extras myself, which is a lot of work. It would be more useful if would spend that time helping out with maintaining the packages I care about in a central repo and then perhaps cherry-pick the updates I need into a local repository, if the specific application requires it. In a way, the people behind centos.karan.org and RPMforge does this at the moment (thank you!), but they don't have as large a library as FE, so if users of RHEL and compatible distributions can do FE backports on a larger scale, it would be even better. /abo From dominik at greysector.net Mon Oct 23 18:17:05 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 20:17:05 +0200 Subject: RPM In-Reply-To: <1161625832.16747.8.camel@max.booze> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> Message-ID: <20061023181705.GD5303@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 19:50, Callum Lerwick wrote: > On Mon, 2006-10-23 at 10:59 +1000, Norman Gaywood wrote: > > Another article and discussion of interest is "Who maintains RPM?", > > posted in August 2006. > > > > http://lwn.net/Articles/196523/ > > After reading that, That article is biased and inflammatory. Can we please stop quoting it? > and especially this[1], can we *PLEASE* put our foot > down, show some balls, take the lead, show some initiative, and fork the > "Fedora Package Manager"? What about "working with upstream"? I thought that was one of the main Fedora goals. > Jeff Johnson isn't fit to maintain Evolution. Why are doing this? Stop flaming, please. > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 Oh, for crying out loud, stop bringing up two year old bugs that have long been resolved. This is not helping. Have you actually tried to talk to Jeff without prejudice? It's impossible and improper to judge someone based on one feral bugreport. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rdieter at math.unl.edu Mon Oct 23 18:16:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Oct 2006 13:16:44 -0500 Subject: RPM References: <20061023145846.GA8818@jadzia.bu.edu> <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> <20061023172516.GB5303@rathann.pekin.waw.pl> Message-ID: Dominik 'Rathann' Mierzejewski wrote: > Frankly, I'm not interested in those past > personal issues, I only care about improving Fedora's packaging tools. So, > let me ask again: what *technical* issues prevent rpm-4.4.7 from being > adopted in fc-devel/fc7? AFAIK, nothing technical (that can't be dealt with anyway). Fact is, many folks have personal/professional problems working with jbj/upstream. So, the biggest issue to tackle seems to be maintainership and (re)defining upstream. Me? I'm 100% ok with jbj, but I'm not the one doing the work. -- Rex From dominik at greysector.net Mon Oct 23 18:37:12 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 23 Oct 2006 20:37:12 +0200 Subject: RPM In-Reply-To: References: <20061023145846.GA8818@jadzia.bu.edu> <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> <20061023172516.GB5303@rathann.pekin.waw.pl> Message-ID: <20061023183712.GF5303@rathann.pekin.waw.pl> On Monday, 23 October 2006 at 20:16, Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > Frankly, I'm not interested in those past > > personal issues, I only care about improving Fedora's packaging tools. So, > > let me ask again: what *technical* issues prevent rpm-4.4.7 from being > > adopted in fc-devel/fc7? > > AFAIK, nothing technical (that can't be dealt with anyway). That was my impression as well. > Fact is, many folks have personal/professional problems working with > jbj/upstream. So, the biggest issue to tackle seems to be maintainership > and (re)defining upstream. IOW, we only need someone that has no personal issues with jbj as the package maintainer for rpm. And, possibly, a separate bugtracker for RPM itself to keep bugreports against RPM package in Fedora and RPM application separate. That's one of the problems, AFAIR. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at jdub.homelinux.org Mon Oct 23 19:09:13 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Oct 2006 14:09:13 -0500 Subject: RPM In-Reply-To: <20061023183712.GF5303@rathann.pekin.waw.pl> References: <20061023145846.GA8818@jadzia.bu.edu> <585EC5A1-69FB-47CF-8E9C-625175BB8528@mac.com> <20061023172516.GB5303@rathann.pekin.waw.pl> <20061023183712.GF5303@rathann.pekin.waw.pl> Message-ID: <1161630553.3841.10.camel@zod.rchland.ibm.com> On Mon, 2006-10-23 at 20:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 20:16, Rex Dieter wrote: > > Dominik 'Rathann' Mierzejewski wrote: > > > > > Frankly, I'm not interested in those past > > > personal issues, I only care about improving Fedora's packaging tools. So, > > > let me ask again: what *technical* issues prevent rpm-4.4.7 from being > > > adopted in fc-devel/fc7? > > > > AFAIK, nothing technical (that can't be dealt with anyway). > > That was my impression as well. > > > Fact is, many folks have personal/professional problems working with > > jbj/upstream. So, the biggest issue to tackle seems to be maintainership > > and (re)defining upstream. > > IOW, we only need someone that has no personal issues with jbj as the > package maintainer for rpm. And, possibly, a separate bugtracker for RPM > itself to keep bugreports against RPM package in Fedora and RPM application > separate. That's one of the problems, AFAIR. We don't get to decide who maintains RPM in Fedora Core. That's up to Red Hat. A separate upstream RPM bugzilla would be good though. josh From ralph+fedoraextras at strg-alt-entf.org Mon Oct 23 19:17:59 2006 From: ralph+fedoraextras at strg-alt-entf.org (Ralph Angenendt) Date: Mon, 23 Oct 2006 21:17:59 +0200 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <3237e4410610230854k4b44d4c2p6fc42cc44bc9fa39@mail.gmail.com> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023153107.GB24288@nostromo.devel.redhat.com> <3237e4410610230854k4b44d4c2p6fc42cc44bc9fa39@mail.gmail.com> Message-ID: <453D1567.5040102@strg-alt-entf.org> Mike McGrath wrote: > This is a tricky topic to discuss because the answer isn't so clear. > On the one hand we should hold the EPEL packages to a high standard > because that just comes along with being 'enterprise'. On the other > hand, we should assume our users will be knowledgeable professionals > who, if need be, have their own policies and procedures in place to > update packages and would therefore find broken packages before they > make it into production environments. Do you really think so (nothing against your positive view of users)? Aren't there loads of people running RHEL because they get *support* with it as they do not have the knowledge inhouse? Regards, Ralph -------------- 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 Mon Oct 23 19:39:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Oct 2006 20:39:09 +0100 Subject: RPM In-Reply-To: <20061023181705.GD5303@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> Message-ID: <1161632349.20225.3.camel@metropolis.intra.city-fan.org> On Mon, 2006-10-23 at 20:17 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 19:50, Callum Lerwick wrote: > > On Mon, 2006-10-23 at 10:59 +1000, Norman Gaywood wrote: > > > Another article and discussion of interest is "Who maintains RPM?", > > > posted in August 2006. > > > > > > http://lwn.net/Articles/196523/ > > > > After reading that, > > That article is biased and inflammatory. Can we please stop quoting it? > > > and especially this[1], can we *PLEASE* put our foot > > down, show some balls, take the lead, show some initiative, and fork the > > "Fedora Package Manager"? > > What about "working with upstream"? I thought that was one of the main Fedora > goals. > > > Jeff Johnson isn't fit to maintain Evolution. > > Why are doing this? Stop flaming, please. > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 > > Oh, for crying out loud, stop bringing up two year old bugs that have > long been resolved. This is not helping. It's resolved in upstream rpm 4.4.5; Fedora is stuck with 4.4.2 and so it doesn't look resolved to me (and I see no sign of a backported fix for this in the Fedora rpm changelog). Which is one of the issues that this thread was raised about. Paul. From pertusus at free.fr Mon Oct 23 19:43:03 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Oct 2006 21:43:03 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453CF8AD.1010800@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> Message-ID: <20061023193905.GA2367@free.fr> On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote: > Hi all! Overall I find the proposal very satisfying, I have some minor remarks. One general remark, maybe it could be said somewhere that contacting by mail/irc could also be done in place or in addition to bugzilla. No need to mention if it is too obvious. > === Inactive Packager === > > The packager normally should keep track of his packages; that means: > > * looking at the [:Extras/PackageStatus: Package Status] pages in the > wiki now and then I am not sure about that one. I find the Package Status very usefull, but I can't see in which case it would justify a change in a package without a report to the maintainer. Otherwise said, I don't think having an issue listed on the Package Status enough to permit experienced users to modify others packages without noticing them. > * fix EVR problems if they get mentioned in the problem reports on the > fedora-extras-list I would propose a refinement here: * fix EVR problems if they get mentioned in the problem reports on the fedora-extras-list, except for EVR issues with devel which occurs outside of the pre-release mass-rebuilds. The reasoning is that during testing periods those EVR issues with devel are not to be considered serious as to justify somebody modifying others package without a notice. > * Important stuff should be fixed as quickly if possible -- waiting > one day for the maintainer to show up and step in to fix a issue that > got reported to him is considered enough Sometimes it is even acceptable not to wait at all. For example one of my packages screwed the build system and I think it was perfectly right not to wait a minute to fix it. > * not that important problems should be dealt with quickly, too -- > waiting for 2-7 days (depending how bad the issue is) is considered enough > > * bugs need similar treatment like security problems: I have a cosmetic remark here, maybe would be better like * bugs needing similar treatment like security problems: > * annoying, but not that harmful bugs -- waiting for 21 days is > considered enough That's not always true. I think that those case should better be agreed upon in bugzilla discussion, and should only be acted upon if there is no disagreement, only a lack of responsivness. > * if you committed changes to another package wait some hours if > possible (normally 24 or 48) before you actually build the updated > package. That leaves some time for the maintainer to wake up ;-) It may be obvious, but this is a good rule but only for issues that are not serious. > As experienced packagers count: > > * FESCo members I don't want to be negative here, nor show disrepect to FESCo members, but I don't think being FESCo members should qualify here. A FESCo member could be there to represent something and not because he has great technical ability to fix packages. As a side note aren't the current FESCo members all sponsor? > * Sponsors > > * Especially the QA and Security SIGs > > * the SIG that's handling the area in which the package or the fix is > needed. But > > * the SIG has to exists for at least two months and needs to have > shown activity in the past two months > > * the member is and experienced Extras packager and around for at > least four months and member of the SIG for at least one month I think that it would also be right if experienced fedora core packagers could be considered as experienced Fedora packagers. Not all the core packagers, since some don't seems to care that much about the packaging guidelines. What about a rule like * core packagers that have been through a number of reviews (for extra or core packages) and are core packagers for more than 4 months. Or something like that. I think that the reverse could also be true, core packagers should seek more assistance in the extras community... But that's another debate. -- Pat From lemenkov at gmail.com Mon Oct 23 19:49:39 2006 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 23 Oct 2006 23:49:39 +0400 Subject: Renaming of fuse-encfs and fuse-sshfs to encfs and sshfs respectively. Message-ID: Hello all! I've talked with Szakacsits Szabolcs (author and maintainer of ntfs-3g, fuse filesystem for reading NTFS partitions) about these two packages names, and he strongly argues that it would be more convenient to name them simply as they are called in upstream. It's obvious, that people will simply type # yum install encfs then they want to install encfs, not # yum install fuse-encfs So we (with current naming scheme) just create another difficulty to Average Joe then he will try to install FC. That's why I (personally as current package maintainer) vote for renaming of these two packages. Any objections? -- With best regards! From ville.skytta at iki.fi Mon Oct 23 19:55:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 Oct 2006 22:55:57 +0300 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061021233219.23b1c35a.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> Message-ID: <1161633357.3527.22.camel@viper.local> On Sat, 2006-10-21 at 23:32 +0200, Michael Schwendt wrote: > This is the full list of binary rpms, which do not have a corresponding > src.rpm in the repository: > > Expiring (keep = 1): /extras/development/SRPMS > Skipping em8300-kmod > Skipping sysprof-kmod Just wondering, why are kmod packages skipped? From seg at haxxed.com Mon Oct 23 19:53:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 23 Oct 2006 14:53:33 -0500 Subject: RPM In-Reply-To: <20061023181705.GD5303@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> Message-ID: <1161633213.16747.27.camel@max.booze> On Mon, 2006-10-23 at 20:17 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 19:50, Callum Lerwick wrote: > > On Mon, 2006-10-23 at 10:59 +1000, Norman Gaywood wrote: > > > Another article and discussion of interest is "Who maintains RPM?", > > > posted in August 2006. > > > > > > http://lwn.net/Articles/196523/ > > > > After reading that, > > That article is biased and inflammatory. Can we please stop quoting it? > > > and especially this[1], can we *PLEASE* put our foot > > down, show some balls, take the lead, show some initiative, and fork the > > "Fedora Package Manager"? > > What about "working with upstream"? I thought that was one of the main Fedora > goals. > > > Jeff Johnson isn't fit to maintain Evolution. > > Why are doing this? Stop flaming, please. > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 > > Oh, for crying out loud, stop bringing up two year old bugs that have > long been resolved. This is not helping. > > Have you actually tried to talk to Jeff without prejudice? It's impossible > and improper to judge someone based on one feral bugreport. Hell, I wrote that response *before* I saw his little exchange with spot, just today. I stand by my GPG signed assessment. In two years his, shall we say, "interpersonal skills" have not matured one bit. I've had to deal with way too many people like him. Its not going to get better. He doesn't even seem to have the saving grace of irreplaceable technical skill. He's not an upstream worth dealing with. My worthless rabble vote is to just admit to ourselves we've forked already, cease contact with Jeff, and end the drama once and for all. Then fix RPM's crappy DB locking. IANARHE -------------- 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 Mon Oct 23 19:59:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Oct 2006 14:59:11 -0500 Subject: Renaming of fuse-encfs and fuse-sshfs to encfs and sshfs respectively. References: Message-ID: Peter Lemenkov wrote: > Hello all! > I've talked with Szakacsits Szabolcs (author and maintainer of > ntfs-3g, fuse filesystem for reading NTFS partitions) about these two > packages names, and he strongly argues that it would be more > convenient to name them simply as they are called in upstream. It's > obvious, that people will simply type > > # yum install encfs > > then they want to install encfs, not > > # yum install fuse-encfs > > So we (with current naming scheme) just create another difficulty to > Average Joe then he will try to install FC. > > That's why I (personally as current package maintainer) vote for > renaming of these two packages. Or just add to fuse-encfs something like: Provides: encfs = %{version} -- Rex From bugs.michael at gmx.net Mon Oct 23 20:42:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 Oct 2006 22:42:36 +0200 Subject: RFC: Junk in Fedora Extras In-Reply-To: <1161633357.3527.22.camel@viper.local> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> <1161633357.3527.22.camel@viper.local> Message-ID: <20061023224236.dfa7d51b.bugs.michael@gmx.net> On Mon, 23 Oct 2006 22:55:57 +0300, Ville Skytt? wrote: > On Sat, 2006-10-21 at 23:32 +0200, Michael Schwendt wrote: > > > This is the full list of binary rpms, which do not have a corresponding > > src.rpm in the repository: > > > > Expiring (keep = 1): /extras/development/SRPMS > > Skipping em8300-kmod > > Skipping sysprof-kmod > > Just wondering, why are kmod packages skipped? Because that is what repomanage did, too: http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-repobuild.py?hideattic=0&r1=1.17&r2=1.18&root=fedora As I understand it, we want to keep kmod packages for old kernel releases. If an updated kmod src.rpm is rebuilt for all kernel releases, however, we can expire old src.rpms. Otherwise not. From ville.skytta at iki.fi Mon Oct 23 21:12:54 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 Oct 2006 00:12:54 +0300 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061023224236.dfa7d51b.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> <1161633357.3527.22.camel@viper.local> <20061023224236.dfa7d51b.bugs.michael@gmx.net> Message-ID: <1161637974.3527.33.camel@viper.local> On Mon, 2006-10-23 at 22:42 +0200, Michael Schwendt wrote: > On Mon, 23 Oct 2006 22:55:57 +0300, Ville Skytt? wrote: > > > On Sat, 2006-10-21 at 23:32 +0200, Michael Schwendt wrote: > > > > > This is the full list of binary rpms, which do not have a corresponding > > > src.rpm in the repository: > > > > > > Expiring (keep = 1): /extras/development/SRPMS > > > Skipping em8300-kmod > > > Skipping sysprof-kmod > > > > Just wondering, why are kmod packages skipped? > > Because that is what repomanage did, too: > > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-repobuild.py?hideattic=0&r1=1.17&r2=1.18&root=fedora Yep, but that served a different purpose. > As I understand it, we want to keep kmod packages for old kernel > releases. Right. > If an updated kmod src.rpm is rebuilt for all kernel releases, > however, we can expire old src.rpms. Otherwise not. Note that we don't just rebuild any src.rpms without touching anything, all kmod package builds result in new corresponding src.rpms being shipped, just like all other packages. So we want to exclude kmod packages (source and binary) from the "keep only N versions of a package around" pruning, but if there are stray kmod binaries for which there's no corresponding srpm, I think they should get the same treatment as everything else. From dennis at ausil.us Mon Oct 23 21:12:56 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 23 Oct 2006 16:12:56 -0500 Subject: Buildsys Downtime In-Reply-To: <200610192219.38921.dennis@ausil.us> References: <200610192219.38921.dennis@ausil.us> Message-ID: <200610231612.56632.dennis@ausil.us> On Thursday 19 October 2006 22:19, Dennis Gilmore wrote: > On Monday October 23 at 10am EST cvs write access and the extras build > system will be disabled. this will allow for CVS to be branched for fc6 > and for the buildsys to have fc6 configs deployed. > > Downtime will be approximately 3 hours. > Ill send a notification before it goes down and again when its back up > > Your understanding and paitence is appreciated. Hi all, Thanks to the hard work of Jeremys cvs foo. we now have FC-6 branches in extras cvs and a the build targets to boot. so please do a cvs update -d on all your packages and go to work on making FC7 better Oh and the buildsys and cvs are back up and functional :) -- Dennis Gilmore, RHCE Proud Australian From wolters.liste at gmx.net Mon Oct 23 21:49:09 2006 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 23 Oct 2006 23:49:09 +0200 Subject: RPM In-Reply-To: <20061023171831.GA5303@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <200610231413.43706.wolters.liste@gmx.net> <20061023171831.GA5303@rathann.pekin.waw.pl> Message-ID: <200610232349.15519.wolters.liste@gmx.net> Once upon a time Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 14:13, Roland Wolters wrote: > > Once upon a time Dominik 'Rathann' Mierzejewski wrote: > > > On Monday, 23 October 2006 at 01:35, Roland Wolters wrote: > > > [...] > > > > > > >[3]http://www.fedoraproject.org/wiki/rpm-devel > > > > > > Why do you say [3] is useless? I think it sums up the current state > > > pretty well. > > > > It is useless in hte way that it does not list the contra side: I wanted > > to get an overview of both sides. > > Why do you think there are any downsides to upgrading to 4.4.7? > I've read the Changelog between 4.4.2 and .7 and nothing jumped at me. > Granted, I'm only a packager, not rpm developer. > Don't ask me - the package is not updated, and there must be reasons for that. Everything else would not make sense. At the given links you also find some hints why there are some disadvantages. Roland -- "Es wird nie m?glich sein, mit Flugmaschinen zu fliegen, die schwerer sind als Luft." -- Lord Kelvin, Pr?sident der Royal Society, 1895 -------------- 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 Mon Oct 23 21:52:10 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 Oct 2006 23:52:10 +0200 Subject: RFC: Junk in Fedora Extras In-Reply-To: <1161637974.3527.33.camel@viper.local> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> <1161633357.3527.22.camel@viper.local> <20061023224236.dfa7d51b.bugs.michael@gmx.net> <1161637974.3527.33.camel@viper.local> Message-ID: <20061023235210.1c0d0780.bugs.michael@gmx.net> On Tue, 24 Oct 2006 00:12:54 +0300, Ville Skytt? wrote: > So we want to exclude kmod packages (source and binary) from the "keep > only N versions of a package around" pruning, but if there are stray > kmod binaries for which there's no corresponding srpm, I think they > should get the same treatment as everything else. Which is what the implementation does. Except that binaries are not excluded via a white-list. The decision whether to delete any binary rpm depends solely on the availability of its src.rpm. No mercy! This also implies that if we want to remove a package from the repository, all we need to do is kill its single src.rpm. From mmcgrath at fedoraproject.org Mon Oct 23 21:55:34 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 23 Oct 2006 16:55:34 -0500 Subject: Reminder about CVS SYNC Message-ID: <3237e4410610231455v467337aak8171086acbfdce37@mail.gmail.com> Just a reminder about http://www.fedoraproject.org/wiki/Extras/CVSSyncNeeded Please add the bugzilla number to your request, it adds significant overhead when it is missing. -Mike From ville.skytta at iki.fi Mon Oct 23 22:08:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 Oct 2006 01:08:19 +0300 Subject: RFC: Junk in Fedora Extras In-Reply-To: <20061023235210.1c0d0780.bugs.michael@gmx.net> References: <20061021233219.23b1c35a.bugs.michael@gmx.net> <1161633357.3527.22.camel@viper.local> <20061023224236.dfa7d51b.bugs.michael@gmx.net> <1161637974.3527.33.camel@viper.local> <20061023235210.1c0d0780.bugs.michael@gmx.net> Message-ID: <1161641300.3527.47.camel@viper.local> On Mon, 2006-10-23 at 23:52 +0200, Michael Schwendt wrote: > On Tue, 24 Oct 2006 00:12:54 +0300, Ville Skytt? wrote: > > > So we want to exclude kmod packages (source and binary) from the "keep > > only N versions of a package around" pruning, but if there are stray > > kmod binaries for which there's no corresponding srpm, I think they > > should get the same treatment as everything else. > > Which is what the implementation does. > > Except that binaries are not excluded via a white-list. The decision > whether to delete any binary rpm depends solely on the availability of its > src.rpm. No mercy! > > This also implies that if we want to remove a package from the repository, > all we need to do is kill its single src.rpm. Great, sounds like it works exactly like I think it should, then. From lists at timj.co.uk Mon Oct 23 22:13:15 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 23 Oct 2006 23:13:15 +0100 Subject: Renaming of fuse-encfs and fuse-sshfs to encfs and sshfs respectively. In-Reply-To: References: Message-ID: <453D3E7B.7050100@timj.co.uk> Peter Lemenkov wrote: > It's obvious, that people will simply type > # yum install encfs > then they want to install encfs, not > # yum install fuse-encfs Actually, it's not. I think I would probably go for "fuse-encfs", since I would associate it with fuse. Admittedly I'm not Joe Inexperienced User, but I don't think that makes it invalid. Also is there a namespace issue here? Do any of the fuse FS modules have the same names as real (non-userspace) filesystem drivers/managers/tools, or the potential to do so? If so, that could be confusing at least. I would just add a "Provides:" if you think it's really necessary (and it doesn't conflict with anything else), but I wouldn't rename the packages. Tim From caillon at redhat.com Mon Oct 23 22:39:53 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 23 Oct 2006 18:39:53 -0400 Subject: RPM In-Reply-To: <20061023181705.GD5303@rathann.pekin.waw.pl> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> Message-ID: <453D44B9.6000103@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 October 2006 at 19:50, Callum Lerwick wrote: >> On Mon, 2006-10-23 at 10:59 +1000, Norman Gaywood wrote: >>> Another article and discussion of interest is "Who maintains RPM?", >>> posted in August 2006. >>> >>> http://lwn.net/Articles/196523/ >> After reading that, > > That article is biased and inflammatory. Can we please stop quoting it? > >> and especially this[1], can we *PLEASE* put our foot >> down, show some balls, take the lead, show some initiative, and fork the >> "Fedora Package Manager"? > > What about "working with upstream"? I thought that was one of the main Fedora > goals. I'm not sure where the confusion is. - Red Hat was upstream (Red Hat Package Manager). - Red Hat had a person working on it. - The person became the assumed upstream because he was the guy working on it. - The person's employment was severed. If the reasons at all involved the maintenance of the package in question, it seems clear that if the person is upstream "working with upstream" is already a bad relationship. The worst possible thing Fedora and Red Hat could do at this point is to engage in a relationship with an upstream developer with intent to sabotage such an integral package. It is conceivable that this is the case based on the past. Most people on this list are unable to determine this without access to the HR files and a better understanding of the situation, and those files probably won't be released. But Greg and Michael seldom make unfounded claims, and if they claim we need to sever these ties, then I agree. You don't dump your long time girlfriend and then expect there to be no hard feelings. From n3npq at mac.com Tue Oct 24 02:42:00 2006 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 23 Oct 2006 22:42:00 -0400 Subject: Fwd: RPM References: Message-ID: <5F98F997-7E25-49E7-A1E2-2D50C9A922FD@mac.com> Begin forwarded message: > > > > The worst possible thing Fedora and Red Hat could do at this > point is to engage in a relationship with > > an upstream developer with intent to sabotage such an integral > package. It is conceivable that this is > > the case based on the past. Most people on this list are unable > to determine this without access to the > > HR files and a better understanding of the situation, and those > files probably won't be released. But > > Greg and Michael seldom make unfounded claims, and if they claim > we need to sever these ties, then I > > agree. You don't dump your long time girlfriend and then expect > there to be no hard feelings. > > Eeek, the hidden HR records have blown my cover. OSS Sabotage! > Incest! Lust! News at 11! > > > > Perhaps you should write a thriller for kuro5shin or LWN. > > > > Get a grip: Blame not on malice what can be explained by ignorance > or ineptitude. > > > > 73 de Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Tue Oct 24 04:52:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Oct 2006 06:52:55 +0200 Subject: Renaming of fuse-encfs and fuse-sshfs to encfs and sshfs respectively. In-Reply-To: References: Message-ID: <453D9C27.9060802@leemhuis.info> Rex Dieter schrieb: > Peter Lemenkov wrote: > >> Hello all! >> I've talked with Szakacsits Szabolcs (author and maintainer of >> ntfs-3g, fuse filesystem for reading NTFS partitions) about these two >> packages names, and he strongly argues that it would be more >> convenient to name them simply as they are called in upstream. It's >> obvious, that people will simply type >> >> # yum install encfs >> >> then they want to install encfs, not >> >> # yum install fuse-encfs >> >> So we (with current naming scheme) just create another difficulty to >> Average Joe then he will try to install FC. >> >> That's why I (personally as current package maintainer) vote for >> renaming of these two packages. > Or just add to fuse-encfs something like: > Provides: encfs = %{version} +1 CU thl From cweyl at alumni.drew.edu Tue Oct 24 05:22:52 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 23 Oct 2006 22:22:52 -0700 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453CF8AD.1010800@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> Message-ID: <7dd7ab490610232222ida6e14cr35e37a06cc46d3c@mail.gmail.com> On 10/23/06, Thorsten Leemhuis wrote: > Hi all! > > we had some discussion one or two weeks ago (and some others earlier) > when touching other peoples packages in CVS might is okay in Fedora > Extras. FESCo worked on a policy for that. Here it is (directly from the > wiki at > http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing > ), please comment: I like :) I think there should be a brief passage on what is acceptable to change when conducting a maintainer-bypass, however... e.g. "as much as is necessary to fix the problem, and no more." e.g. just because my package foo has a security flaw and I've been off repairing the fedora orbital laser platform doesn't mean that person X should fix it _and_ change all my %{buildroot}s to $RPM_BUILD_ROOT. (Though, frankly, if I have access to the FOLP I suspect they're going to be very careful.) -Chris -- Chris Weyl Ex astris, scientia From nicolas.mailhot at laposte.net Tue Oct 24 07:06:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 24 Oct 2006 09:06:41 +0200 (CEST) Subject: RPM In-Reply-To: <453D44B9.6000103@redhat.com> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> <453D44B9.6000103@redhat.com> Message-ID: <41938.192.54.193.51.1161673601.squirrel@rousalka.dyndns.org> Le Mar 24 octobre 2006 00:39, Christopher Aillon a ?crit : > The worst possible thing Fedora and Red Hat could do at this point is to > engage in a relationship with an upstream developer with intent to > sabotage such an integral package. The worst possible thing Fedora and Red Hat could do at this point is to maintain the status-quo and not clarify their rpm plans. Most people there don't care if it's forking or working with jbj, as long as there is someone in charge. Will we start the RHEL6 cycle with no visibility on rpm future? There is only so much that can be fixed at the yum level. -- Nicolas Mailhot From fedora at camperquake.de Tue Oct 24 07:28:35 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 24 Oct 2006 09:28:35 +0200 Subject: Buildsys Downtime In-Reply-To: <200610231612.56632.dennis@ausil.us> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> Message-ID: <20061024092835.0f7fa7ee@banea.int.addix.net> Hi. On Mon, 23 Oct 2006 16:12:56 -0500, Dennis Gilmore wrote: > so please do a cvs update -d on all your packages and go to work on > making FC7 better > > Oh and the buildsys and cvs are back up and functional :) Oooh, fun. Thanks. /me goes to push some beta software into -devel From paul at city-fan.org Tue Oct 24 09:24:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 24 Oct 2006 10:24:20 +0100 Subject: Buildsys Downtime In-Reply-To: <200610231612.56632.dennis@ausil.us> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> Message-ID: <453DDBC4.40308@city-fan.org> Dennis Gilmore wrote: > On Thursday 19 October 2006 22:19, Dennis Gilmore wrote: >> On Monday October 23 at 10am EST cvs write access and the extras build >> system will be disabled. this will allow for CVS to be branched for fc6 >> and for the buildsys to have fc6 configs deployed. >> >> Downtime will be approximately 3 hours. >> Ill send a notification before it goes down and again when its back up >> >> Your understanding and paitence is appreciated. > > Hi all, > > Thanks to the hard work of Jeremys cvs foo. we now have FC-6 branches in > extras cvs and a the build targets to boot. > > so please do a cvs update -d on all your packages and go to work on making FC7 > better > > Oh and the buildsys and cvs are back up and functional :) Thanks; unfortunately it seems that the buildsys is back in non-functioning mode - the last successful build was around 3 hours ago. Since then, builds are failing with few diagnostics, e.g.: Job failed on arch i386 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/ ------------------------------------------------- Time: Tue Oct 24 02:18:33 2006 Target: fedora-development-i386-extras UID: 75aad75259000c30b149793ceeaf105424ca7194 Architecture: i386 SRPM: https://extras64.linux.duke.edu:8886//fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/smbldap-tools-0.9.2-4.fc7.src.rpm Starting download of https://extras64.linux.duke.edu:8886//fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/smbldap-tools-0.9.2-4.fc7.src.rpm. Retrieved https://extras64.linux.duke.edu:8886//fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/smbldap-tools-0.9.2-4.fc7.src.rpm. Waiting for repository to unlock before starting the build... Starting step 'building' with command: /usr/bin/setarch i686 /usr/bin/mock -r fedora-development-i386-core --arch i386 --resultdir=/mnt/build/builder_work/75aad75259000c30b149793ceeaf105424ca7194/result --statedir=/mnt/build/builder_work/75aad75259000c30b149793ceeaf105424ca7194/mock-state --uniqueext=75aad75259000c30b149793ceeaf105424ca7194 /mnt/build/builder_work/75aad75259000c30b149793ceeaf105424ca7194/source/smbldap-tools-0.9.2-4.fc7.src.rpm Cleaning up the buildroot... /usr/bin/setarch i686 /usr/bin/mock clean --uniqueext=75aad75259000c30b149793ceeaf105424ca7194 -r fedora-development-i386-core Output File List: ----------------- Output File: https://hammer3.fedora.redhat.com:8889/75aad75259000c30b149793ceeaf105424ca7194/result/job.log ----------------- ----------------------- Job failed due to build errors! Please see build logs. All that's at the indicated location is a job.log; no build.log. Paul. From bugs.michael at gmx.net Tue Oct 24 09:42:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Oct 2006 11:42:53 +0200 Subject: Buildsys Downtime In-Reply-To: <453DDBC4.40308@city-fan.org> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> Message-ID: <20061024114253.83291380.bugs.michael@gmx.net> On Tue, 24 Oct 2006 10:24:20 +0100, Paul Howarth wrote: > Job failed on arch i386 > > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/ > > Job failed due to build errors! Please see build logs. > > > All that's at the indicated location is a job.log; no build.log. But for ppc, which failed, too: http://buildsys.fedoraproject.org/logs/fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/ppc/root.log file:///pub/fedora/linux/extras/6/ppc/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/extras/6/ppc/repodata/repomd.xml' Trying other mirror. Cannot open/read repomd.xml file for repository: extras failure: repodata/repomd.xml from extras: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from extras: [Errno 256] No more mirrors to try. Cleaning up... From paul at city-fan.org Tue Oct 24 09:53:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 24 Oct 2006 10:53:41 +0100 Subject: Buildsys Downtime In-Reply-To: <20061024114253.83291380.bugs.michael@gmx.net> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> <20061024114253.83291380.bugs.michael@gmx.net> Message-ID: <453DE2A5.9030309@city-fan.org> Michael Schwendt wrote: > On Tue, 24 Oct 2006 10:24:20 +0100, Paul Howarth wrote: > >> Job failed on arch i386 >> >> >> Build logs may be found at >> http://buildsys.fedoraproject.org/logs/fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/ >> > >> Job failed due to build errors! Please see build logs. >> >> >> All that's at the indicated location is a job.log; no build.log. > > But for ppc, which failed, too: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20183-smbldap-tools-0.9.2-4.fc7/ppc/root.log > > > file:///pub/fedora/linux/extras/6/ppc/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/extras/6/ppc/repodata/repomd.xml' > Trying other mirror. > Cannot open/read repomd.xml file for repository: extras > failure: repodata/repomd.xml from extras: [Errno 256] No more mirrors to try. > Error: failure: repodata/repomd.xml from extras: [Errno 256] No more mirrors to try. > Cleaning up... Ah, I was thrown off the scent by the "Job failed on arch i386" message... Paul. From andy at smile.org.ua Tue Oct 24 10:04:47 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Tue, 24 Oct 2006 13:04:47 +0300 Subject: Buildsys Downtime In-Reply-To: <20061024114253.83291380.bugs.michael@gmx.net> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> <20061024114253.83291380.bugs.michael@gmx.net> Message-ID: <453DE53F.5030209@smile.org.ua> Michael Schwendt wrote: > But for ppc, which failed, too: Have te same problem with j-a-c-k building. :-( -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From andy at smile.org.ua Tue Oct 24 11:13:07 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Tue, 24 Oct 2006 14:13:07 +0300 Subject: Renaming of fuse-encfs and fuse-sshfs to encfs and sshfs respectively. In-Reply-To: <453D9C27.9060802@leemhuis.info> References: <453D9C27.9060802@leemhuis.info> Message-ID: <453DF543.8030703@smile.org.ua> Thorsten Leemhuis wrote: >>Or just add to fuse-encfs something like: >>Provides: encfs = %{version} > +1 In other hand, I'd like to see fuse-ntfs-3g as well. May be throught Provides: fuse-%{name} = %{version} -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From mtasaka at ioa.s.u-tokyo.ac.jp Tue Oct 24 12:24:32 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 24 Oct 2006 21:24:32 +0900 Subject: Buildsys Downtime In-Reply-To: <453DE53F.5030209@smile.org.ua> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> <20061024114253.83291380.bugs.michael@gmx.net> <453DE53F.5030209@smile.org.ua> Message-ID: <453E0600.8090005@ioa.s.u-tokyo.ac.jp> Andy Shevchenko wrote: > Michael Schwendt wrote: >> But for ppc, which failed, too: > Have te same problem with j-a-c-k building. :-( > Well, I am seeing building failure on FE-6 and FE-devel for more than four hours. Mamoru Tasaka From dcbw at redhat.com Tue Oct 24 13:55:57 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 24 Oct 2006 09:55:57 -0400 Subject: Buildsys Downtime In-Reply-To: <453E0600.8090005@ioa.s.u-tokyo.ac.jp> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> <20061024114253.83291380.bugs.michael@gmx.net> <453DE53F.5030209@smile.org.ua> <453E0600.8090005@ioa.s.u-tokyo.ac.jp> Message-ID: <1161698157.2970.6.camel@localhost.localdomain> On Tue, 2006-10-24 at 21:24 +0900, Mamoru Tasaka wrote: > Andy Shevchenko wrote: > > Michael Schwendt wrote: > >> But for ppc, which failed, too: > > Have te same problem with j-a-c-k building. :-( > > > Well, I am seeing building failure on FE-6 and FE-devel > for more than four hours. I successfully built a FE-devel package last night around 12:30am EST on i386, ppc, and x86_64. What package are you trying to build, and what was the job #? Dan > Mamoru Tasaka > From mtasaka at ioa.s.u-tokyo.ac.jp Tue Oct 24 14:07:52 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 24 Oct 2006 23:07:52 +0900 Subject: Buildsys Downtime In-Reply-To: <1161698157.2970.6.camel@localhost.localdomain> References: <200610192219.38921.dennis@ausil.us> <200610231612.56632.dennis@ausil.us> <453DDBC4.40308@city-fan.org> <20061024114253.83291380.bugs.michael@gmx.net> <453DE53F.5030209@smile.org.ua> <453E0600.8090005@ioa.s.u-tokyo.ac.jp> <1161698157.2970.6.camel@localhost.localdomain> Message-ID: <453E1E38.6050708@ioa.s.u-tokyo.ac.jp> Dan Williams wrote: > On Tue, 2006-10-24 at 21:24 +0900, Mamoru Tasaka wrote: >> Well, I am seeing building failure on FE-6 and FE-devel >> for more than four hours. > > I successfully built a FE-devel package last night around 12:30am EST on > i386, ppc, and x86_64. What package are you trying to build, and what > was the job #? > > Dan I retried at 23:00 JST(=UTC+9), however again it failed. http://buildsys.fedoraproject.org/build-status/job.psp?uid=20176 http://buildsys.fedoraproject.org/build-status/job.psp?uid=20174 Mamoru From nphilipp at redhat.com Tue Oct 24 16:00:20 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 24 Oct 2006 18:00:20 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <20061023193905.GA2367@free.fr> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> Message-ID: <1161705620.8330.2.camel@gibraltar.stuttgart.redhat.com> On Mon, 2006-10-23 at 21:43 +0200, Patrice Dumas wrote: > On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote: > > Hi all! > > Overall I find the proposal very satisfying, I have some minor remarks. > One general remark, maybe it could be said somewhere that contacting by > mail/irc could also be done in place or in addition to bugzilla. No need > to mention if it is too obvious. Well, bugzilla has one (IMO important) advantage over mail/irc: A neutral entity that tracks that someone made the attempt to contact the maintainer. With IRC you might ping the maintainer, but he hasn't looked at the client before leaving IRC. Mails might get lost in between. 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 fedora at leemhuis.info Tue Oct 24 17:03:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Oct 2006 19:03:51 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <7dd7ab490610232222ida6e14cr35e37a06cc46d3c@mail.gmail.com> References: <453CF8AD.1010800@leemhuis.info> <7dd7ab490610232222ida6e14cr35e37a06cc46d3c@mail.gmail.com> Message-ID: <453E4777.9040000@leemhuis.info> Chris Weyl schrieb: > On 10/23/06, Thorsten Leemhuis wrote: >> Hi all! >> >> we had some discussion one or two weeks ago (and some others earlier) >> when touching other peoples packages in CVS might is okay in Fedora >> Extras. FESCo worked on a policy for that. Here it is (directly from the >> wiki at >> http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing >> ), please comment: > [...] > I think there should be a brief passage on what is acceptable to > change when conducting a maintainer-bypass, however... e.g. "as much > as is necessary to fix the problem, and no more." [...] Quote from the proposal: "experienced packagers should limit their changes to other people packages to things that are well agreed upon. i.e. don't fix things considered somewhat controversial or a matter of style" That should be enough afaics. Cu thl From fedora at leemhuis.info Tue Oct 24 17:36:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Oct 2006 19:36:06 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <20061023193905.GA2367@free.fr> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> Message-ID: <453E4F06.4070109@leemhuis.info> Hi! Patrice Dumas schrieb: > On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote: > > Overall I find the proposal very satisfying, I have some minor remarks. MAny thanks for your comments. > One general remark, maybe it could be said somewhere that contacting by > mail/irc could also be done in place or in addition to bugzilla. No need > to mention if it is too obvious. Yeah, might be a good idea, but bugzilla should be preferred (see Nils mail) >> === Inactive Packager === >> The packager normally should keep track of his packages; that means: >> * looking at the [:Extras/PackageStatus: Package Status] pages in the >> wiki now and then > > I am not sure about that one. I find the Package Status very usefull, but I > can't see in which case it would justify a change in a package without > a report to the maintainer. Otherwise said, I don't think having an issue > listed on the Package Status enough to permit experienced users to modify > others packages without noticing them. Of course not everything that's listed on that page requires that someone else steps up to fix it. But contributors should look at the page now and then and watch out for their names because that's a good way to find potential problem. >> * fix EVR problems if they get mentioned in the problem reports on the >> fedora-extras-list > > I would propose a refinement here: > * fix EVR problems if they get mentioned in the problem reports on the > fedora-extras-list, except for EVR issues with devel which occurs outside > of the pre-release mass-rebuilds. > > The reasoning is that during testing periods those EVR issues with devel > are not to be considered serious as to justify somebody modifying others > package without a notice. Why not? People at any point of time may want to update from FC-current to rawhide. It should just work. And rawhide users are probably the best testers, so they always should have the latest version. Further: I don't think we should go to much into details (like the one you described) because the document otherwise might soon end might end i a big page that might be unmaintainable and to long to read. >> * Important stuff should be fixed as quickly if possible -- waiting >> one day for the maintainer to show up and step in to fix a issue that >> got reported to him is considered enough > Sometimes it is even acceptable not to wait at all. For example one of > my packages screwed the build system and I think it was perfectly right > not to wait a minute to fix it. Agreed, maybe I can get that integrated. >> * not that important problems should be dealt with quickly, too -- >> waiting for 2-7 days (depending how bad the issue is) is considered enough >> * bugs need similar treatment like security problems: > I have a cosmetic remark here, maybe would be better like > * bugs needing similar treatment like security problems: k, I'll integrate that when the wiki is ready again. >> * annoying, but not that harmful bugs -- waiting for 21 days is >> considered enough > That's not always true. I think that those case should better be agreed > upon in bugzilla discussion, and should only be acted upon if there is > no disagreement, only a lack of responsivness. Well, the whole section is titled "Inactive Packager", so this of course only applies to "lack of responsivness" ;-) >> * if you committed changes to another package wait some hours if >> possible (normally 24 or 48) before you actually build the updated >> package. That leaves some time for the maintainer to wake up ;-) > It may be obvious, but this is a good rule but only for issues that are > not serious. Agreed, will adjust. >> As experienced packagers count: >> * FESCo members > > I don't want to be negative here, nor show disrepect to FESCo members, > but I don't think being FESCo members should qualify here. A FESCo member > could be there to represent something and not because he has great > technical ability to fix packages. Well, I think all FESCo members normally should have a "technical ability to fix packages". Maybe one time there will be someone in FESCo that might not have it, but a FESCo member should be able to know about that and leave such work to others. And otherwise yell on the mailinglists ;) Errors get made by everyone and can be fixed. > As a side note aren't the current > FESCo members all sponsor? All FESCo members are sponsors these days. >> * Sponsors >> >> * Especially the QA and Security SIGs >> >> * the SIG that's handling the area in which the package or the fix is >> needed. But >> >> * the SIG has to exists for at least two months and needs to have >> shown activity in the past two months >> >> * the member is and experienced Extras packager and around for at >> least four months and member of the SIG for at least one month > > I think that it would also be right if experienced fedora core packagers > could be considered as experienced Fedora packagers. Not all the core > packagers, since some don't seems to care that much about the packaging > guidelines. What about a rule like > > * core packagers that have been through a number of reviews (for extra > or core packages) and are core packagers for more than 4 months. > > Or something like that. k, agreed. > I think that the reverse could also be true, core packagers should seek > more assistance in the extras community... But that's another debate. +1 :-) Cu thl From pertusus at free.fr Tue Oct 24 17:51:56 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 24 Oct 2006 19:51:56 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453CF8AD.1010800@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> Message-ID: <20061024175156.GA29817@free.fr> On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote: > > The packager normally should keep track of his packages; that means: > > * respond in bugs reported in bugzilla; especially fast if it's a > serious problem like a security issue > > * fix your stuff without explicit poking if it is mentioned in the > problem reports somewhere -- that includes: I think it should be: * fix his stuff without explicit poking if it is mentioned in the problem reports somewhere -- that includes: I may look cosmetic, but the 'you' instead of 'his' confused me. -- Pat From dennis at ausil.us Tue Oct 24 18:18:12 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 24 Oct 2006 13:18:12 -0500 Subject: Buildsys Outage Message-ID: <200610241318.13034.dennis@ausil.us> Hi All, Sorry for the inconvenience but the buildsys is temporarily down while things settle down with the release of FC-6 Your patience is appreciated. -- Dennis Gilmore, RHCE Proud Australian From pertusus at free.fr Tue Oct 24 19:46:05 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 24 Oct 2006 21:46:05 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453E4F06.4070109@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> <453E4F06.4070109@leemhuis.info> Message-ID: <20061024194605.GB29817@free.fr> On Tue, Oct 24, 2006 at 07:36:06PM +0200, Thorsten Leemhuis wrote: > > I don't want to be negative here, nor show disrepect to FESCo members, > > but I don't think being FESCo members should qualify here. A FESCo member > > could be there to represent something and not because he has great > > technical ability to fix packages. > > Well, I think all FESCo members normally should have a "technical > ability to fix packages". Maybe one time there will be someone in FESCo > that might not have it, but a FESCo member should be able to know about > that and leave such work to others. And otherwise yell on the > mailinglists ;) Errors get made by everyone and can be fixed. That is true for all the fedora contributors. I can't see why FESCo members should be treated specially. > > As a side note aren't the current > > FESCo members all sponsor? > > All FESCo members are sponsors these days. Ok, so it is redundant with the other condition today, and if someday a FESCo member isn't qualified as an experienced packager as per the other conditions, I don't think being in FESCo would make him experienced. FESCo members are elected, so they may not be experienced packagers, but something like representatives - although this is more a theoretical possibility, given how the community works. It is not very important, however since in general FESCo members will be sponsors or relevant SIG members, and so listing them separately don't hurt either. -- Pat From fedora at camperquake.de Tue Oct 24 20:02:46 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 24 Oct 2006 22:02:46 +0200 Subject: Splitting an existing package Message-ID: <20061024220246.051a4a57@lain> Hi. I maintain audacious in FE, a media player. Upstream has decided (with the latest release) to split audacious into two packages, one containing the player and one containing the plugins. I'd like to follow this split. So, I'd basically like to get a tree in CVS to put the plugins in, and somehow I do not think this requires a whole new review, since it is the same code as before, just laid out differently. How do I go about this? From pertusus at free.fr Tue Oct 24 20:03:03 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 24 Oct 2006 22:03:03 +0200 Subject: Splitting an existing package In-Reply-To: <20061024220246.051a4a57@lain> References: <20061024220246.051a4a57@lain> Message-ID: <20061024200303.GC29817@free.fr> On Tue, Oct 24, 2006 at 10:02:46PM +0200, Ralf Ertzinger wrote: > Hi. > > I maintain audacious in FE, a media player. Upstream has decided > (with the latest release) to split audacious into two packages, > one containing the player and one containing the plugins. I'd like > to follow this split. > > So, I'd basically like to get a tree in CVS to put the plugins in, > and somehow I do not think this requires a whole new review, since > it is the same code as before, just laid out differently. This could qualify as a sufficiently different for a new review. I think it depends on the package. But in any case there should be a procedure. > How do I go about this? I would like to do the same with the cernlib now that the debian package (which is the real upstream) is split. I asked some time ago but nobody responded... -- Pat From rdieter at math.unl.edu Tue Oct 24 20:17:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 24 Oct 2006 15:17:11 -0500 Subject: Splitting an existing package References: <20061024220246.051a4a57@lain> Message-ID: Ralf Ertzinger wrote: > So, I'd basically like to get a tree in CVS to put the plugins in, > and somehow I do not think this requires a whole new review, since > it is the same code as before, just laid out differently. Play it safe, do another review. It should pass muster quickly. -- Rex From j.w.r.degoede at hhs.nl Tue Oct 24 20:39:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 24 Oct 2006 22:39:17 +0200 Subject: Warning possible incompatible imlib2 update! (devel branch only) Message-ID: <453E79F5.9030304@hhs.nl> Hi, Now that FE-6 has been created / forked of in CVS I'm updating imlib2 in devel to 1.3.0 which is ABI compatible with 1.2.2 but uses gcc's visibility attribute and thus could break nasty programs which use functions not defined in the public header files. Regards, Hans From dennis at ausil.us Tue Oct 24 21:06:04 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 24 Oct 2006 16:06:04 -0500 Subject: Buildsys Outage In-Reply-To: <200610241318.13034.dennis@ausil.us> References: <200610241318.13034.dennis@ausil.us> Message-ID: <200610241606.04968.dennis@ausil.us> On Tuesday 24 October 2006 13:18, Dennis Gilmore wrote: > Hi All, > > Sorry for the inconvenience but the buildsys is temporarily down while > things settle down with the release of FC-6 > > Your patience is appreciated. Hi All, The buildsys in now back online Please mail the list if you experience any issues. -- Dennis Gilmore, RHCE Proud Australian From Christian.Iseli at licr.org Tue Oct 24 22:46:24 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 25 Oct 2006 00:46:24 +0200 Subject: xview anyone ? Message-ID: <20061025004624.4320c333@ludwig-alpha.unil.ch> Hi folks, hrmm... A colleague of mine would like to use a program called treetool, which can be used to display and tweak trees constructed from biological sequences... The fun thing is that this tool needs the xview library (remember Sun and OpenView ?) RH used to distribute an xview package (I actually still have a couple SRPMs), and I see Debian unstable has both treetool and xview... Anyone around here has an xview spec file that will play nicely with modularized X ? I can hear some chuckles in the background... But I just thought I'd ask :-) Cheers, Christian From buildsys at fedoraproject.org Wed Oct 25 00:41:50 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Oct 2006 20:41:50 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-24 Message-ID: <20061025004150.B50B815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 21 NetworkManager-vpnc-0.7.0-0.cvs20060929.3.fc7 aide-0.12-2.fc7 csound-5.03.0-4.fc7 dnsmasq-2.34-2.fc6 dvdisaster-0.70.2-1.fc6 gcstar-0.5.0-3.fc7 highlight-2.4.8-1.fc7 jd-1.8.0-0.2.beta061023.fc6 libburn-0.2.2-2.fc6 libopts-27.4-1.fc7 mercurial-0.9.1-2.fc7 pekwm-0.1.5-5.fc7 puppet-0.20.0-1.fc7 pygpgme-0.1-3.fc7 scrot-0.8-2.fc7 smbldap-tools-0.9.2-4.fc7 telepathy-gabble-0.4.1-1.fc7 tenr-de-styles-pkg-1.0-2.fc7 testdisk-6.5-1.fc7 w3c-markup-validator-0.7.3-1.fc7 xdg-utils-1.0-3.fc7 Packages built and released for Fedora Extras 6: 10 aide-0.12-2.fc6.1 cobbler-0.3.0-1.fc6 dnsmasq-2.34-2.fc6 international-time-0.0.2-2.fc6 koan-0.2.3-1.fc6 libburn-0.2.2-2.fc6 pygpgme-0.1-3.fc6 smbldap-tools-0.9.2-4.fc6 w3c-markup-validator-0.7.3-1.fc6 xdg-utils-1.0-3.fc6 Packages built and released for Fedora Extras 5: 13 autogen-5.8.7-2.fc5 cobbler-0.3.0-1.fc5 dnsmasq-2.34-2.fc5 jd-1.8.0-0.2.beta061023.fc5 koan-0.2.3-1.fc5 libburn-0.2.2-2.fc5 libopts-27.4-1.fc5 perl-Cache-Mmap-0.09-1.fc5 puppet-0.20.0-1.fc5 qt4-4.2.1-2.fc5 testdisk-6.5-1.fc5 w3c-markup-validator-0.7.3-1.fc5 xdg-utils-1.0-3.fc5 Packages built and released for Fedora Extras 4: 3 puppet-0.20.0-1.fc4 qt4-4.1.5-2.fc4 testdisk-6.5-1.fc4 Packages built and released for Fedora Extras 3: 1 testdisk-6.5-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 Wed Oct 25 00:42:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Oct 2006 20:42:26 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-24 Message-ID: <20061025004226.5054215212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bind FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) checkpolicy FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) frysk FC5-updates > FC6 (0:0.0.1.2006.10.13.rh1-1.fc5 > 0:0.0.1.2006.10.02.rh1-1.fc6) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) qt FC5-updates > FC6 (1:3.3.7-0.1.fc5 > 1:3.3.6-13) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) xsane FC5-updates > FC6 (0:0.991-3.fc5 > 0:0.991-2.fc6) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.0-1.fc5 > 0:0.2.8-1.fc6) koan FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) paul AT all-the-johnsons.co.uk: autogen FE5 > FE6 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) rdieter AT math.unl.edu: qt4 FE5 > FE6 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) autogen: paul AT all-the-johnsons.co.uk FE5 > FE6 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) checkpolicy: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.0-1.fc5 > 0:0.2.8-1.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) frysk: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.0.1.2006.10.13.rh1-1.fc5 > 0:0.0.1.2006.10.02.rh1-1.fc6) koan: mdehaan AT redhat.com FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) qt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (1:3.3.7-0.1.fc5 > 1:3.3.6-13) qt4: rdieter AT math.unl.edu FE5 > FE6 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.991-3.fc5 > 0:0.991-2.fc6) From kevin.kofler at chello.at Wed Oct 25 01:01:44 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 25 Oct 2006 01:01:44 +0000 (UTC) Subject: Package EVR problems in FC+FE 2006-10-24 References: <20061025004226.5054215212E@buildsys.fedoraproject.org> Message-ID: This EVR report doesn't look fully prepared for the branching of FC6. There's no FC7/devel appearing in the listings and FC6-updates don't appear to be looked at. It might also still be looking at developement for "FC6" and extras-development for "FE6", though I'm not sure about that one. Kevin Kofler From cweyl at alumni.drew.edu Wed Oct 25 01:37:15 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 24 Oct 2006 18:37:15 -0700 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <20061024194605.GB29817@free.fr> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> <453E4F06.4070109@leemhuis.info> <20061024194605.GB29817@free.fr> Message-ID: <7dd7ab490610241837u4ac1532o772b5e1f102681ae@mail.gmail.com> On 10/24/06, Patrice Dumas wrote: > On Tue, Oct 24, 2006 at 07:36:06PM +0200, Thorsten Leemhuis wrote: > > > As a side note aren't the current > > > FESCo members all sponsor? > > > > All FESCo members are sponsors these days. > > Ok, so it is redundant with the other condition today, and if someday a > FESCo member isn't qualified as an experienced packager as per the other > conditions, I don't think being in FESCo would make him experienced. > FESCo members are elected, so they may not be experienced packagers, but > something like representatives - although this is more a theoretical > possibility, given how the community works. > > It is not very important, however since in general FESCo members will be > sponsors or relevant SIG members, and so listing them separately don't hurt > either. Just to correct the assumption of how it ended up that all FESCo members are sponsors, it might be relevant to note that not all FESCo members were sponsors after the last election... If memory serves, FESCo voted to make all non-sponsor members sponsors on the basis of their being members a couple months back. I don't think there's any guarantee that all future FESCo's will continue to be constituted solely by sponsors unless it either becomes a requirement to hold the office (or consequence thereof). -Chris -- Chris Weyl Ex astris, scientia From buildsys at fedoraproject.org Wed Oct 25 01:43:30 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 25 Oct 2006 01:43:30 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-24 Message-ID: <20061025014330.3615.83287@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-1.fc6.i386 koffice-kivio - 1.6.0-1.fc6.i386 orange - 0.3-3.cvs20051118.fc6.i386 scribus - 1.3.3.4-1.fc6.i386 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (24 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (24 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (24 days) dcbw AT redhat.com csound - 5.03.0-4.fc7.i386 plague - 0.4.4.1-2.fc3.noarch (39 days) plague - 0.4.4.1-2.fc3.noarch (39 days) plague - 0.4.4.1-2.fc4.noarch (39 days) plague - 0.4.4.1-2.fc4.noarch (39 days) plague - 0.4.4.1-2.fc4.noarch (39 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch showimg-pgsql - 0.9.5-10.fc4.i386 showimg-pgsql - 0.9.5-10.fc4.ppc showimg-pgsql - 0.9.5-10.fc4.x86_64 showimg-pgsql - 0.9.5-10.fc5.i386 showimg-pgsql - 0.9.5-10.fc5.ppc showimg-pgsql - 0.9.5-10.fc5.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (15 days) linphone - 1.2.0-4.fc5.ppc (15 days) linphone - 1.2.0-4.fc5.x86_64 (15 days) linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.x86_64 linphone - 1.2.0-7.fc6.x86_64 matt AT truch.net kst - 1.3.1-1.fc6.i386 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (5 days) syck-php - 0.55-9.fc5.ppc (5 days) syck-php - 0.55-9.fc5.x86_64 (5 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 plplot-gnome - 5.6.1-7.fc6.i386 paul AT all-the-johnsons.co.uk autogen - 5.8.7-1.fc6.i386 autogen - 5.8.7-1.fc6.ppc autogen - 5.8.7-1.fc6.ppc autogen - 5.8.7-1.fc6.x86_64 rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 redhat-bugzilla AT linuxnetz.de eggdrop - 1.6.18-3.fc6.i386 eggdrop - 1.6.18-3.fc6.ppc eggdrop - 1.6.18-3.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.ppc requires libopts.so.24 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- csound-5.03.0-4.fc7.i386 requires libpython2.4.so.1.0 gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-1.fc6.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-1.fc6.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.ppc requires libopts.so.24 eggdrop-1.6.18-3.fc6.ppc requires libdns.so.21 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.x86_64 requires libopts.so.24()(64bit) eggdrop-1.6.18-3.fc6.x86_64 requires libdns.so.21()(64bit) linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.i386 requires libopts.so.24 eggdrop-1.6.18-3.fc6.i386 requires libdns.so.21 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: matt AT truch.net package: kst - 1.3.1-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libkjsembed.so.1 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: koffice-kivio - 1.6.0-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 package: orange - 0.3-3.cvs20051118.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 package: koffice-core - 1.6.0-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 package: scribus - 1.3.3.4-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: denis AT poolshark.org package: k3d - 0.6.3.1-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: dcbw AT redhat.com package: csound - 5.03.0-4.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: paul AT all-the-johnsons.co.uk package: autogen - 5.8.7-1.fc6.ppc from fedora-extras-6-ppc unresolved deps: libopts.so.24 package: autogen - 5.8.7-1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libopts.so.24()(64bit) package: autogen - 5.8.7-1.fc6.i386 from fedora-extras-6-i386 unresolved deps: libopts.so.24 ====================================================================== New report for: orion AT cora.nwra.com package: plplot - 5.6.1-7.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 package: plplot-gnome - 5.6.1-7.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: redhat-bugzilla AT linuxnetz.de package: eggdrop - 1.6.18-3.fc6.ppc from fedora-extras-6-ppc unresolved deps: libdns.so.21 package: eggdrop - 1.6.18-3.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libdns.so.21()(64bit) package: eggdrop - 1.6.18-3.fc6.i386 from fedora-extras-6-i386 unresolved deps: libdns.so.21 ====================================================================== New report for: jeff AT ocjtech.us package: linphone - 1.2.0-7.fc6.ppc from fedora-extras-6-ppc unresolved deps: libortp.so.2 package: linphone - 1.2.0-7.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libortp.so.2()(64bit) package: linphone - 1.2.0-7.fc6.i386 from fedora-extras-6-i386 unresolved deps: libortp.so.2 ====================================================================== New report for: rdieter AT math.unl.edu package: gift - 0.11.8.1-6.fc6.1.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 From jkeating at redhat.com Tue Oct 24 21:53:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Oct 2006 17:53:04 -0400 Subject: New Project: pungi - A Fedora release composing tool Message-ID: <200610241753.07447.jkeating@redhat.com> I have started a new project, by the name of Pungi. This project aims to be a tool to compose Fedora releases. The goals include simplicity of both code and interface. I hope it will be a candidate for the Fedora Project's official tool to create user specific composes of Fedora comprising of both Core and Extras packages (or just Fedora packages once things merge) as well as the tool to compose the official Fedora Project spin of Fedora. It should prove useful to anybody creating a Fedora based distribution as well. The project is GPLv2 licensed. How it (I hope) works: A package list is fed into Pungi, either by comps or some other means. A set of yum repos to find packages in are also fed in. Pungi will search for matching packages in the set of repos and add the package to the download list. The download lost is depclosed (somewhat different than depsolved, no local rpmdb involved), all the deps that are pulled in are depclosed, etc... The list of packages is then downloaded into a configured cache dir and hardlinked into an arch specific dir within a configured destination dir. Then anaconda provided tools such as buildinstall, pkgorder, and splittree are ran on the directory of packages turning it into an installable tree and splitting packages into CD iso sized sets. Mkisofs would be used to create teh CD isos and DVD iso. These are the basic steps. The tool could further be extended to run some simple tree sanity to ensure the compose completed correctly, or other post processing type things. How to help: The code for this project lives in a public mercurial repository: hg clone http://linux.duke.edu/projects/pungi pungi Write access is via ssh and can be given upon (validated) request. Discussion of the project will make use of the fedora-buildsys-list at redhat.com mailing list. There are no web pages (other than the hg-web interface at the above URL) currently. The source includes information about design and some files for testing functionality. Since this is my first 'from scratch' python project, I welcome input not only on code content but code design, project layout, etc.. Also, even though I work for Red Hat, this is not so much a Red Hat software project. I'm developing this in the community space, a lot on my own time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- -- Fedora-buildsys-list mailing list Fedora-buildsys-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 25 02:14:58 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 25 Oct 2006 11:14:58 +0900 Subject: Fedora Extras Package Build Report 2006-10-24 In-Reply-To: <20061025004150.B50B815212E@buildsys.fedoraproject.org> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> Message-ID: <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 21 > jd-1.8.0-0.2.beta061023.fc6 This is strange because the rpm I built for FE-devel is jd-1.8.0-0.2.beta061023.fc7, not .fc6. Mamoru Tasaka From rc040203 at freenet.de Wed Oct 25 02:05:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Oct 2006 04:05:49 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453E4F06.4070109@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> <453E4F06.4070109@leemhuis.info> Message-ID: <1161741950.20051.29.camel@mccallum.corsepiu.local> On Tue, 2006-10-24 at 19:36 +0200, Thorsten Leemhuis wrote: > Hi! > > Patrice Dumas schrieb: > > On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote: > >> As experienced packagers count: > >> * FESCo members > > > > I don't want to be negative here, nor show disrepect to FESCo members, > > but I don't think being FESCo members should qualify here. A FESCo member > > could be there to represent something and not because he has great > > technical ability to fix packages. > > Well, I think all FESCo members normally should have a "technical > ability to fix packages". Maybe one time there will be someone in FESCo > that might not have it, but a FESCo member should be able to know about > that and leave such work to others. And otherwise yell on the > mailinglists ;) Errors get made by everyone and can be fixed. > > > As a side note aren't the current > > FESCo members all sponsor? > > All FESCo members are sponsors these days. I would really appreciate it, if people would learn to distinguish their different roles in Fedora, in particular to keep technical issues separate from political and marketing affairs. FESCo is a political organ, not a technical one, nor are FESCO members necessarily active packagers nor specially technically qualified people. So, though it might be true that current FESCO members for some reasons are sponsors, this relation IMO should be consider "random coincidence". The same applies to other Fedora organs, such as ambassadors or FPB's. Ralf From jspaleta at gmail.com Wed Oct 25 05:07:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 Oct 2006 21:07:56 -0800 Subject: RPM In-Reply-To: <453D44B9.6000103@redhat.com> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> <453D44B9.6000103@redhat.com> Message-ID: <604aa7910610242207q2d501f7ej430bbd117881eba2@mail.gmail.com> On 10/23/06, Christopher Aillon wrote: > You don't dump your long time > girlfriend and then expect there to be no hard feelings. I think ben fold summed up this line of thought quite succintly. http://www.lyricsdepot.com/ben-folds-five/song-for-the-dumped.html -jef"and don't for get my black t-shirt"spaleta . From ville.skytta at iki.fi Wed Oct 25 06:50:29 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 25 Oct 2006 09:50:29 +0300 Subject: Package EVR problems in FC+FE 2006-10-24 In-Reply-To: References: <20061025004226.5054215212E@buildsys.fedoraproject.org> Message-ID: <1161759029.3527.83.camel@viper.local> On Wed, 2006-10-25 at 01:01 +0000, Kevin Kofler wrote: > This EVR report doesn't look fully prepared for the branching of FC6. That's right, I'll fix it before the next push. From Axel.Thimm at ATrpms.net Wed Oct 25 07:56:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 09:56:09 +0200 Subject: Fedora Extras packaging beta software into production repos, why? Message-ID: <20061025075609.GE31188@neu.nirvana> Hi, ATrpms is packaging asterisk and friends for quite some time now. ATrpms' buildsystem has also enabled Fedora Extras during the build procedure to ensure better interoperability, e.g. use BR's out of Fedora Extras. For some reason Fedora Extras now had to package a beta version of the asterisk suite instead of the current release. I'm used to packagers at FE ignoring existing packages at other repos which is a bad thing per se, but why - packaging a beta software that is known to have troubles, - creates broken builds for other non-suspecting repos and - gets right into production repos like FC5? Note that for some packages it really makes sense to use beta/prereleases, VCS cuts and the like, but there is no reason to do so in this case. As a consequence I will not only need to rebuild all of the asterisk suite again to pick up the proper dependencies, but also to stop using Fedora Extras as a repo for build requirements and start using Epoch on clean packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed Oct 25 08:06:39 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 25 Oct 2006 10:06:39 +0200 Subject: xview anyone ? In-Reply-To: <20061025004624.4320c333@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> Message-ID: <20061025080639.GA2622@free.fr> On Wed, Oct 25, 2006 at 12:46:24AM +0200, Christian Iseli wrote: > Hi folks, > > hrmm... > > A colleague of mine would like to use a program called treetool, which > can be used to display and tweak trees constructed from biological > sequences... The fun thing is that this tool needs the xview library > (remember Sun and OpenView ?) Treetool seems a nice and usefull tool... > RH used to distribute an xview package (I actually still have a couple > SRPMs), and I see Debian unstable has both treetool and xview... Anyone > around here has an xview spec file that will play nicely with > modularized X ? The debian package has a giant patchset (even though the debian maintainer seems to be the upstream maintainer). So it seems to me that one should coordinate with them. I don't really want to become the xview maintainer since I don't use it, but I could have a look at it and try to produce something by te end of week (unless somebody else is interested). -- Pat From Christian.Iseli at licr.org Wed Oct 25 09:10:32 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 25 Oct 2006 11:10:32 +0200 Subject: xview anyone ? In-Reply-To: <20061025080639.GA2622@free.fr> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> Message-ID: <20061025111032.50812465@ludwig-alpha.unil.ch> On Wed, 25 Oct 2006 10:06:39 +0200, Patrice Dumas wrote: > The debian package has a giant patchset (even though the debian maintainer > seems to be the upstream maintainer). So it seems to me that one should > coordinate with them. Agreed. > I don't really want to become the xview maintainer > since I don't use it, but I could have a look at it and try to produce > something by te end of week (unless somebody else is interested). That'd be great. I can be the maintainer, since it seems it would be useful for colleagues here... Once that's in, I'll look at packaging treetool too (I hope it has no other funky requirements). I think the gde package also requires xview, and would also be useful, so I'll probably look at that one too. Cheers, C From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Oct 25 10:01:17 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 25 Oct 2006 12:01:17 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025075609.GE31188@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> Message-ID: <20061025120117.7e4b0049@python3.es.egwn.lan> Axel Thimm wrote : > As a consequence I will not only need to rebuild all of the asterisk > suite again to pick up the proper dependencies, but also to stop using > Fedora Extras as a repo for build requirements and start using Epoch > on clean packages. Axel, this is frame bait, plain and simple, and I'd really wish you'd omit such comments from discussions in order to first let people understand the problem, then let us all have a constructive discussion about it. These kind of threats will _never_ help, quite the opposite. Back to the initial problem : Extras has included a beta version of asterisk as well as beta versions of the required libraries. So... first question that comes to mind : "Why a beta?" (especially as you state that is has many know problems) I don't know, but you could ask in the review request, or ask Jeffrey C. Ollie directly : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 Note that the release of the package is PLAIN WRONG, and as such the package shouldn't be able to pass the review, and the zaptel package shouldn't have passed its review either : http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a Then the second question : "Why backport to FC5 and not just leave in FC6?". Again, I would have left FC5 alone for such a package, but that's just me. There probably is a reason. Once it is clearer why this decision was made, then we can move forward into the discussion and try to look for solutions to your problem. - Epoch is not the answer. - But what was the question? - It doesn't matter. ;-p Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.11 0.13 0.10 From Axel.Thimm at ATrpms.net Wed Oct 25 10:06:29 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 12:06:29 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025120117.7e4b0049@python3.es.egwn.lan> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> Message-ID: <20061025100629.GA21155@neu.nirvana> On Wed, Oct 25, 2006 at 12:01:17PM +0200, Matthias Saou wrote: > - Epoch is not the answer. > - But what was the question? Rectifying broken asterisk setups? It's me getting 3 reports on list, 1 in bz and 5 in PM within one (1) day on this subject. > - It doesn't matter. Sorry, but I miss the humor in this, and I'm busy fixing broken stuff to get further into 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Oct 25 10:36:23 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 25 Oct 2006 12:36:23 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025100629.GA21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> Message-ID: <20061025123623.5b74bc03@python3.es.egwn.lan> Axel Thimm wrote : > Sorry, but I miss the humor in this, and I'm busy fixing broken stuff > to get further into this. Well, don't think just about the present, think about the long term : You'll also be getting annoying reports about overriding Extras packages regarding libpri, zaptel and asterisk, and the usual bad publicity that accompanies it :-( We'd be all much better off if it can be avoided! To avoid this you could have submitted your packages for Extras inclusion, but it's too late now. What you can do is : 1) Try to pause the asterisk inclusion into Extras until further discussion happens (i.e. someone answers the "Why a beta?") 2) Try to have asterisk and its dependencies not released for FC5 3) Join the discussions that are going on in the bugzilla reviews ...possibly more. I understand why you're unhappy, but I'm just trying to point out that you need to understand that the small "Red Hat Linux" ecosystem has now evolved in a much more complex "Fedora Core + Fedora Extras" one, which is trickier for external packagers on one hand, but simpler on the other since one has now less external packages to manage. Obviously, for packagers like Dag and you who try to cover as many RHEL and Fedora releases as possible, the "simpler" part doesn't really apply all that much... but it could... think "Extras for RHEL" which has been mentioned a few times already, for which I really encourage you to get involved ASAP in order to help get things right, and in a way that won't lead to problems like this asterisk one. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.03 0.09 0.09 From Axel.Thimm at ATrpms.net Wed Oct 25 10:56:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 12:56:27 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025123623.5b74bc03@python3.es.egwn.lan> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> Message-ID: <20061025105627.GD21155@neu.nirvana> On Wed, Oct 25, 2006 at 12:36:23PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > Sorry, but I miss the humor in this, and I'm busy fixing broken stuff > > to get further into this. > > Well, don't think just about the present, think about the long term : > You'll also be getting annoying reports about overriding Extras > packages regarding libpri, zaptel and asterisk, and the usual bad > publicity that accompanies it :-( > We'd be all much better off if it can be avoided! > > To avoid this you could have submitted your packages for Extras > inclusion, but it's too late now. What you can do is : When I offered it was said that zaptel is dead-before-review and the rest due to being dependent as well. > 1) Try to pause the asterisk inclusion into Extras until further > discussion happens (i.e. someone answers the "Why a beta?") No, I'm not going to battle this, and there is no way to "pause" this, after someone's "go" it's was blitz-reviewed and pushed into the repo in lightning speed - I wish my FE packages would slide in like that. There is no mechanism anymore to fix any of this short of the ugly introduction of epochs. I hate epochs and even more so being forced to use them. > 2) Try to have asterisk and its dependencies not released for FC5 Matthias, if it were not *already* released into FC5 and FC6 the bug would not had shown up! > I understand why you're unhappy, but I'm just trying to point out that > you need to understand that the small "Red Hat Linux" ecosystem has now > evolved in a much more complex "Fedora Core + Fedora Extras" one, Exactly and with size comes responsibility. Stamping over existing infrastucture is an unhealthy ecosystem. > think "Extras for RHEL" which has been mentioned a few times > already, for which I really encourage you to get involved ASAP I am even on a non-public list from very early on this matter, so be assured I'm pushing this as well. But it can't be all one-sided. It can't be that (again) the burden lies outside of FE. I've been trying to support FE in the last year as well as I can, and instead of getting the projects closer or some positive feedback I get more breakage and what is funny even more alienation from Joe Random. I'm quite burned out (once again), and need to cater for ATrpms first. Just as as side-note: There is even a paragraph in some of our guidelines of trying to be compatible in some choices with other distributions like SuSE and Debian. But the own 3rd-party repos are ignored. The revolution eats its children. Anyway, too much talk once again. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Oct 25 11:18:54 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Oct 2006 13:18:54 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025105627.GD21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> Message-ID: <453F481E.3030401@leemhuis.info> Hi all! Just for completeness (keeping my nose out of the discussion itself): Axel Thimm schrieb: > On Wed, Oct 25, 2006 at 12:36:23PM +0200, Matthias Saou wrote: >> Axel Thimm wrote : >[...] >> think "Extras for RHEL" which has been mentioned a few times >> already, for which I really encourage you to get involved ASAP > > I am even on a non-public list from very early on this matter, so be > assured I'm pushing this as well. That list is still existent, but not used anymore since the effort was announced in the public. All future discussions will be held on this mailinglist in the open (well, yes, there is the closed FESCo mailinglist were we sometimes [have to] discuss things in private, but we try to avoid using it). CU thl From giallu at gmail.com Wed Oct 25 11:27:08 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 25 Oct 2006 13:27:08 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025105627.GD21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> Message-ID: On 10/25/06, Axel Thimm wrote: > > > 2) Try to have asterisk and its dependencies not released for FC5 > > Matthias, if it were not *already* released into FC5 and FC6 the bug > would not had shown up! Are you talking about astrerisk itself or some dependency? AFAICS, asterisk is still under review, so your comments are very well in time: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 From Axel.Thimm at ATrpms.net Wed Oct 25 11:48:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 13:48:31 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> Message-ID: <20061025114831.GG21155@neu.nirvana> On Wed, Oct 25, 2006 at 01:27:08PM +0200, Gianluca Sforna wrote: > On 10/25/06, Axel Thimm wrote: > > > > >> 2) Try to have asterisk and its dependencies not released for FC5 > > > >Matthias, if it were not *already* released into FC5 and FC6 the bug > >would not had shown up! > > Are you talking about astrerisk itself or some dependency? I'm talking about dependencies. While building the new security hotfix for the released and stable asterisk package it picked up for example beta versions of zaptel and libpri (maybe something else, too, these two already silently defunc'd the package build), because I had turned on FE FC4 upwards for ATrpms' buildsystem since about half a year in the belief that this should help close the gap, but it became a back-fire. > AFAICS, asterisk is still under review, so your comments are very well in > time: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178922 No, it's the dependencies that are already in FC5 in beta. Just to make my point clear: I'm ranting for FE breaking ATrpms, of course, but even for active ATrpms-agnostics there should be one very important issue: Why package beta software, when you don't have to, and why shove it right into productive repos? This just lowers the quality of the repo as a total. I for one am extremely conservative with my own packaging in FE, and I think most people here do so the same to keep the QA standards high. Perhaps FE needs a testing section (many other repos have such stability sections, e.g. "updates" has, kde-redhat has, ATrpms has, freshrpms has and fedora.us also had). Even devel is wrong as it automatically gets blessed to golden status by every FC release. so it's either treating devel as carefully as a release, or creating a space were experimentation is allowed and were packages in there don't get automatically promoted to "stable" ones. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Oct 25 11:55:05 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 25 Oct 2006 13:55:05 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025114831.GG21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> Message-ID: <20061025135505.49859c7b@python3.es.egwn.lan> Axel Thimm wrote : > Just to make my point clear: I'm ranting for FE breaking ATrpms, of > course, but even for active ATrpms-agnostics there should be one very > important issue: Why package beta software, when you don't have to, > and why shove it right into productive repos? This just lowers the > quality of the repo as a total. I for one am extremely conservative > with my own packaging in FE, and I think most people here do so the > same to keep the QA standards high. Then ask the right question to the right person : Ask the zaptel, libpri and asterisk packages owner why he made such a decision. Note that in your first email you write : "Note that for some packages it really makes sense to use beta/prereleases, VCS cuts and the like, but there is no reason to do so in this case." I agree that it makes sense in some cases, but I have no idea if it does in this particular one, nor why it would or wouldn't. I couldn't find any info in the reviews after a quick glance, so I can only once again suggest you ask the person who made the choice. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.06 0.04 0.05 From bugs.michael at gmx.net Wed Oct 25 12:11:00 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 14:11:00 +0200 Subject: Build-sys weirdness (was: Re: Fedora Extras Package Build Report 2006-10-24) In-Reply-To: <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> Message-ID: <20061025141100.51bde19a.bugs.michael@gmx.net> On Wed, 25 Oct 2006 11:14:58 +0900, Mamoru Tasaka wrote: > buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 21 > > jd-1.8.0-0.2.beta061023.fc6 > > This is strange because the rpm I built for FE-devel is > jd-1.8.0-0.2.beta061023.fc7, not .fc6. You forgot to "cvs up" your "common" directory. As a result, you've submitted a .fc6 build request for development, resulting in _two_ (!) src.rpms and .fc7 binary rpms: http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/jd/1.8.0-0.2.beta061023.fc7/SRPM/ Rest assured, a few other packagers have run into the same trap. While the push script is smart in some areas, it doesn't expect more than one src.rpm per build-job, because build-job results are stored in unique sub-directories. I'm not sure yet how to work around that (adding EVR sorting and other overhead sounds wrong to me). You know, we already prune old build results from the needsign queue and only push the latest EVR. The easiest fix is: "Packagers, submit proper build-jobs!" From rdieter at math.unl.edu Wed Oct 25 12:11:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Oct 2006 07:11:23 -0500 Subject: Fedora Extras packaging beta software into production repos, why? References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> Message-ID: Axel Thimm wrote: > Perhaps FE needs a testing section (many other repos have such > stability sections, e.g. "updates" has, kde-redhat has, ATrpms has, > freshrpms has and fedora.us also had). uh huh. +1 -- Rex From rdieter at math.unl.edu Wed Oct 25 12:12:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Oct 2006 07:12:27 -0500 Subject: Fedora Extras packaging beta software into production repos, why? References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> <20061025135505.49859c7b@python3.es.egwn.lan> Message-ID: Matthias Saou wrote: > Axel Thimm wrote : > >> Just to make my point clear: I'm ranting for FE breaking ATrpms, of >> course, but even for active ATrpms-agnostics there should be one very >> important issue: Why package beta software, when you don't have to, >> and why shove it right into productive repos? This just lowers the >> quality of the repo as a total. I for one am extremely conservative >> with my own packaging in FE, and I think most people here do so the >> same to keep the QA standards high. > > Then ask the right question to the right person : Ask the zaptel, > libpri and asterisk packages owner why he made such a decision. Note > that in your first email you write : yup. bugzilla good. mailing list flames bad. -- Rex From bugs.michael at gmx.net Wed Oct 25 12:27:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 14:27:21 +0200 Subject: Build-sys weirdness (was: Re: Fedora Extras Package Build Report 2006-10-24) In-Reply-To: <20061025141100.51bde19a.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> Message-ID: <20061025142721.f0926b53.bugs.michael@gmx.net> On Wed, 25 Oct 2006 14:11:00 +0200, Michael Schwendt wrote: > On Wed, 25 Oct 2006 11:14:58 +0900, Mamoru Tasaka wrote: > > > buildsys at fedoraproject.org wrote: > > > Packages built and released for Fedora Extras development: 21 > > > jd-1.8.0-0.2.beta061023.fc6 > > > > This is strange because the rpm I built for FE-devel is > > jd-1.8.0-0.2.beta061023.fc7, not .fc6. > > You forgot to "cvs up" your "common" directory. As a result, you've > submitted a .fc6 build request for development, resulting in _two_ (!) > src.rpms and .fc7 binary rpms: > > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/jd/1.8.0-0.2.beta061023.fc7/SRPM/ > > Rest assured, a few other packagers have run into the same trap. > > While the push script is smart in some areas, it doesn't expect more than > one src.rpm per build-job, because build-job results are stored in unique > sub-directories. > > I'm not sure yet how to work around that (adding EVR sorting and other > overhead sounds wrong to me). You know, we already prune old build results > from the needsign queue and only push the latest EVR. The easiest fix is: > > "Packagers, submit proper build-jobs!" I'm going to re-push the following build-job results for FE development after removing the .fc6 src.rpms manually: dnsmasq/2.34-2.fc7 eggdrop/1.6.18-4.fc7 gaim-gaym/0.96-3.2.289svn.fc7 highlight/2.4.8-1.fc7 imlib2/1.3.0-1.fc7 jd/1.8.0-0.2.beta061023.fc7 libburn/0.2.2-2.fc7 libopts/27.4-1.fc7 qstat/2.10-6.fc7 ren/1.0-11.fc7 testdisk/6.5-1.fc7 All have been submitted from out-of-date CVS working-copies, where "devel" was still ".fc6". This created two src.rpms, one .fc6, the other .fc7. ./dnsmasq/2.34-2.fc7/SRPM: total 536 drwxrwsr-x 2 root extras_signers 4096 Oct 24 12:37 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 18:27 .. -rw-rw-r-- 1 root extras_signers 264311 Oct 24 12:37 dnsmasq-2.34-2.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 264452 Oct 24 12:37 dnsmasq-2.34-2.fc7.src.rpm ./eggdrop/1.6.18-4.fc7/SRPM: total 2040 drwxrwsr-x 2 root extras_signers 4096 Oct 25 03:33 . drwxrwsr-x 6 root extras_signers 4096 Oct 25 03:33 .. -rw-rw-r-- 1 root extras_signers 1032898 Oct 25 03:33 eggdrop-1.6.18-4.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 1033049 Oct 25 03:33 eggdrop-1.6.18-4.fc7.src.rpm ./gaim-gaym/0.96-3.2.289svn.fc7/SRPM: total 16160 drwxrwsr-x 2 root extras_signers 4096 Oct 24 21:12 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 21:12 .. -rw-rw-r-- 1 root extras_signers 8257074 Oct 24 21:12 gaim-gaym-0.96-3.2.289svn.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 8257153 Oct 24 21:12 gaim-gaym-0.96-3.2.289svn.fc7.src.rpm ./highlight/2.4.8-1.fc7/SRPM: total 728 drwxrwsr-x 2 root extras_signers 4096 Oct 24 13:39 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 18:27 .. -rw-rw-r-- 1 root extras_signers 363221 Oct 24 13:39 highlight-2.4.8-1.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 363267 Oct 24 13:39 highlight-2.4.8-1.fc7.src.rpm ./imlib2/1.3.0-1.fc7/SRPM: total 1896 drwxrwsr-x 2 root extras_signers 4096 Oct 25 03:10 . drwxrwsr-x 6 root extras_signers 4096 Oct 25 03:10 .. -rw-rw-r-- 1 root extras_signers 959825 Oct 25 03:10 imlib2-1.3.0-1.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 959639 Oct 25 03:10 imlib2-1.3.0-1.fc7.src.rpm ./jd/1.8.0-0.2.beta061023.fc7/SRPM: total 648 drwxrwsr-x 2 root extras_signers 4096 Oct 24 11:57 . drwxrwsr-x 6 root extras_signers 4096 Oct 25 08:16 .. -rw-rw-r-- 1 root extras_signers 321664 Oct 24 11:57 jd-1.8.0-0.2.beta061023.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 321877 Oct 24 11:57 jd-1.8.0-0.2.beta061023.fc7.src.rpm ./libburn/0.2.2-2.fc7/SRPM: total 960 drwxrwsr-x 2 root extras_signers 4096 Oct 23 18:03 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 18:27 .. -rw-rw-r-- 1 root extras_signers 480495 Oct 23 18:03 libburn-0.2.2-2.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 480512 Oct 23 18:03 libburn-0.2.2-2.fc7.src.rpm ./libopts/27.4-1.fc7/SRPM: total 840 drwxrwsr-x 2 root extras_signers 4096 Oct 23 17:25 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 18:27 .. -rw-rw-r-- 1 root extras_signers 420631 Oct 23 17:25 libopts-27.4-1.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 420637 Oct 23 17:25 libopts-27.4-1.fc7.src.rpm ./qstat/2.10-6.fc7/SRPM: total 480 drwxrwsr-x 2 root extras_signers 4096 Oct 25 04:07 . drwxrwsr-x 6 root extras_signers 4096 Oct 25 04:07 .. -rw-rw-r-- 1 root extras_signers 233800 Oct 25 04:07 qstat-2.10-6.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 233704 Oct 25 04:07 qstat-2.10-6.fc7.src.rpm ./ren/1.0-11.fc7/SRPM: total 40 drwxrwsr-x 2 root extras_signers 4096 Oct 25 05:08 . drwxrwsr-x 6 root extras_signers 4096 Oct 25 05:08 .. -rw-rw-r-- 1 root extras_signers 14221 Oct 25 05:08 ren-1.0-11.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 14195 Oct 25 05:08 ren-1.0-11.fc7.src.rpm ./testdisk/6.5-1.fc7/SRPM: total 1264 drwxrwsr-x 2 root extras_signers 4096 Oct 24 12:07 . drwxrwsr-x 6 root extras_signers 4096 Oct 24 18:27 .. -rw-rw-r-- 1 root extras_signers 635749 Oct 24 12:07 testdisk-6.5-1.fc6.src.rpm -rw-rw-r-- 1 root extras_signers 635753 Oct 24 12:07 testdisk-6.5-1.fc7.src.rpm From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 25 12:33:36 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 25 Oct 2006 21:33:36 +0900 Subject: Build-sys weirdness In-Reply-To: <20061025142721.f0926b53.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> Message-ID: <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Wed, 25 Oct 2006 14:11:00 +0200, Michael Schwendt wrote: > >> On Wed, 25 Oct 2006 11:14:58 +0900, Mamoru Tasaka wrote: >> >>> buildsys at fedoraproject.org wrote: >>>> Packages built and released for Fedora Extras development: 21 >>>> jd-1.8.0-0.2.beta061023.fc6 >>> This is strange because the rpm I built for FE-devel is >>> jd-1.8.0-0.2.beta061023.fc7, not .fc6. >> You forgot to "cvs up" your "common" directory. As a result, you've >> submitted a .fc6 build request for development, resulting in _two_ (!) >> src.rpms and .fc7 binary rpms: > > I'm going to re-push the following build-job results for FE development > after removing the .fc6 src.rpms manually: > > dnsmasq/2.34-2.fc7 > eggdrop/1.6.18-4.fc7 > gaim-gaym/0.96-3.2.289svn.fc7 > highlight/2.4.8-1.fc7 > imlib2/1.3.0-1.fc7 > jd/1.8.0-0.2.beta061023.fc7 > libburn/0.2.2-2.fc7 > libopts/27.4-1.fc7 > qstat/2.10-6.fc7 > ren/1.0-11.fc7 > testdisk/6.5-1.fc7 Thank you for pointing what is a problem. Well, I was just planning to queue jd/1.8.0-0.2.beta061023.fc7.1 (with common directory updated), but isn't it necessary? Mamoru Tasaka From buildsys at fedoraproject.org Wed Oct 25 13:06:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Oct 2006 09:06:09 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-25 Message-ID: <20061025130609.2A5BA15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 20 dnsmasq-2.34-2.fc7 eggdrop-1.6.18-4.fc7 fmio-2.0.8-8.0.fc7 fwbuilder-2.1.6-0.0.beta.fc7 gaim-gaym-0.96-3.2.289svn.fc7 imlib2-1.3.0-1.fc7 jd-1.8.0-0.2.beta061023.fc7 klamav-0.38-4.fc7 koffice-1.6.0-2.fc7 libburn-0.2.2-2.fc7 libfwbuilder-2.1.6-0.0.beta.fc7 nagios-plugins-1.4.4-1.fc7 php-pecl-zip-1.7.5-1.fc7 qstat-2.10-6.fc7 ren-1.0-11.fc7 renrot-0.25-2.fc7 torque-2.1.6-1.fc7 tuxpaint-stamps-2006.10.21-1.fc6 vdradmin-am-3.4.7-3.fc7 yumex-1.1.6-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 Oct 25 13:06:48 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Oct 2006 09:06:48 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-25 Message-ID: <20061025130648.58F0C15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) FC5-updates > FC7 (0:2.3-42.fc5 > 0:2.3-41.fc6) autofs FC6-updates > FC7 (1:5.0.1-0.rc2.17 > 1:5.0.1-0.rc2.10) beagle FC6-updates > FC7 (0:0.2.10-5.fc6 > 0:0.2.10-3.fc6) bind FC5-updates > FC7 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) FC6-updates > FC7 (30:9.3.3-4.fc6 > 30:9.3.2-41.fc6) checkpolicy FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) fedora-release FC6 > FC7 (0:6-4 > 0:5.92-1) frysk FC5-updates > FC7 (0:0.0.1.2006.10.13.rh1-1.fc5 > 0:0.0.1.2006.10.02.rh1-1.fc6) FC6-updates > FC7 (0:0.0.1.2006.10.23.rh1-1.fc6 > 0:0.0.1.2006.10.02.rh1-1.fc6) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) FC5-updates > FC7 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) FC5-updates > FC7 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) mutt FC6-updates > FC7 (5:1.4.2.2-3.fc6 > 5:1.4.2.2-2) qt FC5-updates > FC7 (1:3.3.7-0.1.fc5 > 1:3.3.6-13) FC6-updates > FC7 (1:3.3.7-0.1.fc6 > 1:3.3.6-13) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) rsh FC6-updates > FC7 (0:0.17-37.fc6 > 0:0.17-36) system-config-date FC6-updates > FC7 (0:1.8.8-1.fc6 > 0:1.8.7-1) system-config-users FC6-updates > FC7 (0:1.2.47-1.fc6 > 0:1.2.46-1.fc6) vnc FC6-updates > FC7 (0:4.1.2-4.fc6 > 0:4.1.2-3.fc6) xsane FC5-updates > FC7 (0:0.991-3.fc5 > 0:0.991-2.fc6) FC6-updates > FC7 (0:0.991-3.fc6 > 0:0.991-2.fc6) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) dlutter AT redhat.com: puppet FE4 > FE6 (0:0.20.0-1.fc4 > 0:0.19.3-1.fc6) FE5 > FE6 (0:0.20.0-1.fc5 > 0:0.19.3-1.fc6) dmitry AT butskoy.name: dvdisaster FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) grenier AT cgsecurity.org: testdisk FE3 > FE6 (0:6.5-1.fc3 > 0:6.4-3.fc6) FE4 > FE6 (0:6.5-1.fc4 > 0:6.4-3.fc6) FE5 > FE6 (0:6.5-1.fc5 > 0:6.4-3.fc6) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.0-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.0-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.3-1.fc6 > 0:0.2.1-1.fc6) mtasaka AT ioa.s.u-tokyo.ac.jp: jd FE5 > FE6 (0:1.8.0-0.2.beta061023.fc5 > 0:1.8.0-0.1.cvs061022.fc6) paul AT all-the-johnsons.co.uk: autogen FE5 > FE6 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) FE5 > FE7 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) libopts FE5 > FE6 (0:27.4-1.fc5 > 0:27.1-7.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) rdieter AT math.unl.edu: qt4 FE5 > FE6 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) FC5-updates > FC7 (0:2.3-42.fc5 > 0:2.3-41.fc6) autofs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:5.0.1-0.rc2.17 > 1:5.0.1-0.rc2.10) autogen: paul AT all-the-johnsons.co.uk FE5 > FE6 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) FE5 > FE7 (0:5.8.7-2.fc5 > 0:5.8.7-1.fc6) beagle: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.2.10-5.fc6 > 0:0.2.10-3.fc6) bind: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (30:9.3.3-0.1.rc2.fc5 > 30:9.3.2-41.fc6) FC6-updates > FC7 (30:9.3.3-4.fc6 > 30:9.3.2-41.fc6) checkpolicy: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.0-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.0-1.fc6 > 0:0.2.8-1.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) dvdisaster: dmitry AT butskoy.name FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) fedora-release: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:6-4 > 0:5.92-1) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) frysk: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.0.1.2006.10.13.rh1-1.fc5 > 0:0.0.1.2006.10.02.rh1-1.fc6) FC6-updates > FC7 (0:0.0.1.2006.10.23.rh1-1.fc6 > 0:0.0.1.2006.10.02.rh1-1.fc6) jd: mtasaka AT ioa.s.u-tokyo.ac.jp FE5 > FE6 (0:1.8.0-0.2.beta061023.fc5 > 0:1.8.0-0.1.cvs061022.fc6) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.3-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libopts: paul AT all-the-johnsons.co.uk FE5 > FE6 (0:27.4-1.fc5 > 0:27.1-7.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) FC5-updates > FC7 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) FC5-updates > FC7 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) mutt: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (5:1.4.2.2-3.fc6 > 5:1.4.2.2-2) puppet: dlutter AT redhat.com FE4 > FE6 (0:0.20.0-1.fc4 > 0:0.19.3-1.fc6) FE5 > FE6 (0:0.20.0-1.fc5 > 0:0.19.3-1.fc6) qt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (1:3.3.7-0.1.fc5 > 1:3.3.6-13) FC6-updates > FC7 (1:3.3.7-0.1.fc6 > 1:3.3.6-13) qt4: rdieter AT math.unl.edu FE5 > FE6 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) rsh: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.17-37.fc6 > 0:0.17-36) system-config-date: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.8.8-1.fc6 > 0:1.8.7-1) system-config-users: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.2.47-1.fc6 > 0:1.2.46-1.fc6) testdisk: grenier AT cgsecurity.org FE3 > FE6 (0:6.5-1.fc3 > 0:6.4-3.fc6) FE4 > FE6 (0:6.5-1.fc4 > 0:6.4-3.fc6) FE5 > FE6 (0:6.5-1.fc5 > 0:6.4-3.fc6) vnc: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:4.1.2-4.fc6 > 0:4.1.2-3.fc6) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.991-3.fc5 > 0:0.991-2.fc6) FC6-updates > FC7 (0:0.991-3.fc6 > 0:0.991-2.fc6) From fedora at leemhuis.info Wed Oct 25 13:31:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Oct 2006 15:31:15 +0200 Subject: testing repo (was: Re: Fedora Extras packaging beta software into production repos, why?) In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> Message-ID: <453F6723.1010100@leemhuis.info> Rex Dieter schrieb: > Axel Thimm wrote: >> Perhaps FE needs a testing section (many other repos have such >> stability sections, e.g. "updates" has, kde-redhat has, ATrpms has, >> freshrpms has and fedora.us also had). > uh huh. +1 :) That topic came up in a FESCo-discussion some days ago. The consensus was to have one afaics (I'm all for it as some of you know from past discussions). But there is yet nobody that's working on it (and some people in past discussions didn't like the "testing" repo idea to much iirc). Any volunteers? Side note: The question is also: Should we really start on this now? Or should we try to get the other major things mostly done first (co-maintainership, new VCS, EPEL, ...) fist, before we work on yet another big problematic topic? Having to many things on the plate might not be the best. Further: There is also the "Core and Extras merge" on the horizon that everyone (including me here) mentions. But that's just a rough idea until now and there are no real plans yet (at least none that I've heard of). But that "merge" has certain implications for Extras: Will we stick to the rolling releases? Or something similar to Core now with a updates and a updates-testing repo? Or a mixture? In other words: Is it worth working on a Extras testing repo now before those things are sorted out? To answer my own question: I don't think it is. But we probably should do it together with the merge (or at least calculate it in) CU thl From bugs.michael at gmx.net Wed Oct 25 13:36:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 15:36:22 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> Message-ID: <20061025153622.498a445f.bugs.michael@gmx.net> On Wed, 25 Oct 2006 07:11:23 -0500, Rex Dieter wrote: > Axel Thimm wrote: > > > Perhaps FE needs a testing section (many other repos have such > > stability sections, e.g. "updates" has, kde-redhat has, ATrpms has, > > freshrpms has and fedora.us also had). > > uh huh. +1 And everytime this topic comes up, it seems the consequences of adding a full "testing" repo are forgotten. First of all, it's another repository, another target to watch for package maintainers who might depend on stuff that's pre-released in "testing". Packages published in "testing" are available to every subsequent build job that targets "testing", too. They can be build dependencies. When moving packages from "testing" to "stable", it's means "all or nothing" for a dependency-chain. Same applies to withdrawing packages from "testing". Same applies to holding up packages. Would such a "testing" repository be popular enough? At fedora.us, we've found that it added extra burden with very little benefit. Same applied to the "unstable" repository. Who really does the testing? Usually you get the bug reports as soon as something appears in "stable", not before that. The few "testing" users would report broken dependencies. But most run-time testing is not done before packages are used on a day-to-day basis, actually. As nice as some features like a "scratch" repository sound, it needs a well thought out proposal instead of just a +1. From jeff at ocjtech.us Wed Oct 25 13:48:54 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 25 Oct 2006 08:48:54 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025105627.GD21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> Message-ID: <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> On Wed, 2006-10-25 at 12:56 +0200, Axel Thimm wrote: > On Wed, Oct 25, 2006 at 12:36:23PM +0200, Matthias Saou wrote: > > Axel Thimm wrote : > > > > > Sorry, but I miss the humor in this, and I'm busy fixing broken stuff > > > to get further into this. > > > > Well, don't think just about the present, think about the long term : > > You'll also be getting annoying reports about overriding Extras > > packages regarding libpri, zaptel and asterisk, and the usual bad > > publicity that accompanies it :-( > > We'd be all much better off if it can be avoided! > > > > To avoid this you could have submitted your packages for Extras > > inclusion, but it's too late now. What you can do is : > > When I offered it was said that zaptel is dead-before-review and > the rest due to being dependent as well. Zaptel would still be dead-before-review except for the fact that Digium has recently become more open to getting the Zaptel kernel modules into Linus' kernel tree. > > 1) Try to pause the asterisk inclusion into Extras until further > > discussion happens (i.e. someone answers the "Why a beta?") I went with the 1.4.0 betas because they are much easier to package without ugly specfile hacks, which were objected to earlier in the review process. They are also pretty solid codewise despite the "beta" appellation. > No, I'm not going to battle this, and there is no way to "pause" this, > after someone's "go" it's was blitz-reviewed and pushed into the repo > in lightning speed - I wish my FE packages would slide in like that. zaptel and libpri were not "blitz reviewed". The review requests have been in bugzilla since January of 2006. The first 1.4.0 beta SRPMS for zaptel were put up for review on October 12th and were imported into CVS on October 14th. The first 1.4.0 beta libpri SRPMS were put up for review on October 13th and were imported on October 14th as well. The asterisk package is still under review. I've seen many other package reviews happen in shorter time. -------------- 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 Wed Oct 25 13:56:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Oct 2006 08:56:08 -0500 Subject: testing repo (was: Re: Fedora Extras packaging beta software into production repos, why?) References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <20061025114831.GG21155@neu.nirvana> <453F6723.1010100@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > In other words: Is it worth working on a Extras testing repo now before > those things are sorted out? To answer my own question: I don't think it > is. I agree. Any extras-testing discussion/work is of lower priority than that other really good stuff you mentioned. -- Rex From buildsys at fedoraproject.org Wed Oct 25 13:57:42 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 25 Oct 2006 13:57:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-25 Message-ID: <20061025135742.25210.58694@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- a.kurtz AT hardsun.net feh - 1.3.4-4.fc6.ppc andreas.bierfert AT lowlatency.de fbdesk - 1.4.0-2.fc6.ppc fluxbox - 0.9.15.1-3.fc6.ppc koffice-core - 1.6.0-2.fc7.i386 koffice-kivio - 1.6.0-2.fc7.i386 orange - 0.3-3.cvs20051118.fc6.i386 scribus - 1.3.3.4-1.fc6.i386 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (25 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (25 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (25 days) dcbw AT redhat.com csound - 5.03.0-4.fc7.i386 plague - 0.4.4.1-2.fc3.noarch (40 days) plague - 0.4.4.1-2.fc3.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch (2 days) showimg-pgsql - 0.9.5-10.fc4.i386 (2 days) showimg-pgsql - 0.9.5-10.fc4.ppc (2 days) showimg-pgsql - 0.9.5-10.fc4.x86_64 (2 days) showimg-pgsql - 0.9.5-10.fc5.i386 (2 days) showimg-pgsql - 0.9.5-10.fc5.ppc (2 days) showimg-pgsql - 0.9.5-10.fc5.x86_64 (2 days) imlinux AT gmail.com nagios-plugins-game - 1.4.4-1.fc7.ppc jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (16 days) linphone - 1.2.0-4.fc5.ppc (16 days) linphone - 1.2.0-4.fc5.x86_64 (16 days) linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.x86_64 linphone - 1.2.0-7.fc6.x86_64 matt AT truch.net kst - 1.3.1-1.fc6.i386 matthias AT rpmforge.net caca-utils - 0.9-11.fc6.ppc camE - 1.9-7.fc6.ppc giblib - 1.2.4-7.fc6.ppc giblib-devel - 1.2.4-7.fc6.ppc mgarski AT post.pl digikam - 0.8.2-3.fc6.ppc miker5slow AT grandecom.net scrot - 0.8-2.fc7.ppc oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (6 days) syck-php - 0.55-9.fc5.ppc (6 days) syck-php - 0.55-9.fc5.x86_64 (6 days) orion AT cora.nwra.com kompose - 0.5.3-6.fc6.ppc plplot - 5.6.1-7.fc6.i386 plplot-gnome - 5.6.1-7.fc6.i386 paul AT all-the-johnsons.co.uk autogen - 5.8.7-1.fc6.i386 autogen - 5.8.7-1.fc6.ppc autogen - 5.8.7-1.fc6.ppc autogen - 5.8.7-1.fc6.x86_64 rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 kipi-plugins - 0.1.2-1.fc6.ppc redhat-bugzilla AT linuxnetz.de eggdrop - 1.6.18-3.fc6.i386 eggdrop - 1.6.18-3.fc6.ppc eggdrop - 1.6.18-3.fc6.x86_64 scott AT perturb.org qcomicbook - 0.3.3-5.fc6.ppc Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.ppc requires libopts.so.24 caca-utils-0.9-11.fc6.ppc requires libImlib2.so.1 camE-1.9-7.fc6.ppc requires libImlib2.so.1 digikam-0.8.2-3.fc6.ppc requires libImlib2.so.1 fbdesk-1.4.0-2.fc6.ppc requires libImlib2.so.1 feh-1.3.4-4.fc6.ppc requires libImlib2.so.1 fluxbox-0.9.15.1-3.fc6.ppc requires libImlib2.so.1 giblib-1.2.4-7.fc6.ppc requires libImlib2.so.1 giblib-devel-1.2.4-7.fc6.ppc requires imlib2-devel kipi-plugins-0.1.2-1.fc6.ppc requires libImlib2.so.1 kompose-0.5.3-6.fc6.ppc requires libImlib2.so.1 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 nagios-plugins-game-1.4.4-1.fc7.ppc requires qstat qcomicbook-0.3.3-5.fc6.ppc requires libImlib2.so.1 scrot-0.8-2.fc7.ppc requires libImlib2.so.1 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- csound-5.03.0-4.fc7.i386 requires libpython2.4.so.1.0 gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.ppc requires libopts.so.24 eggdrop-1.6.18-3.fc6.ppc requires libdns.so.21 linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.x86_64 requires libopts.so.24()(64bit) eggdrop-1.6.18-3.fc6.x86_64 requires libdns.so.21()(64bit) linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- autogen-5.8.7-1.fc6.i386 requires libopts.so.24 eggdrop-1.6.18-3.fc6.i386 requires libdns.so.21 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fbdesk - 1.4.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 package: fluxbox - 0.9.15.1-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 package: koffice-core - 1.6.0-2.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 package: koffice-kivio - 1.6.0-2.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-game - 1.4.4-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: qstat ====================================================================== New report for: scott AT perturb.org package: qcomicbook - 0.3.3-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: mgarski AT post.pl package: digikam - 0.8.2-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: a.kurtz AT hardsun.net package: feh - 1.3.4-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: orion AT cora.nwra.com package: kompose - 0.5.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: miker5slow AT grandecom.net package: scrot - 0.8-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: rdieter AT math.unl.edu package: kipi-plugins - 0.1.2-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 ====================================================================== New report for: matthias AT rpmforge.net package: giblib - 1.2.4-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 package: giblib-devel - 1.2.4-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: imlib2-devel package: camE - 1.9-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 package: caca-utils - 0.9-11.fc6.ppc from fedora-extras-development-ppc unresolved deps: libImlib2.so.1 From giallu at gmail.com Wed Oct 25 14:05:21 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 25 Oct 2006 16:05:21 +0200 Subject: Build-sys weirdness (was: Re: Fedora Extras Package Build Report 2006-10-24) In-Reply-To: <20061025141100.51bde19a.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> Message-ID: On 10/25/06, Michael Schwendt wrote: > On Wed, 25 Oct 2006 11:14:58 +0900, Mamoru Tasaka wrote: > > > buildsys at fedoraproject.org wrote: > > > Packages built and released for Fedora Extras development: 21 > > > jd-1.8.0-0.2.beta061023.fc6 > > > > This is strange because the rpm I built for FE-devel is > > jd-1.8.0-0.2.beta061023.fc7, not .fc6. > > You forgot to "cvs up" your "common" directory. As a result, you've > submitted a .fc6 build request for development, resulting in _two_ (!) > src.rpms and .fc7 binary rpms: I assume this is happening only after each official Fedora release but... is it documented anywhere on the wiki? I surely was a candidate for such a mistake, if only I had to build something right after the release... From Axel.Thimm at ATrpms.net Wed Oct 25 14:07:04 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 16:07:04 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> Message-ID: <20061025140704.GI21155@neu.nirvana> > > No, I'm not going to battle this, and there is no way to "pause" this, > > after someone's "go" it's was blitz-reviewed and pushed into the repo ^^^^^^^^^^^^^^^^^^^ > > in lightning speed - I wish my FE packages would slide in like that. > > zaptel and libpri were not "blitz reviewed". The review requests have > been in bugzilla since January of 2006. [...] -- 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 Wed Oct 25 14:08:59 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 25 Oct 2006 09:08:59 -0500 (CDT) Subject: Build-sys weirdness (was: Re: Fedora Extras Package Build Report 2006-10-24) In-Reply-To: <20061025141100.51bde19a.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> Message-ID: On Wed, 25 Oct 2006, Michael Schwendt wrote: > On Wed, 25 Oct 2006 11:14:58 +0900, Mamoru Tasaka wrote: > >> buildsys at fedoraproject.org wrote: >>> Packages built and released for Fedora Extras development: 21 >>> jd-1.8.0-0.2.beta061023.fc6 >> >> This is strange because the rpm I built for FE-devel is >> jd-1.8.0-0.2.beta061023.fc7, not .fc6. > > You forgot to "cvs up" your "common" directory. As a result, you've > submitted a .fc6 build request for development, resulting in _two_ (!) > src.rpms and .fc7 binary rpms: > > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/jd/1.8.0-0.2.beta061023.fc7/SRPM/ > > Rest assured, a few other packagers have run into the same trap. That's really odd. Before I even touched dnsmasq for the update, I blew away the local directory and checked it out again (to be sure I had the latest everything after the branching), and it seemed to update common: cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh So...if that doesn't do it, what are we supposed to be doing? Jima From bugs.michael at gmx.net Wed Oct 25 14:11:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 16:11:56 +0200 Subject: Attention, all FE packagers! In-Reply-To: <20061025135742.25210.58694@extras64.linux.duke.edu> References: <20061025135742.25210.58694@extras64.linux.duke.edu> Message-ID: <20061025161156.8130dec8.bugs.michael@gmx.net> On Wed, 25 Oct 2006 13:57:42 -0000, Fedora Extras repoclosure wrote: > New report for: imlinux AT gmail.com > > package: nagios-plugins-game - 1.4.4-1.fc7.ppc from fedora-extras-development-ppc > unresolved deps: > qstat Okay, this is due to another invalid build request. qstat must be rebuilt from a properly updated CVS tree. Also update "common". It just doesn't work like this and breaks the FE build-sys badly. Look! http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/qstat/2.10-6.fc7/ppc/ It build .fc6 binaries for ppc, but .fc7 binaries for i386/x86_64: qstat-2.10-6.fc6.ppc.rpm qstat-debuginfo-2.10-6.fc6.ppc.rpm And two src.rpms: qstat-2.10-6.fc6.src.rpm qstat-2.10-6.fc7.src.rpm This is certainly now what you wanted. Note to all: As a more drastic measure, the push script now ignores such invalid build request from being published. If all works well, there will be a warning in the build report. From jkeating at redhat.com Wed Oct 25 14:23:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 10:23:23 -0400 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025153622.498a445f.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061025153622.498a445f.bugs.michael@gmx.net> Message-ID: <200610251023.23564.jkeating@redhat.com> On Wednesday 25 October 2006 09:36, Michael Schwendt wrote: > Packages published in "testing" are available to every subsequent build > job that targets "testing", too. They can be build dependencies. When > moving packages from "testing" to "stable", it's means "all or nothing" > for a dependency-chain. Same applies to withdrawing packages from > "testing". Same applies to holding up packages. This is something I have to deal with internally many many times a week. Our updates-testing collection does not self update, so any time somebody needs to build a set of packages for testing (kde, gnome, mono stuff, any low level package, etc...) I have to do some tagging of some packages to make them available in the buildroot, which defeats the purpose of keeping them separate to begin with. To combat this, what we need is the ability to submit a build and request that certain packages be brought into that specific buildroot, provide a list of package builds that could be found in the packageDB no matter what collection they may be a part of. This is kind of scary too and I don't think its a great solution, but I don't have many others off the top of my head to deal with the split between testing and live. Unfortunately I also feel that the -testing repo does serve a good purpose. It would have caught the KDE fiasco in Core5 (or was it 4?), we make great use of it for testing kernel updates, or adding new features, or doing major version bumps. I see the only other alternative as being personal repo pages (very low probability of widespread testing), or a much more restrictive rule set on what is allowed to be issued as an 'update' to a released product. For development/, please. Development/ exists for people to test the packages that are candidates for the next release. Having test repo for a test repo seems silly to me. Your chance to validate the package for the next release _is_ rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Oct 25 14:24:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Oct 2006 16:24:57 +0200 Subject: Attention, all FE packagers! In-Reply-To: <20061025161156.8130dec8.bugs.michael@gmx.net> References: <20061025135742.25210.58694@extras64.linux.duke.edu> <20061025161156.8130dec8.bugs.michael@gmx.net> Message-ID: <453F73B9.8050805@leemhuis.info> Hi! Michael Schwendt schrieb: > On Wed, 25 Oct 2006 13:57:42 -0000, Fedora Extras repoclosure wrote: > >> New report for: imlinux AT gmail.com >> package: nagios-plugins-game - 1.4.4-1.fc7.ppc from fedora-extras-development-ppc >> unresolved deps: >> qstat > > Okay, this is due to another invalid build request. > qstat must be rebuilt from a properly updated CVS tree. Also update > "common". > > It just doesn't work like this and breaks the FE build-sys badly. Look! [...] (and reply out of order here) > As a more drastic measure, the push script now ignores such invalid > build request from being published. If all works well, there will be > a warning in the build report. Thx for that heads-up Michael. And also many thanks for your great work on the push scripts -- it is much appreciated! One small detail nevertheless: > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/qstat/2.10-6.fc7/ppc/ > It build .fc6 binaries for ppc, but .fc7 binaries for i386/x86_64: The .fc6 binaries on ppc look like a mis-configuration on the ppc-builder to me. See http://buildsys.fedoraproject.org/logs/fedora-development-extras/20270-jack-audio-connection-kit-0.102.20-2.1.fc7/ppc/build.log tagged correctly, but: > Wrote: /builddir/build/RPMS/jack-audio-connection-kit-0.102.20-2.1.fc6.ppc.rpm > Wrote: /builddir/build/RPMS/jack-audio-connection-kit-devel-0.102.20-2.1.fc6.ppc.rpm > Wrote: /builddir/build/RPMS/jack-audio-connection-kit-example-clients-0.102.20-2.1.fc6.ppc.rpm > Wrote: /builddir/build/RPMS/jack-audio-connection-kit-debuginfo-0.102.20-2.1.fc6.ppc.rpm See also others like http://buildsys.fedoraproject.org/logs/fedora-development-extras/20268-yumex-1.1.7-1.0.fc7/noarch/build.log I'll poke dgilmore to fix it. CU thl From Jochen at herr-schmitt.de Wed Oct 25 14:25:53 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 25 Oct 2006 16:25:53 +0200 Subject: How to rename a cvs module In-Reply-To: <0MKxQS-1Gc2iR0ll1-0004fz@mrelayeu.kundenserver.de> References: <0MKwtQ-1Gc0re0Bkw-0007YI@mrelayeu.kundenserver.de> <20061023143917.GD2280@free.fr> <0MKxQS-1Gc2iR0ll1-0004fz@mrelayeu.kundenserver.de> Message-ID: <0ML25U-1Gcjhc15ii-00089F@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 23 Oct 2006 18:31:53 +0200, you wrote: >>It covers one half of the issue, that is removing the old module, to >>create the new one, I think it should be in >>http://fedoraproject.org/wiki/Extras/CVSSyncNeeded >>and I can see that you allready edited it ;-) > >Yes, but I have the feeling, that this request was not fullfill >until now. It is OK, when I do the EOL process for the lincvs module and after the import crossvc with cvs-import.sh Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRT9z8U9gByurcX4MEQJRCQCfZI7DG9gGd1AtdQfKJ+zk2HR1x7YAoPgz 36KJ4ZhTY6Vp8/0G9/Z5IsVN =P9fN -----END PGP SIGNATURE----- From jeff at ocjtech.us Wed Oct 25 14:30:02 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 25 Oct 2006 09:30:02 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025140704.GI21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> Message-ID: <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> On Wed, 2006-10-25 at 16:07 +0200, Axel Thimm wrote: > > > No, I'm not going to battle this, and there is no way to "pause" this, > > > after someone's "go" it's was blitz-reviewed and pushed into the repo > ^^^^^^^^^^^^^^^^^^^ > > > in lightning speed - I wish my FE packages would slide in like that. > > > > zaptel and libpri were not "blitz reviewed". The review requests have > > been in bugzilla since January of 2006. [...] And again, I've seen a number FE packages have a review request opened, been reviewed and been imported in less time than the zaptel and libpri packages took (even if you only count the time between the first posting of 1.4.0 beta review packages and the importation). There have been months and months for people to add themselves to the CC lists of the bugzilla tickets so that they could be kept abreast of developments. There has been a lot of discussion in the FESCo meetings. Even if I had stayed with 1.2.X packages there would have been problems coexisting with the atrpms repository... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Wed Oct 25 15:24:24 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Oct 2006 10:24:24 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025075609.GE31188@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> Message-ID: <200610251024.24940.dennis@ausil.us> On Wednesday 25 October 2006 02:56, Axel Thimm wrote: > Hi, > > ATrpms is packaging asterisk and friends for quite some time > now. ATrpms' buildsystem has also enabled Fedora Extras during the > build procedure to ensure better interoperability, e.g. use BR's out > of Fedora Extras. Axel, Simple solution, you know about it now. exclude the zaptel libpri packages from your buildroot. its fairly simple to do. you could exclude them from your rsync and rebuild repo data Or you could exclude them in your mock config -- Dennis Gilmore, RHCE Proud Australian From fedora at leemhuis.info Wed Oct 25 15:34:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Oct 2006 17:34:46 +0200 Subject: Attention, all FE packagers! In-Reply-To: <453F73B9.8050805@leemhuis.info> References: <20061025135742.25210.58694@extras64.linux.duke.edu> <20061025161156.8130dec8.bugs.michael@gmx.net> <453F73B9.8050805@leemhuis.info> Message-ID: <453F8416.5080105@leemhuis.info> Thorsten Leemhuis schrieb: > Michael Schwendt schrieb: > >> http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/qstat/2.10-6.fc7/ppc/ >> It build .fc6 binaries for ppc, but .fc7 binaries for i386/x86_64: > The .fc6 binaries on ppc look like a mis-configuration on the > ppc-builder to me. See > [...] > I'll poke dgilmore to fix it. He and mmcgrath took a look and it should be fixed now. Cu thl From Axel.Thimm at ATrpms.net Wed Oct 25 15:36:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 17:36:13 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610251023.23564.jkeating@redhat.com> References: <20061025075609.GE31188@neu.nirvana> <20061025153622.498a445f.bugs.michael@gmx.net> <200610251023.23564.jkeating@redhat.com> Message-ID: <20061025153613.GJ21155@neu.nirvana> On Wed, Oct 25, 2006 at 10:23:23AM -0400, Jesse Keating wrote: > For development/, please. Development/ exists for people to test the packages > that are candidates for the next release. Having test repo for a test repo > seems silly to me. Your chance to validate the package for the next release > _is_ rawhide. But at some point rawhide (or the equivalent FE devel repo) becomes a release independent of whether the package being validated in there is ready for production or not. There is no way to say "Hey my package isn't ready for FC6, yet, I thought I was safe in the development repo". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Oct 25 15:37:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 17:37:02 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610251024.24940.dennis@ausil.us> References: <20061025075609.GE31188@neu.nirvana> <200610251024.24940.dennis@ausil.us> Message-ID: <20061025153702.GK21155@neu.nirvana> On Wed, Oct 25, 2006 at 10:24:24AM -0500, Dennis Gilmore wrote: > On Wednesday 25 October 2006 02:56, Axel Thimm wrote: > > Hi, > > > > ATrpms is packaging asterisk and friends for quite some time > > now. ATrpms' buildsystem has also enabled Fedora Extras during the > > build procedure to ensure better interoperability, e.g. use BR's out > > of Fedora Extras. > > Axel, > > Simple solution, you know about it now. exclude the zaptel libpri packages > from your buildroot. its fairly simple to do. you could exclude them from > your rsync and rebuild repo data Or you could exclude them in your mock > config Did you read the last paragraph of the mail you replied to? :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Oct 25 16:02:40 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 12:02:40 -0400 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025153613.GJ21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> Message-ID: <200610251202.40904.jkeating@redhat.com> On Wednesday 25 October 2006 11:36, Axel Thimm wrote: > But at some point rawhide (or the equivalent FE devel repo) becomes a > release independent of whether the package being validated in there is > ready for production or not. There is no way to say "Hey my package > isn't ready for FC6, yet, I thought I was safe in the development > repo". That's why you assume that every package will be published. We do it in Core, we should do it in Extras. If you're so concerned, drive the QA project to include Extras, do freezes in development land of Extras and actually DO a release, rather than the rolling stuff that happens now. Don't want Extras to be a second class citizen, do something about it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Oct 25 16:08:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 18:08:51 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610251202.40904.jkeating@redhat.com> References: <20061025075609.GE31188@neu.nirvana> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> <200610251202.40904.jkeating@redhat.com> Message-ID: <20061025160851.GA8122@neu.nirvana> On Wed, Oct 25, 2006 at 12:02:40PM -0400, Jesse Keating wrote: > On Wednesday 25 October 2006 11:36, Axel Thimm wrote: > > But at some point rawhide (or the equivalent FE devel repo) becomes a > > release independent of whether the package being validated in there is > > ready for production or not. There is no way to say "Hey my package > > isn't ready for FC6, yet, I thought I was safe in the development > > repo". > > That's why you assume that every package will be published. We do it in Core, > we should do it in Extras. If you're so concerned, drive the QA project to > include Extras, do freezes in development land of Extras and actually DO a > release, rather than the rolling stuff that happens now. Don't want Extras > to be a second class citizen, do something about it. But I am (by asking for example for a testing stage repo and for conservative builds in FE and no beta/pre/cvs/svn dumps). FWIW I also agree about trying to move the release model closer to FC's, and this is probably inevitable in the long term anyway when FC and FE will converge further. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Oct 25 16:12:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 18:12:14 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> Message-ID: <20061025161214.GB8122@neu.nirvana> On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > Even if I had stayed with 1.2.X packages there would have been problems > coexisting with the atrpms repository... Why? This only happens if you ignore that these packages exist and are used by a large number of people. -- 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 andy at smile.org.ua Wed Oct 25 16:52:05 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 25 Oct 2006 19:52:05 +0300 Subject: Attention, all FE packagers! In-Reply-To: <453F8416.5080105@leemhuis.info> References: <20061025135742.25210.58694@extras64.linux.duke.edu> <20061025161156.8130dec8.bugs.michael@gmx.net> <453F73B9.8050805@leemhuis.info> <453F8416.5080105@leemhuis.info> Message-ID: <20061025165205.GE30327@serv.smile.org.ua> Hi Thorsten Leemhuis! On Wed, Oct 25, 2006 at 05:34:46PM +0200, Thorsten Leemhuis wrote next: > > I'll poke dgilmore to fix it. > He and mmcgrath took a look and it should be fixed now. Are all packager (with me, of course) need to rebuild all their packets in the devel branch? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From fedora at leemhuis.info Wed Oct 25 17:02:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Oct 2006 19:02:06 +0200 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <20061024194605.GB29817@free.fr> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> <453E4F06.4070109@leemhuis.info> <20061024194605.GB29817@free.fr> Message-ID: <453F988E.9040204@leemhuis.info> Patrice Dumas schrieb: > On Tue, Oct 24, 2006 at 07:36:06PM +0200, Thorsten Leemhuis wrote: >>> I don't want to be negative here, nor show disrepect to FESCo members, >>> but I don't think being FESCo members should qualify here. A FESCo member >>> could be there to represent something and not because he has great >>> technical ability to fix packages. >> Well, I think all FESCo members normally should have a "technical >> ability to fix packages". Maybe one time there will be someone in FESCo >> that might not have it, but a FESCo member should be able to know about >> that and leave such work to others. And otherwise yell on the >> mailinglists ;) Errors get made by everyone and can be fixed. > That is true for all the fedora contributors. I can't see why FESCo members > should be treated specially. I thought it's obvious: Because it's their job to keep Extras running and in a good shape. (Site note: I disagree slightly with Ralfs "FESCo is a political organ" statement in this thread. I think FESCo should be more a technical organ that keeps stuff just rolling -- but sure, that involves politics, so he has it's point and it's not worth debating) Nevertheless, I removed that note -- we had two people that disliked it and no one that backed it, it isn't much of and issue now because all FESCo members are sponsors, so I removed it. Find the latest version of the proposal at http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing stuff that changed in the past days can be looked at, too: http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing?action=diff&rev2=5&rev1=3 CU thl From bugs.michael at gmx.net Wed Oct 25 17:24:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 19:24:15 +0200 Subject: jd (was: Re: Build-sys weirdness) In-Reply-To: <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> Message-ID: <20061025192415.d76671c2.bugs.michael@gmx.net> On Wed, 25 Oct 2006 21:33:36 +0900, Mamoru Tasaka wrote: > Well, I was just planning to queue jd/1.8.0-0.2.beta061023.fc7.1 > (with common directory updated), but isn't it necessary? Package needs work. See bottom of build log: http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 From bugs.michael at gmx.net Wed Oct 25 17:36:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Oct 2006 19:36:42 +0200 Subject: Attention, all FE packagers! In-Reply-To: <20061025165205.GE30327@serv.smile.org.ua> References: <20061025135742.25210.58694@extras64.linux.duke.edu> <20061025161156.8130dec8.bugs.michael@gmx.net> <453F73B9.8050805@leemhuis.info> <453F8416.5080105@leemhuis.info> <20061025165205.GE30327@serv.smile.org.ua> Message-ID: <20061025193642.02c2dc8e.bugs.michael@gmx.net> On Wed, 25 Oct 2006 19:52:05 +0300, Andy Shevchenko wrote: > Hi Thorsten Leemhuis! > > On Wed, Oct 25, 2006 at 05:34:46PM +0200, Thorsten Leemhuis wrote next: > > > > I'll poke dgilmore to fix it. > > He and mmcgrath took a look and it should be fixed now. > Are all packager (with me, of course) need to rebuild all their packets in > the devel branch? Those I've listed as causing trouble have been resubmitted to the build server already. Can't tell more right now, because the build system suffers from repo time-outs and returns some build jobs as failed. And some packages fail during compilation and need updates. In that case, package owner receives a private mail with a link to the build log. From nicolas.mailhot at laposte.net Wed Oct 25 16:51:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 25 Oct 2006 18:51:05 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025160851.GA8122@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> <200610251202.40904.jkeating@redhat.com> <20061025160851.GA8122@neu.nirvana> Message-ID: <1161795065.29370.22.camel@rousalka.dyndns.org> Le mercredi 25 octobre 2006 ? 18:08 +0200, Axel Thimm a ?crit : > On Wed, Oct 25, 2006 at 12:02:40PM -0400, Jesse Keating wrote: > > That's why you assume that every package will be published. We do it in Core, > > we should do it in Extras. If you're so concerned, drive the QA project to > > include Extras, do freezes in development land of Extras and actually DO a > > release, rather than the rolling stuff that happens now. Don't want Extras > > to be a second class citizen, do something about it. > > But I am (by asking for example for a testing stage repo and for > conservative builds in FE and no beta/pre/cvs/svn dumps). IMHO a full-universe testing repo will only evolve in a second rawhide due to package inter-dependencies and temporal overlap of testing operations. The release discipline problems won't be easier to solve just because of the "testing" name Targeted temporary testing spaces (? la p.r.c.) may be more useful, but setting them up will take more admin work than just creating another branch. > FWIW I also > agree about trying to move the release model closer to FC's, and this > is probably inevitable in the long term anyway when FC and FE will > converge further. +1 for hardening the existing process (whoot? I agree with Axel on something???). It's time to recognise FE can learn from FC just as FC learnt from FE. -- Nicolas Mailhot From dennis at ausil.us Wed Oct 25 18:06:15 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Oct 2006 13:06:15 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025153702.GK21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <200610251024.24940.dennis@ausil.us> <20061025153702.GK21155@neu.nirvana> Message-ID: <200610251306.16163.dennis@ausil.us> On Wednesday 25 October 2006 10:37, Axel Thimm wrote: > On Wed, Oct 25, 2006 at 10:24:24AM -0500, Dennis Gilmore wrote: > > On Wednesday 25 October 2006 02:56, Axel Thimm wrote: > > > Hi, > > > > > > ATrpms is packaging asterisk and friends for quite some time > > > now. ATrpms' buildsystem has also enabled Fedora Extras during the > > > build procedure to ensure better interoperability, e.g. use BR's out > > > of Fedora Extras. > > > > Axel, > > > > Simple solution, you know about it now. exclude the zaptel libpri > > packages from your buildroot. its fairly simple to do. you could > > exclude them from your rsync and rebuild repo data Or you could exclude > > them in your mock config > > Did you read the last paragraph of the mail you replied to? :) Yes i read it and you are over reacting. you know there are asterisk and related packages in extras and probably on their way there. You want to keep you own fine and great mock will let you exclude packages from the buildroot so exclude them. your users have protectbase that they can use to to make sure they have your asterisk packages and not Fedora Extras, A technical solution to a technical problem, there is no need to turn a technical problem into a social one. -- Dennis Gilmore, RHCE Proud Australian From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 25 18:17:48 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Oct 2006 03:17:48 +0900 Subject: jd In-Reply-To: <20061025192415.d76671c2.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> Message-ID: <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Wed, 25 Oct 2006 21:33:36 +0900, Mamoru Tasaka wrote: > >> Well, I was just planning to queue jd/1.8.0-0.2.beta061023.fc7.1 >> (with common directory updated), but isn't it necessary? > > Package needs work. See bottom of build log: > http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 > Well, this is due to desktop-file-install change (0.10->0.11). desktop-file-install 0.11 no longer accepts like X-Fedora or X-RedHat-Base... Perhaps many fedora package using desktop files needs fixing. Mamoru From Axel.Thimm at ATrpms.net Wed Oct 25 18:23:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Oct 2006 20:23:02 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1161795065.29370.22.camel@rousalka.dyndns.org> References: <20061025075609.GE31188@neu.nirvana> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> <200610251202.40904.jkeating@redhat.com> <20061025160851.GA8122@neu.nirvana> <1161795065.29370.22.camel@rousalka.dyndns.org> Message-ID: <20061025182302.GA9537@neu.nirvana> On Wed, Oct 25, 2006 at 06:51:05PM +0200, Nicolas Mailhot wrote: > Targeted temporary testing spaces (? la p.r.c.) may be more useful, > but setting them up will take more admin work than just creating > another branch. What's p.r.c? > > FWIW I also agree about trying to move the release model closer to > > FC's, and this is probably inevitable in the long term anyway when > > FC and FE will converge further. > > +1 for hardening the existing process (whoot? I agree with Axel on > something???). Hey, we should celebrate 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 nicolas.mailhot at laposte.net Wed Oct 25 18:36:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 25 Oct 2006 20:36:56 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025182302.GA9537@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> <200610251202.40904.jkeating@redhat.com> <20061025160851.GA8122@neu.nirvana> <1161795065.29370.22.camel@rousalka.dyndns.org> <20061025182302.GA9537@neu.nirvana> Message-ID: <1161801416.3723.1.camel@rousalka.dyndns.org> Le mercredi 25 octobre 2006 ? 20:23 +0200, Axel Thimm a ?crit : > On Wed, Oct 25, 2006 at 06:51:05PM +0200, Nicolas Mailhot wrote: > > Targeted temporary testing spaces (? la p.r.c.) may be more useful, > > but setting them up will take more admin work than just creating > > another branch. > > What's p.r.c? people.redhat.com Where very useful topic-testing repositories are sometimes published, unfortunately often short-lived or truncated due to draconian quotas -- Nicolas Mailhot From jspaleta at gmail.com Wed Oct 25 18:46:34 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 Oct 2006 10:46:34 -0800 Subject: Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing) In-Reply-To: <453F988E.9040204@leemhuis.info> References: <453CF8AD.1010800@leemhuis.info> <20061023193905.GA2367@free.fr> <453E4F06.4070109@leemhuis.info> <20061024194605.GB29817@free.fr> <453F988E.9040204@leemhuis.info> Message-ID: <604aa7910610251146ne99e47bv44e57cfd73f5b7c3@mail.gmail.com> On 10/25/06, Thorsten Leemhuis wrote: > Nevertheless, I removed that note -- we had two people that disliked it > and no one that backed it, it isn't much of and issue now because all > FESCo members are sponsors, so I removed it. Indeed, its a fine distinction at the monent, but the reality is at some point in the future someone with street cred and a proven record of competent conflict management, arbitration skills, or metaphysical McGyver-like get crap done abilities, from one of the less packaging oriented organized community efforts may very well be a fesco member as part of a new blood injection into the group. -jef"my blood hurts"spaleta From rdieter at math.unl.edu Wed Oct 25 18:55:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Oct 2006 13:55:24 -0500 Subject: jd References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: > Michael Schwendt wrote: >> On Wed, 25 Oct 2006 21:33:36 +0900, Mamoru Tasaka wrote: >> >>> Well, I was just planning to queue jd/1.8.0-0.2.beta061023.fc7.1 >>> (with common directory updated), but isn't it necessary? >> >> Package needs work. See bottom of build log: >> http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 >> > Well, this is due to desktop-file-install change (0.10->0.11). > desktop-file-install 0.11 no longer accepts like X-Fedora or > X-RedHat-Base... Perhaps many fedora package using desktop files > needs fixing. or desktop-file-install needs to be fixed/patched to accept X-* categories. Our current packaging guidelines (pretty much) mandate --add-category=X-Fedora to all .desktop files. -- Rex From Christian.Iseli at licr.org Wed Oct 25 19:03:39 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 25 Oct 2006 21:03:39 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025153613.GJ21155@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025153622.498a445f.bugs.michael@gmx.net> <200610251023.23564.jkeating@redhat.com> <20061025153613.GJ21155@neu.nirvana> Message-ID: <20061025210339.3237090d@ludwig-alpha.unil.ch> On Wed, 25 Oct 2006 17:36:13 +0200, Axel Thimm wrote: > There is no way to say "Hey my package > isn't ready for FC6, yet, I thought I was safe in the development > repo". This is not completely true. In the particular case of FC-6, you had two options: - refrain from participating in the mass rebuild, and your package was "automatically" removed - put a request in http://fedoraproject.org/wiki/Extras/FC6Status I agree that going the whole way and doing proper releases would be a good thing, but we ain't there yet. But you are not powerless in the current setup. There are means. And direct dialog between package maintainers can go a long way to reach worthy goals. C From jonathan.underwood at gmail.com Wed Oct 25 19:06:53 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 25 Oct 2006 20:06:53 +0100 Subject: RPM In-Reply-To: <453D44B9.6000103@redhat.com> References: <200610230135.52023.wolters.liste@gmx.net> <20061023005948.GC816@lilith.cluster> <1161625832.16747.8.camel@max.booze> <20061023181705.GD5303@rathann.pekin.waw.pl> <453D44B9.6000103@redhat.com> Message-ID: <645d17210610251206l306ff67anba391a6fda131620@mail.gmail.com> On 23/10/06, Christopher Aillon wrote: > The worst possible thing Fedora and Red Hat could do at this point is to > engage in a relationship with an upstream developer with intent to > sabotage such an integral package. There clearly is a problem of a personal nature, but I think it's unfair to claim that upstream has "intent to sabotage" (as has been claimed several times in this thread, not just in Christophers post) unless there is code in upstream RPM which bears out that statement. Let's stick to facts. Jonathan. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Oct 25 19:07:32 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Oct 2006 04:07:32 +0900 Subject: jd In-Reply-To: References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> Message-ID: <453FB5F4.8050800@ioa.s.u-tokyo.ac.jp> Rex Dieter wrote: > Mamoru Tasaka wrote: > >> Michael Schwendt wrote: >>> Package needs work. See bottom of build log: >>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 >>> >> Well, this is due to desktop-file-install change (0.10->0.11). >> desktop-file-install 0.11 no longer accepts like X-Fedora or >> X-RedHat-Base... Perhaps many fedora package using desktop files >> needs fixing. > > or desktop-file-install needs to be fixed/patched to accept X-* categories. > Our current packaging guidelines (pretty much) > mandate --add-category=X-Fedora to all .desktop files. > > -- Rex > Additional comment. This version (0.11) also refuses the Category "Application". This can be seem on my failure build log: http://buildsys.fedoraproject.org/logs/fedora-development-extras/20286-jd-1.8.0-0.2.beta061023.fc7/ppc/build.log Mamoru From brkamikaze at gmail.com Wed Oct 25 19:42:09 2006 From: brkamikaze at gmail.com (Nikolai) Date: Wed, 25 Oct 2006 16:42:09 -0300 Subject: New Project: pungi - A Fedora release composing tool In-Reply-To: <200610241753.07447.jkeating@redhat.com> References: <200610241753.07447.jkeating@redhat.com> Message-ID: That's a great tool, I was even wondering how to customize a installation CD or how to create another CD to install my favorite extras/livna packages without the need for networking on the new PC :) I'm just learning python, and I think that following a new project will be great for studies. I'll help when I can. From Christian.Iseli at licr.org Wed Oct 25 21:13:28 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 25 Oct 2006 23:13:28 +0200 Subject: FE Package Status of Oct 25, 2006 Message-ID: <20061025231328.193248be@ludwig-alpha.unil.ch> Hi folks, The latest package status report just landed in the wiki. Still haven't found much time for cleanups... oh well. Help welcome :-) Cheers, C ---- FE Package Status of Oct 25, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2454 packages - 115 orphans - 19 packages not available in extras devel or release 3rdshift at comcast dot net libassa 3rdshift at comcast dot net granule andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem cweyl at alumni dot drew dot edu perl-GStreamer gemi at bluewin dot ch TeXmacs ghenry at suretecsystems dot com john green at redhat dot com libfreebob j dot w dot r dot degoede at hhs dot nl MagicPoint matthias at rpmforge dot net SDL_pango michel dot salim at gmail dot com grhino miker5slow at grandecom dot net fluxstyle musuruan at gmail dot com hatari paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at all-the-johnsons dot co dot uk gtksharp pertusus at free dot fr ivman raven at pmail dot pl gaim-gadugadu redhat-bugzilla at linuxnetz dot de bitlbee - 1 packages not available in extras devel but present in release twaugh at redhat dot com international-time - 5 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=203864,209870,211626,211763 tripwire fedora at theholbrooks.org prozilla kushaldas at gmail.com xtide mtasaka at ioa.s.u-tokyo.ac.jp jikes paul at all-the-johnsons.co.uk https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=212198 diction Jochen at herr-schmitt.de - 9 packages present in the development repo which have no owners entry SDL_Pango crossvc gtk-sharp itpp ktechlab php-pecl-Fileinfo pygpgme system-switch-im toped - 20 orphaned packages, yet available in extras devel FreeWnn aspell-mi buildbot doctorj duplicity fltk gdk-pixbuf gnofract4d gnome-password-generator gnome-themes-extras gurlchecker imlib leafpad libedit lostirc pam_mount pam_mysql pam_script python-cvstoys screem - 43 packages that moved to core FE-ACCEPT packages stats: - 1467 accepted, closed package reviews - 21 accepted, closed package reviews not in repo - 16 accepted, closed package reviews not in owners - 12 accepted, open package reviews older than 4 weeks; - 12 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 86 open tickets - 17 tickets with no activity in eight weeks - 14 tickets with no activity in four weeks - 4 closed tickets FE-NEW packages stats: - 145 open tickets - 25 tickets with no activity in eight weeks - 22 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 45 open tickets - 5 tickets with no activity in eight weeks - 2 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks - 1 tickets with no activity in four weeks OPEN-BUGS packages stats: - 253 open tickets - 102 tickets with no activity in eight weeks - 53 tickets with no activity in four weeks CVS stats: - 2451 packages with a devel directory - 8 packages with no owners entry SDL_Pango crossvc gtk-sharp itpp ktechlab php-pecl-Fileinfo pygpgme toped - 190 packages were dropped from extras Maintainers stats: - 230 maintainers - 1 inactive maintainers with open bugs - 2 inactive maintainers Dropped FC packages: - 283 packages were dropped from core since FC 1 Comps.xml files stats: - 846 packages in comps-fe7 file - 448 packages missing from comps-fe7 file - 32 packages in comps-fe7 but not in repo - 846 packages in comps-fe6 file - 445 packages missing from comps-fe6 file - 32 packages in comps-fe6 but not in repo From a.badger at gmail.com Wed Oct 25 21:16:24 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 25 Oct 2006 14:16:24 -0700 Subject: FESCo Meeting 2006-10-19 Message-ID: <1161810984.3018.1.camel@localhost> = 2006 October 19 FESCo Meeting = == Attending == * thl * dgilmore * warren * rdieter * scop * abadger1999 * bpepple * tibbs * ch4chris * jwb (late) == Summary == === EPEL === * There are some unresolved questions from within Red Hat that need to be sorted out. === Enhance AWOL === * tibbs's original work was lost. This will be resurrected this week and discussed next week. === When to Touch Other People's Packages === * thl will send a writeup to the list. === Packaging Committee Report === * Committee Membership dropped to 9 members. * disttag proposal to allow using 6.89 for devel/rawhide passed. * Core has already said they are not going to use this/veto. * FESCo voted down: "Extras will use .fc6.89 for devel even if Core does not plan to use it" so the current plan is that the disttag for devel will remain the next release. (ie: fc7 for upcoming devel) * Meeting time was moved to Tuesdays. === Sponsor Nominations === * Mamoru Tasaka proposed. Will discuss on list. * nirik put together a page for people who might need to be sponsored: http://www.scrye.com/~kevin/fedora-extras/sponsors-report-2006-10-14 === Misc === ==== Extras Package Enables a Repository ==== * https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html * FESCo voted to fix it immediately and tibbs fixed it. * For the general case, this will go to the packaging committee to be made a Guideline with an exception for fedora-release. ==== Kmod Support in the Buildsys ==== * thl status report: * Nothing currently automated * Have to hardcode kversion and kvariant in the spec * Needs updating for each kernel update * Working on merging kmodtool changes from kerneldrivers.org * Working on getting kmodtool into Core ==== Legacy Branch Request ==== * pygpgme needs to be branched for FC-3 so that infrastructure can use it on RHEL4. * Asked if infrastructure uses the packages directly out of the FC-3 tree or if they rebuild the packages anyway. * After meeting follow up: Yes, infrastructure uses the FC-3 built packages directly. ==== Package Database ==== * Infrastructure has a skeleton up but no data imported yet. * Need to proxy from the internal servers to the outside world so everyone can see it. * Brain dump of stages to be functional http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/RoadMap * comps.xml being generated from the PackageDB needs to be looked at further. Dependencies inside comps may make this a harder task. * comps info needs to be part of the package-collection data rather than package as the information can be different in different collections. == Log == {{{ (10:00:48) thl has changed the topic to: FESCo meeting in progress -- init (10:00:58) ***dgilmore is here (10:00:59) thl: hi everyone! (10:01:06) thl: Who's around? (10:01:10) ***jima is here, but rabble. (10:01:19) warren: I'm back home as of today, still settling in (10:01:21) ***rdieter is here. (10:01:28) ***scop is here (10:01:31) jima: geez, i make so many of these meetings, i might as well run for fesco next time. (10:01:31) ***nirik is in the rabble seats, and also working on some other things, but sorta around. (10:01:35) thl: warren, Ignore the flame war on fedora-maintainers ;) (10:01:54) ***abadger1999 here (10:01:58) warren: which flamewar? (10:02:01) ***bpepple is here. (10:02:07) rdieter: exactly. (10:02:10) tibbs: I'm here but my keyboard is dying. (10:02:15) thl: k, so let's start slowly; abadger1999, do you write the summary today? (10:02:33) abadger1999: Yep. I'm back on top of things. (10:02:53) ***c4chris__ is here (10:03:01) thl has changed the topic to: FESCo meeting in progress -- EPEL (10:03:16) dgilmore: thl: we are waiting on CVS branches (10:03:17) thl: there are still some thing inside Red Hat that need to be sorted out (10:03:24) dgilmore: which needs some help from jeremy (10:03:32) thl: jeremy is fighting hard for us (10:03:37) thl: but we can't start yet (10:03:38) adrianr [n=adrian] entered the room. (10:03:55) rdieter: which implies there's someone/something that's resisting this? (10:03:56) thl: that sucks, I know (10:05:01) thl: rdieter, afaics it's more "I don't like a particular detail and thus I raise my hands to stop this for now" (10:05:07) ***cweyl is lurking in the rabble seats (10:05:23) c4chris__: anything we can do to help ? what's the "detail" ? (10:05:51) thl: I don#t know the complete details, sorry (10:06:01) c4chris__: np (10:06:09) rdieter: hopefully jeremy's fedora-fu, ninja, kickboxing skills will be sufficient. (10:06:22) thl: I hope so (10:06:25) thl: so let's move on (10:06:25) dgilmore: rdieter: if not maybe we will need spots nigas also (10:06:35) rdieter: orbital laser? (10:06:40) thl has changed the topic to: FESCo meeting in progress -- Enhance AWOL (10:06:47) thl: rdieter, good idea ;) (10:06:56) thl: well, "Enhance AWOL" (10:07:05) thl: it seems no one really brings this forward (10:07:41) dgilmore: thl: i think we need a better way to determine awol but i have no idea what or how (10:07:41) thl: What i#d like to see is something similar to what I did with "When to touch other peoples packages" (10:07:50) thl: e.g. write a proposal (10:07:54) thl: present in to the list (10:07:57) thl: sorry (10:08:11) thl: present in to the FESCo (with a difff against the current one) (10:08:16) thl: then to the list (10:08:31) thl: modify it if needed (10:08:35) tibbs: Enhancing AWOL was only about clarifying how to orphan multiple packages at once. (10:08:41) thl: and then vote and agree on it in a meeting (10:08:48) thl: tibbs, I know (10:09:07) thl: but without somebody who does above steps it's not getting forwards (10:09:23) thl: So I'm inclinded to say we drop it soon if no one steps up to handle it (10:09:51) thl: come one; It's not that much work for this particular issue (10:09:55) thl: anybody? (10:10:07) thl: non FESCo-members are also invited (10:10:16) ***dgilmore nominates jima (10:10:41) dgilmore: i would do it but dont really have the time right now (10:10:42) bpepple: I'll do it. Though I probably cant't get to it till next week. (10:11:22) rdieter: dgilmore: not nice volunteering someone else (and, seconded, by the way). (: (10:11:32) thl: bpepple, k, thx; then I'll set November, the 2nd as target for now (10:11:39) jima: rdieter: hey! :P (10:11:40) bpepple: np. (10:11:56) dgilmore: rdieter: :) yeah (10:12:17) thl: bpepple, and please be sure to show us a diff somehow (maybe with the included wiki stuff) (10:12:20) tibbs: Sorry, didn't I present a document to the committee for enhancing AWOL already? (10:12:41) thl: tibbs, I got the impression it's not ready yet (10:13:10) thl: is it ready? is a diff against the old one avilable somewhere? that would make reviewing a lot easier (10:13:52) tibbs: I originally posted a set of exactly what changed, but it all wasnot in the proper schedule format. Someone else took it and seems to have removed all of that. (10:14:25) thl: well, the problem was: mjk had the page in this namespace in hte wiki (10:14:33) thl: and hje deleted it when he left us (10:14:42) bpepple: D'Oh! (10:14:53) thl: I recovered the latest version (10:15:03) thl: but maybe it wasn't the latest version (10:15:16) Finalzone [n=luya] entered the room. (10:16:07) thl: tibbs, do you want to proceed with it? or shall we hand it over to bpepple for now? (10:16:08) tibbs: Originally the page was under my namespace, but I moved it under Schedule. (10:16:21) _wart_ [n=wart] entered the room. (10:16:27) tibbs: I'm happy to hand it off if bpepple wants to work on it. (10:16:51) thl: tibbs, well, I'd would like to see the latest version first (10:17:09) thl: that could save us all some work if that incluides everything we need already (10:17:20) thl: let's look out for it after the meeting (10:17:37) thl: and then decide how owns this topic from now on (10:17:55) thl has changed the topic to: FESCo meeting in progress -- When to touch other peoples packages (10:18:06) thl: any further modifications needed? (10:18:10) tibbs: OK, I have the message I originally mailed to the steering committee which details the proposed changes. (10:18:19) thl: otherwise I'll send it to the list soon (10:18:23) tibbs: Sorry, that was about AWOL. (10:18:26) thl: tibbs, great (10:18:33) c4chris__: thl, +1 (10:18:44) thl: can you send it to me? I'll put it in the wiki (10:18:57) thl: tibbs, then we can decide later how to proceed (10:19:35) thl: k, I'll send "When to touch other peoples packages" to the list soon (10:19:51) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report (10:20:17) thl: spot, abadger1999, tibbs, scop ? (10:20:46) rdieter: we dropped committee from 10->9 members, dropped quorum 6->5 (10:21:05) bpepple: rdieter: Did someone leave? (10:21:25) rdieter: yes. (10:22:03) abadger1999: jpo doesn't have enough time at present. (10:22:09) rdieter: and (barely) passed disttag proposal to use 6.89 for devel/rawhide. (10:22:28) rdieter: f13 promised core veto. (10:22:39) ***dgilmore really doesnt like that idea (10:22:54) scop: meeting time was moved to Tuesday starting from next week (10:23:02) thl: rdieter, well, I'd try my best to veto that, too (10:23:07) ***nirik wonders what the advantage would be... easier detection of packages needing rebuild? (10:23:15) thl: well, as long as I don't see a list of benefits (10:23:20) rdieter: nirik: that's one. (10:23:21) thl: that could change my mind (10:23:39) rdieter: makes mass rebuilds easier. (10:23:43) thl: rdieter, I don't buy that; detecting when a package was build is quite easy (10:23:49) abadger1999: nirik: yes, but it's not fool proof, which is one of f13's problems with it. (10:23:55) jima: setting dist to .fc6.89 for rawhide? (10:23:58) thl: and I'm not even sure we need a mass-rebuild each time (10:24:06) tibbs: The point is to let Extras consider it. (10:24:19) dgilmore: we would need to change the buildsys macros reight before mass rebuild to implement that and have fc7 packages have fc7 (10:24:19) tibbs: If extras doesn't decide to use it, no problem. (10:24:21) tibbs: Core has decided not to use it. (10:24:39) tibbs: dgilmore: Yes, that's the idea. (10:24:57) thl: tibbs, well, Core and Extras should use the same stuff (10:25:04) ***nirik thinks it looks like just added complexity. (10:25:06) thl: tibbs, that why we created the Packaging COmmittee (10:25:08) dgilmore: tibbs: thats extra work for me or whoever else helps me for zero gain that i can see (10:25:17) ***dgilmore would need to really be sold on the idea (10:25:20) bpepple: thl: +1 (10:25:22) thl: I even see disadvantages (10:25:34) tibbs: Packaging committee just says "yes, this is allowed". We won't dictate policy for the Extras buildsys. (10:25:46) thl: so let's do that step by step: (10:26:23) f13: thl: don't forget, sometiems the first massrebuild isn't the last massrebuild. OMGGCCBUG! (10:26:27) thl: can I get some -1, 0, or +1 for "extras won't use .fc6.89 for devel if core does not plan to use it" (10:26:27) f13: (: (10:26:38) thl: f13, I know, I know :) (10:26:40) jwb_gone: thl, +1 (10:26:46) jwb_gone is now known as jwb (10:26:48) dgilmore: thl i vote -1 (10:26:49) thl: f13, I'm on your side here ;) (10:26:54) bpepple: thl: +1 (10:27:00) abadger1999: thl: Double negative? (10:27:05) scop: 0 (I voted for 0 in packaging committee too) (10:27:10) jwb: yeah, double negatives are weird (10:27:13) tibbs: I abstain here. (10:27:15) thl: abadger1999, yeah, that's a bit problematic (10:27:16) jwb: i vote to not sure it (10:27:16) abadger1999: A +1 == do not use .fc89, right? (10:27:21) jwb: s/sure/use (10:27:29) ***jwb apologizes for being late. real life (10:27:33) abadger1999: err .fc6.89 (10:27:35) rdieter: abadger1999: right. (10:27:40) abadger1999: +1 (10:27:44) c4chris__: I don't like .fc6.89 as a disttag. I'm not sure if that's a +1 or a -1 (10:27:58) dgilmore: c4chris__: its a -1 (10:27:58) jwb: tibbs, who brought up this proposal? (10:28:07) abadger1999: It's a +1 (10:28:09) f13: jwb: Axel Thimm (10:28:22) jwb: f13, ok thank oyu (10:28:28) ***f13 sees chaos with the vote (: (10:28:32) c4chris__: dgilmore, not according to abadger1999 ... (10:28:35) thl: f13, agreed, sorry (10:28:40) dgilmore: as the person most likely to implement it I really want to strongly oppose it (10:28:45) f13: nobody knows which way they're voting, just like a US President election (10:28:58) ***dgilmore is confused now (10:29:01) abadger1999: let's rephrase: "extras will use .fc6.89 for devel even if core does not plan to use it" (10:29:06) f13: dgilmore: funny, thats me on the Core side and I feel exactly like you. (10:29:06) jwb: dgilmore, thl used a double negative :) (10:29:21) abadger1999: Vote -1 to disagree with using .fc6.89 (10:29:22) bpepple: abadger1999: -1 (10:29:25) abadger1999: Vote +1 to agree (10:29:26) thl: abadger1999, -1 (10:29:27) abadger1999: -1 (10:29:29) jwb: -1 (10:29:32) c4chris__: abadger1999, -1 (10:29:33) dgilmore: -1 (10:29:56) BobJensen is now known as BobJensen-Away (10:29:57) ***rdieter abstains (for now): 0 (10:30:04) jwb: i think it's silly to differ now given that we're supposedly merging with Core anyway (10:30:10) thl: jwb, agreed (10:30:17) bpepple: jwb: agreed. (10:30:41) rdieter: jwb: good point, count me as -1 then. (10:30:46) dgilmore: i count 6 negative. i abstinance thats enough to have it knocked back right? (10:30:51) thl: Then we wait for the decision from core for now (10:30:53) rdieter: yup (10:31:03) f13: thl: core already made the decision (10:31:10) tibbs: Core is a definite no. (10:31:12) warren: -1 (10:31:17) dgilmore: f13: well i guess we need to shout from the roof dont do it (10:31:18) thl: k, so, then there is no need to discuss this further afaics (10:31:31) rdieter: stick a fork in it (10:31:44) thl: k, anything else from the Packaging Committee? (10:32:00) rdieter: that's it. (10:32:12) thl: k, so let's move on (10:32:25) thl has changed the topic to: FESCo meeting in progress -- Sponsorship nominations (10:32:30) thl: any new nominations? (10:33:01) dgilmore: none from me (10:33:31) tibbs: I suppose we should consider Mamory Tasaka, (10:33:41) tibbs: but I have not looked over his 34 reviews yet. (10:33:47) nirik: BTW, for sponsors looking for people to sponsor I put together a list last week: http://www.scrye.com/~kevin/fedora-extras/sponsors-report-2006-10-14 (10:33:56) tibbs: Sorry, Mamoru Tasaka. (10:34:16) bpepple: tibbs: I think he reviewed a couple of my packages, and he did a good job. Is he interested? (10:34:36) tibbs: I haven't discussed it with him. (10:34:56) tibbs: I just noticed that he is the non-sponsor reviewer with the largest number of completed reviews. (10:35:02) thl: tibbs, please ask him, and if he agrees send a RFC to cvsextras-sponsors please (10:35:10) abadger1999: nirik: Nice list. (10:35:23) tibbs: We really need to re-consider Paul Johnson as well. (10:35:29) volp [n=volp] entered the room. (10:36:03) nirik: I think some of the folks on there with multiple packages should be looked at by sponsors... (10:36:18) nirik: the folks with only one submission and no bugzilla activity will probibly sit there for a while. (10:36:27) thl: nirik, can that list be integrated in c4chris__'s reports somehow? (10:36:44) thl: tibbs, well, propose him on the list, too (10:36:56) thl: I'll ask cwickert it he's interested (10:37:10) nirik: possibly. I just generated it by hand... if c4chris__ can figure a way to automate it, that would be great (10:37:32) thl: k, so let's move on (10:37:52) c4chris__: nirik, I'll give it a try (10:38:02) thl has changed the topic to: FESCo meeting in progress -- approve kmod's (10:38:06) thl: rt2x00-kmod is on the list (10:38:18) jwb: hm, i missed that one (10:38:24) thl: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 (10:38:50) thl: hmmm (10:38:58) thl: I think i left a comment in the report (10:39:04) thl: but seem it never landed there (10:39:06) thl: forget about this (10:39:13) thl: we'll get back to it next week (10:39:20) thl: doesn't make to much sense without it (10:39:43) thl has changed the topic to: FESCo meeting in progress -- misc (10:40:01) f13: thl: as an 'outsider' I have a topic. (10:40:19) thl: f13, wait a moment please (10:40:31) thl: first: clement, -- https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html (10:40:48) tibbs: This absolutely must get fixed ASAP. (10:40:49) thl: do we agree that we remove it as quickly as possible? (10:40:53) rdieter: +1 (10:41:00) bpepple: thl: +1 (10:41:05) tibbs: +1. (10:41:08) scop: +1 (10:41:11) jwb: +1 (10:41:15) tibbs: Delete the package or just fix it to not install the repo? (10:41:23) thl: delete it now (10:41:25) thl: fix later (10:41:33) dgilmore: thl: i say we just remove the repo config file (10:41:39) rdieter: delete first, then fix (later) (10:41:42) cwickert [n=chris] entered the room. (10:41:47) dgilmore: thl: just fix it (10:42:02) jwb: dgilmore, it needs a fix, rebuild, and push to be effective (10:42:09) f13: thl: haha, thats what I was going ot bring up (10:42:13) thl: dgilmore, the maintainer should fix it (10:42:20) rdieter: thl: +1 (10:42:25) dgilmore: jwb: yeah a it will take the same time to propagate as a removal (10:42:26) scop: I can take care of the push if something happens quickly (10:42:27) thl: and someone really should tell him that that was quite bad bad (10:42:43) rdieter: (and tell the reviewer) (10:42:48) thl: rdieter, agreed (10:42:52) thl: and fedora-extras-list (10:43:02) tibbs: It's just one line from the specfile. (10:43:06) thl: can anybody handle all the steps please? (10:43:09) thl: scop ? (10:43:19) nirik: perhaps rpmlint could add a check for repo files and tag it as a E ? (10:43:19) jwb: i can fix it (10:43:28) bpepple: nirik: +1 (10:43:40) thl: jwb, k, then fix it (10:43:41) dgilmore: jwb: if you dont want to i will (10:43:46) jwb: already working on it (10:43:49) dgilmore: :) (10:43:53) tibbs: Seems everyone wants to fix it. (10:43:59) tibbs: I already had vi open. (10:44:03) thl: :) (10:44:07) jwb: tibbs, you're ahead of me. go ahead (10:44:08) thl: well, settled then (10:44:10) thl: f13 ? (10:44:33) jwb: tibbs, if i don't hear from you in 10 minutes that it's done, i'll proceed ;) (10:44:35) tibbs: Wow, no changelog for the last change, either. (10:45:02) f13: thl: I was going to ask if this should be an Extras acceptable practice, or if it should go into Packaging guidelines. Becuase if it's a packaging guideline, then fedora-release doesn't pass muster (: (10:45:03) dgilmore: sounds like some maintainer education is needed (10:45:11) thl: btw who tells the packager and the list about it? tibbs, jwb, dgilmore ? (10:45:24) rdieter: fedora-release is a reasonable exception, clearly. (: (10:45:25) bpepple: f13: It should go into the Packaging Guidelines. (10:45:33) dgilmore: thl: ill write something to the list and mainatiner (10:45:39) thl: dgilmore, thx (10:46:17) thl: Packaging Guidelines +1 -- fedora-release is a special exception (10:46:23) dgilmore: +1 (10:46:25) tibbs: Running test builds now; I'll check in and build in a few. (10:46:27) c4chris__: +1 (10:46:29) rdieter: I almost think this falls under the general category of "don't do anything stoooopid". (10:46:30) abadger1999: +1 (10:46:30) bpepple: thl: +1 (10:46:40) dgilmore: rdieter: pretty much (10:46:49) thl: rdieter, agree; maybe we should have a page "*this* is stupid" (10:46:51) abadger1999: rdieter: heh. One would think ;-) (10:46:53) cweyl: rdieter: that's always been my favourite rule :) (10:46:56) volp left the room (quit: Read error: 60 (Operation timed out)). (10:47:14) dgilmore: but stupidity got through the cracks so we need to say dont do this in addition to dont be stupid (10:47:16) f13: Packaging Wall of Shame (10:47:28) rdieter: having a "this is stupid" page might not be a bad idea. (10:47:28) f13: dgilmore: it was disabled when it went through review (10:47:38) f13: got enabled post review. Sneaky sneaky (10:48:08) thl: k, so let's move on (10:48:14) c4chris__: hmm, more QA stuff to write... ;-) (10:48:16) dgilmore: f13: :( it probably should have had a rm -f in the spec (10:48:20) thl: "kmod support in the buildsys" is in the misc list (10:48:35) thl: i'll handle that (I assume no one else is interesed) (10:48:47) dgilmore: thl: im not sure what the current status of kmods in the buildsys are (10:48:49) thl: so it's more a reminder that we need to get the kmod building automated (10:49:13) thl: nothing automated, possible with hardcoded kversion and kvariant (10:49:29) thl: but that needs updateing for each kernel update :/ (10:49:52) thl: "integrate kmodtool changes from kerneldrivers.org" and "get kmodtool included in core" are also on my plate (10:49:58) thl: I'm working on it already (10:50:15) dgilmore: thl: ok well if anything is needed in plague let me know (10:50:20) thl: the consensus on a private dicsussion about "integrate kmodtool changes from kerneldrivers.org" (10:50:28) thl: was to integrate changes into cvs (10:50:30) dgilmore: I have a few additions to plague im working on (10:50:50) thl: normally, and only discuss the big changes in FESCo and the PAckaging Committe (10:50:57) thl: it that okay for everyone? (10:51:06) c4chris__: thl, +1 (10:51:13) rdieter: thl: +1 (10:51:15) bpepple: thl: +1 (10:51:17) scop: sure (10:51:31) thl: k (10:51:50) thl has changed the topic to: FESCo meeting in progress -- Maintainer Responsibility Policy (10:51:57) thl: sorry, I had no time for it (10:52:12) thl: I'll try to driver this forward soon (10:52:26) thl has changed the topic to: FESCo meeting in progress -- what next? (10:52:36) thl: we still have some topics on the list: (10:52:41) thl: Comaintainership (10:52:47) thl: Package Database (10:52:53) thl: Use comps.xml properly (10:52:59) thl: Feature support in Extras (10:53:07) thl: does anyone want to discuss one of those? (10:53:07) abadger1999: I need to get a package branched for infrastructure (10:53:17) abadger1999: pygpgme (10:53:38) abadger1999: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210217 (10:53:39) rdieter: a separate branch? why? (10:53:51) tibbs: Branched to FC3? (10:53:51) scop: branched for an old distro version? (10:53:53) thl: yeah, why? (10:53:55) abadger1999: tibbs: yes (10:54:21) abadger1999: I wrote a script to handle encrypting passwords for all the admins with thir gpg keys (10:54:23) dgilmore: abadger1999: what are we going to use it for? (10:54:26) tibbs: I'm pretty happy to allow legacy branches for anything infrastructure needs. (10:54:31) thl: abadger1999, could you next time please add it before the meeting on http://www.fedoraproject.org/wiki/Extras/Schedule/BranchRequestsForOldDists ? (10:54:34) abadger1999: But it uses pygpgme to do the heavy lifting. (10:54:41) thl: then we are aware of it and can prepare (10:54:54) abadger1999: thl: Can do. (10:55:00) dgilmore: abadger1999: whats it currently branched for? (10:55:05) thl: otherwise i agree with tibbs: I'm pretty happy to allow legacy branches for anything infrastructure needs. (10:55:08) thl: so +1 (10:55:21) c4chris__: +1 (10:55:25) ***nirik wonders what part of the infrastructure is still on FC3... (10:55:35) ***scop is not entirely happy to hear infrastructure runs/depends on that old distros... ;) (10:55:40) dgilmore: nirik: we have RHEL4 servers (10:55:44) abadger1999: It's currently just in devel. (10:55:56) rdieter: that's what EL-4 branches are for. :) (10:55:58) abadger1999: I figured I'd wait on my branch requests until I got approval here. (10:56:08) dgilmore: rdieter: but they dont exist yet (10:56:08) rdieter: +1 for FC-3 branch (10:56:48) scop: +1 if you'll create everything in between FC-3 and devel, too (10:56:48) bpepple: +1 for FC3 branch (10:56:58) tibbs: +1 (10:57:14) thl: sorry, I suddenly got guests (10:57:15) rdieter: scop: why bother with FC-4? (10:57:20) abadger1999: scop: Yep. (10:57:22) scop: upgrade paths? (10:57:23) thl: jwb, can you handle the rest of the meeting? (10:57:28) abadger1999: rdieter: because of upgrades. (10:57:40) dgilmore: rdieter: for continuitity (10:57:41) rdieter: scop: upgrades between to legacy releases? ick. ok, I guess. (10:57:48) rdieter: s/to/two/ (10:58:09) dgilmore: the last of our FC-3 servers went to FC-5 when i upgraded the builders (10:58:25) scop: rdieter, consider user installing the package on FC-3, then upgrading to FC-4, then FC-5, and leaving it at that because there's something in FC-6 she doesn't like (10:58:52) jwb: thl, no actually. more real life meetings now. tibbs? (10:58:55) dgilmore: i do say if we do it we do it for all branches (10:59:12) dgilmore: other option is to make a infratructure cvs tree (10:59:20) dgilmore: and pull in what we need (10:59:21) tibbs: What is left to cover? I think I have my keyboard mostly working now. (10:59:24) rdieter: that's even worse. (10:59:41) c4chris__: rdieter, agreed (11:00:14) scop: what "that" is even worse? (11:00:31) rdieter: worse = "separate infrastructure cvs tree" (11:00:39) scop: ok, yep (11:00:48) jima: i agree -- i'd rather have to maintain crap for fc3. (11:01:00) tibbs: Yes, I think that's a terrible idea. Obviously for instrastructure we'd like to have RHEL branches, but that's otherwise held up. (11:01:04) nirik: well, the binary is going to be locally built from the FC-3 branch? so why not just build it from a devel branch and tweak it as needed? (11:01:36) jima: nirik: possibly less work involved. (11:01:37) nirik: either way it's going to be a locally built package for RHEL, right? (11:02:14) tibbs: Do the infrastructure folks uses the built FC3 packages as-is? (11:02:45) tibbs: If so, this makes sense as long as the package maintainer is actually willing to maintain the FC3 branch. (11:03:16) ***scop sees clement finished building, will go kick a push now (11:03:22) dgilmore: tibbs: im not 100% sure how we use them (11:03:46) ***dgilmore only really deals with builders and there all fc5 (11:04:03) abadger1999: Hmm.. Good question. Because infrastructure has been requesting FC-3 branches I assumed we use the packages as is. (11:04:24) abadger1999: I'd have to ask mmcgrath or warren to be sure, though. (11:04:33) tibbs: OK. (11:04:41) tibbs: Well, anyone around to talk about the package database? (11:04:57) jima: scop: wtg on the expedited fix. (11:04:58) tibbs: I'm really curious to see how it's coming along. (11:05:12) abadger1999: Sure -- there's a skeleton up for infrastructure people to start working on. (11:05:14) tibbs has changed the topic to: FESCo meeting in progress -- Package Database (11:05:15) scop: jima, ? (11:05:24) jima: scop: way to go (11:05:34) scop: ah, thanks ;) (11:05:36) volp [n=volp] entered the room. (11:05:42) abadger1999: I need to proxy that out to admin.fp.o so people outside infrastructure can access it. (11:05:58) jima: scop: nice to see we can shift into high gear when people do insane things like that. (11:06:07) scop: pushes take a looooong time though (11:06:11) c4chris__: and we need to put some data in there for people to look at (11:06:23) abadger1999: And then I'm working on importing data from owners.list and CVSROOT/modules (11:06:42) tibbs: What's actually working at this point? It sounds as if it's fairly well along. (11:07:10) abadger1999: yes and no. (11:07:19) abadger1999: Like I say it's a skeleton. (11:07:31) abadger1999: So the pieces to support the packageDB are in place. (11:07:43) delero left the room. (11:07:45) abadger1999: But the data and the website to pull the database info have to be written (11:08:27) tibbs: Sounds good in any case. I think this will help things significantly when it starts getting hooked up. (11:08:28) c4chris__: and some tables need to be adjusted to accept a bit more data (11:08:39) abadger1999: Right. (11:08:44) abadger1999: http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/RoadMap (11:09:11) abadger1999: Brain dumped some of my thoughts on where we're at and where we are going. (11:09:32) tibbs: Cool. Well, I guess proper co-maintainership hinges off of this. (11:09:48) tibbs: What about comps.xml? (11:10:16) ***scop needs to go in a few minutes (11:10:29) tibbs: dgilmore: anything going on there? (11:10:31) tibbs has changed the topic to: FESCo meeting in progress -- Use comps.xml properly (11:10:34) c4chris__: no that much. (11:10:43) c4chris__: I need to clean it up a bit (11:11:00) c4chris__: and dgilmore needs to push it... (11:11:01) dgilmore: tibbs: not yet i need to sit down with jeremy and we havent been able to yet (11:11:11) f13: did the uncategorized thing get fixed? (11:11:14) tibbs: Glue him to his chair? (11:11:29) dgilmore: tibbs: i think they stapled him to it (11:11:30) tibbs: Folks still seem a bit lost on where some packages should go. (11:11:33) c4chris__: tibbs, in a week or so, maybe... :-) (11:11:34) dgilmore: doesnt help (11:12:06) tibbs: And we don't seem to have much policy on when to add new groups. (11:12:48) tibbs: Extras and Core need to mesh pretty closely when it comes to comps, don't they? (11:13:10) tibbs: Otherwise the install experience gets kind of crappy with lots of random groups. (11:13:20) f13: yeah (11:13:24) f13: they need to mesh (11:13:37) f13: and most likely use existing categories, just add new groups if necessary or add to existing groups (11:13:42) f13: always "optional" (11:14:03) tibbs: Does core have written rules for adding comps that we could refer to? (11:14:08) f13: although, one could argue that if it's an Extras only group that the group could be optional and things WITHIN the group could be "default" or "manditory" (11:14:13) f13: tibbs: we don't. (11:14:29) f13: tibbs: tribal knowledge thats been passed down to me, and I usually run changes through Bill Nottingham and Jeremy Katz (11:14:58) tibbs: I've seen Extras contributors concerned about the impact of where they put their package and how it might interfere with installs or confuse users. (11:15:18) tibbs: Especially when it comes to things like command-line applications or servers. (11:15:39) c4chris__: tibbs, I know. Not clear to me either... (11:15:51) tibbs: So it might be good to get some basic guidelines written down at some point. (11:16:03) tibbs: I expect that the package DB will make some of this easier. (11:16:19) tibbs: As I understand things, folks won't have to go editing comps.xml.in any longer. (11:16:23) c4chris__: tibbs, I'm kinda hoping that when FC7 is out the dorr, some Core people will have time to discuss this (11:16:38) tibbs: I hope you mean FC6. (11:16:50) c4chris__: tibbs, oops, yes FC6 (11:17:17) tibbs: Anyone have anything else to discuss? We've gone off the end of the list. (11:17:26) tibbs has changed the topic to: FESCo meeting in progress -- finishing up (11:17:27) ***dgilmore has nothing (11:17:37) drpixel [n=drpixel] entered the room. (11:17:45) ***tibbs will close the meeting in 60... (11:17:45) f13: tibbs: hrm. (11:17:52) tibbs: hmm? (11:18:01) f13: tibbs: unless the package DB has some really finegrained info on packages, comps may still be necessary (11:18:09) f13: and I don't think we want that kind of info in a db (11:18:26) abadger1999: f13: What's needed? (11:18:26) ***f13 is thinking to the _future_ where core/extras all play in the same pool (11:18:41) tibbs: I thought the idea was that the DB would have a field for category/group (11:18:51) tibbs: And you could generate comps.xml from that. (11:18:59) ***nirik notes that FE-NEW is down around 130... which is the lowest its been in a while. Now's a great chance to push it down further. ;) (11:19:05) tibbs: Knowing the existing groups could allow folks to just pick from a list. (11:19:10) f13: abadger1999: 'what groups does this package go in', 'is it default/manditory/optionl in that group', 'in this group is it dependant on another package having already been selected' (11:19:23) jima: tibbs: that's what i was assuming, too. (11:19:35) jima: like, have a drop-down menu or whatnot. (11:19:53) f13: I could see a web interface to the Extras comps.in file (11:20:00) f13: which has pretty drop downs and checkboxen (11:20:32) dgilmore: f13: that would be cool (11:20:41) c4chris__: f13, sure, but why not attach this to the package DB? (11:20:53) tibbs: I, perhaps naively, assumed that this would just be part of the package DB. (11:20:55) jima: all i'm uncertain about is why that would need to be segregated from the package db. (11:21:04) jima: c4chris__, tibbs: +1 (11:21:18) abadger1999: f13: The first two are pretty simple to add the dependencies may or may not. But I don't think it's out of reach. (11:21:21) dgilmore: f13: it probably should be part of the packagedb some kind of comps info. (11:21:37) abadger1999: s/add the/add. The/ (11:21:47) ***dgilmore needs to go get lunch (11:21:51) tibbs: In other words,the packagedb stores all available info about packages and can generate or replace things like owners.list, comps, CVS ACLs, etc. (11:22:02) f13: dunno, depends on how utterly huge and unweildy you want the DB to be (11:22:12) f13: we're fighting that with brew right now. (11:22:25) jima: i imagine it'd be fairly trivial to add, as compared to designing a completely different system for maintaining comps.xml (11:22:27) f13: we didn't even want to think about doing comps info in our packagedb (11:22:59) tibbs: It's sad to see two packagedbs. (11:23:05) f13: for us, a package may be inherited into any number of collections or products, where the comps info may be completely invalid (11:23:55) tibbs: Anything else to cover? (11:24:15) tibbs: \me will close in 60 (11:24:24) tibbs: erm... (11:24:57) tibbs: ...30 (11:25:20) tibbs: ...10 (11:25:31) tibbs: EOM. Thanks, folks. }}} -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 dlutter at redhat.com Thu Oct 26 00:48:06 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 25 Oct 2006 17:48:06 -0700 Subject: Initial Proposal for doing Enterprise Extras In-Reply-To: <20061023153107.GB24288@nostromo.devel.redhat.com> References: <80d7e4090609151030s7a525a6ew9f5a28bf20cb457@mail.gmail.com> <3237e4410609151302x84d774cmec77d6a4b8cecf0c@mail.gmail.com> <80d7e4090609151613i179ac7a7x80e64604f5d08e4e@mail.gmail.com> <20061023150136.GB8818@jadzia.bu.edu> <20061023153107.GB24288@nostromo.devel.redhat.com> Message-ID: <1161823686.7808.23.camel@localhost.localdomain> On Mon, 2006-10-23 at 11:31 -0400, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > Offhand, I couldn't disagree more. You mean you'd rather live with the bugs > > that those 100+ package updates fix? No thanks. If you don't want the > > churn, then don't update your el4 boxen. > > So, you're requiring the user to explicitly browse the updates for > security vs. non-security fixes, for example? With the updateinfo.xml metadata that core is generating, this could be addressed with a simple addition to the update/repo tracking tools on the user's side. That assumes, of course, that that data is generated for extras ;) David From buildsys at fedoraproject.org Thu Oct 26 01:27:41 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Oct 2006 21:27:41 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-25 Message-ID: <20061026012741.A4DF715212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 24 Invalid build results: asymptote-1.16-1.fc7 Invalid build results: jack-audio-connection-kit-0.102.20-2.1.fc7 Invalid build results: libfreebob-1.0.0-3.fc7 Invalid build results: python-sexy-0.1.9-2.fc7 autogen-5.8.7-2.fc7 csound-5.03.0-5.fc7 dnsmasq-2.34-2.fc7 eggdrop-1.6.18-4.fc7 highlight-2.4.8-1.fc7 imlib2-1.3.0-1.fc7 jd-1.8.0-0.3.beta061023.fc7 kipi-plugins-0.1.2-2.fc7 libburn-0.2.2-2.fc7 libopts-27.4-1.fc7 ntfs-3g-0-0.4.20070920.fc7 numpy-1.0-1.fc7 qstat-2.10-6.fc7 ren-1.0-11.fc7 rpmdevtools-5.3-1.fc6 rrdtool-1.2.15-5.fc7 testdisk-6.5-1.fc7 wvs-data-0.0.20020219-2 yumex-1.1.7-1.0.fc6 zaptel-1.4.0-4.fc7.beta2 Packages built and released for Fedora Extras 6: 26 NetworkManager-vpnc-0.7.0-0.cvs20060929.3.fc6 asymptote-1.16-1.fc6 autogen-5.8.7-2.fc6 basket-0.6.0-1.fc6 cobbler-0.3.1-1.fc6 eggdrop-1.6.18-4.fc6 gaim-gaym-0.96-3.2.289svn.fc6 highlight-2.4.8-1.fc6.1 international-time-0.0.2-2.fc6.1 jack-audio-connection-kit-0.102.20-2.1.fc6 jd-1.8.0-0.2.beta061023.fc6 koan-0.2.4-1.fc6 libfreebob-1.0.0-3.fc6 libopts-27.4-1.fc6 nagios-plugins-1.4.4-1.fc6 ntfs-3g-0-0.4.20070920.fc6 php-pecl-zip-1.7.5-1.fc6 puppet-0.20.0-1.fc6 python-sexy-0.1.9-2.fc6 qt4-4.2.1-2.fc6 rpmdevtools-5.3-1.fc6 rrdtool-1.2.15-5.fc6 telepathy-gabble-0.4.1-1.fc6 testdisk-6.5-1.fc6 torque-2.1.6-1.fc6 yumex-1.1.7-1.0.fc6 Packages built and released for Fedora Extras 5: 13 asymptote-1.16-1.fc5 basket-0.6.0-1.fc5 cobbler-0.3.1-1.fc5 eggdrop-1.6.18-4.fc5 highlight-2.4.8-1.fc5.1 nagios-plugins-1.4.4-1.fc5 ntfs-3g-0-0.4.20070920.fc5 php-pecl-zip-1.7.5-1.fc5 pygpgme-0.1-3.fc5 python-sexy-0.1.8-5.fc5 rpmdevtools-5.3-1.fc5 rrdtool-1.2.15-5.fc5 torque-2.1.6-1.fc5 Packages built and released for Fedora Extras 4: 5 asymptote-1.16-1.fc4 eggdrop-1.6.18-4.fc4 nagios-plugins-1.4.4-1.fc4 pygpgme-0.1-3.fc4 torque-2.1.6-1.fc4 Packages built and released for Fedora Extras 3: 2 pygpgme-0.1-3.fc3 torque-2.1.6-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From green at redhat.com Thu Oct 26 01:50:00 2006 From: green at redhat.com (Anthony Green) Date: Wed, 25 Oct 2006 18:50:00 -0700 Subject: Fedora Extras Package Build Report 2006-10-25 In-Reply-To: <20061026012741.A4DF715212E@buildsys.fedoraproject.org> References: <20061026012741.A4DF715212E@buildsys.fedoraproject.org> Message-ID: <1161827400.21517.5.camel@localhost.localdomain> On Wed, 2006-10-25 at 21:27 -0400, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 24 > Invalid build results: libfreebob-1.0.0-3.fc7 What does this mean? The build results are here: http://buildsys.fedoraproject.org/logs/fedora-development-extras/20261-libfreebob-1.0.0-3.fc7 The ppc job log mentions fc6, which is wrong. Is this what buildsys is complaining about? Other than that it all looks good to me. AG From green at redhat.com Thu Oct 26 01:52:01 2006 From: green at redhat.com (Anthony Green) Date: Wed, 25 Oct 2006 18:52:01 -0700 Subject: Fedora Extras Package Build Report 2006-10-25 In-Reply-To: <1161827400.21517.5.camel@localhost.localdomain> References: <20061026012741.A4DF715212E@buildsys.fedoraproject.org> <1161827400.21517.5.camel@localhost.localdomain> Message-ID: <1161827521.21517.7.camel@localhost.localdomain> Ignore this. I just found the thread on the fedora maintainers list talking about this. AG On Wed, 2006-10-25 at 18:50 -0700, Anthony Green wrote: > On Wed, 2006-10-25 at 21:27 -0400, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 24 > > Invalid build results: libfreebob-1.0.0-3.fc7 > > What does this mean? The build results are here: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20261-libfreebob-1.0.0-3.fc7 > > The ppc job log mentions fc6, which is wrong. Is this what buildsys is > complaining about? Other than that it all looks good to me. > > AG > From buildsys at fedoraproject.org Thu Oct 26 02:35:14 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Oct 2006 22:35:14 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-25 Message-ID: <20061026023514.1A05515212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 4 asymptote-1.16-1.fc7 jack-audio-connection-kit-0.102.20-2.1.fc7 libfreebob-1.0.0-3.fc7 python-sexy-0.1.9-2.fc7 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 Oct 26 02:35:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Oct 2006 22:35:49 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-25 Message-ID: <20061026023549.85DE815212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) checkpolicy FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) gnome-netstatus FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mdadm FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) shadow-utils FC6-updates > FC7 (2:4.0.17-7.fc6 > 2:4.0.17-5) tar FC6-updates > FC7 (2:1.15.1-21.fc6 > 2:1.15.1-19) traceroute FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) dmitry AT butskoy.name: dvdisaster FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) gauret AT free.fr: basket FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) rdieter AT math.unl.edu: qt4 FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) basket: gauret AT free.fr FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) checkpolicy: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) dvdisaster: dmitry AT butskoy.name FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) gnome-netstatus: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mdadm: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) qt4: rdieter AT math.unl.edu FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) shadow-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:4.0.17-7.fc6 > 2:4.0.17-5) tar: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:1.15.1-21.fc6 > 2:1.15.1-19) traceroute: UNKNOWN OWNER (possibly Core package) FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) From buildsys at fedoraproject.org Thu Oct 26 03:34:33 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 26 Oct 2006 03:34:33 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-25 Message-ID: <20061026033433.21990.96005@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-2.fc7.i386 koffice-kivio - 1.6.0-2.fc7.i386 orange - 0.3-3.cvs20051118.fc6.i386 scribus - 1.3.3.4-1.fc6.i386 sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (25 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (25 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (25 days) dcbw AT redhat.com csound - 5.03.0-5.fc7.i386 plague - 0.4.4.1-2.fc3.noarch (40 days) plague - 0.4.4.1-2.fc3.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) plague - 0.4.4.1-2.fc4.noarch (40 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch (2 days) showimg-pgsql - 0.9.5-10.fc4.i386 (2 days) showimg-pgsql - 0.9.5-10.fc4.ppc (2 days) showimg-pgsql - 0.9.5-10.fc4.x86_64 (2 days) showimg-pgsql - 0.9.5-10.fc5.i386 (2 days) showimg-pgsql - 0.9.5-10.fc5.ppc (2 days) showimg-pgsql - 0.9.5-10.fc5.x86_64 (2 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 nagios-plugins-ide_smart - 1.4.3-20.fc5.i386 nagios-plugins-ide_smart - 1.4.3-20.fc5.ppc nagios-plugins-ide_smart - 1.4.3-20.fc5.x86_64 nagios-plugins-ide_smart - 1.4.3-20.fc6.i386 nagios-plugins-ide_smart - 1.4.3-20.fc6.ppc nagios-plugins-ide_smart - 1.4.3-20.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (16 days) linphone - 1.2.0-4.fc5.ppc (16 days) linphone - 1.2.0-4.fc5.x86_64 (16 days) linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.i386 linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.ppc linphone - 1.2.0-7.fc6.x86_64 linphone - 1.2.0-7.fc6.x86_64 matt AT truch.net kst - 1.3.1-1.fc6.i386 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (6 days) syck-php - 0.55-9.fc5.ppc (6 days) syck-php - 0.55-9.fc5.x86_64 (6 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 plplot-gnome - 5.6.1-7.fc6.i386 rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- csound-5.03.0-5.fc7.i386 requires libpython2.4.so.1.0 gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 linphone-1.2.0-7.fc6.i386 requires libortp.so.2 linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc6.ppc requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) nagios-plugins-ide_smart-1.4.3-20.fc6.x86_64 requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc6.i386 requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc5.ppc requires nagios-plugins = 0:1.4.3-20.fc5 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) nagios-plugins-ide_smart-1.4.3-20.fc5.x86_64 requires nagios-plugins = 0:1.4.3-20.fc5 perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc5.i386 requires nagios-plugins = 0:1.4.3-20.fc5 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: dcbw AT redhat.com package: csound - 5.03.0-5.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-ide_smart - 1.4.3-20.fc6.ppc from fedora-extras-6-ppc unresolved deps: nagios-plugins = 0:1.4.3-20.fc6 package: nagios-plugins-ide_smart - 1.4.3-20.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: nagios-plugins = 0:1.4.3-20.fc6 package: nagios-plugins-ide_smart - 1.4.3-20.fc6.i386 from fedora-extras-6-i386 unresolved deps: nagios-plugins = 0:1.4.3-20.fc6 package: nagios-plugins-ide_smart - 1.4.3-20.fc5.ppc from fedora-extras-5-ppc unresolved deps: nagios-plugins = 0:1.4.3-20.fc5 package: nagios-plugins-ide_smart - 1.4.3-20.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: nagios-plugins = 0:1.4.3-20.fc5 package: nagios-plugins-ide_smart - 1.4.3-20.fc5.i386 from fedora-extras-5-i386 unresolved deps: nagios-plugins = 0:1.4.3-20.fc5 package: nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc from fedora-extras-4-ppc unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 package: nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 package: nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 from fedora-extras-4-i386 unresolved deps: nagios-plugins = 0:1.4.3-20.fc4 From ville.skytta at iki.fi Thu Oct 26 05:45:00 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Oct 2006 08:45:00 +0300 Subject: jd In-Reply-To: <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> Message-ID: <1161841500.3527.107.camel@viper.local> On Thu, 2006-10-26 at 03:17 +0900, Mamoru Tasaka wrote: > Michael Schwendt wrote: > > On Wed, 25 Oct 2006 21:33:36 +0900, Mamoru Tasaka wrote: > > > >> Well, I was just planning to queue jd/1.8.0-0.2.beta061023.fc7.1 > >> (with common directory updated), but isn't it necessary? > > > > Package needs work. See bottom of build log: > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 > > > Well, this is due to desktop-file-install change (0.10->0.11). > desktop-file-install 0.11 no longer accepts like X-Fedora or > X-RedHat-Base... Huh, really? That would sound like a bug in desktop-file-install to me. http://standards.freedesktop.org/menu-spec/latest/ar01s03.html "The Categories field is a list of strings used to classify menu items. For example, applications in the AudioVideo category might end up in the "Sound & Video" submenu. Appendix A, Registered Categories enumerates the standard categories. Categories not in this document must be prefixed by the string "X-" indicating that they are extensions. Categories are case-sensitive." From mtasaka at ioa.s.u-tokyo.ac.jp Thu Oct 26 05:54:04 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Oct 2006 14:54:04 +0900 Subject: Desktop-file-utils 0.11 change (was: Re: jd) In-Reply-To: <1161841500.3527.107.camel@viper.local> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> <1161841500.3527.107.camel@viper.local> Message-ID: <45404D7C.2060202@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote: > On Thu, 2006-10-26 at 03:17 +0900, Mamoru Tasaka wrote: >> Michael Schwendt wrote: >>> Package needs work. See bottom of build log: >>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 >>> >> Well, this is due to desktop-file-install change (0.10->0.11). >> desktop-file-install 0.11 no longer accepts like X-Fedora or >> X-RedHat-Base... > > Huh, really? That would sound like a bug in desktop-file-install to me. > > http://standards.freedesktop.org/menu-spec/latest/ar01s03.html Well, this is real. You can check this by: http://buildsys.fedoraproject.org/logs/fedora-development-extras/20286-jd-1.8.0-0.2.beta061023.fc7/ppc/build.log Please see the bottom line of this log. Mamoru From weed at thebucket.org Thu Oct 26 07:22:35 2006 From: weed at thebucket.org (Chris Ausbrooks) Date: Thu, 26 Oct 2006 02:22:35 -0500 Subject: I would like to take ownership of gnome-themes-extras Message-ID: <4540623B.6010300@thebucket.org> I just noticed that gnome-themes-extras in on the orphan list as of fc6. I'm pretty well versed in rpm packaging, but I've never done anything official. If you google me and search for all combinations of "weed" and "bucket" together (my old college account was similar to my current account) you'll find that I've been around for quite some time. Like I said, I would love to take over this fairly simple package, but I will require some small amount of hand-holding (someone to show me (or point me to a howto on) how to use your bug tracking and content management systems). Thanks for your time, Chris Ausbrooks From giallu at gmail.com Thu Oct 26 07:29:59 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 26 Oct 2006 09:29:59 +0200 Subject: I would like to take ownership of gnome-themes-extras In-Reply-To: <4540623B.6010300@thebucket.org> References: <4540623B.6010300@thebucket.org> Message-ID: On 10/26/06, Chris Ausbrooks wrote: > Like I said, I would love to take over this fairly simple package, but I > will require some small amount of hand-holding (someone to show me (or > point me to a howto on) how to use your bug tracking and content > management systems). I guess your starting point should be: http://www.fedoraproject.org/wiki/Extras From bugs.michael at gmx.net Thu Oct 26 11:38:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 13:38:55 +0200 Subject: Desktop-file-utils 0.11 change (was: Re: jd) In-Reply-To: <45404D7C.2060202@ioa.s.u-tokyo.ac.jp> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> <1161841500.3527.107.camel@viper.local> <45404D7C.2060202@ioa.s.u-tokyo.ac.jp> Message-ID: <20061026133855.d9340180.bugs.michael@gmx.net> On Thu, 26 Oct 2006 14:54:04 +0900, Mamoru Tasaka wrote: > Ville Skytt? wrote: > > On Thu, 2006-10-26 at 03:17 +0900, Mamoru Tasaka wrote: > >> Michael Schwendt wrote: > >>> Package needs work. See bottom of build log: > >>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 > >>> > >> Well, this is due to desktop-file-install change (0.10->0.11). > >> desktop-file-install 0.11 no longer accepts like X-Fedora or > >> X-RedHat-Base... > > > > Huh, really? That would sound like a bug in desktop-file-install to me. > > > > http://standards.freedesktop.org/menu-spec/latest/ar01s03.html > > Well, this is real. You can check this by: > http://buildsys.fedoraproject.org/logs/fedora-development-extras/20286-jd-1.8.0-0.2.beta061023.fc7/ppc/build.log > Please see the bottom line of this log. > > Mamoru Still, the question is whether to fix desktop-file-install or our spec files? The build.log only says that either this is the new and expected behaviour or there is a bug in d-f-i. Does desktop-file-validate give the same output? From mtasaka at ioa.s.u-tokyo.ac.jp Thu Oct 26 11:52:29 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Oct 2006 20:52:29 +0900 Subject: Desktop-file-utils 0.11 change In-Reply-To: <20061026133855.d9340180.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <453EC8A2.9060300@ioa.s.u-tokyo.ac.jp> <20061025141100.51bde19a.bugs.michael@gmx.net> <20061025142721.f0926b53.bugs.michael@gmx.net> <453F59A0.5080409@ioa.s.u-tokyo.ac.jp> <20061025192415.d76671c2.bugs.michael@gmx.net> <453FAA4C.4030906@ioa.s.u-tokyo.ac.jp> <1161841500.3527.107.camel@viper.local> <45404D7C.2060202@ioa.s.u-tokyo.ac.jp> <20061026133855.d9340180.bugs.michael@gmx.net> Message-ID: <4540A17D.6@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Thu, 26 Oct 2006 14:54:04 +0900, Mamoru Tasaka wrote: > >> Ville Skytt? wrote: >>> On Thu, 2006-10-26 at 03:17 +0900, Mamoru Tasaka wrote: >>>> Michael Schwendt wrote: >>>>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=20286 >>>>> >>>> Well, this is due to desktop-file-install change (0.10->0.11). >>>> desktop-file-install 0.11 no longer accepts like X-Fedora or >>>> X-RedHat-Base... >>> Huh, really? That would sound like a bug in desktop-file-install to me. >> Well, this is real. You can check this by: >> http://buildsys.fedoraproject.org/logs/fedora-development-extras/20286-jd-1.8.0-0.2.beta061023.fc7/ppc/build.log > > Still, the question is whether to fix desktop-file-install or our > spec files? For now I don't know. If fedora want to use "Application" or "X-Fedora" category, desktop-file-utils should be fixed, otherwise all desktop files using these categories should be fixed. > Does desktop-file-validate give the same output? Actually yes (yes means that desktop-file-validate complaints). The original (i.e. jd-1.8.0-0.2.beta061023.fc6) desktop file of jd is: ---------------------------------------------- [Desktop Entry] Name=JD 2ch browser Comment=JD is a 2ch browser based on gtkmm2. Exec=jd Icon=jd.png Terminal=false Type=Application Encoding=UTF-8 Categories=Application;Network;X-Red-Hat-Base;X-Fedora; X-Desktop-File-Install-Version=0.10 --------------------------------------------- Checking this by desktop-file-validate (version 0.11) complains about "Application" "X-Red-Hat-Base" "X-Fedora". Error message is like: ./fedora-jd.desktop: error: Categories values must be one of "Core", "Java", "ConsoleOnly" (found "Application") Mamoru From jkeating at redhat.com Thu Oct 26 13:58:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 09:58:22 -0400 Subject: Desktop-file-utils 0.11 change In-Reply-To: <4540A17D.6@ioa.s.u-tokyo.ac.jp> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <20061026133855.d9340180.bugs.michael@gmx.net> <4540A17D.6@ioa.s.u-tokyo.ac.jp> Message-ID: <200610260958.25455.jkeating@redhat.com> On Thursday 26 October 2006 07:52, Mamoru Tasaka wrote: > > Still, the question is whether to fix desktop-file-install or our > > spec files? > > For now I don't know. If fedora want to use "Application" or "X-Fedora" > category, desktop-file-utils should be fixed, otherwise all desktop files > using these categories should be fixed. I spoke to the maintainer of the package, it will be fixed to accept the X-Foo tags again. Hopefully it will be fixed today for tonight's rawhide push. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Oct 26 14:23:49 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Oct 2006 17:23:49 +0300 Subject: Desktop-file-utils 0.11 change In-Reply-To: <200610260958.25455.jkeating@redhat.com> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <20061026133855.d9340180.bugs.michael@gmx.net> <4540A17D.6@ioa.s.u-tokyo.ac.jp> <200610260958.25455.jkeating@redhat.com> Message-ID: <1161872629.3527.136.camel@viper.local> On Thu, 2006-10-26 at 09:58 -0400, Jesse Keating wrote: > On Thursday 26 October 2006 07:52, Mamoru Tasaka wrote: > > > Still, the question is whether to fix desktop-file-install or our > > > spec files? > > > > For now I don't know. If fedora want to use "Application" or "X-Fedora" > > category, desktop-file-utils should be fixed, otherwise all desktop files > > using these categories should be fixed. "Application" has not been a standard category in a long time, but rejecting X-* is clearly a bug. On the other hand, I'm not aware of any benefits from adding X-Fedora to every desktop file... > I spoke to the maintainer of the package, it will be fixed to accept the X-Foo > tags again. Hopefully it will be fixed today for tonight's rawhide push. Thanks, I wish I'd read that 15 minutes ago :P https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212350 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Oct 26 14:26:39 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 26 Oct 2006 16:26:39 +0200 Subject: Desktop-file-utils 0.11 change In-Reply-To: <1161872629.3527.136.camel@viper.local> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <20061026133855.d9340180.bugs.michael@gmx.net> <4540A17D.6@ioa.s.u-tokyo.ac.jp> <200610260958.25455.jkeating@redhat.com> <1161872629.3527.136.camel@viper.local> Message-ID: <20061026162639.6158a8cb@python3.es.egwn.lan> Ville Skytt? wrote : > On the other hand, I'm not aware of any > benefits from adding X-Fedora to every desktop file... This has always seemed like a useless fedora.us leftover to me. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Rawhide) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.23 0.18 0.12 From jkeating at redhat.com Thu Oct 26 14:41:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 10:41:58 -0400 Subject: Desktop-file-utils 0.11 change In-Reply-To: <20061026162639.6158a8cb@python3.es.egwn.lan> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <1161872629.3527.136.camel@viper.local> <20061026162639.6158a8cb@python3.es.egwn.lan> Message-ID: <200610261041.58205.jkeating@redhat.com> On Thursday 26 October 2006 10:26, Matthias Saou wrote: > > On the other hand, I'm not aware of any > > benefits from adding X-Fedora to every desktop file... > > This has always seemed like a useless fedora.us leftover to me. I thought it was used in how the Gnome menus are actually setup in Fedora, but upon closer look (and discussing with our desktop folks) X-Fedora is 100% useless. --vendor fedora is only there because a --vendor is required by desktop-file-utils, but I hear word that we're going to fix that, as the vendor tag isn't used by anything either. So in this case, I think we need to remove the suggestion of at least X-Fedora from the Guidelines. Any future package should not use it, and existing packages can remove it at will. I'll send this through the packaging committee for an email vote. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Oct 26 14:56:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Oct 2006 09:56:19 -0500 Subject: Desktop-file-utils 0.11 change References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <1161872629.3527.136.camel@viper.local> <20061026162639.6158a8cb@python3.es.egwn.lan> <200610261041.58205.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > --vendor fedora is only there because a --vendor is required by > desktop-file-utils, but I hear word that we're going to fix that, as the > vendor tag isn't used by anything either. We just ratified an update for that in the Packaging Guidelines: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles (waiting for me to move/writup in the official guidelines). -- Rex From bugs.michael at gmx.net Thu Oct 26 15:13:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 17:13:15 +0200 Subject: Desktop-file-utils 0.11 change In-Reply-To: <200610261041.58205.jkeating@redhat.com> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <1161872629.3527.136.camel@viper.local> <20061026162639.6158a8cb@python3.es.egwn.lan> <200610261041.58205.jkeating@redhat.com> Message-ID: <20061026171315.2535a31a.bugs.michael@gmx.net> On Thu, 26 Oct 2006 10:41:58 -0400, Jesse Keating wrote: > On Thursday 26 October 2006 10:26, Matthias Saou wrote: > > > On the other hand, I'm not aware of any > > > benefits from adding X-Fedora to every desktop file... > > > > This has always seemed like a useless fedora.us leftover to me. > > I thought it was used in how the Gnome menus are actually setup in Fedora, but > upon closer look (and discussing with our desktop folks) X-Fedora is 100% > useless. X-Red-Hat-Extras is useless, too. Does that make it a "useless Red Hat leftover"? It is widely known that X-Fedora has never served any purpose other than allowing for a future desktop menu editing feature. At one time, only X-Red-Hat-Base was needed to make a menu entry appear in the top-level menus, whereas everything else only appeared in the sub-menus. From dcbw at redhat.com Thu Oct 26 15:35:48 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Oct 2006 11:35:48 -0400 Subject: Extras build system back up In-Reply-To: <20051017212801.GJ5856@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> Message-ID: <1161876948.2927.40.camel@localhost.localdomain> On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > As I see you've figured out, it should be fixed now. Server-side issue > > with some database fields being way too small. They are larger now :) > > Yes, thanks. Is > > [Server] > ... > allow_uploads = True > > the recommended change to config? Sorry for the lag... allow_uploads should only be configured if you're using SRPM-only building and you want to allow people to upload random SRPMs to the build server. It's useless for CVS builds. Dan > I notice plague list once creates config with > > allow_uploads = no > > thanks, > -chris > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Thu Oct 26 15:36:58 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Oct 2006 11:36:58 -0400 Subject: Extras build system back up In-Reply-To: <20051017212801.GJ5856@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> Message-ID: <1161877018.2927.41.camel@localhost.localdomain> On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > As I see you've figured out, it should be fixed now. Server-side issue > > with some database fields being way too small. They are larger now :) > > Yes, thanks. Is > > [Server] > ... > allow_uploads = True Haha, I just saw this was sent over a year ago. Yay for evolution and threaded message lists. > the recommended change to config? > > I notice plague list once creates config with > > allow_uploads = no > > thanks, > -chris > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From orion at cora.nwra.com Thu Oct 26 15:38:20 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 26 Oct 2006 09:38:20 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-25 In-Reply-To: <20061026033433.21990.96005@extras64.linux.duke.edu> References: <20061026033433.21990.96005@extras64.linux.duke.edu> Message-ID: <4540D66C.9020705@cora.nwra.com> Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > ---------------------------------------------------------------------- > orion AT cora.nwra.com > plplot - 5.6.1-7.fc6.i386 > plplot-gnome - 5.6.1-7.fc6.i386 > > Broken packages in fedora-extras-development-x86_64: > ---------------------------------------------------------------------- > csound-5.03.0-5.fc7.i386 requires libpython2.4.so.1.0 > k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 > koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 > koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 > plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 > plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 > scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 > > Broken packages in fedora-extras-development-i386: > ---------------------------------------------------------------------- > linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Why is libpython2.4.so.1.0 missing on x86_64 but not i386? -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Thu Oct 26 16:10:58 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Oct 2006 18:10:58 +0200 Subject: Desktop-file-utils 0.11 change In-Reply-To: <20061026171315.2535a31a.bugs.michael@gmx.net> References: <20061025004150.B50B815212E@buildsys.fedoraproject.org> <1161872629.3527.136.camel@viper.local> <20061026162639.6158a8cb@python3.es.egwn.lan> <200610261041.58205.jkeating@redhat.com> <20061026171315.2535a31a.bugs.michael@gmx.net> Message-ID: <20061026161058.GA30901@neu.nirvana> On Thu, Oct 26, 2006 at 05:13:15PM +0200, Michael Schwendt wrote: > On Thu, 26 Oct 2006 10:41:58 -0400, Jesse Keating wrote: > > > On Thursday 26 October 2006 10:26, Matthias Saou wrote: > > > > On the other hand, I'm not aware of any > > > > benefits from adding X-Fedora to every desktop file... > > > > > > This has always seemed like a useless fedora.us leftover to me. > > > > I thought it was used in how the Gnome menus are actually setup in Fedora, but > > upon closer look (and discussing with our desktop folks) X-Fedora is 100% > > useless. > > X-Red-Hat-Extras is useless, too. Does that make it a "useless Red Hat > leftover"? > > It is widely known that X-Fedora has never served any purpose other than > allowing for a future desktop menu editing feature. > > At one time, only X-Red-Hat-Base was needed to make a menu entry appear in > the top-level menus, whereas everything else only appeared in the > sub-menus. I remember that there was even some kind request by Red Hat to not use some of these and mangle the top-level menus, but I cannot put my finger on it now. Probably RH7.3-RH9 era. -- 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 Thu Oct 26 18:14:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 20:14:32 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-25 In-Reply-To: <4540D66C.9020705@cora.nwra.com> References: <20061026033433.21990.96005@extras64.linux.duke.edu> <4540D66C.9020705@cora.nwra.com> Message-ID: <20061026201432.29480605.bugs.michael@gmx.net> On Thu, 26 Oct 2006 09:38:20 -0600, Orion Poplawski wrote: > > Broken packages in fedora-extras-development-x86_64: > > ---------------------------------------------------------------------- > > csound-5.03.0-5.fc7.i386 requires libpython2.4.so.1.0 > > k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 > > koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 > > koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 > > plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 > > plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 > > scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 > > > > Broken packages in fedora-extras-development-i386: > > ---------------------------------------------------------------------- > > linphone-1.2.0-7.fc6.i386 requires libortp.so.2 > > Why is libpython2.4.so.1.0 missing on x86_64 but not i386? This is multi-lib enabled Fedora Extras Development. In addition to Wine (and its dependencies), now i386 -devel packages and their dependencies are available in x86_64 Extras, too. If libpython2.4.so.1.0 i386 (!) is not in Rawhide x86_64, we need to talk about it and either start black-listing i386 Extras packages, which we don't want to have multi-lib enabled (or fix the sub-packages). Above are dependencies of: csound-devel k3d-devel koffice-devel plplot-devel scribus-devel From ville.skytta at iki.fi Thu Oct 26 20:14:27 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Oct 2006 23:14:27 +0300 Subject: rpms/geomview/devel geomview.spec,1.28,1.29 In-Reply-To: <200610261934.k9QJYZXh018108@cvs-int.fedora.redhat.com> References: <200610261934.k9QJYZXh018108@cvs-int.fedora.redhat.com> Message-ID: <1161893667.3527.156.camel@viper.local> On Thu, 2006-10-26 at 12:34 -0700, Rex Dieter wrote: > Modified Files: > geomview.spec > Log Message: > * Thu Oct 26 2006 Rex Dieter 1.8.2-0.23.rc9 > - fixup desktop-file-install usage [...] > # .desktop entry > -mkdir -p $RPM_BUILD_ROOT%{_datadir}/applications > -desktop-file-install --vendor fedora \ > +desktop-file-install --vendor="" \ > --dir $RPM_BUILD_ROOT%{_datadir}/applications \ > - --add-category X-Fedora \ > %{SOURCE1} Isn't the above --vendor change directly against http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles [0]? It'd cause the desktop file to be renamed between package revisions and thus breakage. [0] "It is important that vendor_id stay constant for the life of a package." From rdieter at math.unl.edu Thu Oct 26 20:26:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Oct 2006 15:26:05 -0500 Subject: rpms/geomview/devel geomview.spec,1.28,1.29 References: <200610261934.k9QJYZXh018108@cvs-int.fedora.redhat.com> <1161893667.3527.156.camel@viper.local> Message-ID: Ville Skytt? wrote: > On Thu, 2006-10-26 at 12:34 -0700, Rex Dieter wrote: > >> Modified Files: >> geomview.spec >> Log Message: >> * Thu Oct 26 2006 Rex Dieter 1.8.2-0.23.rc9 >> - fixup desktop-file-install usage > [...] >> # .desktop entry >> -mkdir -p $RPM_BUILD_ROOT%{_datadir}/applications >> -desktop-file-install --vendor fedora \ >> +desktop-file-install --vendor="" \ >> --dir $RPM_BUILD_ROOT%{_datadir}/applications \ >> - --add-category X-Fedora \ >> %{SOURCE1} > > Isn't the above --vendor change directly against > http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles [0]? It'd > cause the desktop file to be renamed between package revisions and thus > breakage. > > [0] "It is important that vendor_id stay constant for the life of a > package." Crap, violated my own packaging proposal. I snarfed out both X-Fedora and fedora by accident. -- Rex From bugs.michael at gmx.net Thu Oct 26 21:38:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 23:38:23 +0200 Subject: FCXStatus wiki pages Message-ID: <20061026233823.0a878ca3.bugs.michael@gmx.net> > /Extras/FC3Status, /Extras/FC4Status, ... /Extras/FC6Status What had started as a Wiki page for requesting builds of packages for FC-3, when Seth Vidal was our human build-system, has served a different purpose for a long time. We've extended the original page with a pointer on how to use the automatic build-system, we've used the pages for tracking some things around Fedora Extras (like packages dropped from Core), we've created a new page for every version of FC, and we've used the pages as a way for package maintainers to submit special requests to RPM package repository admins. Now it's time to stop this. Too many [confusing] pages. Too many places where to track some things. At the same time: Too many places where some things are not tracked properly. Too many things we don't really want to track, do we? ;) We've practised and evaluated this long enough now. The single place where to submit _special_ requests to the repository admins is this: http://fedoraproject.org/wiki/Extras/RepoRequests [...] If we could use OTRS instead, somebody in charge of that system please get back to me. [...] It should be the rare exception that you want something to be removed from the repository or that you want huge data packages duplicated to multiple repositories. What about obsolete sub-packages in the repository? As an addition to the previous process, the new RepoPrune code in production also gets rid of obsolete sub-packages in FE Development automatically (!) when your next update is published. We keep only a single release per package. For the stable branches of Fedora Extras, we keep at most two releases per package. It is recommended that you request removal of obsolete sub-packages, especially if they are broken. From mmcgrath at fedoraproject.org Thu Oct 26 23:11:33 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 26 Oct 2006 18:11:33 -0500 Subject: Build machine failures Message-ID: <3237e4410610261611v5bde8edfuadbaa40344b52f4c@mail.gmail.com> Due to one hardware failure and another failure we're looking into, our x86_64 builders are down to 1, so for the time being be nice :) -Mike From seg at haxxed.com Fri Oct 27 03:54:43 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 26 Oct 2006 22:54:43 -0500 Subject: Extras build system back up In-Reply-To: <1161877018.2927.41.camel@localhost.localdomain> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> <1161877018.2927.41.camel@localhost.localdomain> Message-ID: <1161921284.6421.3.camel@max.booze> On Thu, 2006-10-26 at 11:36 -0400, Dan Williams wrote: > Haha, I just saw this was sent over a year ago. Yay for evolution and > threaded message lists. Yeah, Evolution's threading is broken, IMHO. I keep missing important replies, because Evo threads them with the previous messages, and sorts based on the oldest message in the thread, not the newest. Probably time for an RFE... -------------- 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 Fri Oct 27 07:36:10 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 27 Oct 2006 09:36:10 +0200 Subject: Extras build system back up In-Reply-To: <1161921284.6421.3.camel@max.booze> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> <1161877018.2927.41.camel@localhost.localdomain> <1161921284.6421.3.camel@max.booze> Message-ID: <20061027093610.3f2b889f@banea.int.addix.net> Hi. On Thu, 26 Oct 2006 22:54:43 -0500, Callum Lerwick wrote: > Yeah, Evolution's threading is broken, IMHO. I keep missing important > replies, because Evo threads them with the previous messages, and > sorts based on the oldest message in the thread, not the newest. FWIW, I think this behaviour is sane (just judging from your description, not having used evo myself). Thunderbird threads and then sorts the threads by the newest message in the thread, which drives me crazy :) Sylpheed acts like evo from your description, and I like it that way. From buildsys at fedoraproject.org Fri Oct 27 08:20:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 27 Oct 2006 04:20:05 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-27 Message-ID: <20061027082005.767F715212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 11 bitlbee-1.0.3-5.fc7 fedora-package-config-smart-6.89-7 geomview-1.8.2-0.25.rc9.fc7 gnupg2-1.9.94-1.fc7 imlib2-1.3.0-2.fc7 linphone-1.5.0-2.fc7 maxima-5.10.0-7.fc7 php-pear-XML-Serializer-0.18.0-2.fc7 sbcl-0.9.18-1.fc7 uw-imap-2006c1-1.fc7 wordpress-2.0.4-1.fc7 Packages built and released for Fedora Extras 6: 8 bitlbee-1.0.3-5.fc6 fedora-package-config-smart-6-8 hatari-0.90-5.fc6 php-json-1.2.1-5.fc6 php-shout-0.3.1-7.fc6 ren-1.0-11.fc6 vdradmin-am-3.4.7-3.fc6 wordpress-2.0.4-1.fc6 Packages built and released for Fedora Extras 5: 9 bitlbee-1.0.3-5.fc5 fedora-package-config-smart-5-7 hatari-0.90-5.fc5 php-json-1.2.1-2.fc5 php-shout-0.3.1-6.fc5 ren-1.0-11.fc5 thewidgetfactory-0.2.1-2.fc5 vdradmin-am-3.4.7-3.fc5 wordpress-2.0.4-1.fc5 Packages built and released for Fedora Extras 4: 2 fedora-package-config-smart-4-6 wordpress-2.0.4-1.fc4 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 Fri Oct 27 08:20:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 27 Oct 2006 04:20:40 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-27 Message-ID: <20061027082040.D92CB15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) bluez-utils FC6-updates > FC7 (0:3.7-2 > 0:2.25-12) checkpolicy FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) gnome-netstatus FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) libsepol FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mdadm FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) traceroute FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) dmitry AT butskoy.name: dvdisaster FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.3.1-7.fc6 > 0:0.3.1-6.fc6) gauret AT free.fr: basket FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) rdieter AT math.unl.edu: qt4 FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) basket: gauret AT free.fr FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) bluez-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.7-2 > 0:2.25-12) checkpolicy: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) dvdisaster: dmitry AT butskoy.name FE5 > FE6 (0:0.70.2-1.fc5 > 0:0.70.1-1.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) gnome-netstatus: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.12.28-1.fc5 > 0:1.12.27-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mdadm: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.3.1-7.fc6 > 0:0.3.1-6.fc6) qt4: rdieter AT math.unl.edu FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) traceroute: UNKNOWN OWNER (possibly Core package) FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) From j.w.r.degoede at hhs.nl Fri Oct 27 08:38:02 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Oct 2006 10:38:02 +0200 Subject: State of multilib development update Message-ID: <4541C56A.5070903@hhs.nl> Hi all, Some time ago I send the message below, I've now filed bugs left and right and I'm posting this again with the BZ url's for those interested. --- Yesterday I tried to build i386 rpms on my x86_64 using the new multilib-devel packages instead of resorting to an i386 chroot. Although we have come a long way to making this possible there are still a few issues which makes doing this very hard: 1) gcc ignores setarch ====================== "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64 system as expected however, "setarch i386 gcc -o hello helloworld.c" also creates an x86_64 elf file instead of an i386 one, to get an i386 one I must do: "gcc -m32 -o hello helloworld.c". This is unfortunate, because even though rpmbuild adds -m32 to the *FLAGS environment variables things still don't for many packages, because they for example often ignore LDFLAGS, thus not specifying -m32 when linking, causing things to fail. A work around is to create shell script wrappers for gcc, g++ and ld which always add -m32, put these somewhere outside the standard $PATH and add the location to PATH when you want to build i386 binaries. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212520 (which got closed as not a bug, as I was already afraid). 2) rpmbuild ignores setarch =========================== "setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo, I know "rpmbuild --target i386" works better but still has issues, for example libdir is still set to /usr/lib64, this is already in bugzilla. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194123 3) pkgconfig ignores setarch ============================ I thought that pkgconfig was supposed to get this right and hence it was used to implement verious replacement foo-config scripts, but pkgconfig doesn't get this right. When testing I had only libpng-devel.i386 installed not the x86_64 version: --- [hans at shalem ~]$ pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found --- Behaves as expected, since it searches /usr/lib64/pkgconfig where there is no libpng.pc --- [hans at shalem ~]$ setarch i386 pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found [hans at shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc -> libpng12.pc --- Does not behave as expected, it should search /usr/lib/pkgconfig and find libpng.pc This can be worked around by doing a "export PKG_CONFIG_PATH=/usr/lib/pkgconfig" BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212522 4) rpmbuild lets x86_64 packages satisfy BR's when building for i386 ==================================================================== The subject says most of it, when doing an rpmbuild --target=i386 I don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel . I know things aren't that easy because with something like BR: desktop-file-utils, the x86_64 version will do fine. Suggestion: make rpmbuild check the arch of BR's who's name ends with -devel. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212523 5) xxx-devel.arch should require xxx.arch not just xxx ====================================================== When I install libXt-devel.i386 I expect it to drag in libXt.i386 and not to be happy with the already installed libXt.x86_64 . This will also stop some polution with i386 packages of x86_64 system, because currently we have the following scenario: libXt-1.0.2-3.fc6.x86_64 is installed Users does "yum install libXt-devel.x86_64" Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64, which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the x86_64 version of libXt and as an added bonus also install the i386 version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64 BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212524 Let me know what you think & Regards, Hans From j.w.r.degoede at hhs.nl Fri Oct 27 08:55:04 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Oct 2006 10:55:04 +0200 Subject: Howto build i386 packages on x86_64 FC-6 Message-ID: <4541C968.6080400@hhs.nl> Hi all, As you know from previous mails I've been doing some experimenting with building i386 packages on x86_64 (trying to see if the new multilib-devel really works). I currently have a working setup for this which I would like to share with you, for the why of these please see my previous mail titled: "State of multilib development update" Here is the how: 1 One time preperation steps ============================ 1a) Create a dir somewhere which is not in your default $PATH, I use $HOME/rpmbuild-i386 1b) Add the following gcc, cc, g++ and ld wrapper scripts to this dir: gcc --- #!/bin/bash exec /usr/bin/gcc -m32 "$@" --- cc --- #!/bin/bash exec /usr/bin/gcc -m32 "$@" --- g++ --- #!/bin/bash exec /usr/bin/g++ -m32 "$@" --- ld --- #!/bin/bash exec /usr/bin/ld -b elf32-i386 "$@" --- 1c) Somewhere in your $PATH add the following rpmbuild-i386 wrapper script: rpmbuild-i386 --- #!/bin/bash export PATH=$HOME/rpmbuild-i386:$PATH export PKG_CONFIG_PATH=/usr/lib/pkgconfig exec setarch i386 rpmbuild --target i386 "$@" --- Notice that you should modify the export PATH=xxx line to match your setup 1d) mark all these scripts as executable 1e) rm /etc/rpm/platform (see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194123 2 Per package steps =================== 2a) Manually check you've got i386 versions installed of all BuildRequires (and of the Requires of those BuildRequires) This must be done because rpmbuild will hapily try to build an i386 package when you've only got an x86_64 version of the required foo-devel, since you do have (a version of) foo-devel Notice that there are exceptions here, in the case of desktop-file-utils and ImageMagick (when only using convert) the x86_64 versions will do fine. 2b) Build the package using rpmbuild-i386 instead of plean rpmbuild, for example: "rpmbuild-i386 -bb bar.spec" Enjoy and Regards, Hans p.s. It is possible to create a make-i386 command in a very similar way, perhaps it is an idea to create a little package called build-i386 for this? From rc040203 at freenet.de Fri Oct 27 09:07:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Oct 2006 11:07:04 +0200 Subject: State of multilib development update In-Reply-To: <4541C56A.5070903@hhs.nl> References: <4541C56A.5070903@hhs.nl> Message-ID: <1161940024.10072.126.camel@mccallum.corsepiu.local> On Fri, 2006-10-27 at 10:38 +0200, Hans de Goede wrote: > Hi all, > "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64 > system as expected however, "setarch i386 gcc -o hello helloworld.c" > also creates an x86_64 elf file instead of an i386 one, to get an i386 > one I must do: "gcc -m32 -o hello helloworld.c". > > This is unfortunate, GCC's -m are the actual origin of multilibs (NOTE: multilibs == building for architecture variants; not multiarch'ing == running different architectures in the same run-time environment !). > because even though rpmbuild adds -m32 to the > *FLAGS environment variables things still don't for many packages, > because they for example often ignore LDFLAGS, It is controversial if -m should be part of CFLAGS or LDFLAGS etc. Some people consider it to be a mistake, because -m can comprise effects on various components of a toolchain, not only the compiler (E.g. there exist targets from whom -m set CPP defines). > thus not specifying -m32 > when linking, causing things to fail. Adding -m directly to CC, CXX etc. is an alternative approach. Ralf From buildsys at fedoraproject.org Fri Oct 27 09:18:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 27 Oct 2006 09:18:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-27 Message-ID: <20061027091845.26420.40076@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-2.fc7.i386 (2 days) koffice-kivio - 1.6.0-2.fc7.i386 (2 days) orange - 0.3-3.cvs20051118.fc6.i386 (3 days) scribus - 1.3.3.4-1.fc6.i386 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (27 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (27 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (27 days) dcbw AT redhat.com csound - 5.03.0-5.fc7.i386 (2 days) plague - 0.4.4.1-2.fc3.noarch (42 days) plague - 0.4.4.1-2.fc3.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 (3 days) gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch (4 days) showimg-pgsql - 0.9.5-10.fc4.i386 (4 days) showimg-pgsql - 0.9.5-10.fc4.ppc (4 days) showimg-pgsql - 0.9.5-10.fc4.x86_64 (4 days) showimg-pgsql - 0.9.5-10.fc5.i386 (4 days) showimg-pgsql - 0.9.5-10.fc5.ppc (4 days) showimg-pgsql - 0.9.5-10.fc5.x86_64 (4 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc5.i386 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc5.ppc (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc5.x86_64 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc6.i386 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc6.ppc (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc6.x86_64 (2 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (18 days) linphone - 1.2.0-4.fc5.ppc (18 days) linphone - 1.2.0-4.fc5.x86_64 (18 days) linphone - 1.2.0-7.fc6.i386 (3 days) linphone - 1.2.0-7.fc6.ppc (3 days) linphone - 1.2.0-7.fc6.x86_64 (3 days) matt AT truch.net kst - 1.3.1-1.fc6.i386 (3 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (8 days) syck-php - 0.55-9.fc5.ppc (8 days) syck-php - 0.55-9.fc5.x86_64 (8 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 (3 days) plplot-gnome - 5.6.1-7.fc6.i386 (3 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 (3 days) Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- csound-5.03.0-5.fc7.i386 requires libpython2.4.so.1.0 gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc6.ppc requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) nagios-plugins-ide_smart-1.4.3-20.fc6.x86_64 requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc6.i386 requires nagios-plugins = 0:1.4.3-20.fc6 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc5.ppc requires nagios-plugins = 0:1.4.3-20.fc5 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) nagios-plugins-ide_smart-1.4.3-20.fc5.x86_64 requires nagios-plugins = 0:1.4.3-20.fc5 perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 nagios-plugins-ide_smart-1.4.3-20.fc5.i386 requires nagios-plugins = 0:1.4.3-20.fc5 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 From jkeating at redhat.com Fri Oct 27 10:24:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Oct 2006 06:24:17 -0400 Subject: Extras build system back up In-Reply-To: <20061027093610.3f2b889f@banea.int.addix.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <1161921284.6421.3.camel@max.booze> <20061027093610.3f2b889f@banea.int.addix.net> Message-ID: <200610270624.20313.jkeating@redhat.com> On Friday 27 October 2006 03:36, Ralf Ertzinger wrote: > Sylpheed acts like evo from your description, and I like it that way. As does kmail. Sane filtering plus using 'go to next unread' that loops around is somewhat necessary in this configuration though. I don't let messages sit unread, if I need to go back to the m I mark as important. Then I can sort based on said flag and see all the messages that still need my action. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Oct 27 13:05:27 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Oct 2006 15:05:27 +0200 Subject: Headsup: significant libcddb update for devel repo Message-ID: <45420417.8050802@hhs.nl> Hi all, I've just updated libcddb to the ABI and API compatible 1.3.0 release, here is whats new: * [IMPORTANT] The text search functionality currently does not work anymore. This feature uses the search form on the freedb.org website. But since this form has disappeared, text search fails. In the mean time you might make use of the album command of the freedb2.org servers (see below). * [NEW] Support was added for the 'album' command of the freedb2.org servers. This feature can be used to do a text search for a certain album. It does not perform any HTML page parsing but uses an extension of the CDDB protocol. As input the function needs a disc with either the artist or title filled in. The results are similar as for the query command; i.e. a list of matching disc IDs together with their categories. The example program also supports this feature. * [NEW] Functions where added to set (libcddb_set_flags) or reset (libcddb_reset_flags) some flags. The flags used influence the behaviour of the library. By default all flags are disabled. Currently the following flags are available: - CDDB_F_EMPTY_STR: When this flag is set, the library will never return a NULL pointer for a string. Instead the empty string will be returned. - CDDB_F_NO_TRACK_ARTIST: When this flag is set, the library will not return the disc artist if the track artist is undefined. A NULL pointer (or the empty string if CDDB_F_EMPTY_STR is set) will be returned instead. Regards, Hans From nicolas.mailhot at laposte.net Fri Oct 27 14:10:44 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Oct 2006 16:10:44 +0200 (CEST) Subject: Howto build i386 packages on x86_64 FC-6 In-Reply-To: <200610271254.k9RCs1Gu017630@laptop13.inf.utfsm.cl> References: <200610271254.k9RCs1Gu017630@laptop13.inf.utfsm.cl> Message-ID: <23366.192.54.193.51.1161958244.squirrel@rousalka.dyndns.org> Le Ven 27 octobre 2006 14:54, Horst H. von Brand a ?crit : > Hans de Goede wrote: >> As you know from previous mails I've been doing some experimenting with >> building i386 packages on x86_64 (trying to see if the new >> multilib-devel really works). > > Isn't it enough to say something like: > > rpmbuild -ba --target i386 some-funky.spec LOL It should be enough, if the tools were fixed -- Nicolas Mailhot From fedora at leemhuis.info Fri Oct 27 14:31:45 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Oct 2006 16:31:45 +0200 Subject: Enhanced AWOL policy Message-ID: <45421851.1050903@leemhuis.info> Hi, there were small changes for the AWOL policy proposed. Look at http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=5&rev1=4 for the details. Are those changes okay for everybody? If not: please comment on the list. While at it: Are other enhancements needed? FESCo will probably discuss and vote on the proposed changes in the next meeting. CU thl From j.w.r.degoede at hhs.nl Fri Oct 27 16:10:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Oct 2006 18:10:32 +0200 Subject: Headsup: ogre soname change in next push Message-ID: <45422F78.80806@hhs.nl> Hi all, I've updated ogre to 1.2.3 and as always with a new upstream ogre release this breaks the ABI and changes the soname! The API is compatible so you should be able to fix any breakage by simply rebuilding your packages. I'll rebuild chess which uses ogre and which I maintain as soon as ogre is done building. Regards, Hans From paul at xelerance.com Fri Oct 27 16:29:27 2006 From: paul at xelerance.com (Paul Wouters) Date: Fri, 27 Oct 2006 18:29:27 +0200 (CEST) Subject: Enhanced AWOL policy In-Reply-To: <45421851.1050903@leemhuis.info> References: <45421851.1050903@leemhuis.info> Message-ID: On Fri, 27 Oct 2006, Thorsten Leemhuis wrote: > there were small changes for the AWOL policy proposed. Look at > > http://www.fedoraproject.org/wiki/Extras/Schedule/EnhanceAWOL?action=diff&rev2=5&rev1=4 > > for the details. Are those changes okay for everybody? If not: please > comment on the list. The maintainers are encouraged to maintain their Vacation file, but people who want to change a package are not instructed to check that Vacatin file. > While at it: Are other enhancements needed? I would like to see a mention of "trying to find the maintainer on alternative email addresses". The maintainer (esp smaller ones who don't really read the fedora lists actively) might just have a broken email address, and might not be aware of it. Paul From gemi at bluewin.ch Fri Oct 27 16:33:55 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 27 Oct 2006 18:33:55 +0200 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? Message-ID: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> I imported the oorexx package into CVS Extras. It build fine on i386 and ppc. However it requires the 32-bit glibc for building x86_64. Is there a way to do this? When building in mock, only the the 64-bit library is installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, but this didn't work. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From Matt_Domsch at dell.com Fri Oct 27 16:45:26 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 27 Oct 2006 11:45:26 -0500 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> Message-ID: <20061027164526.GA10752@lists.us.dell.com> On Fri, Oct 27, 2006 at 06:33:55PM +0200, G?rard Milmeister wrote: > I imported the oorexx package into CVS Extras. It build fine on i386 and > ppc. However it requires the 32-bit glibc for building x86_64. Is there > a way to do this? When building in mock, only the the 64-bit library is > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > but this didn't work. BuildRequires: glibc.i386 I'd think. -- 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 dennis at ausil.us Fri Oct 27 17:00:29 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 27 Oct 2006 12:00:29 -0500 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> Message-ID: <200610271200.30830.dennis@ausil.us> On Friday 27 October 2006 11:33, G?rard Milmeister wrote: > I imported the oorexx package into CVS Extras. It build fine on i386 and > ppc. However it requires the 32-bit glibc for building x86_64. Is there > a way to do this? When building in mock, only the the 64-bit library is > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > but this didn't work. you can't right now all *.i?86 packages are excluded for the x86_64 buildroot glibc.i686 and glibc.i386 cant be installed in the chroot as a result. what about your package needs the 32 bit glibc? -- Dennis Gilmore, RHCE Proud Australian From gemi at bluewin.ch Fri Oct 27 17:13:26 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 27 Oct 2006 19:13:26 +0200 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <200610271200.30830.dennis@ausil.us> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <200610271200.30830.dennis@ausil.us> Message-ID: <1161969206.29944.0.camel@scriabin.tannenrauch.ch> On Fri, 2006-10-27 at 12:00 -0500, Dennis Gilmore wrote: > On Friday 27 October 2006 11:33, G?rard Milmeister wrote: > > I imported the oorexx package into CVS Extras. It build fine on i386 and > > ppc. However it requires the 32-bit glibc for building x86_64. Is there > > a way to do this? When building in mock, only the the 64-bit library is > > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > > but this didn't work. > you can't right now all *.i?86 packages are excluded for the x86_64 buildroot > glibc.i686 and glibc.i386 cant be installed in the chroot as a result. what > about your package needs the 32 bit glibc? Here is an ML post on this subject: http://sourceforge.net/mailarchive/message.php?msg_id=11336924 -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From Matt_Domsch at dell.com Fri Oct 27 17:17:48 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 27 Oct 2006 12:17:48 -0500 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <1161969206.29944.0.camel@scriabin.tannenrauch.ch> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <200610271200.30830.dennis@ausil.us> <1161969206.29944.0.camel@scriabin.tannenrauch.ch> Message-ID: <20061027171748.GB10752@lists.us.dell.com> On Fri, Oct 27, 2006 at 07:13:26PM +0200, G?rard Milmeister wrote: > On Fri, 2006-10-27 at 12:00 -0500, Dennis Gilmore wrote: > > On Friday 27 October 2006 11:33, G??rard Milmeister wrote: > > > I imported the oorexx package into CVS Extras. It build fine on i386 and > > > ppc. However it requires the 32-bit glibc for building x86_64. Is there > > > a way to do this? When building in mock, only the the 64-bit library is > > > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > > > but this didn't work. > > you can't right now all *.i?86 packages are excluded for the x86_64 buildroot > > glibc.i686 and glibc.i386 cant be installed in the chroot as a result. what > > about your package needs the 32 bit glibc? > Here is an ML post on this subject: > http://sourceforge.net/mailarchive/message.php?msg_id=11336924 This would indicate you need to ExcludeArch: x86_64 and just not try building it there then. Yes? -- 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 gemi at bluewin.ch Fri Oct 27 17:30:06 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 27 Oct 2006 19:30:06 +0200 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <20061027171748.GB10752@lists.us.dell.com> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <200610271200.30830.dennis@ausil.us> <1161969206.29944.0.camel@scriabin.tannenrauch.ch> <20061027171748.GB10752@lists.us.dell.com> Message-ID: <1161970206.1800.0.camel@scriabin.tannenrauch.ch> On Fri, 2006-10-27 at 12:17 -0500, Matt Domsch wrote: > On Fri, Oct 27, 2006 at 07:13:26PM +0200, G?rard Milmeister wrote: > > On Fri, 2006-10-27 at 12:00 -0500, Dennis Gilmore wrote: > > > On Friday 27 October 2006 11:33, G??rard Milmeister wrote: > > > > I imported the oorexx package into CVS Extras. It build fine on i386 and > > > > ppc. However it requires the 32-bit glibc for building x86_64. Is there > > > > a way to do this? When building in mock, only the the 64-bit library is > > > > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > > > > but this didn't work. > > > you can't right now all *.i?86 packages are excluded for the x86_64 buildroot > > > glibc.i686 and glibc.i386 cant be installed in the chroot as a result. what > > > about your package needs the 32 bit glibc? > > Here is an ML post on this subject: > > http://sourceforge.net/mailarchive/message.php?msg_id=11336924 > > This would indicate you need to ExcludeArch: x86_64 > and just not try building it there then. Yes? That's the current state of affairs. Is it correct that oorexx is the still available to x86_64 users? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From fedora at leemhuis.info Fri Oct 27 17:55:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Oct 2006 19:55:01 +0200 Subject: Thanks everyone for your great work in Extras Message-ID: <454247F5.30603@leemhuis.info> Hi, FC6 is out and FE6 seems to work quite well afaics. So I'd like to use this post-release situation (guys, remember, we need to prepare the next release soon, FC7 is only round about six month away afaik) simply to say: Thanks everyone for your great work in Extras. And of course also thanks to the Core developers for their work on FC6. I'd like to send out some special thanks to: - Ville Skytt? -- for managing the mass rebuild. It was a lot of work and a lot of things got cleaned up. I think it was worth the effort and Extras is in a lot better shape now. - Michael Schwendt -- for the build/push and the recent scripts that do some cleanups now and then - Christian Iseli -- for pushing the second partial mass-rebuild - Denis Gilmore, Mike McGrath and some other sysadmis -- for managing the build servers - Matt Domsch -- for his mass-rebuilds to fix the missing build requires CU thl From bugs.michael at gmx.net Fri Oct 27 18:08:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Oct 2006 20:08:16 +0200 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <1161970206.1800.0.camel@scriabin.tannenrauch.ch> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <200610271200.30830.dennis@ausil.us> <1161969206.29944.0.camel@scriabin.tannenrauch.ch> <20061027171748.GB10752@lists.us.dell.com> <1161970206.1800.0.camel@scriabin.tannenrauch.ch> Message-ID: <20061027200816.e3f6b9d9.bugs.michael@gmx.net> On Fri, 27 Oct 2006 19:30:06 +0200, G?rard Milmeister wrote: > > > Here is an ML post on this subject: > > > http://sourceforge.net/mailarchive/message.php?msg_id=11336924 > > > > This would indicate you need to ExcludeArch: x86_64 > > and just not try building it there then. Yes? > > That's the current state of affairs. Is it correct that oorexx is the > still available to x86_64 users? If we tell the push script to copy it like "wine" from i386 to x86_64, yes. Else, no. From tian at c-sait.net Fri Oct 27 18:28:25 2006 From: tian at c-sait.net (Christian Jodar) Date: Fri, 27 Oct 2006 20:28:25 +0200 Subject: gcstar module disappeared from CVS Message-ID: <20061027202825.39db41f7@tianbox> Hello, I submitted gcstar that has been approved. I imported then the .src.rpm using cvs-import.sh script. It created the module. Then I checked out it and requested a build in devel branch. Everything went fine. I requested also FC-5 and FC-6 branches using CVSSyncNeeded page from Wiki. It has been done successfully and in CVS repository, I can see corresponding directories into extras/rpms/gcstar. So everything looks OK for me. But I have this error: > cvs co gcstar For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs server: cannot find module `gcstar' - ignored cvs [checkout aborted]: cannot expand modules So the module gcstar is not available since the CVS sync. Maybe I did something wrong, but I don't know what yet. Do I need to use again cvs-import.sh? For the moment, it prevents me from requesting any build (even in devel branch). Thank you for your help. Christian Jodar. From bugs.michael at gmx.net Fri Oct 27 21:20:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Oct 2006 23:20:33 +0200 Subject: gcstar module disappeared from CVS In-Reply-To: <20061027202825.39db41f7@tianbox> References: <20061027202825.39db41f7@tianbox> Message-ID: <20061027232033.52fa09dc.bugs.michael@gmx.net> On Fri, 27 Oct 2006 20:28:25 +0200, Christian Jodar wrote: > Hello, > > I submitted gcstar that has been approved. I imported then the .src.rpm using > cvs-import.sh script. It created the module. > > Then I checked out it and requested a build in devel branch. Everything went > fine. I requested also FC-5 and FC-6 branches using CVSSyncNeeded page from > Wiki. It has been done successfully and in CVS repository, I can see > corresponding directories into extras/rpms/gcstar. So everything looks OK for > me. But I have this error: > > > cvs co gcstar > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > cvs server: cannot find module `gcstar' - ignored > cvs [checkout aborted]: cannot expand modules > > > So the module gcstar is not available since the CVS sync. Maybe I did > something wrong, but I don't know what yet. Do I need to use again > cvs-import.sh? For the moment, it prevents me from requesting any build (even > in devel branch). It was removed in: revision 1.11956 date: 2006/10/23 22:59:58; author: katzj; state: Exp; lines: +0 -2 remove not fully imported modules Later, mmcgrath added your branches for FC-6 and FC-5, but the main gcstar module is gone. From dominik at greysector.net Fri Oct 27 21:33:23 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Oct 2006 23:33:23 +0200 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <20061027164526.GA10752@lists.us.dell.com> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <20061027164526.GA10752@lists.us.dell.com> Message-ID: <20061027213323.GC3341@rathann.pekin.waw.pl> On Friday, 27 October 2006 at 18:45, Matt Domsch wrote: > On Fri, Oct 27, 2006 at 06:33:55PM +0200, G?rard Milmeister wrote: > > I imported the oorexx package into CVS Extras. It build fine on i386 and > > ppc. However it requires the 32-bit glibc for building x86_64. Is there > > a way to do this? When building in mock, only the the 64-bit library is > > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > > but this didn't work. > > BuildRequires: glibc.i386 > > I'd think. You would, but that doesn't work. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buildsys at fedoraproject.org Sat Oct 28 00:21:30 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 27 Oct 2006 20:21:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-27 Message-ID: <20061028002130.BEDD115212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 13 ORBit-0.5.17-20.fc7 csound-5.03.0-7.fc7 gtk-sharp-1.0.10-12.fc7 kdeartwork-extras-3.5.5-2.fc7 libcddb-1.3.0-1.fc7 liferea-1.0.25-1.fc7 mod_nss-1.0.6-1.fc7 nagios-plugins-1.4.4-2.fc7 ogre-1.2.3-1.fc7 perl-Chatbot-Eliza-1.04-3.fc7 perl-Math-Pari-2.010709-1.fc7 telepathy-gabble-0.4.2-1.fc7 xchat-gnome-0.14-1.fc7 Packages built and released for Fedora Extras 6: 12 ORBit-0.5.17-20.fc6 dvdisaster-0.70.2-2.fc6 geomview-1.8.2-0.25.rc9.fc6 gtk-sharp-1.0.10-12.fc6 international-time-0.0.2-2.fc6.2 kdeartwork-extras-3.5.4-6.fc6 liferea-1.0.25-1.fc6 mod_nss-1.0.6-1.fc6 monodevelop-0.12-6.fc6 nagios-plugins-1.4.4-2.fc6 telepathy-gabble-0.4.2-1.fc6 xchat-gnome-0.14-1.fc6 Packages built and released for Fedora Extras 5: 4 Invalid rebuild: moodle-1.6.3-2.fc5 geomview-1.8.2-0.25.rc9.fc5 mod_nss-1.0.6-1.fc5 nagios-plugins-1.4.4-2.fc5 Packages built and released for Fedora Extras 4: 1 Invalid rebuild: moodle-1.6.3-2.fc4 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 Sat Oct 28 00:22:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 27 Oct 2006 20:22:07 -0400 (EDT) Subject: Package EVR problems in FC+FE 2006-10-27 Message-ID: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): anacron FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) checkpolicy FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse-changelog FC6-updates > FC7 (1:2.3.3-2.fc6 > 1:2.3.3-1.fc7) fonts-japanese FC5-updates > FC7 (0:0.20061016-1.fc5 > 0:0.20050222-11.1.1) FC6-updates > FC7 (0:0.20061016-1.fc6 > 0:0.20050222-11.1.1) gaim FC6-updates > FC7 (2:2.0.0-0.17.beta4.fc6 > 2:2.0.0-0.16.beta4.fc7) gnome-netstatus FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) libsepol FC5-updates > FC7 (0:1.15.1-1.fc5 > 0:1.15.1-1) FC6-updates > FC7 (0:1.15.1-1.fc6 > 0:1.15.1-1) libvirt FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mdadm FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) traceroute FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) dmitry AT butskoy.name: dvdisaster FE6 > FE7 (0:0.70.2-2.fc6 > 0:0.70.2-1.fc6) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.3.1-7.fc6 > 0:0.3.1-6.fc6) gauret AT free.fr: basket FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) paul AT all-the-johnsons.co.uk: monodevelop FE6 > FE7 (0:0.12-6.fc6 > 0:0.12-5.fc6) petersen AT redhat.com: m17n-db FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) rdieter AT math.unl.edu: qt4 FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) ---------------------------------------------------------------------- anacron: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) basket: gauret AT free.fr FE5 > FE7 (0:0.6.0-1.fc5 > 0:0.5.0-10.fc6) FE6 > FE7 (0:0.6.0-1.fc6 > 0:0.5.0-10.fc6) checkpolicy: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:1.32-1.fc5 > 0:1.30.12-1) FC5-updates > FC7 (0:1.32-1.fc5 > 0:1.30.12-1) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.1-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.1-1.fc6 > 0:0.2.8-1.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FE5 > FC6 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) FE5 > FC7 (0:0.6.0-2.fc5 > 0:0.6.0-1.fc6) dvdisaster: dmitry AT butskoy.name FE6 > FE7 (0:0.70.2-2.fc6 > 0:0.70.2-1.fc6) eclipse-changelog: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:2.3.3-2.fc6 > 1:2.3.3-1.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-1.fc5 > 0:0.2.1-3.fc6) fonts-japanese: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.20061016-1.fc5 > 0:0.20050222-11.1.1) FC6-updates > FC7 (0:0.20061016-1.fc6 > 0:0.20050222-11.1.1) gaim: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:2.0.0-0.17.beta4.fc6 > 2:2.0.0-0.16.beta4.fc7) gnome-netstatus: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libsepol: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.15.1-1.fc5 > 0:1.15.1-1) FC6-updates > FC7 (0:1.15.1-1.fc6 > 0:1.15.1-1) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-2.FC5 > 0:0.1.7-2) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) m17n-db: petersen AT redhat.com FE3 > FC5 (0:1.3.3-1.fc3 > 0:1.3.3-1) FE4 > FC5 (0:1.3.3-1.fc4 > 0:1.3.3-1) mdadm: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.5.4-2.fc6 > 0:2.5.4-1.fc7) monodevelop: paul AT all-the-johnsons.co.uk FE6 > FE7 (0:0.12-6.fc6 > 0:0.12-5.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.3.1-7.fc6 > 0:0.3.1-6.fc6) qt4: rdieter AT math.unl.edu FE5 > FE7 (0:4.2.1-2.fc5 > 0:4.2.1-1.fc6) FE6 > FE7 (0:4.2.1-2.fc6 > 0:4.2.1-1.fc6) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) traceroute: UNKNOWN OWNER (possibly Core package) FC5 > FC7 (2:1.0.4-1.2 > 0:2.0.1-1) FC6 > FC7 (2:1.0.4-2 > 0:2.0.1-1) vnc: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:4.1.2-5.fc6 > 0:4.1.2-4.fc7) xsane: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:0.991-4.fc5 > 0:0.991-3.fc7) FC6-updates > FC7 (0:0.991-4.fc6 > 0:0.991-3.fc7) From bugs.michael at gmx.net Sat Oct 28 01:14:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 03:14:27 +0200 Subject: repoview for debuginfo packages? Message-ID: <20061028031427.3ae5df5d.bugs.michael@gmx.net> When earlier this night I patched our extras-repobuild script (which runs createrepo) to make it backup repoview files, I've noticed that we still run repoview for "debuginfo" rpms, e.g. http://fedoraproject.org/extras/development/i386/debug/repodata/index.html and had to patch the script a 2nd time to get it right. *urgh* Do we really want or need extra repoview pages for debuginfo packages? Who browses them in addition to the repoview pages for normal packages? From jkeating at redhat.com Sat Oct 28 01:15:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Oct 2006 21:15:58 -0400 Subject: repoview for debuginfo packages? In-Reply-To: <20061028031427.3ae5df5d.bugs.michael@gmx.net> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> Message-ID: <200610272115.58619.jkeating@redhat.com> On Friday 27 October 2006 21:14, Michael Schwendt wrote: > Do we really want or need extra repoview pages for debuginfo packages? I wouldn't think so. > Who browses them in addition to the repoview pages for normal packages? Are we using comps yet for repoview? That might make repoview more worthwhile, but probably still not for debuginfo. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Oct 28 01:25:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 28 Oct 2006 01:25:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-27 Message-ID: <20061028012514.18245.84150@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-4.fc6.i386 blender - 2.42a-4.fc6.ppc blender - 2.42a-4.fc6.x86_64 andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-2.fc7.i386 (2 days) koffice-kivio - 1.6.0-2.fc7.i386 (2 days) orange - 0.3-3.cvs20051118.fc6.i386 (3 days) scribus - 1.3.3.4-1.fc6.i386 (3 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (27 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (27 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (27 days) dcbw AT redhat.com csound - 5.03.0-7.fc7.i386 plague - 0.4.4.1-2.fc3.noarch (42 days) plague - 0.4.4.1-2.fc3.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) plague - 0.4.4.1-2.fc4.noarch (42 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 (3 days) gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch (4 days) showimg-pgsql - 0.9.5-10.fc4.i386 (4 days) showimg-pgsql - 0.9.5-10.fc4.ppc (4 days) showimg-pgsql - 0.9.5-10.fc4.x86_64 (4 days) showimg-pgsql - 0.9.5-10.fc5.i386 (4 days) showimg-pgsql - 0.9.5-10.fc5.ppc (4 days) showimg-pgsql - 0.9.5-10.fc5.x86_64 (4 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (2 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (2 days) j.w.r.degoede AT hhs.nl chess - 1.0-3.fc6.i386 chess - 1.0-3.fc6.ppc chess - 1.0-3.fc6.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (18 days) linphone - 1.2.0-4.fc5.ppc (18 days) linphone - 1.2.0-4.fc5.x86_64 (18 days) linphone - 1.2.0-7.fc6.i386 (3 days) linphone - 1.2.0-7.fc6.ppc (3 days) linphone - 1.2.0-7.fc6.x86_64 (3 days) matt AT truch.net kst - 1.3.1-1.fc6.i386 (3 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (8 days) syck-php - 0.55-9.fc5.ppc (8 days) syck-php - 0.55-9.fc5.x86_64 (8 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 (3 days) plplot-gnome - 5.6.1-7.fc6.i386 (3 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 (3 days) tcallawa AT redhat.com gambas-runtime - 1.0.17-3.fc6.i386 gambas-runtime - 1.0.17-3.fc6.ppc Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-4.fc6.ppc requires libgettextlib-0.14.6.so chess-1.0-3.fc6.ppc requires libCEGUIOgreRenderer-1.2.2.so chess-1.0-3.fc6.ppc requires libOgreMain-1.2.2.so gambas-runtime-1.0.17-3.fc6.ppc requires libgettextlib-0.14.6.so Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-4.fc6.x86_64 requires libgettextlib-0.14.6.so()(64bit) chess-1.0-3.fc6.x86_64 requires libCEGUIOgreRenderer-1.2.2.so()(64bit) chess-1.0-3.fc6.x86_64 requires libOgreMain-1.2.2.so()(64bit) csound-5.03.0-7.fc7.i386 requires libpython2.4.so.1.0 gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-4.fc6.i386 requires libgettextlib-0.14.6.so chess-1.0-3.fc6.i386 requires libCEGUIOgreRenderer-1.2.2.so chess-1.0-3.fc6.i386 requires libOgreMain-1.2.2.so gambas-runtime-1.0.17-3.fc6.i386 requires libgettextlib-0.14.6.so Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: dcbw AT redhat.com package: csound - 5.03.0-7.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libpython2.4.so.1.0 ====================================================================== New report for: Jochen AT herr-schmitt.de package: blender - 2.42a-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgettextlib-0.14.6.so package: blender - 2.42a-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgettextlib-0.14.6.so()(64bit) package: blender - 2.42a-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgettextlib-0.14.6.so ====================================================================== New report for: j.w.r.degoede AT hhs.nl package: chess - 1.0-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libCEGUIOgreRenderer-1.2.2.so libOgreMain-1.2.2.so package: chess - 1.0-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libCEGUIOgreRenderer-1.2.2.so()(64bit) libOgreMain-1.2.2.so()(64bit) package: chess - 1.0-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libCEGUIOgreRenderer-1.2.2.so libOgreMain-1.2.2.so ====================================================================== New report for: tcallawa AT redhat.com package: gambas-runtime - 1.0.17-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgettextlib-0.14.6.so package: gambas-runtime - 1.0.17-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgettextlib-0.14.6.so From Matt_Domsch at dell.com Sat Oct 28 03:03:15 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 27 Oct 2006 22:03:15 -0500 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <20061027213323.GC3341@rathann.pekin.waw.pl> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <20061027164526.GA10752@lists.us.dell.com> <20061027213323.GC3341@rathann.pekin.waw.pl> Message-ID: <20061028030315.GB11240@lists.us.dell.com> On Fri, Oct 27, 2006 at 11:33:23PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 27 October 2006 at 18:45, Matt Domsch wrote: > > On Fri, Oct 27, 2006 at 06:33:55PM +0200, G?rard Milmeister wrote: > > > I imported the oorexx package into CVS Extras. It build fine on i386 and > > > ppc. However it requires the 32-bit glibc for building x86_64. Is there > > > a way to do this? When building in mock, only the the 64-bit library is > > > installed. I tried to require /usr/include/gnu/stubs-32.h explicitly, > > > but this didn't work. > > > > BuildRequires: glibc.i386 > > > > I'd think. > > You would, but that doesn't work. It does in mock, just not on the builders. :-( Current mock's fedora-devel-x86_64-core.cfg file has: [main] ... exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 \ g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 (wrapping mine) which is designed to allow inclusion of glibc.i?86 only in the x86_64 chroots. >From what you and Dennis suggest, the Extras builders don't have this same exclude line, but have the older exclude line which absolutely disallowed all .i?86 packages in the x86_64 chroot. 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 lists at timj.co.uk Sat Oct 28 10:48:45 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 28 Oct 2006 11:48:45 +0100 Subject: Package EVR problems in FC+FE 2006-10-27 In-Reply-To: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> References: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> Message-ID: <4543358D.4060704@timj.co.uk> buildsys at fedoraproject.org wrote: > UNKNOWN OWNER (possibly Core package): > anacron > FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) Are these FPs or does nobody in Core actually care? (If not why not?) Are people in Core getting to see these reports? (From previous discussions it sounds like many are not subscribed here) It's obviously too late for bad EVRs from FC5-updates to FC6 base, but in general should bugs be filed? Tim From sundaram at fedoraproject.org Sat Oct 28 10:53:51 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 28 Oct 2006 16:23:51 +0530 Subject: Package EVR problems in FC+FE 2006-10-27 In-Reply-To: <4543358D.4060704@timj.co.uk> References: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> <4543358D.4060704@timj.co.uk> Message-ID: <454336BF.1030206@fedoraproject.org> Tim Jackson wrote: > buildsys at fedoraproject.org wrote: > >> UNKNOWN OWNER (possibly Core package): >> anacron >> FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) > > Are these FPs or does nobody in Core actually care? (If not why not?) > > Are people in Core getting to see these reports? (From previous > discussions it sounds like many are not subscribed here) Many of them are not subscribed to this list at all but we always encourage all the maintainers in core to be subscribed to fedora-maintainers list instead. So I have suggested already to move this report into that list since now it is not actually limited to extras packages. That is probably going to be more efficient. Rahul From bugs.michael at gmx.net Sat Oct 28 13:16:10 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 15:16:10 +0200 Subject: repoview for debuginfo packages? In-Reply-To: <200610272115.58619.jkeating@redhat.com> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <200610272115.58619.jkeating@redhat.com> Message-ID: <20061028151610.66976b6d.bugs.michael@gmx.net> On Fri, 27 Oct 2006 21:15:58 -0400, Jesse Keating wrote: > > Do we really want or need extra repoview pages for debuginfo packages? > > I wouldn't think so. > > > Who browses them in addition to the repoview pages for normal packages? > > Are we using comps yet for repoview? That might make repoview more > worthwhile, but probably still not for debuginfo. Hmmm, that's a different topic, though. I've found this: http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly Can anybody give a status update on that, please? I see Target date "FC6". But that's all I could find. I'm not aware of anyone proposing changes/updates to the push process. We do feed a comps.xml file to createrepo, but we don't update it from what is stored in CVS. Repoview takes all its input from repodata files. From dwmw2 at infradead.org Sat Oct 28 13:14:22 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 28 Oct 2006 14:14:22 +0100 Subject: 32-bit glibc required in mock for building oorexx on x86_64. How? In-Reply-To: <20061027171748.GB10752@lists.us.dell.com> References: <1161966835.22482.3.camel@scriabin.tannenrauch.ch> <200610271200.30830.dennis@ausil.us> <1161969206.29944.0.camel@scriabin.tannenrauch.ch> <20061027171748.GB10752@lists.us.dell.com> Message-ID: <1162041262.19446.512.camel@pmac.infradead.org> On Fri, 2006-10-27 at 12:17 -0500, Matt Domsch wrote: > > Here is an ML post on this subject: > > http://sourceforge.net/mailarchive/message.php?msg_id=11336924 > > This would indicate you need to ExcludeArch: x86_64 > and just not try building it there then. Yes? Please make sure a bug is filed with the above link. -- dwmw2 From fedora at leemhuis.info Sat Oct 28 13:39:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Oct 2006 15:39:04 +0200 Subject: repoview for debuginfo packages? In-Reply-To: <20061028151610.66976b6d.bugs.michael@gmx.net> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <200610272115.58619.jkeating@redhat.com> <20061028151610.66976b6d.bugs.michael@gmx.net> Message-ID: <45435D78.4050802@leemhuis.info> Michael Schwendt schrieb: > On Fri, 27 Oct 2006 21:15:58 -0400, Jesse Keating wrote: >>> Do we really want or need extra repoview pages for debuginfo packages? >> I wouldn't think so. >> >>> Who browses them in addition to the repoview pages for normal packages? >> Are we using comps yet for repoview? That might make repoview more >> worthwhile, but probably still not for debuginfo. > Hmmm, that's a different topic, though. I've found this: > http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly > Can anybody give a status update on that, please? dgilmore asked jeremy for details how to realize it when they branched Extras for FC6. Don't know how far the real work went after that. > I see Target date "FC6". Now "Nov 2006" > But that's all I could find. Because nobody actually started to really work on it. Cu thl From jwboyer at jdub.homelinux.org Sat Oct 28 14:11:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 28 Oct 2006 09:11:38 -0500 Subject: Thanks everyone for your great work in Extras In-Reply-To: <454247F5.30603@leemhuis.info> References: <454247F5.30603@leemhuis.info> Message-ID: <1162044698.3139.16.camel@vader.jdub.homelinux.org> On Fri, 2006-10-27 at 19:55 +0200, Thorsten Leemhuis wrote: > Hi, > > FC6 is out and FE6 seems to work quite well afaics. So I'd like to use > this post-release situation (guys, remember, we need to prepare the next > release soon, FC7 is only round about six month away afaik) simply to say: > > Thanks everyone for your great work in Extras. > And of course also thanks to the Core developers for their work on FC6. > > I'd like to send out some special thanks to: > > - Ville Skytt? -- for managing the mass rebuild. It was a lot of work > and a lot of things got cleaned up. I think it was worth the effort and > Extras is in a lot better shape now. > - Michael Schwendt -- for the build/push and the recent scripts that do > some cleanups now and then > - Christian Iseli -- for pushing the second partial mass-rebuild > - Denis Gilmore, Mike McGrath and some other sysadmis -- for managing > the build servers > - Matt Domsch -- for his mass-rebuilds to fix the missing build requires A big +10 josh From bugs.michael at gmx.net Sat Oct 28 14:47:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 16:47:05 +0200 Subject: comps.xml in Extras (was: Re: repoview for debuginfo packages?) In-Reply-To: <45435D78.4050802@leemhuis.info> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <200610272115.58619.jkeating@redhat.com> <20061028151610.66976b6d.bugs.michael@gmx.net> <45435D78.4050802@leemhuis.info> Message-ID: <20061028164705.87a73b2e.bugs.michael@gmx.net> On Sat, 28 Oct 2006 15:39:04 +0200, Thorsten Leemhuis wrote: > >> Are we using comps yet for repoview? That might make repoview more > >> worthwhile, but probably still not for debuginfo. > > Hmmm, that's a different topic, though. I've found this: > > http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly > > Can anybody give a status update on that, please? > > dgilmore asked jeremy for details how to realize it when they branched > Extras for FC6. Don't know how far the real work went after that. Private conversation? Or another mailing-list? extras-tree$ find . -name comps.xml|xargs ls -la|cut -c40- 413075 May 31 2005 ./4/i386/comps.xml 413075 Oct 27 03:17 ./4/i386/repodata/comps.xml 413075 May 31 2005 ./4/ppc/comps.xml 413075 Oct 27 03:14 ./4/ppc/repodata/comps.xml 413075 May 31 2005 ./4/x86_64/comps.xml 413075 Oct 27 03:16 ./4/x86_64/repodata/comps.xml 35647 Apr 17 2006 ./5/i386/comps.xml 35647 Oct 27 19:26 ./5/i386/repodata/comps.xml 35647 Apr 17 2006 ./5/ppc/comps.xml 35647 Oct 27 19:21 ./5/ppc/repodata/comps.xml 35647 Apr 17 2006 ./5/x86_64/comps.xml 35647 Oct 27 19:24 ./5/x86_64/repodata/comps.xml 35647 Apr 17 2006 ./6/i386/comps.xml 35647 Oct 27 19:15 ./6/i386/repodata/comps.xml 35647 Apr 17 2006 ./6/ppc/comps.xml 35647 Oct 27 19:12 ./6/ppc/repodata/comps.xml 35647 Apr 17 2006 ./6/x86_64/comps.xml 35647 Oct 27 19:13 ./6/x86_64/repodata/comps.xml 35647 Apr 17 2006 ./development/i386/comps.xml 35647 Oct 27 21:06 ./development/i386/repodata/comps.xml 35647 Apr 17 2006 ./development/ppc/comps.xml 35647 Oct 27 20:59 ./development/ppc/repodata/comps.xml 35647 Apr 17 2006 ./development/x86_64/comps.xml 35647 Oct 27 21:04 ./development/x86_64/repodata/comps.xml From bugs.michael at gmx.net Sat Oct 28 14:58:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 16:58:39 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025075609.GE31188@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> Message-ID: <20061028165839.f202892e.bugs.michael@gmx.net> On Wed, 25 Oct 2006 09:56:09 +0200, Axel Thimm wrote: > ATrpms is packaging asterisk and friends for quite some time > now. ATrpms' buildsystem has also enabled Fedora Extras during the > build procedure to ensure better interoperability, e.g. use BR's out > of Fedora Extras. > > For some reason Fedora Extras now had to package a beta version of the > asterisk suite instead of the current release. I'm used to packagers > at FE ignoring existing packages at other repos which is a bad thing > per se, but why > > - packaging a beta software that is known to have troubles, > - creates broken builds for other non-suspecting repos and > - gets right into production repos like FC5? > > Note that for some packages it really makes sense to use > beta/prereleases, VCS cuts and the like, but there is no reason to do > so in this case. > > As a consequence I will not only need to rebuild all of the asterisk > suite again to pick up the proper dependencies, but also to stop using > Fedora Extras as a repo for build requirements and start using Epoch > on clean packages. This topic came to a sudden end on the same day it was started, without a clear resolution and without any conclusion on whether including beta versions of some software is "okay" in this case. Has FESCo looked into this? From fedora at leemhuis.info Sat Oct 28 15:04:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Oct 2006 17:04:02 +0200 Subject: comps.xml in Extras In-Reply-To: <20061028164705.87a73b2e.bugs.michael@gmx.net> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <200610272115.58619.jkeating@redhat.com> <20061028151610.66976b6d.bugs.michael@gmx.net> <45435D78.4050802@leemhuis.info> <20061028164705.87a73b2e.bugs.michael@gmx.net> Message-ID: <45437162.8060203@leemhuis.info> Michael Schwendt schrieb: > On Sat, 28 Oct 2006 15:39:04 +0200, Thorsten Leemhuis wrote: >>>> Are we using comps yet for repoview? That might make repoview more >>>> worthwhile, but probably still not for debuginfo. >>> Hmmm, that's a different topic, though. I've found this: >>> http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly >>> Can anybody give a status update on that, please? >> dgilmore asked jeremy for details how to realize it when they branched >> Extras for FC6. Don't know how far the real work went after that. > Private conversation? Or another mailing-list? FESCo meeting. But is was some months ago. Should be in the archives and in the summaries that were posted to the list. > extras-tree$ find . -name comps.xml|xargs ls -la|cut -c40- [...] > 35647 Apr 17 2006 ./6/i386/comps.xml > 35647 Oct 27 19:15 ./6/i386/repodata/comps.xml > 35647 Apr 17 2006 ./6/ppc/comps.xml > 35647 Oct 27 19:12 ./6/ppc/repodata/comps.xml > 35647 Apr 17 2006 ./6/x86_64/comps.xml > 35647 Oct 27 19:13 ./6/x86_64/repodata/comps.xml [...] Jeremy, dgilmore (both CCed)? Cu thl From jwboyer at jdub.homelinux.org Sat Oct 28 15:05:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 28 Oct 2006 10:05:38 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061028165839.f202892e.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> Message-ID: <1162047938.3139.24.camel@vader.jdub.homelinux.org> On Sat, 2006-10-28 at 16:58 +0200, Michael Schwendt wrote: > On Wed, 25 Oct 2006 09:56:09 +0200, Axel Thimm wrote: > > This topic came to a sudden end on the same day it was started, without a > clear resolution and without any conclusion on whether including beta > versions of some software is "okay" in this case. > > Has FESCo looked into this? No. And I don't think we should. Theoretically, the maintainers of the packages know best as to how stable the software they are packaging is, what the timeline for said beta is to reach production, etc. If another maintainer questions this, then open a bug report against the package explaining why. That being said, my personal opinion is that "beta" or pre-release packages should only be done in the devel branch, and only if that beta has a really good chance of becoming an actual release before the devel branch is forked for the next Extras release. As for the third party repo aspect of this, that is quite difficult. There are potentially tons of third party repos, which already conflict with each other. We cannot show preference for one or the other. That does not mean that a third party repository maintainer cannot open a bug. It just means that we cannot expect Extras maintainers to go looking for problems in each and every third party repo before updating something. josh From ville.skytta at iki.fi Sat Oct 28 15:14:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 28 Oct 2006 18:14:33 +0300 Subject: Package EVR problems in FC+FE 2006-10-27 In-Reply-To: <454336BF.1030206@fedoraproject.org> References: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> <4543358D.4060704@timj.co.uk> <454336BF.1030206@fedoraproject.org> Message-ID: <1162048473.11104.8.camel@viper.local> On Sat, 2006-10-28 at 16:23 +0530, Rahul Sundaram wrote: > Tim Jackson wrote: > > buildsys at fedoraproject.org wrote: > > > >> UNKNOWN OWNER (possibly Core package): > >> anacron > >> FC5-updates > FC6 (0:2.3-42.fc5 > 0:2.3-41.fc6) > > > > Are these FPs or does nobody in Core actually care? (If not why not?) > > > > Are people in Core getting to see these reports? (From previous > > discussions it sounds like many are not subscribed here) > > Many of them are not subscribed to this list at all but we always > encourage all the maintainers in core to be subscribed to > fedora-maintainers list instead. So I have suggested already to move > this report into that list since now it is not actually limited to > extras packages. That is probably going to be more efficient. If someone can verify/set it up so that buildsys at fedoraproject.org can post to fedora-maintainers, let me know and I'll change the recipient address. From fedora at leemhuis.info Sat Oct 28 15:19:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Oct 2006 17:19:23 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061028165839.f202892e.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> Message-ID: <454374FB.5030207@leemhuis.info> Michael Schwendt schrieb: > On Wed, 25 Oct 2006 09:56:09 +0200, Axel Thimm wrote: >> ATrpms is packaging asterisk and friends for quite some time >> now. ATrpms' buildsystem has also enabled Fedora Extras during the >> build procedure to ensure better interoperability, e.g. use BR's out >> of Fedora Extras. >> >> For some reason Fedora Extras now had to package a beta version of the >> asterisk suite instead of the current release. I'm used to packagers >> at FE ignoring existing packages at other repos which is a bad thing >> per se, but why >> >> - packaging a beta software that is known to have troubles, >> - creates broken builds for other non-suspecting repos and >> - gets right into production repos like FC5? >> >> Note that for some packages it really makes sense to use >> beta/prereleases, VCS cuts and the like, but there is no reason to do >> so in this case. >> >> As a consequence I will not only need to rebuild all of the asterisk >> suite again to pick up the proper dependencies, but also to stop using >> Fedora Extras as a repo for build requirements and start using Epoch >> on clean packages. > > This topic came to a sudden end on the same day it was started, without a > clear resolution and without any conclusion on whether including beta > versions of some software is "okay" in this case. > > Has FESCo looked into this? Nope, not that I'm aware off. If somebody feels that FESCo should look at it please propose a solution for this problem (and how it can be prevented in the future) and put if up for discussion here on the list so community and FESCo members can comment. Putting it up in the wiki so other can enhance/modify it gives bonus points. Adjust the proposal if needed after the discussion. Then FESCo will look at it in a meeting -- if a consensus was found on the list is should be nothing more then "do as prosoed and discussed on the list? foo: +1, bar +1, foobar: +1 ..." That's how it should work IMHO to get stuff like this solved (and that's how stuff within FESCo gets done normally, too; see for example the recent AWOL extensions, the "When to fix other peoples packages stuff). Some people would prefer to say "here is a problem, FESCo please solve it", but that often doesn't work to well afaics. People that are interested in an issue are often the best to get that issue solved. And they don't have to be FESCo members to get it solved. CU thl From fedora at leemhuis.info Sat Oct 28 15:22:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Oct 2006 17:22:43 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162047938.3139.24.camel@vader.jdub.homelinux.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> Message-ID: <454375C3.5020507@leemhuis.info> Josh Boyer schrieb: > On Sat, 2006-10-28 at 16:58 +0200, Michael Schwendt wrote: >> On Wed, 25 Oct 2006 09:56:09 +0200, Axel Thimm wrote: >> This topic came to a sudden end on the same day it was started, without a >> clear resolution and without any conclusion on whether including beta >> versions of some software is "okay" in this case. >> Has FESCo looked into this? > > No. And I don't think we should. > > Theoretically, the maintainers of the packages know best as to how > stable the software they are packaging is, what the timeline for said > beta is to reach production, etc. If another maintainer questions this, > then open a bug report against the package explaining why. > > That being said, my personal opinion is that "beta" or pre-release > packages should only be done in the devel branch, and only if that beta > has a really good chance of becoming an actual release before the devel > branch is forked for the next Extras release. > > As for the third party repo aspect of this, that is quite difficult. > There are potentially tons of third party repos, which already conflict > with each other. We cannot show preference for one or the other. That > does not mean that a third party repository maintainer cannot open a > bug. It just means that we cannot expect Extras maintainers to go > looking for problems in each and every third party repo before updating > something. +1 CU thl From fedora at leemhuis.info Sat Oct 28 15:25:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Oct 2006 17:25:58 +0200 Subject: Package EVR problems in FC+FE 2006-10-27 In-Reply-To: <1162048473.11104.8.camel@viper.local> References: <20061028002207.8F4DE15212E@buildsys.fedoraproject.org> <4543358D.4060704@timj.co.uk> <454336BF.1030206@fedoraproject.org> <1162048473.11104.8.camel@viper.local> Message-ID: <45437686.7050507@leemhuis.info> Ville Skytt? schrieb: > > If someone can verify/set it up so that buildsys at fedoraproject.org can > post to fedora-maintainers, let me know and I'll change the recipient > address. "buildsys at fedoraproject.org" added to "accept_these_nonmembers" in mailman, so mails from that address should hopefully come through now. Cu thl From bugs.michael at gmx.net Sat Oct 28 16:11:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 18:11:54 +0200 Subject: Invalid rebuilds (was: Re: Fedora Extras Package Build Report 2006-10-27) In-Reply-To: <20061028002130.BEDD115212E@buildsys.fedoraproject.org> References: <20061028002130.BEDD115212E@buildsys.fedoraproject.org> Message-ID: <20061028181154.9cece57f.bugs.michael@gmx.net> On Fri, 27 Oct 2006 20:21:30 -0400 (EDT), buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 5: 4 > > Invalid rebuild: moodle-1.6.3-2.fc5 (!) > geomview-1.8.2-0.25.rc9.fc5 > mod_nss-1.0.6-1.fc5 > nagios-plugins-1.4.4-2.fc5 > > > Packages built and released for Fedora Extras 4: 1 > > Invalid rebuild: moodle-1.6.3-2.fc4 This is a rather new feature, which normally is quiet and does not add anything to the build report. It happens again and again for unknown reasons. It means that somebody has built a package release, which had been built and published before. The build results are discarded if any of the built rpms exists in the repository already. If you need to rebuild a package (i.e. recompile/relink the software against its build dependencies), do it right and increase the package %{release} appropriately to produce valid update packages. From ville.skytta at iki.fi Sat Oct 28 16:54:23 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 28 Oct 2006 19:54:23 +0300 Subject: rpms/wvs-data/devel wvs-data.spec,1.1,1.2 In-Reply-To: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> References: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> Message-ID: <1162054463.11104.17.camel@viper.local> On Sat, 2006-10-28 at 09:22 -0700, Mamoru Tasaka wrote: > Modified Files: > wvs-data.spec > Log Message: > * Sat Oct 28 2006 Mamoru Tasaka > - Add %{?dist} tag as buildsys forces this. No it doesn't, %{?dist} is and always has been optional. http://fedoraproject.org/wiki/Packaging/DistTag However some other way of managing proper EVRs between branches needs to be used if one chooses not to use it. From bugs.michael at gmx.net Sat Oct 28 17:06:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 19:06:19 +0200 Subject: rpms/wvs-data/FC-6 wvs-data.spec,1.1,1.2 In-Reply-To: <200610281623.k9SGNpdm016440@cvs-int.fedora.redhat.com> References: <200610281623.k9SGNpdm016440@cvs-int.fedora.redhat.com> Message-ID: <20061028190619.17c82bb6.bugs.michael@gmx.net> On Sat, 28 Oct 2006 09:23:51 -0700, Mamoru Tasaka (mtasaka) wrote: > Author: mtasaka > > Update of /cvs/extras/rpms/wvs-data/FC-6 > Log Message: > * Sat Oct 28 2006 Mamoru Tasaka > - Add %{?dist} tag as buildsys forces this. It doesn't. What makes you think so? > -Release: 2 > +Release: 2%{?dist} Actually, you don't want this at all. This is a 40M data package. Noarch even. Once built a single time, you would rather want this be hardlinked/copied to the other target distributions. And if no questionable rebuild policies forced you to rebuild this noarch package, you could keep it for a very long time without rebuilding it. From mtasaka at ioa.s.u-tokyo.ac.jp Sat Oct 28 17:03:24 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 02:03:24 +0900 Subject: rpms/wvs-data/devel wvs-data.spec,1.1,1.2 In-Reply-To: <1162054463.11104.17.camel@viper.local> References: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> <1162054463.11104.17.camel@viper.local> Message-ID: <45438D5C.8000300@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote: > On Sat, 2006-10-28 at 09:22 -0700, Mamoru Tasaka wrote: > >> Modified Files: >> wvs-data.spec >> Log Message: >> * Sat Oct 28 2006 Mamoru Tasaka >> - Add %{?dist} tag as buildsys forces this. > > No it doesn't, %{?dist} is and always has been optional. > http://fedoraproject.org/wiki/Packaging/DistTag > > However some other way of managing proper EVRs between branches needs to > be used if one chooses not to use it. > For this case, without this buildsys complained as following. --------------------------------------------------- cvs tag -c wvs-data-0_0_20020219-2 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs ERROR: The tag wvs-data-0_0_20020219-2 is already applied on a different branch ERROR: You can not forcibly move tags between branches wvs-data-0_0_20020219-2:devel:mtasaka:1161814318 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] error 1 ---------------------------------------------------- Mamoru Tasaka From ville.skytta at iki.fi Sat Oct 28 18:02:11 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 28 Oct 2006 21:02:11 +0300 Subject: rpms/wvs-data/devel wvs-data.spec,1.1,1.2 In-Reply-To: <45438D5C.8000300@ioa.s.u-tokyo.ac.jp> References: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> <1162054463.11104.17.camel@viper.local> <45438D5C.8000300@ioa.s.u-tokyo.ac.jp> Message-ID: <1162058531.11104.39.camel@viper.local> On Sun, 2006-10-29 at 02:03 +0900, Mamoru Tasaka wrote: > Ville Skytt? wrote: > > On Sat, 2006-10-28 at 09:22 -0700, Mamoru Tasaka wrote: > > > >> Modified Files: > >> wvs-data.spec > >> Log Message: > >> * Sat Oct 28 2006 Mamoru Tasaka > >> - Add %{?dist} tag as buildsys forces this. > > > > No it doesn't, %{?dist} is and always has been optional. > > http://fedoraproject.org/wiki/Packaging/DistTag > > > > However some other way of managing proper EVRs between branches needs to > > be used if one chooses not to use it. > > For this case, without this buildsys complained as following. CVS complained, not the buildsys. > cvs tag -c wvs-data-0_0_20020219-2 > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > ERROR: The tag wvs-data-0_0_20020219-2 is already applied on a different branch > ERROR: You can not forcibly move tags between branches Exactly. See the "However..." part in my previous reply. But more importantly, see Michael's reply about the unnecessity of the disttag in this case. From mmcgrath at fedoraproject.org Sat Oct 28 18:04:04 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 28 Oct 2006 13:04:04 -0500 Subject: Invalid rebuilds (was: Re: Fedora Extras Package Build Report 2006-10-27) In-Reply-To: <20061028181154.9cece57f.bugs.michael@gmx.net> References: <20061028002130.BEDD115212E@buildsys.fedoraproject.org> <20061028181154.9cece57f.bugs.michael@gmx.net> Message-ID: <3237e4410610281104y1d3486a9j210adb18d5ed06e5@mail.gmail.com> On 10/28/06, Michael Schwendt wrote: > On Fri, 27 Oct 2006 20:21:30 -0400 (EDT), buildsys at fedoraproject.org wrote: > > > Packages built and released for Fedora Extras 5: 4 > > > > Invalid rebuild: moodle-1.6.3-2.fc5 > > (!) > > > geomview-1.8.2-0.25.rc9.fc5 > > mod_nss-1.0.6-1.fc5 > > nagios-plugins-1.4.4-2.fc5 > > > > > > Packages built and released for Fedora Extras 4: 1 > > > > Invalid rebuild: moodle-1.6.3-2.fc4 > > This is a rather new feature, which normally is quiet and does not add > anything to the build report. It happens again and again for unknown > reasons. > > It means that somebody has built a package release, which had been built > and published before. The build results are discarded if any of the built > rpms exists in the repository already. > > If you need to rebuild a package (i.e. recompile/relink the software > against its build dependencies), do it right and increase the package > %{release} appropriately to produce valid update packages. Could this also happen if someone accidently did a make plague twice? -Mike From bugs.michael at gmx.net Sat Oct 28 18:30:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 20:30:44 +0200 Subject: Invalid rebuilds (was: Re: Fedora Extras Package Build Report 2006-10-27) In-Reply-To: <3237e4410610281104y1d3486a9j210adb18d5ed06e5@mail.gmail.com> References: <20061028002130.BEDD115212E@buildsys.fedoraproject.org> <20061028181154.9cece57f.bugs.michael@gmx.net> <3237e4410610281104y1d3486a9j210adb18d5ed06e5@mail.gmail.com> Message-ID: <20061028203044.6d2e9259.bugs.michael@gmx.net> On Sat, 28 Oct 2006 13:04:04 -0500, Mike McGrath wrote: > > > Packages built and released for Fedora Extras 5: 4 > > > > > > Invalid rebuild: moodle-1.6.3-2.fc5 > > > > (!) > > > > > geomview-1.8.2-0.25.rc9.fc5 > > > mod_nss-1.0.6-1.fc5 > > > nagios-plugins-1.4.4-2.fc5 > > > > > > > > > Packages built and released for Fedora Extras 4: 1 > > > > > > Invalid rebuild: moodle-1.6.3-2.fc4 > > > > This is a rather new feature, which normally is quiet and does not add > > anything to the build report. It happens again and again for unknown > > reasons. > > > > It means that somebody has built a package release, which had been built > > and published before. The build results are discarded if any of the built > > rpms exists in the repository already. > > > > If you need to rebuild a package (i.e. recompile/relink the software > > against its build dependencies), do it right and increase the package > > %{release} appropriately to produce valid update packages. > > Could this also happen if someone accidently did a make plague twice? Not if make plague is run twice within minutes. Only if build job #1 finishes and is published before build job #2 finishes and overwrites the results of job #1 (or vice versa depending on build speed). In this case, moodle-1.6.3-2.{fc4,fc5} were released on 23-Oct-2006 before. From buildsys at fedoraproject.org Sat Oct 28 18:47:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 28 Oct 2006 14:47:52 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-10-28 Message-ID: <20061028184752.534DA15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 16 azureus-2.5.0.0-8.fc7 chess-1.0-4.fc7 dircproxy-1.2.0-0.5.beta2.fc7 gaim-otr-3.0.1-0.3.20060921cvs.fc7 gcstar-0.5.0-4.fc7 gtksourceview-sharp-2.0-24.fc7 jack-audio-connection-kit-0.102.20-3.fc7 jd-1.8.0-0.3.cvs061028.fc7 licq-1.3.4-2 perl-Error-0.17008-1.fc7 perl-Module-ScanDeps-0.68-1.fc7 php-manual-en-20061026-1.fc7 php-pear-Log-1.9.9-1.fc7 scribes-0.2.9.89-3.fc7 wine-docs-0.9.24-1.fc7 wvs-data-0.0.20020219-2.fc7 Packages built and released for Fedora Extras 6: 16 anjuta-2.0.2-9.fc6 azureus-2.5.0.0-8.fc6 cvs2svn-1.5.0-1.fc6 dircproxy-1.2.0-0.5.beta2.fc6 gcstar-0.5.0-4.fc6 gtksourceview-sharp-2.0-24.fc6 jack-audio-connection-kit-0.102.20-3.fc6 perl-Module-ScanDeps-0.68-1.fc6 php-manual-en-20061026-1.fc6 php-pear-Log-1.9.9-1.fc6 scribes-0.2.9.89-1.fc6 wine-0.9.24-1.fc6 wine-docs-0.9.24-1.fc6 wv-1.2.4-1.fc6 wvs-data-0.0.20020219-2.fc6 yaz-2.1.36-1.fc6 Packages built and released for Fedora Extras 5: 12 cvs2svn-1.5.0-1.fc5 gcstar-0.5.0-4.fc5 gtksourceview-sharp-2.0-24.fc5 perl-Module-ScanDeps-0.68-1.fc5 php-manual-en-20061026-1.fc5 php-pear-Log-1.9.9-1.fc5 quilt-0.46-1.fc5 wine-0.9.24-1.fc5 wine-docs-0.9.24-1.fc5 wv-1.2.4-1.fc5 wvs-data-0.0.20020219-2.fc5 yaz-2.1.36-1.fc5 Packages built and released for Fedora Extras 4: 2 wine-0.9.24-1.fc4 wine-docs-0.9.24-1.fc4 Packages built and released for Fedora Extras 3: 2 wine-0.9.24-1.fc3 wine-docs-0.9.24-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 Oct 28 19:47:42 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 28 Oct 2006 19:47:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-28 Message-ID: <20061028194742.14892.86900@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-4.fc6.i386 blender - 2.42a-4.fc6.ppc blender - 2.42a-4.fc6.x86_64 andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-2.fc7.i386 (3 days) koffice-kivio - 1.6.0-2.fc7.i386 (3 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 libopensync-plugin-evolution2 - 0.19-1.fc6.ppc libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 orange - 0.3-3.cvs20051118.fc6.i386 (4 days) scribus - 1.3.3.4-1.fc6.i386 (4 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (28 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (28 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (28 days) bdpepple AT ameritech.net contact-lookup-applet - 0.15-1.fc6.i386 contact-lookup-applet - 0.15-1.fc6.ppc contact-lookup-applet - 0.15-1.fc6.x86_64 eds-feed - 0.5.0-5.fc6.i386 eds-feed - 0.5.0-5.fc6.ppc eds-feed - 0.5.0-5.fc6.x86_64 liferea - 1.0.25-1.fc7.i386 liferea - 1.0.25-1.fc7.ppc liferea - 1.0.25-1.fc7.x86_64 dcbw AT redhat.com csound - 5.03.0-7.fc7.i386 plague - 0.4.4.1-2.fc3.noarch (43 days) plague - 0.4.4.1-2.fc3.noarch (43 days) plague - 0.4.4.1-2.fc4.noarch (43 days) plague - 0.4.4.1-2.fc4.noarch (43 days) plague - 0.4.4.1-2.fc4.noarch (43 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 (4 days) fedora AT leemhuis.info mail-notification-evolution-plugin - 3.0-7.fc6.i386 mail-notification-evolution-plugin - 3.0-7.fc6.ppc mail-notification-evolution-plugin - 3.0-7.fc6.x86_64 gauret AT free.fr perl-Unicode-MapUTF8 - 1.09-6.fc5.noarch (5 days) showimg-pgsql - 0.9.5-10.fc4.i386 (5 days) showimg-pgsql - 0.9.5-10.fc4.ppc (5 days) showimg-pgsql - 0.9.5-10.fc4.x86_64 (5 days) showimg-pgsql - 0.9.5-10.fc5.i386 (5 days) showimg-pgsql - 0.9.5-10.fc5.ppc (5 days) showimg-pgsql - 0.9.5-10.fc5.x86_64 (5 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (3 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (3 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (3 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (19 days) linphone - 1.2.0-4.fc5.ppc (19 days) linphone - 1.2.0-4.fc5.x86_64 (19 days) linphone - 1.2.0-7.fc6.i386 (4 days) linphone - 1.2.0-7.fc6.ppc (4 days) linphone - 1.2.0-7.fc6.x86_64 (4 days) jkeating AT redhat.com contacts - 0.1-5.20060813svn.fc6.i386 contacts - 0.1-5.20060813svn.fc6.ppc contacts - 0.1-5.20060813svn.fc6.x86_64 dates - 0.1-4.20060813svn.fc6.i386 dates - 0.1-4.20060813svn.fc6.i386 dates - 0.1-4.20060813svn.fc6.ppc dates - 0.1-4.20060813svn.fc6.x86_64 lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 deskbar-applet - 2.16.0-1.fc6.ppc deskbar-applet - 2.16.0-1.fc6.x86_64 matt AT truch.net kst - 1.3.1-1.fc6.i386 (4 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (9 days) syck-php - 0.55-9.fc5.ppc (9 days) syck-php - 0.55-9.fc5.x86_64 (9 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 (4 days) plplot-gnome - 5.6.1-7.fc6.i386 (4 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc6.1.i386 (4 days) tcallawa AT redhat.com evolution-bogofilter - 0.2.0-3.fc6.i386 evolution-bogofilter - 0.2.0-3.fc6.ppc evolution-bogofilter - 0.2.0-3.fc6.x86_64 gambas-runtime - 1.0.17-3.fc6.i386 gambas-runtime - 1.0.17-3.fc6.ppc triad AT df.lth.se gnome-phone-manager - 0.8-3.fc6.i386 gnome-phone-manager - 0.8-3.fc6.ppc gnome-phone-manager - 0.8-3.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-4.fc6.ppc requires libgettextlib-0.14.6.so contact-lookup-applet-0.15-1.fc6.ppc requires libedataserver-1.2.so.7 contacts-0.1-5.20060813svn.fc6.ppc requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.ppc requires libedataserver-1.2.so.7 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 eds-feed-0.5.0-5.fc6.ppc requires libedataserver-1.2.so.7 evolution-bogofilter-0.2.0-3.fc6.ppc requires libedataserver-1.2.so.7 gambas-runtime-1.0.17-3.fc6.ppc requires libgettextlib-0.14.6.so gnome-phone-manager-0.8-3.fc6.ppc requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 liferea-1.0.25-1.fc7.ppc requires firefox = 0:1.5.0.7 mail-notification-evolution-plugin-3.0-7.fc6.ppc requires libedataserver-1.2.so.7 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-4.fc6.x86_64 requires libgettextlib-0.14.6.so()(64bit) contact-lookup-applet-0.15-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) contacts-0.1-5.20060813svn.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) csound-5.03.0-7.fc7.i386 requires libpython2.4.so.1.0 dates-0.1-4.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) eds-feed-0.5.0-5.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) evolution-bogofilter-0.2.0-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) gift-0.11.8.1-6.fc6.1.i386 requires libmagic.so.1 gnome-phone-manager-0.8-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) liferea-1.0.25-1.fc7.x86_64 requires firefox = 0:1.5.0.7 mail-notification-evolution-plugin-3.0-7.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-4.fc6.i386 requires libgettextlib-0.14.6.so contact-lookup-applet-0.15-1.fc6.i386 requires libedataserver-1.2.so.7 contacts-0.1-5.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 eds-feed-0.5.0-5.fc6.i386 requires libedataserver-1.2.so.7 evolution-bogofilter-0.2.0-3.fc6.i386 requires libedataserver-1.2.so.7 gambas-runtime-1.0.17-3.fc6.i386 requires libgettextlib-0.14.6.so gnome-phone-manager-0.8-3.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 liferea-1.0.25-1.fc7.i386 requires firefox = 0:1.5.0.7 mail-notification-evolution-plugin-3.0-7.fc6.i386 requires libedataserver-1.2.so.7 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.ppc requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) perl-Unicode-MapUTF8-1.09-6.fc5.noarch requires perl(Unicode::Map8) showimg-pgsql-0.9.5-10.fc5.x86_64 requires libpqxx-2.6.7.so()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 showimg-pgsql-0.9.5-10.fc5.i386 requires libpqxx-2.6.7.so syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.ppc requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.x86_64 requires libpqxx-2.6.7.so()(64bit) sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 showimg-pgsql-0.9.5-10.fc4.i386 requires libpqxx-2.6.7.so sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-evolution2 - 0.19-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7 package: libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: libopensync-plugin-evolution2 - 0.19-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libetpan.so.6 package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libetpan.so.6()(64bit) package: sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libetpan.so.6 ====================================================================== New report for: triad AT df.lth.se package: gnome-phone-manager - 0.8-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: gnome-phone-manager - 0.8-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: gnome-phone-manager - 0.8-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-2.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== New report for: jkeating AT redhat.com package: dates - 0.1-4.20060813svn.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: contacts - 0.1-5.20060813svn.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: dates - 0.1-4.20060813svn.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7 package: dates - 0.1-4.20060813svn.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: contacts - 0.1-5.20060813svn.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: contacts - 0.1-5.20060813svn.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 package: dates - 0.1-4.20060813svn.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 ====================================================================== New report for: tcallawa AT redhat.com package: evolution-bogofilter - 0.2.0-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: evolution-bogofilter - 0.2.0-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: evolution-bogofilter - 0.2.0-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 ====================================================================== New report for: lmacken AT redhat.com package: deskbar-applet - 2.16.0-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: deskbar-applet - 2.16.0-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: deskbar-applet - 2.16.0-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 ====================================================================== New report for: fedora AT leemhuis.info package: mail-notification-evolution-plugin - 3.0-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: mail-notification-evolution-plugin - 3.0-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: mail-notification-evolution-plugin - 3.0-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 ====================================================================== New report for: bdpepple AT ameritech.net package: liferea - 1.0.25-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: firefox = 0:1.5.0.7 package: contact-lookup-applet - 0.15-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: eds-feed - 0.5.0-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libedataserver-1.2.so.7 package: liferea - 1.0.25-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: firefox = 0:1.5.0.7 package: eds-feed - 0.5.0-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: contact-lookup-applet - 0.15-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libedataserver-1.2.so.7()(64bit) package: contact-lookup-applet - 0.15-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 package: liferea - 1.0.25-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: firefox = 0:1.5.0.7 package: eds-feed - 0.5.0-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libedataserver-1.2.so.7 From bugs.michael at gmx.net Sat Oct 28 19:58:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Oct 2006 21:58:16 +0200 Subject: wvs-data (was: Re: Fedora Extras Package Build Report 2006-10-28) In-Reply-To: <20061028184752.534DA15212E@buildsys.fedoraproject.org> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> Message-ID: <20061028215816.592551a9.bugs.michael@gmx.net> On Sat, 28 Oct 2006 14:47:52 -0400 (EDT), buildsys wrote: > wvs-data-0.0.20020219-2.fc7 > wvs-data-0.0.20020219-2.fc6 > wvs-data-0.0.20020219-2.fc5 =:-O 1) It makes no sense to build this as long as XTide and friends are not approved. 2) You now have rushed into a situation I doubt you really appreciate. This 40M huge noarch data package is listed as a dependency of XTide. When upgrading from FC5 to FC6, your XTide users will need to update 40M without any change in the data. And the same again when they would upgrade from FC6 to Rawhide. From lists at timj.co.uk Sat Oct 28 20:51:06 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 28 Oct 2006 21:51:06 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162047938.3139.24.camel@vader.jdub.homelinux.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> Message-ID: <4543C2BA.9000206@timj.co.uk> Josh Boyer wrote: > That being said, my personal opinion is that "beta" or pre-release > packages should only be done in the devel branch, and only if that beta > has a really good chance of becoming an actual release before the devel > branch is forked for the next Extras release. This to me is the best argument for something *like* a "testing" repo I've seen. I've never been convinced about the whole "testing" thing to date, but I can see a limited use for some packages (especially big ones with long release cycles and beta/RC periods) where regular users might want to use the latest and greatest but it wouldn't be appropriate to put it into devel, which might of course become a release branch. In fact even if there's any doubt about whether the package might not be ready for the next release (e.g. close to FC7 branch) it makes it awkward for the maintainer because you they potentially have to revert devel (go backwards)and undo good work if it turned out the package wasn't quite ready in time for a branch, which isn't ideal. It makes more sense in my head if you call "testing" something like "bleeding edge". Tim From giallu at gmail.com Sat Oct 28 20:54:41 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 28 Oct 2006 22:54:41 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162047938.3139.24.camel@vader.jdub.homelinux.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> Message-ID: On 10/28/06, Josh Boyer wrote: > On Sat, 2006-10-28 at 16:58 +0200, Michael Schwendt wrote: > > On Wed, 25 Oct 2006 09:56:09 +0200, Axel Thimm wrote: > > > > This topic came to a sudden end on the same day it was started, without a > > clear resolution and without any conclusion on whether including beta > > versions of some software is "okay" in this case. > > > > Has FESCo looked into this? > > No. And I don't think we should. > > Theoretically, the maintainers of the packages know best as to how > stable the software they are packaging is, what the timeline for said > beta is to reach production, etc. If another maintainer questions this, > then open a bug report against the package explaining why. I agree. It's not FESCO's call to decide if a given package is OK even if beta. > > That being said, my personal opinion is that "beta" or pre-release > packages should only be done in the devel branch, and only if that beta > has a really good chance of becoming an actual release before the devel > branch is forked for the next Extras release. This seems sane, and IMHO could be formalized in the packaging guidelines, at least as a SHOULD item. > > As for the third party repo aspect of this, that is quite difficult. > There are potentially tons of third party repos, which already conflict > with each other. We cannot show preference for one or the other. That > does not mean that a third party repository maintainer cannot open a > bug. It just means that we cannot expect Extras maintainers to go > looking for problems in each and every third party repo before updating > something. > Axel made clear he was not seeking for any kind of "preference" for its own repo. However, he raised another interesting topic, stating that he felt the package was "blitz reviewed": so, why don't we add a fixed delay from a given point in the review ( for example, from the last update to the package, or from putting FE-ACCEPT on it). This could give enough time to interested parties for joining the review and commenting _before_ the package is imported and built. From lists at timj.co.uk Sat Oct 28 21:01:06 2006 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 28 Oct 2006 22:01:06 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> Message-ID: <4543C512.9090107@timj.co.uk> Gianluca Sforna wrote: > However, he raised another interesting topic, stating that he felt the > package was "blitz reviewed": so, why don't we add a fixed delay from > a given point in the review ( for example, from the last update to the > package, or from putting FE-ACCEPT on it). I'm not sure this is a great idea unless $fixed_delay is quite short. It may add unnecessary/pointless/irritating delays to trivial or uncontentious packages. What might be more useful in terms of soliciting opinion would be some kind of notification to fedora-extras-list when the package request is first submitted (but no subsequent Bugzilla noise), to gain a wider audience and attention to the fact that a particular package is being proposed. Tim From Axel.Thimm at ATrpms.net Sat Oct 28 21:10:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Oct 2006 23:10:22 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <454375C3.5020507@leemhuis.info> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> Message-ID: <20061028211022.GB19403@neu.nirvana> On Sat, Oct 28, 2006 at 05:22:43PM +0200, Thorsten Leemhuis wrote: > Josh Boyer schrieb: > > As for the third party repo aspect of this, that is quite difficult. > > There are potentially tons of third party repos, which already conflict > > with each other. We cannot show preference for one or the other. That > > does not mean that a third party repository maintainer cannot open a > > bug. It just means that we cannot expect Extras maintainers to go > > looking for problems in each and every third party repo before updating > > something. > > +1 I think this is a dangerous attitude. W/o going into ugly details I believe the reason that Fedora has such a cluttered 3rd party repository support in comparison to all other distros is just because of that historic strategic and tactical errors (IMO) that were at the beginning of the project alienating most 3rd party repositories. The last years have shown that this can be undone, but unfortunately at a slow pace, and with often setbacks. In order to close the gaps in the community you need to follow embracement politics, not (actively) ignore and alienate parts of it. It was just a few days ago that someone ranted about a 3rd party repo forking Fedora, and this is just an example which shows that the actors are reversed. I deliberately left off details to not micro-discuss again about repo foorpms and package bar and baz, I'm just targetting the big picture. -- 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 Sat Oct 28 21:11:32 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 28 Oct 2006 23:11:32 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4543C512.9090107@timj.co.uk> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <4543C512.9090107@timj.co.uk> Message-ID: On 10/28/06, Tim Jackson wrote: > Gianluca Sforna wrote: > > > However, he raised another interesting topic, stating that he felt the > > package was "blitz reviewed": so, why don't we add a fixed delay from > > a given point in the review ( for example, from the last update to the > > package, or from putting FE-ACCEPT on it). > > I'm not sure this is a great idea unless $fixed_delay is quite short. It > may add unnecessary/pointless/irritating delays to trivial or > uncontentious packages. True. I was thinking something like a week > > What might be more useful in terms of soliciting opinion would be some > kind of notification to fedora-extras-list when the package request is > first submitted (but no subsequent Bugzilla noise), to gain a wider > audience and attention to the fact that a particular package is being > proposed. Or an RSS feed... From Axel.Thimm at ATrpms.net Sat Oct 28 21:18:04 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Oct 2006 23:18:04 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4543C512.9090107@timj.co.uk> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <4543C512.9090107@timj.co.uk> Message-ID: <20061028211804.GC19403@neu.nirvana> On Sat, Oct 28, 2006 at 10:01:06PM +0100, Tim Jackson wrote: > Gianluca Sforna wrote: > > >However, he raised another interesting topic, stating that he felt the > >package was "blitz reviewed": so, why don't we add a fixed delay from > >a given point in the review ( for example, from the last update to the > >package, or from putting FE-ACCEPT on it). The blitz-review by itself is not wrong, but the synergy of blitz-review & beta-software & untested software (because only the dependencies made the review and the main application package itself is known to have upstream issues at the current beta version) well that makes is a no-go. After all at the very least the beta dependencies have proved to break the non-beta application package, but at run and build time, so one wanders what good are they at all? > I'm not sure this is a great idea unless $fixed_delay is quite short. It > may add unnecessary/pointless/irritating delays to trivial or > uncontentious packages. > > What might be more useful in terms of soliciting opinion would be some > kind of notification to fedora-extras-list when the package request is > first submitted (but no subsequent Bugzilla noise), to gain a wider > audience and attention to the fact that a particular package is being > proposed. Or maybe a package going beta/pre/anything non-release should require a second reviewer. As well as an already submitted package suddenly going beta should have s/o's blessing - currently if I package foo-1.0 and it passes review I could properly upgrade to foo-2.0-0.bleeding1 on the next day w/o anyone noticing before it's too late. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Oct 28 21:18:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Oct 2006 23:18:34 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061025161214.GB8122@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> <20061025161214.GB8122@neu.nirvana> Message-ID: <20061028211834.GD19403@neu.nirvana> On Wed, Oct 25, 2006 at 06:12:14PM +0200, Axel Thimm wrote: > On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > > Even if I had stayed with 1.2.X packages there would have been problems > > coexisting with the atrpms repository... > > Why? This only happens if you ignore that these packages exist > and are used by a large number of people. No answer on this 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 seg at haxxed.com Sat Oct 28 21:19:09 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 28 Oct 2006 16:19:09 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4543C512.9090107@timj.co.uk> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <4543C512.9090107@timj.co.uk> Message-ID: <1162070349.12610.59.camel@localhost.localdomain> On Sat, 2006-10-28 at 22:01 +0100, Tim Jackson wrote: > What might be more useful in terms of soliciting opinion would be some > kind of notification to fedora-extras-list when the package request is > first submitted (but no subsequent Bugzilla noise), to gain a wider > audience and attention to the fact that a particular package is being > proposed. +1 !!!!! I'm 12143 messages behind in fedora-package-review. I gave up on trying to keep up long ago. Also, I'd like an rss feed/mailing list for every new package that hits the repo. Rather than every single package update. End users would probably be interested in such a thing too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Sat Oct 28 21:43:40 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 28 Oct 2006 16:43:40 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061028211022.GB19403@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> Message-ID: <1162071820.3139.39.camel@vader.jdub.homelinux.org> On Sat, 2006-10-28 at 23:10 +0200, Axel Thimm wrote: > On Sat, Oct 28, 2006 at 05:22:43PM +0200, Thorsten Leemhuis wrote: > > Josh Boyer schrieb: > > > As for the third party repo aspect of this, that is quite difficult. > > > There are potentially tons of third party repos, which already conflict > > > with each other. We cannot show preference for one or the other. That > > > does not mean that a third party repository maintainer cannot open a > > > bug. It just means that we cannot expect Extras maintainers to go > > > looking for problems in each and every third party repo before updating > > > something. > > > > +1 > > I think this is a dangerous attitude. W/o going into ugly details I > believe the reason that Fedora has such a cluttered 3rd party > repository support in comparison to all other distros is just because > of that historic strategic and tactical errors (IMO) that were at the > beginning of the project alienating most 3rd party repositories. Let me put it this way. If third party repositories had no conflicting packages with either Core, Extras, or _each other_, I personally might consider trying to take them into account. But that will _never_ happen. And trying to take them all into account when updating packages is just pain. However, that doesn't mean that people can't try to take them into account. I'm sure some people try and do succeed in checking various third party repositories before updating things. I applaud them for their efforts. I just don't see how it's justifiable to _require_ it to be done by all maintainers. > The last years have shown that this can be undone, but unfortunately > at a slow pace, and with often setbacks. In order to close the gaps in > the community you need to follow embracement politics, not (actively) > ignore and alienate parts of it. I think we both agree that the embracement (good word) needs to go both ways. Not overriding Core/Extras packages is a good start. It makes cross-repo verification easier. > > It was just a few days ago that someone ranted about a 3rd party repo > forking Fedora, and this is just an example which shows that the > actors are reversed. Sorry, I don't follow here. I fail to see how this is the opposite of that other discussion. (Remember, the above are all just my opinions. I'm not speaking for FESCo.) josh From bugs.michael at gmx.net Sat Oct 28 22:13:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 00:13:27 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> Message-ID: <20061029001327.c3cb62e5.bugs.michael@gmx.net> On Sat, 28 Oct 2006 22:54:41 +0200, Gianluca Sforna wrote: > > Theoretically, the maintainers of the packages know best as to how > > stable the software they are packaging is, what the timeline for said > > beta is to reach production, etc. If another maintainer questions this, > > then open a bug report against the package explaining > > I agree. It's not FESCO's call to decide if a given package is OK even if beta. Almost funny, given that we don't do any mandatory run-time testing during the review process. It's not that easy to say "packagers know best". If that were the case, we could kill the reviewing. The question is whether we want to open the flood-gates by setting precedence and letting in many other pre-release versions, effectively moving closer to the bleeding edge? When some people ask whether anything is wrong with a beta, it is equally valid to ask what's wrong with the last official stable release? Where are the answers to both questions? > > That being said, my personal opinion is that "beta" or pre-release > > packages should only be done in the devel branch, and only if that beta > > has a really good chance of becoming an actual release before the devel > > branch is forked for the next Extras release. > > This seems sane, and IMHO could be formalized in the packaging > guidelines, at least as a SHOULD item. I'd rather be more rigorous and require packagers and reviewers to explain why a pre-release version or VCS snapshot is preferred over a stable release. This ought to be part of the approval process and also be required during package maintenance. It would not be the first time somebody wanted to package a beta release way too early and without good reason. One example from the top of my head is Audacity. It even segfaulted reproducibly when built without mp3 support. Back in time, where did most repository mixing problems come from? Correct. Not just from providing the same packages in different repositories. Packaging conflicting ABIs and APIs lead to the most repo mixing problems. > Axel made clear he was not seeking for any kind of "preference" for > its own repo. > > However, he raised another interesting topic, stating that he felt the > package was "blitz reviewed": Do you disagree? I don't. Less than 24 hours between a sudden upgrade to a beta version and its approval. Plus the worst fact: The other packages in the dependency-chain are not ready yet. From bugs.michael at gmx.net Sat Oct 28 22:27:46 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 00:27:46 +0200 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162070349.12610.59.camel@localhost.localdomain> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <4543C512.9090107@timj.co.uk> <1162070349.12610.59.camel@localhost.localdomain> Message-ID: <20061029002746.19bcb7d5.bugs.michael@gmx.net> On Sat, 28 Oct 2006 16:19:09 -0500, Callum Lerwick wrote: > On Sat, 2006-10-28 at 22:01 +0100, Tim Jackson wrote: > > What might be more useful in terms of soliciting opinion would be some > > kind of notification to fedora-extras-list when the package request is > > first submitted (but no subsequent Bugzilla noise), to gain a wider > > audience and attention to the fact that a particular package is being > > proposed. > > +1 !!!!! I'm 12143 messages behind in fedora-package-review. I gave up > on trying to keep up long ago. > > Also, I'd like an rss feed/mailing list for every new package that hits > the repo. Rather than every single package update. End users would > probably be interested in such a thing too. One of the most crucial aspects of the package review process is that we want packages in the distribution which work actually, NOT to be misunderstood as "we approve something to let it in and then the packager can do with the package what he wants and needs no stinking reviews anymore". The reviewing is still considered a hurdle, a bottleneck. In some people's minds, Fedora Extras doesn't grow quickly enough. This is dangerous. We must be able to rely on the reviewers to only approve something which is usable. This is particularly important when there are dependencies, which still wait for approval. From chris.stone at gmail.com Sat Oct 28 22:53:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 28 Oct 2006 15:53:26 -0700 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162071820.3139.39.camel@vader.jdub.homelinux.org> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <454375C3.5020507@leemhuis.info> <20061028211022.GB19403@neu.nirvana> <1162071820.3139.39.camel@vader.jdub.homelinux.org> Message-ID: On 10/28/06, Josh Boyer wrote: > On Sat, 2006-10-28 at 23:10 +0200, Axel Thimm wrote: > > It was just a few days ago that someone ranted about a 3rd party repo > > forking Fedora, and this is just an example which shows that the > > actors are reversed. > > Sorry, I don't follow here. I fail to see how this is the opposite of > that other discussion. I *think* the point he is trying to make is that some people don't like 3rd party repositories overriding Fedora Extras without good reason and some other people dont like Fedora Extras maintainers adding packages in Fedora Extras without first consulting with the 3rd party repositories. Which goes back to my original idea of having an official Fedora wiki page that lists 3rd party repositories. Fedora Extras maintainers could then check this wiki page to find out which repositories might already have a package available for the package they want to submit. The wiki page will also have information such as which repositories have a review or QA process, which repositories override core or extras (and if they do override these packages, is there a specific reason for them to do so). As well as any other additional information which is required to inform other users of such repositories. From jeff at ocjtech.us Sun Oct 29 00:57:22 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 28 Oct 2006 19:57:22 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061028211834.GD19403@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> <20061025161214.GB8122@neu.nirvana> <20061028211834.GD19403@neu.nirvana> Message-ID: <1162083442.2866.18.camel@lt21223.campus.dmacc.edu> On Sat, 2006-10-28 at 23:18 +0200, Axel Thimm wrote: > On Wed, Oct 25, 2006 at 06:12:14PM +0200, Axel Thimm wrote: > > On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > > > Even if I had stayed with 1.2.X packages there would have been problems > > > coexisting with the atrpms repository... > > > > Why? This only happens if you ignore that these packages exist > > and are used by a large number of people. > > No answer on this one? If atrpms and FE both have asterisk packages it would be difficult to use both repos at the same time. In any case, the fact that a package exists in another repo is not a good enough reason to keep it out of FE. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Sun Oct 29 01:37:50 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 28 Oct 2006 20:37:50 -0500 Subject: comps.xml in Extras In-Reply-To: <45437162.8060203@leemhuis.info> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <20061028164705.87a73b2e.bugs.michael@gmx.net> <45437162.8060203@leemhuis.info> Message-ID: <200610282037.50873.dennis@ausil.us> On Saturday 28 October 2006 10:04 am, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Sat, 28 Oct 2006 15:39:04 +0200, Thorsten Leemhuis wrote: > >>>> Are we using comps yet for repoview? That might make repoview more > >>>> worthwhile, but probably still not for debuginfo. > >>> > >>> Hmmm, that's a different topic, though. I've found this: > >>> http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly > >>> Can anybody give a status update on that, please? > >> > >> dgilmore asked jeremy for details how to realize it when they branched > >> Extras for FC6. Don't know how far the real work went after that. > > > > Private conversation? Or another mailing-list? > > FESCo meeting. But is was some months ago. Should be in the archives and > in the summaries that were posted to the list. make comps did not work. and i haven't had a chance to look at why yet. -- Dennis Gilmore, RHCE Proud Australian From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 29 05:02:26 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 14:02:26 +0900 Subject: wvs-data In-Reply-To: <20061028215816.592551a9.bugs.michael@gmx.net> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> <20061028215816.592551a9.bugs.michael@gmx.net> Message-ID: <454435E2.5060707@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Sat, 28 Oct 2006 14:47:52 -0400 (EDT), buildsys wrote: > >> wvs-data-0.0.20020219-2.fc7 >> wvs-data-0.0.20020219-2.fc6 >> wvs-data-0.0.20020219-2.fc5 > > =:-O > Well, would you tell me exactly what I should do to avoid adding %%dist tag? It seems that CVS server refuses to "make tag" as "You can not forcibly move tags between branches". For this case tagging was not needed? Or is there any way to just "copy" noarch.rpm on FE-devel branch to another branch? Mamoru From kevin.kofler at chello.at Sun Oct 29 05:23:42 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Oct 2006 05:23:42 +0000 (UTC) Subject: Heads-up: mono-basic Message-ID: I just happened to notice mono-basic was silently dropped from Core when upstream recently split it out of the mono distribution. So if anyone is interested, someone will have to maintain in Extras. (Maybe the monodevelop maintainer?) Kevin Kofler From kevin.kofler at chello.at Sun Oct 29 05:26:01 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Oct 2006 05:26:01 +0000 (UTC) Subject: Heads-up: mono-basic References: Message-ID: Note that this also affects FC6, not just Rawhide. Kevin Kofler From j.w.r.degoede at hhs.nl Sun Oct 29 07:37:06 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 08:37:06 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029001327.c3cb62e5.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> Message-ID: <45445A22.9070301@hhs.nl> Michael Schwendt wrote: > It's not that easy to say "packagers know best". If that were the case, we > could kill the reviewing. The question is whether we want to open the > flood-gates by setting precedence and letting in many other pre-release > versions, effectively moving closer to the bleeding edge? > Sure it is that easy, because the packager should now best, can we please leave some (plenty of room actually) in all our procedures for the packagers discretion. Sometimes a beta release is better, because for example it fixes a few big bugs in the latest stable, but upstream wants to fix a last bug (which is also in the latest stable) before releasing a new stable. I've even had BZ requests requesting an update to the beta. Or the beta is the only version which works with the latest stable version of libfoo, where as the latest stable requires an older version of libfoo which isn't in core/extras. > When some people ask whether anything is wrong with a beta, it is equally > valid to ask what's wrong with the last official stable release? Where are > the answers to both questions? > Exactly who says that the beta has more bugs / problems then the latest stable, since its newer its supposed to be an improvement, this can be in features but also in bugcount. For example I would expect a 1.0.1 RC to be better then 1.0.0 for most products, so which do I package? > I'd rather be more rigorous and require packagers and reviewers to explain > why a pre-release version or VCS snapshot is preferred over a stable > release. > During initial review sure! > This ought to be part of the approval process and also be required during > package maintenance. > NO, we currently trust the packages todo the right thing wants a package has passed review and in case of grave error / unfixed bugs we have the AWOL policy, that should be enough. > It would not be the first time somebody wanted to package a beta release > way too early and without good reason. One example from the top of my head > is Audacity. It even segfaulted reproducibly when built without mp3 > support. > Yes, so we need high quality packagers, we need to educate them, no system is 100% error free, adding layer upon layer of procedures in practice hardly makes any difference in quality, in many cases it actually makes things worse, since people are spending time fighting procedures instead of fixing / improving things. Trust me on this I work for a Dutch university and bureaucracy is killing our educational system! And worse bureaucracy allows disfunctional teachers to hide behind it and blame all the procedures, leaving them in place where in the old days they would have lost there jobs and be replaced with a better teacher. We need motivated packagers with an awereness of these issues. If you put everything in procedures, you are asking for packagers which will hide behind those procedures they will say: "I followed the procedure for beta software so I did nothing wrong", even though there way to bleeding edge package caused major havoc! Its quite simple: motivated and educated packagers good, bureaucracy bad! Regards, Hans From ville.skytta at iki.fi Sun Oct 29 08:06:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 29 Oct 2006 10:06:56 +0200 Subject: wvs-data In-Reply-To: <454435E2.5060707@ioa.s.u-tokyo.ac.jp> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> <20061028215816.592551a9.bugs.michael@gmx.net> <454435E2.5060707@ioa.s.u-tokyo.ac.jp> Message-ID: <1162109216.11104.55.camel@viper.local> On Sun, 2006-10-29 at 14:02 +0900, Mamoru Tasaka wrote: > Or is there any way > to just "copy" noarch.rpm on FE-devel branch to another > branch? http://fedoraproject.org/wiki/Extras/RepoRequests From paul at all-the-johnsons.co.uk Sun Oct 29 08:39:04 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 29 Oct 2006 08:39:04 +0000 Subject: Heads-up: mono-basic In-Reply-To: References: Message-ID: <1162111144.29366.2.camel@T7.Linux> Hi, > I just happened to notice mono-basic was silently dropped from Core when > upstream recently split it out of the mono distribution. So if anyone is > interested, someone will have to maintain in Extras. (Maybe the monodevelop > maintainer?) mono-basic was spilt out as it was basically very broken come the 1.1.17 release. If alexl doesn't want to bring it back into Core when things restabilise, I'm more than happy to take it to extras. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 Sun Oct 29 09:51:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 29 Oct 2006 10:51:15 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162083442.2866.18.camel@lt21223.campus.dmacc.edu> References: <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> <20061025161214.GB8122@neu.nirvana> <20061028211834.GD19403@neu.nirvana> <1162083442.2866.18.camel@lt21223.campus.dmacc.edu> Message-ID: <20061029095115.GC5357@neu.nirvana> On Sat, Oct 28, 2006 at 07:57:22PM -0500, Jeffrey C. Ollie wrote: > On Sat, 2006-10-28 at 23:18 +0200, Axel Thimm wrote: > > On Wed, Oct 25, 2006 at 06:12:14PM +0200, Axel Thimm wrote: > > > On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > > > > Even if I had stayed with 1.2.X packages there would have been problems > > > > coexisting with the atrpms repository... > > > > > > Why? This only happens if you ignore that these packages exist > > > and are used by a large number of people. > > > > No answer on this one? > > If atrpms and FE both have asterisk packages it would be difficult to > use both repos at the same time. In any case, the fact that a package > exists in another repo is not a good enough reason to keep it out of FE. But it would make sense to provide an upgrade path or seek any kind of coordination, or not? Instead the situation you created is that neither non-ATrpms users, nor ATrpms users could make any use of asterisk at all. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Sun Oct 29 09:53:54 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 29 Oct 2006 10:53:54 +0100 Subject: SH fingerprints for FE machines Message-ID: <20061029105354.5074d897@lain> Hi. Is there an official place that lists the SSH keys for the machines used by the Fedora project that are accessible via SSH? Especially I am interested in the fingerprint for cvs.fedora.redhat.com. From Axel.Thimm at ATrpms.net Sun Oct 29 10:04:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 29 Oct 2006 11:04:20 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <45445A22.9070301@hhs.nl> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> Message-ID: <20061029100420.GD5357@neu.nirvana> On Sun, Oct 29, 2006 at 08:37:06AM +0100, Hans de Goede wrote: > Michael Schwendt wrote: > >When some people ask whether anything is wrong with a beta, it is > >equally valid to ask what's wrong with the last official stable > >release? Where are the answers to both questions? > > Exactly who says that the beta has more bugs / problems then the > latest stable, since its newer its supposed to be an improvement, > this can be in features but also in bugcount. > > For example I would expect a 1.0.1 RC to be better then 1.0.0 for > most products, so which do I package? I think this is quite easy to answer: If the software is labeled as beta/pre/cvs/svn/rc in fact anything non-released, then upstream obviously considers this software not ready for mass distribution. There are exceptions to this rule like some projects that never release or release every few millenia and explicitely ask to use their VCS, but these are indeed the exception and it's straightforward to fulfill Michael's request, e.g. "packaging from CVS due to upstream recommending doing so instead of using the old release version". Where packagers should really offer an explanation is when upstream has a sensible release cycle, doesn't recommend jumping on VCS or betas and still the packager sees a need to package non-released software. -- 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 paul at all-the-johnsons.co.uk Sun Oct 29 10:43:43 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 29 Oct 2006 10:43:43 +0000 Subject: Heads-up: mono-basic In-Reply-To: <1162111144.29366.2.camel@T7.Linux> References: <1162111144.29366.2.camel@T7.Linux> Message-ID: <1162118623.29366.16.camel@T7.Linux> On Sun, 2006-10-29 at 08:39 +0000, Paul wrote: > Hi, > > > I just happened to notice mono-basic was silently dropped from Core when > > upstream recently split it out of the mono distribution. So if anyone is > > interested, someone will have to maintain in Extras. (Maybe the monodevelop > > maintainer?) > > mono-basic was spilt out as it was basically very broken come the 1.1.17 > release. > > If alexl doesn't want to bring it back into Core when things > restabilise, I'm more than happy to take it to extras. As a follow up, the zip file available from the mono sources is, um, not compilable, so until it's sorted, we're pretty much without mono-basic. The good news though is that mono 1.2 will be out shortly, so hopefully that will hit rawhide in the very near future. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Oct 29 10:43:42 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 29 Oct 2006 11:43:42 +0100 Subject: rpms/wvs-data/devel wvs-data.spec,1.1,1.2 In-Reply-To: <1162054463.11104.17.camel@viper.local> References: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> <1162054463.11104.17.camel@viper.local> Message-ID: <20061029114342.1231ae2e@python3.es.egwn.lan> Ville Skytt? wrote : > On Sat, 2006-10-28 at 09:22 -0700, Mamoru Tasaka wrote: > > > Modified Files: > > wvs-data.spec > > Log Message: > > * Sat Oct 28 2006 Mamoru Tasaka > > - Add %{?dist} tag as buildsys forces this. > > No it doesn't, %{?dist} is and always has been optional. > http://fedoraproject.org/wiki/Packaging/DistTag > > However some other way of managing proper EVRs between branches needs to > be used if one chooses not to use it. It's worth pointing out also that %%{?dist} is probably what you wanted to use in the %changelog since otherwise it will get expanded and the binary package's changelog will contain "Add .fc7 tag as...". Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Rawhide) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.45 0.22 0.07 From kevin.kofler at chello.at Sun Oct 29 10:55:53 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Oct 2006 10:55:53 +0000 (UTC) Subject: Heads-up: mono-basic References: <1162111144.29366.2.camel@T7.Linux> <1162118623.29366.16.camel@T7.Linux> Message-ID: Paul writes: > As a follow up, the zip file available from the mono sources is, um, not > compilable, so until it's sorted, we're pretty much without mono-basic. Oh great... That explains why it hasn't been packaged. ;-) Kevin Kofler From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 29 11:08:09 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 20:08:09 +0900 Subject: rpms/wvs-data/devel wvs-data.spec,1.1,1.2 In-Reply-To: <20061029114342.1231ae2e@python3.es.egwn.lan> References: <200610281622.k9SGMjGb016413@cvs-int.fedora.redhat.com> <1162054463.11104.17.camel@viper.local> <20061029114342.1231ae2e@python3.es.egwn.lan> Message-ID: <45448B99.2070700@ioa.s.u-tokyo.ac.jp> Matthias Saou wrote: >>> Modified Files: >>> wvs-data.spec >>> Log Message: >>> * Sat Oct 28 2006 Mamoru Tasaka >>> - Add %{?dist} tag as buildsys forces this. > > It's worth pointing out also that %%{?dist} is probably what you wanted > to use in the %changelog since otherwise it will get expanded and the > binary package's changelog will contain "Add .fc7 tag as...". > > Matthias I wrote %%{?dist} to changelog and "make clog" changed it to %{?dist} (without original spec file unchanged). Mamoru From bugs.michael at gmx.net Sun Oct 29 11:35:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 12:35:20 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <45445A22.9070301@hhs.nl> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> Message-ID: <20061029123520.aa99832c.bugs.michael@gmx.net> On Sun, 29 Oct 2006 08:37:06 +0100, Hans de Goede wrote: > > It's not that easy to say "packagers know best". If that were the case, we > > could kill the reviewing. The question is whether we want to open the > > flood-gates by setting precedence and letting in many other pre-release > > versions, effectively moving closer to the bleeding edge? > > Sure it is that easy, because the packager should now best, can we please > leave some (plenty of room actually) in all our procedures for the packagers > discretion. Sometimes a beta release is better, because for example it fixes > a few big bugs in the latest stable, but upstream wants to fix a last bug (which > is also in the latest stable) before releasing a new stable. > > I've even had BZ requests requesting an update to the beta. Or the beta is the only > version which works with the latest stable version of libfoo, where as the latest stable > requires an older version of libfoo which isn't in core/extras. Splitting-hairs. Can we please leave corner-cases out of this? We are interested in the _general guidelines_, NOT in corner-cases. When you see me using the plural instead of the singular this still is because _we_ at the Fedora Extras project should have many common interests. And not landing in guinea-pig hell (and API/ABI breakage hell) because of too many pre-release packages should be one of our interest. [Sure, with some upstream projects you can often check out a product from VCS which is nothing else than last stable release plus a few minor fixes applied on the road to a future stable update. I've been there before, too. I've even skipped a new stable release, because my package including various patches offered exactly the same than another stable release, except for the increase minor version.] > > When some people ask whether anything is wrong with a beta, it is equally > > valid to ask what's wrong with the last official stable release? Where are > > the answers to both questions? > > > > Exactly who says that the beta has more bugs / problems then the latest stable, since its > newer its supposed to be an improvement, this can be in features but also in bugcount. > > For example I would expect a 1.0.1 RC to be better then 1.0.0 for most products, so which > do I package? In general? Stick to 1.0.0 unless you give good reason as why the RC is superior. It depends on the size and contents of the diff between 1.0.0 and 1.0.1 RC and also depends on the reasons why upstream finds it necessary to publish the code as a RC instead of simply declaring it gold. > > I'd rather be more rigorous and require packagers and reviewers to explain > > why a pre-release version or VCS snapshot is preferred over a stable > > release. > > > > During initial review sure! Aha. Can this be counted as a +1 then? ;) After approval the reviewing is not over. The package maintainer becomes the primary reviewer, often the only reviewer until a package is built and users start testing it. This must not mean that a stable release is used to pass the review process only to upgrade to a beta afterwards without giving good reason. Right? > Its quite simple: motivated and educated packagers good, bureaucracy bad! Motivation is a rather vague term here. Too much "wrong motivation" can easily lead to over-ambitious packaging and then is bad, too. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 29 11:55:10 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 20:55:10 +0900 Subject: wvs-data In-Reply-To: <1162109216.11104.55.camel@viper.local> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> <20061028215816.592551a9.bugs.michael@gmx.net> <454435E2.5060707@ioa.s.u-tokyo.ac.jp> <1162109216.11104.55.camel@viper.local> Message-ID: <4544969E.2080301@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote: > On Sun, 2006-10-29 at 14:02 +0900, Mamoru Tasaka wrote: > >> Or is there any way >> to just "copy" noarch.rpm on FE-devel branch to another >> branch? > > http://fedoraproject.org/wiki/Extras/RepoRequests > It seems that I don't have the right to edit the page. Mamoru From bugs.michael at gmx.net Sun Oct 29 12:03:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 13:03:13 +0100 Subject: comps.xml in Extras In-Reply-To: <200610282037.50873.dennis@ausil.us> References: <20061028031427.3ae5df5d.bugs.michael@gmx.net> <20061028164705.87a73b2e.bugs.michael@gmx.net> <45437162.8060203@leemhuis.info> <200610282037.50873.dennis@ausil.us> Message-ID: <20061029130313.5ebaf9b5.bugs.michael@gmx.net> On Sat, 28 Oct 2006 20:37:50 -0500, Dennis Gilmore wrote: > > >>>> Are we using comps yet for repoview? That might make repoview more > > >>>> worthwhile, but probably still not for debuginfo. > > >>> > > >>> Hmmm, that's a different topic, though. I've found this: > > >>> http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly > > >>> Can anybody give a status update on that, please? > > >> > > >> dgilmore asked jeremy for details how to realize it when they branched > > >> Extras for FC6. Don't know how far the real work went after that. > > > > > > Private conversation? Or another mailing-list? > > > > FESCo meeting. But is was some months ago. Should be in the archives and > > in the summaries that were posted to the list. > make comps did not work. and i haven't had a chance to look at why yet. Because the makefile does not include a "comps" target, and "make all" referred to the non-existant target, too. When deleting it, "make" and "make all" work. From bugs.michael at gmx.net Sun Oct 29 12:36:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 13:36:25 +0100 Subject: wvs-data In-Reply-To: <4544969E.2080301@ioa.s.u-tokyo.ac.jp> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> <20061028215816.592551a9.bugs.michael@gmx.net> <454435E2.5060707@ioa.s.u-tokyo.ac.jp> <1162109216.11104.55.camel@viper.local> <4544969E.2080301@ioa.s.u-tokyo.ac.jp> Message-ID: <20061029133625.899c2850.bugs.michael@gmx.net> On Sun, 29 Oct 2006 20:55:10 +0900, Mamoru Tasaka wrote: > Ville Skytt? wrote: > > On Sun, 2006-10-29 at 14:02 +0900, Mamoru Tasaka wrote: > > > >> Or is there any way > >> to just "copy" noarch.rpm on FE-devel branch to another > >> branch? > > > > http://fedoraproject.org/wiki/Extras/RepoRequests > > > > It seems that I don't have the right to edit the page. http://fedoraproject.org/wiki/EditGroupQueue From j.w.r.degoede at hhs.nl Sun Oct 29 13:44:09 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 14:44:09 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029100420.GD5357@neu.nirvana> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029100420.GD5357@neu.nirvana> Message-ID: <4544B029.3040006@hhs.nl> Axel Thimm wrote: > On Sun, Oct 29, 2006 at 08:37:06AM +0100, Hans de Goede wrote: >> Michael Schwendt wrote: >>> When some people ask whether anything is wrong with a beta, it is >>> equally valid to ask what's wrong with the last official stable >>> release? Where are the answers to both questions? >> Exactly who says that the beta has more bugs / problems then the >> latest stable, since its newer its supposed to be an improvement, >> this can be in features but also in bugcount. >> >> For example I would expect a 1.0.1 RC to be better then 1.0.0 for >> most products, so which do I package? > > I think this is quite easy to answer: If the software is labeled as > beta/pre/cvs/svn/rc in fact anything non-released, then upstream > obviously considers this software not ready for mass distribution. > > There are exceptions to this rule like some projects that never > release or release every few millenia and explicitely ask to use their > VCS, but these are indeed the exception and it's straightforward to > fulfill Michael's request, e.g. "packaging from CVS due to upstream > recommending doing so instead of using the old release version". > > Where packagers should really offer an explanation is when upstream > has a sensible release cycle, doesn't recommend jumping on VCS or betas > and still the packager sees a need to package non-released software. > I agree and I'm not against having a packaging should use latest stable not rc / beta / cvs. But that should be a Should and not a Must and such a rule will have exceptions and then the question becomes what is the procedure for such exceptions? Michael's mail tends to permission must be asked and down that road (which Michael has advocated before for other issues) lies having to ask permission to some kinda committee for every fart one lets and down that same road lies the hell known as bureaucracy! Example at my work if I want to visit a secondary computer science school to promote the computer science study I work for I must first ask permission to someone in a building in another city with zero knowledge of Computer Science because the bureaucrats wants our University to speak with one voice to the outside world, end result smaller harder to sell studies get less and less students because we are no longer allowed to take care of our own marketing and the central University marketing committee couldn't care less because small technical studies are not those where huge gains in overall number of students can be had. all I'm saying is sure a general rule of thumb is ok, but please leave room for the packagers to make exceptions when necessary themselves, don't leave this up to some committee! Regards, Hans From j.w.r.degoede at hhs.nl Sun Oct 29 13:53:43 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 14:53:43 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029123520.aa99832c.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029123520.aa99832c.bugs.michael@gmx.net> Message-ID: <4544B267.7080705@hhs.nl> Michael Schwendt wrote: > On Sun, 29 Oct 2006 08:37:06 +0100, Hans de Goede wrote: > >>> It's not that easy to say "packagers know best". If that were the case, we >>> could kill the reviewing. The question is whether we want to open the >>> flood-gates by setting precedence and letting in many other pre-release >>> versions, effectively moving closer to the bleeding edge? >> Sure it is that easy, because the packager should now best, can we please >> leave some (plenty of room actually) in all our procedures for the packagers >> discretion. Sometimes a beta release is better, because for example it fixes >> a few big bugs in the latest stable, but upstream wants to fix a last bug (which >> is also in the latest stable) before releasing a new stable. >> >> I've even had BZ requests requesting an update to the beta. Or the beta is the only >> version which works with the latest stable version of libfoo, where as the latest stable >> requires an older version of libfoo which isn't in core/extras. > > Splitting-hairs. Can we please leave corner-cases out of this? > We are interested in the _general guidelines_, NOT in corner-cases. > General guidelines are easy, corner cases are the problem and thus must be discussed! I've no problem with general guidelines as long as there is room for exceptions in those guidelines, and package owners are trusted to judge when such an exception is necessary. IOW I don't want to have to ask permission if I find such an exception necessary (for wathever reason). If people dislike my decision they can file a bug and if my reponse isn't good they can start complaining on the mailinglist. If I get lots of complaints and don't want to change may ways my CVS access may be pulled. That is enough of a mechanism which works well. We don't need tons and tons and tons of rules and procedures! > When you see me using the plural instead of the singular this still is > because _we_ at the Fedora Extras project should have many common > interests. And not landing in guinea-pig hell (and API/ABI breakage hell) > because of too many pre-release packages should be one of our interest. > Yes we do have many common interest that is why we are a group, perhaps even a team. And this all starts with trusting fellow team members, and trust is something which, excuse me for saying so, you seem to have a serious lack of! >>> I'd rather be more rigorous and require packagers and reviewers to explain >>> why a pre-release version or VCS snapshot is preferred over a stable >>> release. >>> >> During initial review sure! > > Aha. Can this be counted as a +1 then? ;) > For an initial review yes, also usually packages which tend to need a beta / CVS already do so when reviewed, the need for a beta happening later is rare. > After approval the reviewing is not over. The package maintainer becomes > the primary reviewer, often the only reviewer until a package is built and > users start testing it. > ?? The review is over, sure the package maintainer has to stick to the guidelines and do its best not to introduce any (packaging) errors, but there is no formal review anymore. Going of topic I always run rpmlint before the final commit and make tag build, perhaps we can make running rpmlint part of Makefile.common so that say "make x86_64" will run rpmlint on the resulting rpms? > This must not mean that a stable release is used to pass the review > process only to upgrade to a beta afterwards without giving good > reason. Right? > That depends on the afterwards, 2 days later no that is seriously abusing the process, but 6 months later if the packager finds he has a good reason yes, once again we have to trust each other! >> Its quite simple: motivated and educated packagers good, bureaucracy bad! > > Motivation is a rather vague term here. Too much "wrong motivation" can > easily lead to over-ambitious packaging and then is bad, too. > Once again this all boils down to trust, and we can't trust each other we might as well stop FE right here and now! Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Sun Oct 29 14:36:07 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 23:36:07 +0900 Subject: wvs-data In-Reply-To: <20061029133625.899c2850.bugs.michael@gmx.net> References: <20061028184752.534DA15212E@buildsys.fedoraproject.org> <20061028215816.592551a9.bugs.michael@gmx.net> <454435E2.5060707@ioa.s.u-tokyo.ac.jp> <1162109216.11104.55.camel@viper.local> <4544969E.2080301@ioa.s.u-tokyo.ac.jp> <20061029133625.899c2850.bugs.michael@gmx.net> Message-ID: <4544BC57.2010809@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Sun, 29 Oct 2006 20:55:10 +0900, Mamoru Tasaka wrote: >> It seems that I don't have the right to edit the page. > http://fedoraproject.org/wiki/EditGroupQueue Thank you. From bugs.michael at gmx.net Sun Oct 29 14:59:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 15:59:52 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4544B029.3040006@hhs.nl> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029100420.GD5357@neu.nirvana> <4544B029.3040006@hhs.nl> Message-ID: <20061029155952.6c8d9d26.bugs.michael@gmx.net> On Sun, 29 Oct 2006 14:44:09 +0100, Hans de Goede wrote: > > Where packagers should really offer an explanation is when upstream > > has a sensible release cycle, doesn't recommend jumping on VCS or betas > > and still the packager sees a need to package non-released software. > > > > I agree and I'm not against having a packaging should use latest stable > not rc / beta / cvs. But that should be a Should and not a Must and such > a rule will have exceptions and then the question becomes what is the > procedure for such exceptions? Michael's mail tends to permission must > be asked and down that road (which Michael has advocated before for > other issues) lies having to ask permission to some kinda committee for > every fart one lets and down that same road lies the hell known as > bureaucracy! Refrain from putting words into my mouth. All I ask for is an explanation in the spec file (which is something I've proposed "before for other issues") and in the review ticket. From bugs.michael at gmx.net Sun Oct 29 15:20:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 16:20:20 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4544B267.7080705@hhs.nl> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029123520.aa99832c.bugs.michael@gmx.net> <4544B267.7080705@hhs.nl> Message-ID: <20061029162020.a572168a.bugs.michael@gmx.net> On Sun, 29 Oct 2006 14:53:43 +0100, Hans de Goede wrote: > > This must not mean that a stable release is used to pass the review > > process only to upgrade to a beta afterwards without giving good > > reason. Right? > > > > That depends on the afterwards, 2 days later no that is seriously > abusing the process, but 6 months later if the packager finds he has a > good reason yes, once again we have to trust each other! Again, this is splitting-hairs. And once more, even if an upgrade to a beta is done 6 months later, the reason for such an upgrade can be documented in the %changelog. Afterall, the packager overrules upstream's release scheme. Sometimes much disliked by upstream developers when they discover that a distribution includes a pre-release. Why not document the decision? > >> Its quite simple: motivated and educated packagers good, bureaucracy bad! > > > > Motivation is a rather vague term here. Too much "wrong motivation" can > > easily lead to over-ambitious packaging and then is bad, too. > > > > Once again this all boils down to trust, and we can't trust each other > we might as well stop FE right here and now! The step you're missing is the time it takes to build up trust. We are at a level where we still see ABI breakage in upgrades for FE5 or FE6. Usually, the spec changelog says nothing else than "Update to 2.x", and only afterwards, the reported breakage is cleaned up with rebuilds. No comment on whether the ABI breakage was expected or not. If breakage was expected, I would hope for at least a warning the in spec changelog. And that would increase trust in the packager. In one mail, you wrote: > Yes, so we need high quality packagers, we need to educate them, no > system is 100% error free, So, obviously there are different levels of trust. One level is to trust a packager's good intentions. Another level is to trust his capabilities. What is so difficult about requesting packagers to be more verbose in spec changelog comments _and_ reviews? It is not bureaucracy where you depend on somebody else's decision. You just document "your stuff" and be done. From j.w.r.degoede at hhs.nl Sun Oct 29 17:39:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 18:39:53 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029155952.6c8d9d26.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029100420.GD5357@neu.nirvana> <4544B029.3040006@hhs.nl> <20061029155952.6c8d9d26.bugs.michael@gmx.net> Message-ID: <4544E769.8080407@hhs.nl> Michael Schwendt wrote: > On Sun, 29 Oct 2006 14:44:09 +0100, Hans de Goede wrote: > >>> Where packagers should really offer an explanation is when upstream >>> has a sensible release cycle, doesn't recommend jumping on VCS or betas >>> and still the packager sees a need to package non-released software. >>> >> I agree and I'm not against having a packaging should use latest stable >> not rc / beta / cvs. But that should be a Should and not a Must and such >> a rule will have exceptions and then the question becomes what is the >> procedure for such exceptions? Michael's mail tends to permission must >> be asked and down that road (which Michael has advocated before for >> other issues) lies having to ask permission to some kinda committee for >> every fart one lets and down that same road lies the hell known as >> bureaucracy! > > Refrain from putting words into my mouth. All I ask for is an explanation > in the spec file (which is something I've proposed "before for other > issues") and in the review ticket. > > If that is all you want then let me apologize, although I'm a fan of the current review process I'm also a bit allergic to unnecesarry rules. Some people here (and in my memory you are one of them but I could be wrong there) seem to want to add a new/rule procedure for each incident instead of looking at the bigger picture and only create procedures which work for the whole of the bigger picture, and then only if truely necessary. Having people explain the why of the beta in the spec sounds reasonable (for new beta/rc packages that is, adding this for all current packages is overkill). Regards, Hans From michel.salim at gmail.com Sun Oct 29 17:36:49 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 29 Oct 2006 12:36:49 -0500 Subject: redhat-lsb not in ExceptionList? Message-ID: <883cfe6d0610290936s673866d0nb52c3f5296479911@mail.gmail.com> Would it make sense to have redhat-lsb installed in mock? My understanding is that the LSB specifies files that any Linux system is expected to have, so it should not be necessary to have to BuildRequire on them. Regards, -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From fedora-extras-list.listman at linuxnetz.de Sun Oct 29 17:46:12 2006 From: fedora-extras-list.listman at linuxnetz.de (Robert Scheck) Date: Sun, 29 Oct 2006 18:46:12 +0100 Subject: Duplicity is orphaned Message-ID: <20061029174612.GA17160@hurricane.linuxnetz.de> Hello folks, when looking to http://fedoraproject.org/wiki/Extras/OrphanedPackages, it looks like that duplicity got orphaned at 2006-09-16. If nobody (especially Michael, the last maintainer) takes care within the next few days, I would take it... Greetings, Robert From j.w.r.degoede at hhs.nl Sun Oct 29 18:02:06 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 19:02:06 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029162020.a572168a.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029123520.aa99832c.bugs.michael@gmx.net> <4544B267.7080705@hhs.nl> <20061029162020.a572168a.bugs.michael@gmx.net> Message-ID: <4544EC9E.1070304@hhs.nl> Michael Schwendt wrote: > On Sun, 29 Oct 2006 14:53:43 +0100, Hans de Goede wrote: > >> That depends on the afterwards, 2 days later no that is seriously >> abusing the process, but 6 months later if the packager finds he has a >> good reason yes, once again we have to trust each other! > > Again, this is splitting-hairs. > > And once more, even if an upgrade to a beta is done 6 months later, the > reason for such an upgrade can be documented in the %changelog. > And again I agree, I must have misread / understood you wrong. There aren't many ways to rub me the bad way / I don't have many allergies, but bureaucracy is one of them, so I guess I overreacted. Yes requesting people to properly document the why (for example in case a special request was made through BZ refer to the BZ ticket) is very reasonable. > Afterall, the packager overrules upstream's release scheme. Sometimes much > disliked by upstream developers when they discover that a distribution > includes a pre-release. Why not document the decision? > Documenting good, having to ask permission bad, so it seems we agree and I misunderstood. >>>> Its quite simple: motivated and educated packagers good, bureaucracy bad! >>> Motivation is a rather vague term here. Too much "wrong motivation" can >>> easily lead to over-ambitious packaging and then is bad, too. >>> >> Once again this all boils down to trust, and we can't trust each other >> we might as well stop FE right here and now! > > The step you're missing is the time it takes to build up trust. > Yes the time needed for new FE contributers to become familiar with FE and more importantly to learn all the fine details (like whats an ABI, how can I check if it changes?) is a problem, but we must have a way for people to make mistakes to learn from. I do not see an easy answer to this. In the case of ABI breakage I guess we need to write some docs on this, atleast on howto check for soname changes. Also I prefer to start with a certain level of trust, but I think our main "conflict" here is the choice of words, with trust I mean the Dutch vertrouwen, German Vertrauen. As said I prefer to trust people (with regard to their intensions) from the start, I agree that with regard to their technical skills they often have to learn much and that takes time. > We are at a level where we still see ABI breakage in upgrades for FE5 or > FE6. Usually, the spec changelog says nothing else than "Update to 2.x", > and only afterwards, the reported breakage is cleaned up with rebuilds. > No comment on whether the ABI breakage was expected or not. If breakage > was expected, I would hope for at least a warning the in spec changelog. > And that would increase trust in the packager. > Yes that is a big problem, one which I was bitten by once too with my directfb push. Now I know better and I only do ABI changing updates in devel. I've just pushed a few now FE-6 is out, which I have deliberately delayed until FE-6 was released as I didn't want to add any ABI breakage to devel once the mass rebuild had started. Going offtopic here, AFAIK we still don't have a policy for this I once did a feeble attempt at one, but I now see that was overcomplicated and thus didn't get a warm reception, may I thus introduce a new attempt at a simple soname / ABI breakage policy: 1) soname / ABI changing updates may only be done in the devel branch 2) Normally* any not backward compatible ABI change should come with a new soname 3) Any ABI and/or soname packages must be announced with a mail to fedora-extras-list 4) Adding new libraries to non devel with a different soname then found in existing packages of these libs in third party repos should be avoided. *) Exception, when you're packaging a pre release of a library the ABI may change without changing the soname, packaging such a pre-release should be avoided if possible. > In one mail, you wrote: > >> Yes, so we need high quality packagers, we need to educate them, no >> system is 100% error free, > > So, obviously there are different levels of trust. One level is to trust > a packager's good intentions. Another level is to trust his capabilities. > Ah, yes I see now how you use (and can use) the same word (trust) for these two, forget about my above ramblings. Yes I agree I assume good intentions, but I don't assume good packaging skills > What is so difficult about requesting packagers to be more verbose in > spec changelog comments _and_ reviews? It is not bureaucracy where you > depend on somebody else's decision. You just document "your stuff" and > be done. > As already said I agree, this mainly seems a misunderstanding, sorry! Regards, Hans From Matt_Domsch at dell.com Sun Oct 29 18:02:17 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 29 Oct 2006 12:02:17 -0600 Subject: redhat-lsb not in ExceptionList? In-Reply-To: <883cfe6d0610290936s673866d0nb52c3f5296479911@mail.gmail.com> References: <883cfe6d0610290936s673866d0nb52c3f5296479911@mail.gmail.com> Message-ID: <20061029180217.GA13218@lists.us.dell.com> On Sun, Oct 29, 2006 at 12:36:49PM -0500, Michel Salim wrote: > Would it make sense to have redhat-lsb installed in mock? My > understanding is that the LSB specifies files that any Linux system is > expected to have, so it should not be necessary to have to > BuildRequire on them. OS versions that claim to be LSB-certified at a given level may have those, and they may be provided by a set of RPMs that are not included in the base distribution. redhat-lsb "Provides: lsb", so any LSB-compliant app can "Require: lsb". LSB is really no different than any other set of dependencies, except that they aim for wider cross-distro compatibility. I don't see a strong reason to put them in the default buildroot, just buildrequire them if needed at build time. 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 Sun Oct 29 18:22:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 Oct 2006 19:22:22 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4544E769.8080407@hhs.nl> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029100420.GD5357@neu.nirvana> <4544B029.3040006@hhs.nl> <20061029155952.6c8d9d26.bugs.michael@gmx.net> <4544E769.8080407@hhs.nl> Message-ID: <20061029192222.0029735e.bugs.michael@gmx.net> On Sun, 29 Oct 2006 18:39:53 +0100, Hans de Goede wrote: > If that is all you want then let me apologize, although I'm a fan of the > current review process I'm also a bit allergic to unnecesarry rules. > Some people here (and in my memory you are one of them but I could be > wrong there) seem to want to add a new/rule procedure for each incident > instead of looking at the bigger picture and only create procedures > which work for the whole of the bigger picture, and then only if truely > necessary. Wow, thanks for the flowers. :-/ Sounds like FUD and nothing else than a personal insult. If you've ever had reason to disagree with me, you should have opened your mouth at the best opportunity. Right now I have no idea what "incidents" an proposals you refer to. All I can tell is that I find your sweeping statement impolite and inappropriate. From j.w.r.degoede at hhs.nl Sun Oct 29 19:00:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Oct 2006 20:00:07 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029192222.0029735e.bugs.michael@gmx.net> References: <20061025075609.GE31188@neu.nirvana> <20061028165839.f202892e.bugs.michael@gmx.net> <1162047938.3139.24.camel@vader.jdub.homelinux.org> <20061029001327.c3cb62e5.bugs.michael@gmx.net> <45445A22.9070301@hhs.nl> <20061029100420.GD5357@neu.nirvana> <4544B029.3040006@hhs.nl> <20061029155952.6c8d9d26.bugs.michael@gmx.net> <4544E769.8080407@hhs.nl> <20061029192222.0029735e.bugs.michael@gmx.net> Message-ID: <4544FA37.7020306@hhs.nl> Michael Schwendt wrote: > On Sun, 29 Oct 2006 18:39:53 +0100, Hans de Goede wrote: > >> If that is all you want then let me apologize, although I'm a fan of the >> current review process I'm also a bit allergic to unnecesarry rules. >> Some people here (and in my memory you are one of them but I could be >> wrong there) seem to want to add a new/rule procedure for each incident >> instead of looking at the bigger picture and only create procedures >> which work for the whole of the bigger picture, and then only if truely >> necessary. > > Wow, thanks for the flowers. :-/ > > Sounds like FUD and nothing else than a personal insult. > As said my memory could be serving me wrong here, that happens. This is nothing personal. I'm trying to fight the tendency in FE to sometimes create to many rules / procedures, I've got nothing against you personal. > If you've ever had reason to disagree with me, you should have opened your > mouth at the best opportunity. Right now I have no idea what "incidents" > an proposals you refer to. All I can tell is that I find your sweeping > statement impolite and inappropriate. > I'm sorry to hear that, this wasn't intended that way. Regards, Hans From jeff at ocjtech.us Sun Oct 29 20:35:01 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sun, 29 Oct 2006 14:35:01 -0600 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061029095115.GC5357@neu.nirvana> References: <20061025120117.7e4b0049@python3.es.egwn.lan> <20061025100629.GA21155@neu.nirvana> <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> <20061025161214.GB8122@neu.nirvana> <20061028211834.GD19403@neu.nirvana> <1162083442.2866.18.camel@lt21223.campus.dmacc.edu> <20061029095115.GC5357@neu.nirvana> Message-ID: <1162154101.3452.26.camel@lt21223.campus.dmacc.edu> On Sun, 2006-10-29 at 10:51 +0100, Axel Thimm wrote: > On Sat, Oct 28, 2006 at 07:57:22PM -0500, Jeffrey C. Ollie wrote: > > On Sat, 2006-10-28 at 23:18 +0200, Axel Thimm wrote: > > > On Wed, Oct 25, 2006 at 06:12:14PM +0200, Axel Thimm wrote: > > > > On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > > > > > Even if I had stayed with 1.2.X packages there would have been problems > > > > > coexisting with the atrpms repository... > > > > > > > > Why? This only happens if you ignore that these packages exist > > > > and are used by a large number of people. > > > > > > No answer on this one? > > > > If atrpms and FE both have asterisk packages it would be difficult to > > use both repos at the same time. In any case, the fact that a package > > exists in another repo is not a good enough reason to keep it out of FE. > > But it would make sense to provide an upgrade path or seek any kind of > coordination, or not? Maybe it makes sense for you, and maybe it makes sense for people that use atrpms, but it doesn't make sense to me. If I want to package a piece of software for Fedora Extras and it meets all of the other FE packaging guidelines I'm going to package it and not worry about what umpteen other repos may be doing. > Instead the situation you created is that > neither non-ATrpms users, Hmm?? Non-ATrpms users aren't any worse off than they were before... Until the Asterisk package is approved and the Zaptel kernel modules are in the kernel package they'll still have to compile Asterisk from source - probably not much different from what they do now. Plus we have convinced Digium to reconsider getting the Zaptel kernel modules into the vanilla kernel, I think that says a lot about > nor ATrpms users could make any use of asterisk at all. If ATrpms wants to have packages that override packages in Fedora Extras, either bump the epoch or provide some other mechanism for ATrpms users to get the ATrpms Asterisk packages rather than the Fedora Extras version. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Sun Oct 29 21:12:39 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 29 Oct 2006 16:12:39 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-10-29 Message-ID: <20061029211239.83A95152139@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 27 basket-0.6.0-1.fc7 contact-lookup-applet-0.15-2.fc7 eds-feed-0.5.0-6.fc7 gift-0.11.8.1-6.fc7 gnome-phone-manager-0.8-4.fc7 hatari-0.90-5.fc7 heartbeat-2.0.7-3.fc7 itpp-3.10.6-1.fc7 jd-1.8.0-0.4.cvs061028.fc7 kbibtex-0.1.5-2.fc7 licq-1.3.4-2.fc7 liferea-1.0.25-2.fc7 lucidlife-0.9.1-1.fc7 mail-notification-3.0-8.fc7 moodle-1.6.3-3.fc7 pan-0.117-2.fc7 perl-Unicode-Map8-0.12-11.fc7 perl-Unicode-MapUTF8-1.11-3.fc7 php-pear-Date-Holidays-0.16.1-1.fc7 qt4-4.2.1-2.fc7 qtparted-0.4.5-10.fc7 showimg-0.9.5-12.fc7 smbldap-tools-0.9.2-5.fc7 tuxpaint-0.9.16-3.fc7 wv-1.2.4-1.fc7 wvs-data-0.0.20020219-3 xchat-gnome-0.15-1.fc7 Packages built and released for Fedora Extras 6: 19 contact-lookup-applet-0.15-2.fc6 csound-5.03.0-7.fc6 eds-feed-0.5.0-6.fc6 gaim-otr-3.0.1-0.3.20060921cvs.fc6 heartbeat-2.0.7-3.fc6 itpp-3.10.6-1.fc6 jd-1.8.0-0.3.beta061023.fc6 licq-1.3.4-2.fc6 lucidlife-0.9.1-1.fc6 moodle-1.6.3-3.fc6 pan-0.117-2.fc6 perl-Chatbot-Eliza-1.04-3.fc6 perl-Unicode-Map8-0.12-11.fc6 perl-Unicode-MapUTF8-1.11-3.fc6 php-pear-XML-Serializer-0.18.0-2.fc6 poedit-1.3.5-1.fc6 showimg-0.9.5-12.fc6 smbldap-tools-0.9.2-5.fc6 xchat-gnome-0.15-1.fc6 Packages built and released for Fedora Extras 5: 12 heartbeat-2.0.7-3.fc5 itpp-3.10.6-1.fc5 jd-1.8.0-0.3.beta061023.fc5 kbibtex-0.1.5-3.fc5 lucidlife-0.9.1-1.fc5.1 moodle-1.6.3-3.fc5 perl-Chatbot-Eliza-1.04-3.fc5 perl-Unicode-Map8-0.12-11.fc5 perl-Unicode-MapUTF8-1.11-3.fc5 php-pear-XML-Serializer-0.18.0-2.fc5 poedit-1.3.5-1.fc5 showimg-0.9.5-12.fc5 Packages built and released for Fedora Extras 4: 5 heartbeat-2.0.7-3.fc4 kbibtex-0.1.5-3.fc4 moodle-1.6.3-3.fc4 showimg-0.9.5-12.fc4 wv-1.0.3-3.fc4 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 Sun Oct 29 22:12:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 29 Oct 2006 22:12:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-29 Message-ID: <20061029221212.8739.22496@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-4.fc6.i386 (2 days) blender - 2.42a-4.fc6.ppc (2 days) blender - 2.42a-4.fc6.x86_64 (2 days) andreas.bierfert AT lowlatency.de koffice-core - 1.6.0-2.fc7.i386 (4 days) koffice-kivio - 1.6.0-2.fc7.i386 (4 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 libopensync-plugin-evolution2 - 0.19-1.fc6.ppc libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 orange - 0.3-3.cvs20051118.fc6.i386 (5 days) scribus - 1.3.3.4-1.fc6.i386 (5 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (29 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (29 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (29 days) bdpepple AT ameritech.net liferea - 1.0.25-2.fc7.i386 liferea - 1.0.25-2.fc7.ppc liferea - 1.0.25-2.fc7.x86_64 dcbw AT redhat.com csound - 5.03.0-7.fc7.i386 (2 days) plague - 0.4.4.1-2.fc3.noarch (44 days) plague - 0.4.4.1-2.fc3.noarch (44 days) plague - 0.4.4.1-2.fc4.noarch (44 days) plague - 0.4.4.1-2.fc4.noarch (44 days) plague - 0.4.4.1-2.fc4.noarch (44 days) denis AT poolshark.org k3d - 0.6.3.1-1.fc6.i386 (5 days) imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (4 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (4 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (4 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (20 days) linphone - 1.2.0-4.fc5.ppc (20 days) linphone - 1.2.0-4.fc5.x86_64 (20 days) linphone - 1.2.0-7.fc6.i386 (5 days) linphone - 1.2.0-7.fc6.ppc (5 days) linphone - 1.2.0-7.fc6.x86_64 (5 days) jkeating AT redhat.com contacts - 0.1-5.20060813svn.fc6.i386 contacts - 0.1-5.20060813svn.fc6.ppc contacts - 0.1-5.20060813svn.fc6.x86_64 dates - 0.1-4.20060813svn.fc6.i386 dates - 0.1-4.20060813svn.fc6.i386 dates - 0.1-4.20060813svn.fc6.ppc dates - 0.1-4.20060813svn.fc6.x86_64 lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 deskbar-applet - 2.16.0-1.fc6.ppc deskbar-applet - 2.16.0-1.fc6.x86_64 matt AT truch.net kst - 1.3.1-1.fc6.i386 (5 days) oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (10 days) syck-php - 0.55-9.fc5.ppc (10 days) syck-php - 0.55-9.fc5.x86_64 (10 days) orion AT cora.nwra.com plplot - 5.6.1-7.fc6.i386 (5 days) plplot-gnome - 5.6.1-7.fc6.i386 (5 days) rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 tcallawa AT redhat.com evolution-bogofilter - 0.2.0-3.fc6.i386 evolution-bogofilter - 0.2.0-3.fc6.ppc evolution-bogofilter - 0.2.0-3.fc6.x86_64 gambas-runtime - 1.0.17-3.fc6.i386 (2 days) gambas-runtime - 1.0.17-3.fc6.ppc (2 days) Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- blender-2.42a-4.fc6.ppc requires libgettextlib-0.14.6.so contacts-0.1-5.20060813svn.fc6.ppc requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.ppc requires libedataserver-1.2.so.7 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 evolution-bogofilter-0.2.0-3.fc6.ppc requires libedataserver-1.2.so.7 gambas-runtime-1.0.17-3.fc6.ppc requires libgettextlib-0.14.6.so libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 liferea-1.0.25-2.fc7.ppc requires firefox = 0:2.0.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- blender-2.42a-4.fc6.x86_64 requires libgettextlib-0.14.6.so()(64bit) contacts-0.1-5.20060813svn.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) csound-5.03.0-7.fc7.i386 requires libpython2.4.so.1.0 dates-0.1-4.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) evolution-bogofilter-0.2.0-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 k3d-0.6.3.1-1.fc6.i386 requires libpython2.4.so.1.0 koffice-core-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 koffice-kivio-1.6.0-2.fc7.i386 requires libpython2.4.so.1.0 kst-1.3.1-1.fc6.i386 requires libkjsembed.so.1 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) liferea-1.0.25-2.fc7.x86_64 requires firefox = 0:2.0.2 orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 plplot-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 plplot-gnome-5.6.1-7.fc6.i386 requires libpython2.4.so.1.0 scribus-1.3.3.4-1.fc6.i386 requires libpython2.4.so.1.0 Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- blender-2.42a-4.fc6.i386 requires libgettextlib-0.14.6.so contacts-0.1-5.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 dates-0.1-4.20060813svn.fc6.i386 requires libedataserver-1.2.so.7 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 evolution-bogofilter-0.2.0-3.fc6.i386 requires libedataserver-1.2.so.7 gambas-runtime-1.0.17-3.fc6.i386 requires libgettextlib-0.14.6.so libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 liferea-1.0.25-2.fc7.i386 requires firefox = 0:2.0.2 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: rdieter AT math.unl.edu package: gift - 0.11.8.1-6.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libmagic.so.1 ====================================================================== New report for: bdpepple AT ameritech.net package: liferea - 1.0.25-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: firefox = 0:2.0.2 package: liferea - 1.0.25-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: firefox = 0:2.0.2 package: liferea - 1.0.25-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: firefox = 0:2.0.2 From michel.salim at gmail.com Sun Oct 29 23:13:34 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 29 Oct 2006 18:13:34 -0500 Subject: redhat-lsb not in ExceptionList? In-Reply-To: <20061029180217.GA13218@lists.us.dell.com> References: <883cfe6d0610290936s673866d0nb52c3f5296479911@mail.gmail.com> <20061029180217.GA13218@lists.us.dell.com> Message-ID: <883cfe6d0610291513i3ec68b5esa24217edadb3c7f9@mail.gmail.com> On 10/29/06, Matt Domsch wrote: > OS versions that claim to be LSB-certified at a given level may have > those, and they may be provided by a set of RPMs that are not included > in the base distribution. redhat-lsb "Provides: lsb", so any > LSB-compliant app can "Require: lsb". LSB is really no different than > any other set of dependencies, except that they aim for wider > cross-distro compatibility. I don't see a strong reason to put them > in the default buildroot, just buildrequire them if needed at build > time. > Fair enough. I'm just curious - isn't the earliest Fedora release that Extras targets - FC-3? - LSB-compliant, and comes with redhat-lsb preinstalled as part of the base install? -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From Axel.Thimm at ATrpms.net Mon Oct 30 00:52:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Oct 2006 01:52:12 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162154101.3452.26.camel@lt21223.campus.dmacc.edu> References: <20061025123623.5b74bc03@python3.es.egwn.lan> <20061025105627.GD21155@neu.nirvana> <1161784135.2957.22.camel@lt21223.campus.dmacc.edu> <20061025140704.GI21155@neu.nirvana> <1161786602.2957.33.camel@lt21223.campus.dmacc.edu> <20061025161214.GB8122@neu.nirvana> <20061028211834.GD19403@neu.nirvana> <1162083442.2866.18.camel@lt21223.campus.dmacc.edu> <20061029095115.GC5357@neu.nirvana> <1162154101.3452.26.camel@lt21223.campus.dmacc.edu> Message-ID: <20061030005212.GH28387@neu.nirvana> On Sun, Oct 29, 2006 at 02:35:01PM -0600, Jeffrey C. Ollie wrote: > On Sun, 2006-10-29 at 10:51 +0100, Axel Thimm wrote: > > On Sat, Oct 28, 2006 at 07:57:22PM -0500, Jeffrey C. Ollie wrote: > > > On Sat, 2006-10-28 at 23:18 +0200, Axel Thimm wrote: > > > > On Wed, Oct 25, 2006 at 06:12:14PM +0200, Axel Thimm wrote: > > > > > On Wed, Oct 25, 2006 at 09:30:02AM -0500, Jeffrey C. Ollie wrote: > > > > > > Even if I had stayed with 1.2.X packages there would have been problems > > > > > > coexisting with the atrpms repository... > > > > > > > > > > Why? This only happens if you ignore that these packages exist > > > > > and are used by a large number of people. > > > > > > > > No answer on this one? > > > > > > If atrpms and FE both have asterisk packages it would be difficult to > > > use both repos at the same time. In any case, the fact that a package > > > exists in another repo is not a good enough reason to keep it out of FE. > > > > But it would make sense to provide an upgrade path or seek any kind of > > coordination, or not? > > Maybe it makes sense for you, and maybe it makes sense for people that > use atrpms, but it doesn't make sense to me. Ignoring these users and stampeding over their systems is not really neccessary. > > Instead the situation you created is that neither non-ATrpms > > users, > > Hmm?? Non-ATrpms users aren't any worse off than they were before... > Until the Asterisk package is approved and the Zaptel kernel modules are > in the kernel package they'll still have to compile Asterisk from source > - probably not much different from what they do now. OK, then please try to build from source the released asterisk version. And find out that the beta dependencies break asterisk in a silent way. There is no API break that would fail the build, instead the build is dysfunctional. > > nor ATrpms users could make any use of asterisk at all. > > If ATrpms wants to have packages that override packages in Fedora > Extras, either bump the epoch or provide some other mechanism for ATrpms > users to get the ATrpms Asterisk packages rather than the Fedora Extras > version. Thanks for forcing ATrpms to use epochs. And I really wonder who is overriding whom in this case. And with what: A yet incomplete solution (since the main app is missing) based on beta versions of software with known problems (which is why it's beta after all). You're adding to the problem of repo gaps and incompatibilities in the Fedora world w/o contributing any real added value otherwise. And all that because "it doesn't make sense to you to coordinate". -- 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 vonbrand at inf.utfsm.cl Mon Oct 30 01:15:56 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 29 Oct 2006 22:15:56 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Message from Axel Thimm of "Sat, 28 Oct 2006 23:10:22 +0200." <20061028211022.GB19403@neu.nirvana> Message-ID: <200610300115.k9U1Fu5b021467@laptop13.inf.utfsm.cl> Axel Thimm wrote: > On Sat, Oct 28, 2006 at 05:22:43PM +0200, Thorsten Leemhuis wrote: > > Josh Boyer schrieb: > > > As for the third party repo aspect of this, that is quite difficult. > > > There are potentially tons of third party repos, which already conflict > > > with each other. We cannot show preference for one or the other. That > > > does not mean that a third party repository maintainer cannot open a > > > bug. It just means that we cannot expect Extras maintainers to go > > > looking for problems in each and every third party repo before updating > > > something. > > > > +1 > I think this is a dangerous attitude. W/o going into ugly details I > believe the reason that Fedora has such a cluttered 3rd party > repository support in comparison to all other distros Which ones? Fedora is /large/ (larger than most), so problems show up more clearly. Some "others" have the policy of "everything is official", so (by definition) there can't be a problem with external stuff. > is just because > of that historic strategic and tactical errors (IMO) that were at the > beginning of the project alienating most 3rd party repositories. I'm not so sure they were errors... it is quite reasonable to ask (and gently nudge/force) for third parties to roll their stuff into the official repos. [...] > I deliberately left off details to not micro-discuss again about repo > foorpms and package bar and baz, I'm just targetting the big picture. Those you should BZ. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Oct 30 01:31:54 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 29 Oct 2006 22:31:54 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Message from "Christopher Stone" of "Sat, 28 Oct 2006 15:53:26 PDT." Message-ID: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> Christopher Stone wrote: [..] > I *think* the point he is trying to make is that some people don't > like 3rd party repositories overriding Fedora Extras without good > reason and some other people dont like Fedora Extras maintainers > adding packages in Fedora Extras without first consulting with the 3rd > party repositories. Ludicrous. That would give *third* parties, unrelated ones at that, a sort of veto power. > Which goes back to my original idea of having an official Fedora wiki > page that lists 3rd party repositories. Fedora Extras maintainers > could then check this wiki page to find out which repositories might > already have a package available for the package they want to submit. If it is an "official twiki", they aren't really third party anymore. Plus, am I supposed to register my own local repository there too? How do you weigh repositories like ATrpms vs MyOwnLocalRepo? What do you do with repositories which include (or are mostly composed of) stuff that Fedora wouldn't touch with a 10 foot pole? Who would do the (massive!) work to keep this up to date and reasonably accurate? Quite a boring job too, so it is rather unlikely a bunch of volunteers show up... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Oct 30 01:44:15 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 29 Oct 2006 22:44:15 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Message from Michael Schwendt of "Sun, 29 Oct 2006 16:20:20 BST." <20061029162020.a572168a.bugs.michael@gmx.net> Message-ID: <200610300144.k9U1iFdP022262@laptop13.inf.utfsm.cl> Michael Schwendt wrote: [...] > We are at a level where we still see ABI breakage in upgrades for FE5 or > FE6. Usually, the spec changelog says nothing else than "Update to 2.x", > and only afterwards, the reported breakage is cleaned up with rebuilds. > No comment on whether the ABI breakage was expected or not. If breakage > was expected, I would hope for at least a warning the in spec changelog. > And that would increase trust in the packager. If breakage was expected, a responsible developer would /not/ push the package out, so this is completely moot. [...] > What is so difficult about requesting packagers to be more verbose in > spec changelog comments _and_ reviews? It is not bureaucracy where you > depend on somebody else's decision. You just document "your stuff" and > be done. Well said. Too much %changelogs are way too laconic. If a version update, please add a reference to the (upstream, WWW) changelog. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Oct 30 01:47:26 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 29 Oct 2006 22:47:26 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Your message of "Sat, 28 Oct 2006 21:51:06 BST." <4543C2BA.9000206@timj.co.uk> Message-ID: <200610300147.k9U1lQAP022283@laptop13.inf.utfsm.cl> Tim Jackson wrote: [...] > This to me is the best argument for something *like* a "testing" repo > I've seen. I've never been convinced about the whole "testing" thing > to date, but I can see a limited use for some packages (especially big > ones with long release cycles and beta/RC periods) where regular users > might want to use the latest and greatest but it wouldn't be > appropriate to put it into devel, which might of course become a > release branch. In fact even if there's any doubt about whether the > package might not be ready for the next release (e.g. close to FC7 > branch) it makes it awkward for the maintainer because you they > potentially have to revert devel (go backwards)and undo good work if > it turned out the package wasn't quite ready in time for a branch, > which isn't ideal. That would mean having stable versions, development, and testing. Too much for a short-lived distribution like Fedora. There are testing packages announced from time to time in developer's own space, that should be enough. Perhaps that should be expanded to Extras people? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From Axel.Thimm at ATrpms.net Mon Oct 30 07:22:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Oct 2006 08:22:31 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610300115.k9U1Fu5b021467@laptop13.inf.utfsm.cl> References: <20061028211022.GB19403@neu.nirvana> <200610300115.k9U1Fu5b021467@laptop13.inf.utfsm.cl> Message-ID: <20061030072231.GC498@neu.nirvana> On Sun, Oct 29, 2006 at 10:15:56PM -0300, Horst H. von Brand wrote: > Axel Thimm wrote: > > On Sat, Oct 28, 2006 at 05:22:43PM +0200, Thorsten Leemhuis wrote: > > > Josh Boyer schrieb: > > > > As for the third party repo aspect of this, that is quite difficult. > > > > There are potentially tons of third party repos, which already conflict > > > > with each other. We cannot show preference for one or the other. That > > > > does not mean that a third party repository maintainer cannot open a > > > > bug. It just means that we cannot expect Extras maintainers to go > > > > looking for problems in each and every third party repo before updating > > > > something. > > > > > > +1 > > > I think this is a dangerous attitude. W/o going into ugly details I > > believe the reason that Fedora has such a cluttered 3rd party > > repository support in comparison to all other distros > > Which ones? W/o wanting to sound like the distro expert of the week I would say all major ones. > Fedora is /large/ (larger than most), so problems show up more > clearly. Some "others" have the policy of "everything is official", > so (by definition) there can't be a problem with external stuff. No, that's not the reason. And none of the Debian/Ubuntu/SuSE/Mandriva have "everything is official" policies, perhaps some smaller distributions do. > > is just because > > of that historic strategic and tactical errors (IMO) that were at the > > beginning of the project alienating most 3rd party repositories. > > I'm not so sure they were errors... it is quite reasonable to ask (and > gently nudge/force) for third parties to roll their stuff into the official > repos. I'm referring to times where there were no official repos. And asking/coordinating is what I'm after, so we are probably on the same side even if you don't know it. > [...] > > > I deliberately left off details to not micro-discuss again about repo > > foorpms and package bar and baz, I'm just targetting the big picture. > > Those you should BZ. You missed the "again" part. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Oct 30 09:36:30 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 30 Oct 2006 10:36:30 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610300147.k9U1lQAP022283@laptop13.inf.utfsm.cl> References: <4543C2BA.9000206@timj.co.uk> <200610300147.k9U1lQAP022283@laptop13.inf.utfsm.cl> Message-ID: <20061030093630.GA2273@free.fr> On Sun, Oct 29, 2006 at 10:47:26PM -0300, Horst H. von Brand wrote: > There are testing packages announced from time to time in developer's own > space, that should be enough. Perhaps that should be expanded to Extras > people? Kevin did that for the xfce beta releases. I am not sure there were a high number of testers in comparison of the number of xfce users, but I think it helped. -- Pat From denis at poolshark.org Mon Oct 30 10:58:34 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 30 Oct 2006 11:58:34 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> Message-ID: <4545DADA.3040600@poolshark.org> Horst H. von Brand wrote: > Christopher Stone wrote: > > [..] > >> I *think* the point he is trying to make is that some people don't >> like 3rd party repositories overriding Fedora Extras without good >> reason and some other people dont like Fedora Extras maintainers >> adding packages in Fedora Extras without first consulting with the 3rd >> party repositories. > > Ludicrous. That would give *third* parties, unrelated ones at that, a sort > of veto power. +1. It seems to me if a conflict exists between FE and a third-party repo, this is by definition the problem of the 3rd party repo maintainer, since nothing was preventing him/her to either submit the conflicting package into FE in the first place, or at least review the FE submission. And on the subject of a wiki page with available 3rd party repositories, it certainly should only contain repos that are *designed* to be add-on repos over FC and FE, in that order. From pertusus at free.fr Mon Oct 30 11:39:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 30 Oct 2006 12:39:35 +0100 Subject: xview anyone ? In-Reply-To: <20061025111032.50812465@ludwig-alpha.unil.ch> References: <20061025004624.4320c333@ludwig-alpha.unil.ch> <20061025080639.GA2622@free.fr> <20061025111032.50812465@ludwig-alpha.unil.ch> Message-ID: <20061030113934.GA3195@free.fr> On Wed, Oct 25, 2006 at 11:10:32AM +0200, Christian Iseli wrote: > > That'd be great. I can be the maintainer, since it seems it would be > useful for colleagues here... http://www.lmd.jussieu.fr/~pdlmd/xview-3.2-0.1.p4.src.rpm It was not an easy task, but now it's done. Normally, the imake files are more or less FHS compliant now, and I even use them to do the staged install of xview itself. However if treetool uses other variables to construct the directories, you may have to modify paths in files in config/XView.*. I had to install some fonts, that's a bit strange since they are listed in the fonts.dir file in /usr/share/X11/fonts/misc. I tested a bit and it seemed that using fontconfig didn't worked, that's why I also added the fonts to /usr/share/X11/fonts/misc. The X and Xfs servers seems to have to be restarted before those fonts are taken into account. Don't know if all that is normal or if I did something wrong. I tested the ol*wm window managers, they seemed to work, and also the clock program seems to be functionnal. The difference between this and the debian package are * I put together the 2 ol*wm packages * I put xview_xgettext and xview_msgfmt in xview-clients and not xview-devel (the idea is to have multi lib parallel installable devel package). -- Pat From bugs.michael at gmx.net Mon Oct 30 11:54:00 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 12:54:00 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4545DADA.3040600@poolshark.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> Message-ID: <20061030125400.119558d6.bugs.michael@gmx.net> On Mon, 30 Oct 2006 11:58:34 +0100, Denis Leroy wrote: > Horst H. von Brand wrote: > > > > [..] > > > >> I *think* the point he is trying to make is that some people don't > >> like 3rd party repositories overriding Fedora Extras without good > >> reason and some other people dont like Fedora Extras maintainers > >> adding packages in Fedora Extras without first consulting with the 3rd > >> party repositories. > > > > Ludicrous. That would give *third* parties, unrelated ones at that, a sort > > of veto power. > > +1. > > It seems to me if a conflict exists between FE and a third-party repo, > this is by definition the problem of the 3rd party repo maintainer, > since nothing was preventing him/her to either submit the conflicting > package into FE in the first place, or at least review the FE submission. > > And on the subject of a wiki page with available 3rd party repositories, > it certainly should only contain repos that are *designed* to be add-on > repos over FC and FE, in that order. There's still no reason to release partial dependency-chains into Fedora Extras after less than 24 hours between a sudden upgrade to a beta and the approval. That puts FE into a situation where we don't offer a working set of packages as long as the remaining packages are still under review, but which increases the risk that it breaks something our users have either built themselves or downloaded from 3rd party repos. At fedora.us we've always tried to publish complete dependency chains. We should realise that FE is not "complete" (and won't ever be complete with regard to the somet things). We should not make it more difficult for 3rd party packagers, who have joined FE already, to transfer more of their stuff to FE gradually while continuing to maintain their own repos. From vonbrand at inf.utfsm.cl Mon Oct 30 13:09:04 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 30 Oct 2006 10:09:04 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Message from Patrice Dumas of "Mon, 30 Oct 2006 10:36:30 BST." <20061030093630.GA2273@free.fr> Message-ID: <200610301309.k9UD94Bn004396@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Sun, Oct 29, 2006 at 10:47:26PM -0300, Horst H. von Brand wrote: > > There are testing packages announced from time to time in developer's own > > space, that should be enough. Perhaps that should be expanded to Extras > > people? > Kevin did that for the xfce beta releases. I am not sure there were a > high number of testers in comparison of the number of xfce users, but I > think it helped. XFCE isn't /that/ popular to begin with... but yes, I use it sometimes, and did futz around some with the betas. And I've certainly tried one-off (or preview-of-tomorrows-rawhide) packages on breakage. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Oct 30 13:15:24 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 30 Oct 2006 10:15:24 -0300 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: Your message of "Mon, 30 Oct 2006 11:58:34 BST." <4545DADA.3040600@poolshark.org> Message-ID: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> Denis Leroy wrote: [...] > And on the subject of a wiki page with available 3rd party > repositories, it certainly should only contain repos that are > *designed* to be add-on repos over FC and FE, in that order. If they are listed officially as "compatible with Fedora", what makes them "less official" than Extras? Better fold the packages into Extras, and be done with it. Unless they ship packages that Fedora can't/won't ship... in which case Fedora could end up in legal hot water for telling people how to break the law/go against the licenses (or at least end up in a very unconfortable position wrt its own guidelines). Perhaps it should be made easier to join Extras? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From pertusus at free.fr Mon Oct 30 13:38:37 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 30 Oct 2006 14:38:37 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> References: <4545DADA.3040600@poolshark.org> <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> Message-ID: <20061030133837.GA2268@free.fr> On Mon, Oct 30, 2006 at 10:15:24AM -0300, Horst H. von Brand wrote: > Denis Leroy wrote: > > [...] > > > And on the subject of a wiki page with available 3rd party > > repositories, it certainly should only contain repos that are > > *designed* to be add-on repos over FC and FE, in that order. > > If they are listed officially as "compatible with Fedora", what makes them > "less official" than Extras? Better fold the packages into Extras, and be > done with it. Unless they ship packages that Fedora can't/won't ship... in > which case Fedora could end up in legal hot water for telling people how to > break the law/go against the licenses (or at least end up in a very > unconfortable position wrt its own guidelines). This doesn't concern that much packages, and in that case there is livna. > Perhaps it should be made easier to join Extras? I don't think this is the issue. The third party repo maintainers won't certainly have hard time being sponsored. -- Pat From denis at poolshark.org Mon Oct 30 14:29:21 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 30 Oct 2006 15:29:21 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030125400.119558d6.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> Message-ID: <45460C41.7030007@poolshark.org> Michael Schwendt wrote: > That puts FE into a situation where we don't offer a working set of > packages as long as the remaining packages are still under review, but > which increases the risk that it breaks something our users have either > built themselves or downloaded from 3rd party repos. At fedora.us we've > always tried to publish complete dependency chains. Agreed, that seems common sense to me. Though of course we have to live with the limits of the review process. For example Michael, you're reviewing gideon which I submitted (as a side note, i just got renamed 'crow', i'll have updates soon), but has dependencies on 2 other packages from the same author which I had to submit for review and build separately (and update as well to match the version of gideon under review). Is there an alternative to a serial dependency chain like this ? Bulk, or group reviews ? If some 3rd party repo had gideon available, it would have been difficult to go through the review process for all 3 without causing a conflict at some point. > We should realise that FE is not "complete" (and won't ever be complete > with regard to the somet things). We should not make it more difficult for > 3rd party packagers, who have joined FE already, to transfer more of their > stuff to FE gradually while continuing to maintain their own repos. Right, assuming the transfer process has indeed started. In the repo we're talking about here, I'm openly questioning that fact. From denis at poolshark.org Mon Oct 30 14:38:47 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 30 Oct 2006 15:38:47 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> References: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> Message-ID: <45460E77.8090800@poolshark.org> Horst H. von Brand wrote: > Denis Leroy wrote: > > [...] > >> And on the subject of a wiki page with available 3rd party >> repositories, it certainly should only contain repos that are >> *designed* to be add-on repos over FC and FE, in that order. > > If they are listed officially as "compatible with Fedora", what makes them > "less official" than Extras? Better fold the packages into Extras, and be > done with it. Unless they ship packages that Fedora can't/won't ship... in > which case Fedora could end up in legal hot water for telling people how to > break the law/go against the licenses (or at least end up in a very > unconfortable position wrt its own guidelines). I think there's a little bit of taboo and FUD going on here. If you explain the issues at hand clearly (scope of software patents, open vs close source, etc...), I don't see why mentioning 3rd-party repos should be problematic. I mean, those repos don't distribute illegal copyrighted movies or something :-) From bugs.michael at gmx.net Mon Oct 30 15:18:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 16:18:26 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <45460C41.7030007@poolshark.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> Message-ID: <20061030161826.f408f106.bugs.michael@gmx.net> On Mon, 30 Oct 2006 15:29:21 +0100, Denis Leroy wrote: > Michael Schwendt wrote: > > That puts FE into a situation where we don't offer a working set of > > packages as long as the remaining packages are still under review, but > > which increases the risk that it breaks something our users have either > > built themselves or downloaded from 3rd party repos. At fedora.us we've > > always tried to publish complete dependency chains. > > Agreed, that seems common sense to me. Though of course we have to live > with the limits of the review process. For example Michael, you're > reviewing gideon which I submitted (as a side note, i just got renamed > 'crow', i'll have updates soon), but has dependencies on 2 other > packages from the same author which I had to submit for review and build > separately (and update as well to match the version of gideon under > review). Is there an alternative to a serial dependency chain like this > ? Bulk, or group reviews ? If some 3rd party repo had gideon available, > it would have been difficult to go through the review process for all 3 > without causing a conflict at some point. There is a simple solution: --> All or nothing. <-- [...] Don't build pieces of a package-set just because they are approved already. Keep all dependencies in FE-ACCEPT state until the other packages in FE-REVIEW are approved, too. Consider FE-ACCEPT a freeze. Don't apply further updates, not even version upgrades, as that creates a moving target. You can do all that in CVS or in a private working-copy until the whole show is ready. When your reviewer approves a package from your set of packages, apparently it's good enough as a build requirement for the pending reviews, isn't it? At least the reviewer should have performed a test-build of the complete package-set to verify that everything works together. Among the things that slow down reviews are: * Reviewers, who demand minor version upgrades without pointing out any issues. * Packagers, who apply many changes to a package which have not been asked for. From tibbs at math.uh.edu Mon Oct 30 16:06:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 30 Oct 2006 10:06:11 -0600 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030125400.119558d6.bugs.michael@gmx.net> (Michael Schwendt's message of "Mon, 30 Oct 2006 12:54:00 +0100") References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> There's still no reason to release partial dependency-chains into MS> Fedora Extras after less than 24 hours between a sudden upgrade to MS> a beta and the approval. So it sounds to me like we should concentrate on what went wrong in this instance instead of ballooning the discussion into a flamewar over what (if anything) Fedora needs to do to to accommodate other repositories. - J< From tibbs at math.uh.edu Mon Oct 30 16:10:37 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 30 Oct 2006 10:10:37 -0600 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> (Horst H. von Brand's message of "Mon, 30 Oct 2006 10:15:24 -0300") References: <200610301315.k9UDFOtj004460@laptop13.inf.utfsm.cl> Message-ID: >>>>> "HHvB" == Horst H von Brand writes: HHvB> Perhaps it should be made easier to join Extras? Is it really that difficult? Submit some packages, get reviews and sponsorship, check in? Any maintainer of an external repository should have a sufficient body of work that sponsorship should be easy to obtain. Unless, of course, the quality of the packages is substandard, but then I doubt anyone seriously argues for relaxing that restriction. - J< From eric.tanguy at univ-nantes.fr Mon Oct 30 17:12:54 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 30 Oct 2006 18:12:54 +0100 Subject: find-lang.sh syntax Message-ID: <1162228374.3737.16.camel@bureau.maison> In a spec file i found : %find_lang %{name} --all-name which is translated to /usr/lib/rpm/redhat/find-lang.sh %{buildroot} %{name} --all-name but during the build process i obtain this error message : + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root ruby-gettext --all-name grep: unrecognized option `--all-name' Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. No translations found for ruby-gettext in /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root it seems that --all-name is an unrecognized option but looking inside the script it's a valid option but maybe i don't understand or use it well. Someone could help me ? Eric From ville.skytta at iki.fi Mon Oct 30 17:27:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 30 Oct 2006 19:27:19 +0200 Subject: find-lang.sh syntax In-Reply-To: <1162228374.3737.16.camel@bureau.maison> References: <1162228374.3737.16.camel@bureau.maison> Message-ID: <1162229239.3109.7.camel@viper.local> On Mon, 2006-10-30 at 18:12 +0100, Tanguy Eric wrote: > + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root ruby-gettext --all-name ^^^^^^ [...] > it seems that --all-name is an unrecognized option Yep, it's only in /usr/lib/rpm/find-lang.sh, not /usr/lib/rpm/redhat/find-lang.sh. Looks like the version in redhat-rpm-config lags behind the one in rpm-build - would you mind filing a bug against redhat-rpm-config about it? From eric.tanguy at univ-nantes.fr Mon Oct 30 17:39:15 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 30 Oct 2006 18:39:15 +0100 Subject: find-lang.sh syntax In-Reply-To: <1162229239.3109.7.camel@viper.local> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> Message-ID: <1162229955.3005.3.camel@bureau.maison> Le lundi 30 octobre 2006 ? 19:27 +0200, Ville Skytt? a ?crit : > On Mon, 2006-10-30 at 18:12 +0100, Tanguy Eric wrote: > > > + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root ruby-gettext --all-name > ^^^^^^ > [...] > > it seems that --all-name is an unrecognized option > > Yep, it's only in /usr/lib/rpm/find-lang.sh, > not /usr/lib/rpm/redhat/find-lang.sh. Looks like the version in > redhat-rpm-config lags behind the one in rpm-build - would you mind > filing a bug against redhat-rpm-config about it? > Yes it's done https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213041 but how to solve this to achieve to build my package locally ? I have to wait this bug will be corrected ? Eric From nicolas.mailhot at laposte.net Mon Oct 30 18:00:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 30 Oct 2006 19:00:46 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030161826.f408f106.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> Message-ID: <1162231246.16192.37.camel@rousalka.dyndns.org> Le lundi 30 octobre 2006 ? 16:18 +0100, Michael Schwendt a ?crit : > There is a simple solution: --> All or nothing. <-- > > [...] > > Don't build pieces of a package-set just because they are approved > already. Keep all dependencies in FE-ACCEPT state until the other packages > in FE-REVIEW are approved, too. It's simple but stupid. 1. The dependencies won't conflict less when released later, you're only maximizing the pain by releasing packages which never had exposure separately. 2. You're needlessly maximising bureaucratic inertia. Dependencies often have worth by themselves, either for other FE packages or for people running unpackaged stuff in the wild. For example a few years ago I packaged most amavisd-new deps which certainly helped when amavisd-new was packaged by someone else. Your rule would have forced the amavisd-new packager to start from scratch. 3. You're rewarding the people who don't get their packages reviewed and penalise people who follow the appropriate process. At most, 3rd party maintainers could be allowed to ask in a review for a grace period after a package is approved (this grace-period being non-reconductible and with a fixed maximum). I say at most because as in any FLOSS project the people doing the work get to decide, and in this case the person submitting his package is the one doing the work. This is the same for Fedora, kernel patches, whatever. And it's *fair*. You want something packaged a certain way you do the packaging first. You build a userbase outside of the normal process with packages that can't be imported as-is (because they fail review rules?) Tough luck, not FE's problem, you knew the risks. -- Nicolas Mailhot From bugs.michael at gmx.net Mon Oct 30 18:10:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 19:10:33 +0100 Subject: find-lang.sh syntax In-Reply-To: <1162229955.3005.3.camel@bureau.maison> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> <1162229955.3005.3.camel@bureau.maison> Message-ID: <20061030191033.b5f093ee.bugs.michael@gmx.net> On Mon, 30 Oct 2006 18:39:15 +0100, Tanguy Eric wrote: > Le lundi 30 octobre 2006 ? 19:27 +0200, Ville Skytt? a ?crit : > > On Mon, 2006-10-30 at 18:12 +0100, Tanguy Eric wrote: > > > > > + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root ruby-gettext --all-name > > ^^^^^^ > > [...] > > > it seems that --all-name is an unrecognized option > > > > Yep, it's only in /usr/lib/rpm/find-lang.sh, > > not /usr/lib/rpm/redhat/find-lang.sh. Looks like the version in > > redhat-rpm-config lags behind the one in rpm-build - would you mind > > filing a bug against redhat-rpm-config about it? > > > Yes it's done > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213041 but how to > solve this to achieve to build my package locally ? I have to wait this > bug will be corrected ? It's likely a duplicate bug report, since I remember I've hit this before. In wesnoth.spec it still says: | %find_lang %{name}.\* | #/usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT %name --all-name | ... | %files -f %{name}.\*.lang The --all-name line is commented out. Depending on what kind of names you want to include, let me point out that instead of %{name} you can use a regular expression. The .lang filename becomes the same than the regular expression, so that is ugly (and dangerous due to * wildcards) but works. From eric.tanguy at univ-nantes.fr Mon Oct 30 18:21:02 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 30 Oct 2006 19:21:02 +0100 Subject: find-lang.sh syntax In-Reply-To: <20061030191033.b5f093ee.bugs.michael@gmx.net> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> <1162229955.3005.3.camel@bureau.maison> <20061030191033.b5f093ee.bugs.michael@gmx.net> Message-ID: <1162232462.3810.6.camel@bureau.maison> Le lundi 30 octobre 2006 ? 19:10 +0100, Michael Schwendt a ?crit : > On Mon, 30 Oct 2006 18:39:15 +0100, Tanguy Eric wrote: > > > Le lundi 30 octobre 2006 ? 19:27 +0200, Ville Skytt? a ?crit : > > > On Mon, 2006-10-30 at 18:12 +0100, Tanguy Eric wrote: > > > > > > > + /usr/lib/rpm/redhat/find-lang.sh /var/tmp/ruby-gettext-1.0.0-2.rcn.FC6-root ruby-gettext --all-name > > > ^^^^^^ > > > [...] > > > > it seems that --all-name is an unrecognized option > > > > > > Yep, it's only in /usr/lib/rpm/find-lang.sh, > > > not /usr/lib/rpm/redhat/find-lang.sh. Looks like the version in > > > redhat-rpm-config lags behind the one in rpm-build - would you mind > > > filing a bug against redhat-rpm-config about it? > > > > > Yes it's done > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213041 but how to > > solve this to achieve to build my package locally ? I have to wait this > > bug will be corrected ? > > It's likely a duplicate bug report, since I remember I've hit this > before. In wesnoth.spec it still says: > > | %find_lang %{name}.\* > | #/usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT %name --all-name > | ... > | %files -f %{name}.\*.lang > > The --all-name line is commented out. > > Depending on what kind of names you want to include, let me point out that > instead of %{name} you can use a regular expression. The .lang filename > becomes the same than the regular expression, so that is ugly (and > dangerous due to * wildcards) but works. > > My problem is i try to rebuild ruby-gettext package because it's still not in extras. The package name is ruby-gettext but the locales are : %{_datadir}/locale/*/LC_MESSAGES/rgettext.mo %{_datadir}/locale/*/LC_MESSAGES/rmsgfmt.mo so i'm not sure to understand how to manage this as i have also : %files -f %{name}.lang what do you think of this ? Eric From bugs.michael at gmx.net Mon Oct 30 19:02:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 20:02:16 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162231246.16192.37.camel@rousalka.dyndns.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> Message-ID: <20061030200216.dbeca49b.bugs.michael@gmx.net> On Mon, 30 Oct 2006 19:00:46 +0100, Nicolas Mailhot wrote: > Le lundi 30 octobre 2006 ? 16:18 +0100, Michael Schwendt a ?crit : > > > There is a simple solution: --> All or nothing. <-- > > > > [...] > > > > Don't build pieces of a package-set just because they are approved > > already. Keep all dependencies in FE-ACCEPT state until the other packages > > in FE-REVIEW are approved, too. > > It's simple but stupid. Great choice of language here. Either you have misunderstood me or you are out on a mission to insult other people. Or both. > 1. The dependencies won't conflict less when released later, you're only > maximizing the pain by releasing packages which never had exposure > separately. No, far from it. And there is nothing like "maximizing pain". You only try to play with words. Actually, in the majority of cases it is impossible to review individual pieces of a dependency-chain without taking a look at the entire set of packages. > 2. You're needlessly maximising bureaucratic inertia. Where? > Dependencies often > have worth by themselves, either for other FE packages or for people > running unpackaged stuff in the wild. You say "stupid", I say "nonsense". > For example a few years ago I > packaged most amavisd-new deps which certainly helped when amavisd-new > was packaged by someone else. Your rule would have forced the > amavisd-new packager to start from scratch. No. Please re-read and try again. > 3. You're rewarding the people who don't get their packages reviewed and > penalise people who follow the appropriate process. No. This comment is beyond my comprehension. Sounds like FUD. Try again. From bugs.michael at gmx.net Mon Oct 30 19:04:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 20:04:22 +0100 Subject: find-lang.sh syntax In-Reply-To: <1162232462.3810.6.camel@bureau.maison> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> <1162229955.3005.3.camel@bureau.maison> <20061030191033.b5f093ee.bugs.michael@gmx.net> <1162232462.3810.6.camel@bureau.maison> Message-ID: <20061030200422.6b4eaead.bugs.michael@gmx.net> On Mon, 30 Oct 2006 19:21:02 +0100, Tanguy Eric wrote: > > | %find_lang %{name}.\* > > | #/usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT %name --all-name > > | ... > > | %files -f %{name}.\*.lang > > > > The --all-name line is commented out. > > > > Depending on what kind of names you want to include, let me point out that > > instead of %{name} you can use a regular expression. The .lang filename > > becomes the same than the regular expression, so that is ugly (and > > dangerous due to * wildcards) but works. > > > > > > My problem is i try to rebuild ruby-gettext package because it's still > not in extras. The package name is ruby-gettext but the locales are : > %{_datadir}/locale/*/LC_MESSAGES/rgettext.mo > %{_datadir}/locale/*/LC_MESSAGES/rmsgfmt.mo > > so i'm not sure to understand how to manage this as i have also : > %files -f %{name}.lang > > what do you think of this ? %find r.\* %files -f r.\*.lang should work, although it's admittedly ugly. From eric.tanguy at univ-nantes.fr Mon Oct 30 19:16:55 2006 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 30 Oct 2006 20:16:55 +0100 Subject: find-lang.sh syntax In-Reply-To: <20061030200422.6b4eaead.bugs.michael@gmx.net> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> <1162229955.3005.3.camel@bureau.maison> <20061030191033.b5f093ee.bugs.michael@gmx.net> <1162232462.3810.6.camel@bureau.maison> <20061030200422.6b4eaead.bugs.michael@gmx.net> Message-ID: <1162235815.3093.4.camel@bureau.maison> Le lundi 30 octobre 2006 ? 20:04 +0100, Michael Schwendt a ?crit : > On Mon, 30 Oct 2006 19:21:02 +0100, Tanguy Eric wrote: > > > > > | %find_lang %{name}.\* > > > | #/usr/lib/rpm/find-lang.sh $RPM_BUILD_ROOT %name --all-name > > > | ... > > > | %files -f %{name}.\*.lang > > > > > > The --all-name line is commented out. > > > > > > Depending on what kind of names you want to include, let me point out that > > > instead of %{name} you can use a regular expression. The .lang filename > > > becomes the same than the regular expression, so that is ugly (and > > > dangerous due to * wildcards) but works. > > > > > > > > > > My problem is i try to rebuild ruby-gettext package because it's still > > not in extras. The package name is ruby-gettext but the locales are : > > %{_datadir}/locale/*/LC_MESSAGES/rgettext.mo > > %{_datadir}/locale/*/LC_MESSAGES/rmsgfmt.mo > > > > so i'm not sure to understand how to manage this as i have also : > > %files -f %{name}.lang > > > > what do you think of this ? > > %find r.\* > > %files -f r.\*.lang > > should work, although it's admittedly ugly. > In fact, i mv /usr/lib/rpm/redhat/find-lang.sh to /usr/lib/rpm/redhat/find-lang.sh.old and make ln -s /usr/lib/rpm/redhat/find-lang.sh /usr/lib/rpm/redhat/find-lang.sh and it works fine using --all-name option! thanks Eric From bugs.michael at gmx.net Mon Oct 30 19:55:11 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 20:55:11 +0100 Subject: find-lang.sh syntax In-Reply-To: <1162235815.3093.4.camel@bureau.maison> References: <1162228374.3737.16.camel@bureau.maison> <1162229239.3109.7.camel@viper.local> <1162229955.3005.3.camel@bureau.maison> <20061030191033.b5f093ee.bugs.michael@gmx.net> <1162232462.3810.6.camel@bureau.maison> <20061030200422.6b4eaead.bugs.michael@gmx.net> <1162235815.3093.4.camel@bureau.maison> Message-ID: <20061030205511.3d5b32ac.bugs.michael@gmx.net> On Mon, 30 Oct 2006 20:16:55 +0100, Tanguy Eric wrote: > > %find r.\* > > > > %files -f r.\*.lang > > > > should work, although it's admittedly ugly. > > > In fact, i mv /usr/lib/rpm/redhat/find-lang.sh > to /usr/lib/rpm/redhat/find-lang.sh.old and make ln > -s /usr/lib/rpm/redhat/find-lang.sh /usr/lib/rpm/redhat/find-lang.sh and > it works fine using --all-name option! You may execute the script with full path, but you must not move it from within a Fedora Extras package spec file, because the file is not in your build root. From nicolas.mailhot at laposte.net Mon Oct 30 20:23:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 30 Oct 2006 21:23:51 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030200216.dbeca49b.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> Message-ID: <1162239832.16192.89.camel@rousalka.dyndns.org> Le lundi 30 octobre 2006 ? 20:02 +0100, Michael Schwendt a ?crit : > On Mon, 30 Oct 2006 19:00:46 +0100, Nicolas Mailhot wrote: > > > Le lundi 30 octobre 2006 ? 16:18 +0100, Michael Schwendt a ?crit : > > > > > There is a simple solution: --> All or nothing. <-- > > > > > > [...] > > > > > > Don't build pieces of a package-set just because they are approved > > > already. Keep all dependencies in FE-ACCEPT state until the other packages > > > in FE-REVIEW are approved, too. > > > > It's simple but stupid. > > Great choice of language here. Either you have misunderstood me or you are > out on a mission to insult other people. Or both. I'll admit to being in a foul mood, part of which being caused by yet another message trying to 'fix' the non-broken part of last week's conflict, and that after a lot of people tried very hard not to feed the flames by keeping quiet. > > 1. The dependencies won't conflict less when released later, you're only > > maximizing the pain by releasing packages which never had exposure > > separately. > > No, far from it. And there is nothing like "maximizing pain". You only try > to play with words. No I don't. When you release twenty conflicting packages at once instead of releasing them as they are approved you are maximizing pain. There's a reason for the "release early, release often" rule. After a certain amount of changes forks just become entrenched because it's so many things to change at once before merging with mainline. > Actually, in the majority of cases it is impossible to review individual > pieces of a dependency-chain without taking a look at the entire set of > packages. Integration is good but package sanity is more tricky. If pieces of something are released separately that does mean maybe 80 to 90% of the packaging can be reviewed separately. Also the best test for integration is to release parts of a dependency chains and get feedback on how these parts are integrated by other entities (end-users, 3rd-party repositories, etc). > > 2. You're needlessly maximising bureaucratic inertia. > > Where? Packagers already complain the process takes too long. Have packagers wait for the last of a dependency set to be approved before releasing means we'll have even more dropouts before the review ends. > > Dependencies often > > have worth by themselves, either for other FE packages or for people > > running unpackaged stuff in the wild. > > You say "stupid", I say "nonsense". 1. Take any system running an unpackaged app (don't pretend no such thing exists) 2. Strip it of all the packaged components the app uses and force its admin to install them separately (no problem since you maintain the packaged deps have no value to the sysadmin) 3. If the sysadmin let you live, come back to report. > > For example a few years ago I > > packaged most amavisd-new deps which certainly helped when amavisd-new > > was packaged by someone else. Your rule would have forced the > > amavisd-new packager to start from scratch. > > No. Please re-read and try again. Please look at the amavisd-new ecosystem release timeline and come back. The full process took months if not years. I would *not* be maintaining part of the amavisd dependencies today if I had been forced to wait for amavisd-new approval before release. > > 3. You're rewarding the people who don't get their packages reviewed and > > penalise people who follow the appropriate process. > > No. This comment is beyond my comprehension. Sounds like FUD. > Try again. Any time you make the FE release process longer and more difficult you just prove right the people who insist it's too hard and you can't blame them for setting their own 3rd-party repositories. Approved is approved. *IF* you're reviewing all the packages in a packageset *AND* you feel you need the big picture you should not approve them separately. Now if a reviewer feels he can OK one bit of a packageset separately, one should not invoke "packageset veto" to block him. -- Nicolas Mailhot From bpepple at fedoraproject.org Mon Oct 30 21:42:11 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 30 Oct 2006 16:42:11 -0500 Subject: Enhanced AWOL policy In-Reply-To: References: <45421851.1050903@leemhuis.info> Message-ID: <1162244531.17414.24.camel@Chuck> On Fri, 2006-10-27 at 18:29 +0200, Paul Wouters wrote: The maintainers are encouraged to maintain their Vacation file, but people who want to change a package are not instructed to check that Vacatin file. I think this is a good idea. I've gone ahead and added your suggestion to the wiki. I would like to see a mention of "trying to find the maintainer on alternative email addresses". The maintainer (esp smaller ones who don't really read the fedora lists actively) might just have a broken email address, and might not be aware of it. This seems to me an unnecessary burden on the FE contributor using the AWOL policy, and before adding it to the policy I would like to hear from others on the list. /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 Mon Oct 30 22:26:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 23:26:40 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162239832.16192.89.camel@rousalka.dyndns.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> Message-ID: <20061030232640.b0029775.bugs.michael@gmx.net> On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote: > I'll admit to being in a foul mood, part of which being caused by yet > another message trying to 'fix' the non-broken part of last week's > conflict, and that after a lot of people tried very hard not to feed the > flames by keeping quiet. A couple of valid questions have been raised. And an upgrade to a beta release with an approval in less than 24 hours is something that is broken. In particular since with a rushed release of beta-level pieces you increase the risk of breaking even _compatible_ 3rd party repositories. And your hands are empty, so you cannot even recommend a downgrade or disabling the 3rd party repo. All you can do is shake your head and say: "Sorry, Joe User, we're not ready yet. You need to disable Fedora Extras and check back as soon as the remaining packages are ready. When that is, we don't know." Oh man, if you think you are in "a foul mood", I'm surprised that these days I find myself argueing *for* 3rd party repositories instead of defending FE's right to include and publish whatever we want. And that is only because I dislike the way fragments are pushed out to stable trees without being finished with the complete package-set. Instead of practising sane release habits in order to gain experience for something like EPEL, we move closer to the infamous dumping-ground. > When you release twenty conflicting packages at once instead > of releasing them as they are approved you are maximizing pain. No, because then your hands are not empty. You have an approved complete set of packages which is expected to "just work". This is much better than pushing out fragments. > > Actually, in the majority of cases it is impossible to review individual > > pieces of a dependency-chain without taking a look at the entire set of > > packages. > > Integration is good but package sanity is more tricky. If pieces of > something are released separately that does mean maybe 80 to 90% of the > packaging can be reviewed separately. Also the best test for integration > is to release parts of a dependency chains and get feedback on how these > parts are integrated by other entities (end-users, 3rd-party > repositories, etc). The same feedback that started this thread? If we really expect integration by 3rd party repositories, we ought not jump to beta releases so suddenly. > > > 2. You're needlessly maximising bureaucratic inertia. > > > > Where? > > Packagers already complain the process takes too long. > Have packagers wait for the last of a dependency set to be approved > before releasing means we'll have even more dropouts before the review > ends. Reviewers complain that many packages need a lot of work before they would be ready. And if packagers drop off that is because they don't show real interest in getting their packages right. Look at the many packages, which have no BuildRequires at all, because the packager does not know about this requirement. When all of a sudden the reviewer requests changes to a package, which seems to just build on the packager's system, guess how some people react. If everybody, who complains about the slowness of the review process, contributed a review occasionally, this would help. Ask yourself, how long is it since your last review? > 1. Take any system running an unpackaged app (don't pretend no such > thing exists) > 2. Strip it of all the packaged components the app uses and force its > admin to install them separately (no problem since you maintain the > packaged deps have no value to the sysadmin) > 3. If the sysadmin let you live, come back to report. If you come up with such examples, the sad truth is that so far we fail miserably, because we break ABIs (and not just ABIs) way too often with all those library major version upgrades, where we don't offer compatibility packages. Fact is: we still don't care about 3rd party packages or "unpackaged" end-user installations. We only care where cooperation and collaboration has been agreed on _actively_. Which is something which works with _every_ 3rd party repository out there, provided we are willing to do it and not slam the door right into someone's face. > > > For example a few years ago I > > > packaged most amavisd-new deps which certainly helped when amavisd-new > > > was packaged by someone else. Your rule would have forced the > > > amavisd-new packager to start from scratch. > > > > No. Please re-read and try again. > > Please look at the amavisd-new ecosystem release timeline and come back. > The full process took months if not years. I would *not* be maintaining > part of the amavisd dependencies today if I had been forced to wait for > amavisd-new approval before release. Please take into account the very small number of contributors which processed hundreds of reviews and simply could not be everywhere. Several different concepts of getting more packagers to do reviews have been tried. Packagers have been encouraged to exchange reviews, packagers have been asked to collect feedback from interested users, so a single reviewer would not need to everything alone and could sign off the technical packaging and be done. And since you mention "months if not years", even packages, which are actively maintained and just wait for a review in bugzilla, often contain serious defects or pitfalls, simply because not even the packager attempts at reviewing his own package. > *IF* you're reviewing all the packages in a packageset *AND* you feel > you need the big picture you should not approve them separately. Now if > a reviewer feels he can OK one bit of a packageset separately, one > should not invoke "packageset veto" to block him. From now on I will look for ways to veto when I plan to review parts of a dep-chain and when I have reason to believe a package approval is rushed. The only alternative is to stop reviewing. From bugs.michael at gmx.net Mon Oct 30 22:44:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 Oct 2006 23:44:33 +0100 Subject: Enhanced AWOL policy In-Reply-To: <1162244531.17414.24.camel@Chuck> References: <45421851.1050903@leemhuis.info> <1162244531.17414.24.camel@Chuck> Message-ID: <20061030234433.ef5035cb.bugs.michael@gmx.net> On Mon, 30 Oct 2006 16:42:11 -0500, Brian Pepple wrote: > I would like to see a mention of "trying to find the maintainer > on alternative email addresses". The maintainer (esp smaller > ones who don't really read the fedora lists actively) might just > have a broken email address, and might not be aware of it. > > This seems to me an unnecessary burden on the FE contributor using the > AWOL policy, and before adding it to the policy I would like to hear > from others on the list. Right. Don't add it. A maintainer, whose email is so broken that all messages end up in /dev/null without bouncing, most likely has lost contact with the project and hasn't received any list-traffic for several weeks either. The least such a maintainer ought to do is to submit bi-weekly queries for new bug reports. The responsibility to keep the important bugzilla email address in a working state should be on the maintainer's shoulders. Btw, is subscription of fedora-maintainers still mandatory? From bpepple at fedoraproject.org Mon Oct 30 22:57:59 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 30 Oct 2006 17:57:59 -0500 Subject: Enhanced AWOL policy In-Reply-To: <20061030234433.ef5035cb.bugs.michael@gmx.net> References: <45421851.1050903@leemhuis.info> <1162244531.17414.24.camel@Chuck> <20061030234433.ef5035cb.bugs.michael@gmx.net> Message-ID: <1162249079.20476.0.camel@Chuck> On Mon, 2006-10-30 at 23:44 +0100, Michael Schwendt wrote: > > Btw, is subscription of fedora-maintainers still mandatory? > Yes. /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 caillon at redhat.com Mon Oct 30 23:02:53 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 30 Oct 2006 18:02:53 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030232640.b0029775.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> Message-ID: <4546849D.8020600@redhat.com> Michael Schwendt wrote: > On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote: > > >> I'll admit to being in a foul mood, part of which being caused by yet >> another message trying to 'fix' the non-broken part of last week's >> conflict, and that after a lot of people tried very hard not to feed the >> flames by keeping quiet. >> > > A couple of valid questions have been raised. And an upgrade to a beta > release with an approval in less than 24 hours is something that is > broken. Not necessarily. There can be valid reasons to do so. Major security problems in the old one can be a valid reason. The old package might violate some sort of patent or copyright or trademark which has been fixed in the beta. Probably other reasons, too. From bugs.michael at gmx.net Mon Oct 30 23:30:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 00:30:55 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <4546849D.8020600@redhat.com> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> Message-ID: <20061031003055.d6aae014.bugs.michael@gmx.net> On Mon, 30 Oct 2006 18:02:53 -0500, Christopher Aillon wrote: > Michael Schwendt wrote: > > On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote: > > > > > >> I'll admit to being in a foul mood, part of which being caused by yet > >> another message trying to 'fix' the non-broken part of last week's > >> conflict, and that after a lot of people tried very hard not to feed the > >> flames by keeping quiet. > >> > > > > A couple of valid questions have been raised. And an upgrade to a beta > > release with an approval in less than 24 hours is something that is > > broken. > > Not necessarily. There can be valid reasons to do so. Major security > problems in the old one can be a valid reason. The old package might > violate some sort of patent or copyright or trademark which has been > fixed in the beta. Probably other reasons, too. None of your examples is a valid reason, because all this is still during the Fedora Extras New Package Process when the package is _not_ included within Fedora Extras yet. We don't do reviews for packages which are part of Fedora Extras already. So the cases you've given do not depend on any prior approval. From tcallawa at redhat.com Mon Oct 30 23:36:10 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 30 Oct 2006 17:36:10 -0600 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031003055.d6aae014.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> Message-ID: <1162251370.7933.238.camel@dhcp-32-122.ord.redhat.com> On Tue, 2006-10-31 at 00:30 +0100, Michael Schwendt wrote: > On Mon, 30 Oct 2006 18:02:53 -0500, Christopher Aillon wrote: > > > Michael Schwendt wrote: > > > On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote: > > > > > > > > >> I'll admit to being in a foul mood, part of which being caused by yet > > >> another message trying to 'fix' the non-broken part of last week's > > >> conflict, and that after a lot of people tried very hard not to feed the > > >> flames by keeping quiet. > > >> > > > > > > A couple of valid questions have been raised. And an upgrade to a beta > > > release with an approval in less than 24 hours is something that is > > > broken. I think there are obviously valid and invalid reasons to have "beta" or "prerelease" versions of software in Fedora. Perhaps any packager wishing to go to a "beta" or "prerelease" should have to present their rationalization to the Fedora Packaging Committee/FESCO for approval? ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tibbs at math.uh.edu Tue Oct 31 00:18:20 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Oct 2006 18:18:20 -0600 Subject: Enhanced AWOL policy In-Reply-To: <1162244531.17414.24.camel@Chuck> References: <45421851.1050903@leemhuis.info> <1162244531.17414.24.camel@Chuck> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> This seems to me an unnecessary burden on the FE contributor using BP> the AWOL policy, and before adding it to the policy I would like BP> to hear from others on the list. I think that it would be an undue burden to make it a requirement to try to chase down alternative means of contact. Nothing prevents someone who is interested from doing that, of course, but the simple fact is that it is the responsibility of all maintainers to remain in contact with the project and to have a valid and working email address on file. - J< From bugs.michael at gmx.net Tue Oct 31 00:29:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 01:29:54 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162251370.7933.238.camel@dhcp-32-122.ord.redhat.com> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <1162251370.7933.238.camel@dhcp-32-122.ord.redhat.com> Message-ID: <20061031012954.102ff98f.bugs.michael@gmx.net> On Mon, 30 Oct 2006 17:36:10 -0600, Tom 'spot' Callaway wrote: > I think there are obviously valid and invalid reasons to have "beta" or > "prerelease" versions of software in Fedora. Perhaps any packager > wishing to go to a "beta" or "prerelease" should have to present their > rationalization to the Fedora Packaging Committee/FESCO for approval? As mentioned before somewhere in this thread, an explanation during review (and later in the spec %changelog) would suffice. From nicolas.mailhot at laposte.net Tue Oct 31 06:46:04 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 31 Oct 2006 07:46:04 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061030232640.b0029775.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> Message-ID: <1162277167.16192.109.camel@rousalka.dyndns.org> Le lundi 30 octobre 2006 ? 23:26 +0100, Michael Schwendt a ?crit : > On Mon, 30 Oct 2006 21:23:51 +0100, Nicolas Mailhot wrote: > > > I'll admit to being in a foul mood, part of which being caused by yet > > another message trying to 'fix' the non-broken part of last week's > > conflict, and that after a lot of people tried very hard not to feed the > > flames by keeping quiet. > > A couple of valid questions have been raised. And an upgrade to a beta > release with an approval in less than 24 hours is something that is > broken. In particular since with a rushed release of beta-level pieces you > increase the risk of breaking even _compatible_ 3rd party repositories. You'd be right if projects used strict versioning. Since the vast majority doesn't you're wrong. Also, this would not apply to devel Also your proposal is not answering the beta question at all. > And your hands are empty, so you cannot even recommend a downgrade or > disabling the 3rd party repo. You mean, you can't even do the kind of recommendation the same 3rd-party flamed about the week before this one ? > All you can do is shake your head and say: > "Sorry, Joe User, we're not ready yet. All you can do is shake your head and say: "Sorry, Joe User, this is being integrated in FE and your 3rd-party provider is not ready for the partial migration yet" > Instead of practising sane release habits in order to gain experience for > something like EPEL, we move closer to the infamous dumping-ground. Sane release habits include releasing beta versions, experimenting and generally not waiting till everything is cooked (and stale) before thinking about releasing. This is why RHEL relies on FC This is why FC relies on rawhide THis is why rawhide relies on p.r.c. experiements > > When you release twenty conflicting packages at once instead > > of releasing them as they are approved you are maximizing pain. > > No, because then your hands are not empty. You have an approved complete > set of packages which is expected to "just work". This is much better than > pushing out fragments. This will just result as with clamav in "FE released a set of packages using totally different conventions than me, it will never gracefully upgrade users of my repo, I'll maintain my fork ad vitam eternam then" > > > Actually, in the majority of cases it is impossible to review individual > > > pieces of a dependency-chain without taking a look at the entire set of > > > packages. > > > > Integration is good but package sanity is more tricky. If pieces of > > something are released separately that does mean maybe 80 to 90% of the > > packaging can be reviewed separately. Also the best test for integration > > is to release parts of a dependency chains and get feedback on how these > > parts are integrated by other entities (end-users, 3rd-party > > repositories, etc). > > The same feedback that started this thread? Yes. Thought it could have been more constructive > If we really expect integration by 3rd party repositories, we ought not > jump to beta releases so suddenly. > > > > > 2. You're needlessly maximising bureaucratic inertia. > > > > > > Where? > > > > Packagers already complain the process takes too long. > > Have packagers wait for the last of a dependency set to be approved > > before releasing means we'll have even more dropouts before the review > > ends. > > Reviewers complain that many packages need a lot of work before they would > be ready. And if packagers drop off that is because they don't show real > interest in getting their packages right. Look at the many packages, which > have no BuildRequires at all, because the packager does not know about > this requirement. When all of a sudden the reviewer requests changes to a > package, which seems to just build on the packager's system, guess how > some people react. So your magic bullet is allow anyone to freeze indefinitely a review by declaring it's part of a bigger packageset. > If everybody, who complains about the slowness of the review process, > contributed a review occasionally, this would help. > > Ask yourself, how long is it since your last review? 4 days actually > > 1. Take any system running an unpackaged app (don't pretend no such > > thing exists) > > 2. Strip it of all the packaged components the app uses and force its > > admin to install them separately (no problem since you maintain the > > packaged deps have no value to the sysadmin) > > 3. If the sysadmin let you live, come back to report. > > If you come up with such examples, the sad truth is that so far we fail > miserably, because we break ABIs (and not just ABIs) way too often with > all those library major version upgrades, where we don't offer > compatibility packages. So is it a yes or a no? > Fact is: we still don't care about 3rd party packages or "unpackaged" > end-user installations. So what is the problem with releasing partial packagesets again ? > We only care where cooperation and collaboration has been agreed on _actively_. Which is why I proposed to allow 3rd-paties interested in cooperation to request a non-extendable grace period in the review. This requires them to explicitely implicate themselves, instead of relying passively on the glacial pace of FE > And since you mention "months if not years", even packages, which are > actively maintained and just wait for a review in bugzilla, I'm not talking about actively maintained packages waiting for a review in bugzilla I'm talking about actively maintained packages which passed the review and are in FE. > > *IF* you're reviewing all the packages in a packageset *AND* you feel > > you need the big picture you should not approve them separately. Now if > > a reviewer feels he can OK one bit of a packageset separately, one > > should not invoke "packageset veto" to block him. > > From now on I will look for ways to veto when I plan to review parts of a > dep-chain and when I have reason to believe a package approval is > rushed. The only alternative is to stop reviewing. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Tue Oct 31 07:47:15 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 31 Oct 2006 08:47:15 +0100 Subject: New libgda and libgnomedb packages available for testing Message-ID: <4546FF83.6090700@hhs.nl> Hi, I've created packages of libgda and libgnomedb 1.99.1, these are not in FE-devel yet because they contains API changes and gnumeric can't compile against these new versions. For those interested here are the SRPMS: http://people.atrpms.net/~hdegoede/libgda-1.99.1-1.fc7.src.rpm http://people.atrpms.net/~hdegoede/libgnomedb-1.99.1-1.fc7.src.rpm Regards, Hans From nicolas.mailhot at laposte.net Tue Oct 31 09:55:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 31 Oct 2006 10:55:05 +0100 (CET) Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031003055.d6aae014.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> Message-ID: <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> Le Mar 31 octobre 2006 00:30, Michael Schwendt a ?crit : > On Mon, 30 Oct 2006 18:02:53 -0500, Christopher Aillon wrote: > >> Michael Schwendt wrote: >> > A couple of valid questions have been raised. And an upgrade to a beta >> > release with an approval in less than 24 hours is something that is >> > broken. >> >> Not necessarily. There can be valid reasons to do so. Major security >> problems in the old one can be a valid reason. The old package might >> violate some sort of patent or copyright or trademark which has been >> fixed in the beta. Probably other reasons, too. > > None of your examples is a valid reason, because all this is still during > the Fedora Extras New Package Process when the package is _not_ included > within Fedora Extras yet. So the FE review should approve the known-broken version of some software instead of the known-fixed/improved beta is that what you are saying ? The problem is not beta vs stable or 3rd party vs FE. The problem is staging releases so people can test at the appropriate time and are not surprised by the result. Stability of EPEL is ensured by exposure in FE first Stability of FE is ensured by exposure in FE devel first (*not* FCx will be released in one week, let's dump new versions of all my packages in FE devel now, but FCxT1 will be released in one week, let's put all my dangerous FE bits - new major versions, packaging changes, beta versions, whatever - in FE devel now). Creating a huge backlog of packages few people tested on a live system and that will be dumped in FE and EPEL simultaneously once the last review of the packageset is done won't help anyone. Ability to request grace periods in reviews or staging in devel first will help coordinate and test. Blocking on a magical "stable release" or "packageset review completed" event won't. People will just assume the magical event will occur later (sometimes even never, as Axel honestly stated), not review/test anything, and come back screaming bloody murder when the packageset is actually released. -- Nicolas Mailhot From bugs.michael at gmx.net Tue Oct 31 10:21:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 11:21:39 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <1162277167.16192.109.camel@rousalka.dyndns.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <1162277167.16192.109.camel@rousalka.dyndns.org> Message-ID: <20061031112139.685abc2d.bugs.michael@gmx.net> On Tue, 31 Oct 2006 07:46:04 +0100, Nicolas Mailhot wrote: > > A couple of valid questions have been raised. And an upgrade to a beta > > release with an approval in less than 24 hours is something that is > > broken. In particular since with a rushed release of beta-level pieces you > > increase the risk of breaking even _compatible_ 3rd party repositories. > > You'd be right if projects used strict versioning. Since the vast > majority doesn't you're wrong. > > Also, this would not apply to devel Said beta releases have been put into "stable", i.e. FC-5 and FC-6, immediately. Hence the stuff has NOT been given a chance to mature in devel, not even a few days, for observers to take notice of their addition to FE. > Also your proposal is not answering the beta question at all. What is it? That any community observers, who may have followed the status of the asterisk+deps reviews, all of a sudden needed to be unbelievably fast because after a long time of reviewing stable releases, there is a jump to a beta release which is approved in less than 24 hours. > > All you can do is shake your head and say: > > "Sorry, Joe User, we're not ready yet. > > All you can do is shake your head and say: "Sorry, Joe User, this is > being integrated in FE and your 3rd-party provider is not ready for the > partial migration yet" ?? Not yet? The 3rd party package provider has had a complete set of rpms for this software. > Sane release habits include releasing beta versions, experimenting and > generally not waiting till everything is cooked (and stale) before > thinking about releasing. Cheap talk, Nicolas, considering that none of this has given a chance to be post-reviewed in devel. > > No, because then your hands are not empty. You have an approved complete > > set of packages which is expected to "just work". This is much better than > > pushing out fragments. > > This will just result as with clamav in "FE released a set of packages > using totally different conventions than me, it will never gracefully > upgrade users of my repo, I'll maintain my fork ad vitam eternam then" No problem. Different package design can be a valid justification for somebody to offer alternative packages. This is not the same than offering only fragments, beta even. Beta fragments aim at increasing barriers. > So your magic bullet is allow anyone to freeze indefinitely a review by > declaring it's part of a bigger packageset. Freeze = good. Freeze = no moving target. Freeze = beneficial for the reviewer, who does more than suggesting tabs-to-spaces fixes. > > If everybody, who complains about the slowness of the review process, > > contributed a review occasionally, this would help. > > > > Ask yourself, how long is it since your last review? > > 4 days actually Which email address is that? FE-ACCEPT points to a single approval only. If you think this thread could be more constructive, simply jumping on the bandwagon of those, who complain about the slowness of the review process, is not constructive at all. Because it doesn't propose what should be done with all the pending packages, which are in serious need of fixes, and what could be done to lower hurdles for stock contributors (we've talked about it a long time ago, but have found that at least some items must be reviewed, so we cannot get rid of reviewing for long-time contributors or something like that). > > > 1. Take any system running an unpackaged app (don't pretend no such > > > thing exists) > > > 2. Strip it of all the packaged components the app uses and force its > > > admin to install them separately (no problem since you maintain the > > > packaged deps have no value to the sysadmin) > > > 3. If the sysadmin let you live, come back to report. > > > > If you come up with such examples, the sad truth is that so far we fail > > miserably, because we break ABIs (and not just ABIs) way too often with > > all those library major version upgrades, where we don't offer > > compatibility packages. > > So is it a yes or a no? It's an irrelevant example. Said sysadmin will be very annoyed by sudden upgrades to beta releases. Twisting words doesn't lead to anything at all. *If* we offer a library package, in good hope that some of our users creates a dependency on it (through software which is not in FE), we ought to cover this scenario in the packaging guidelines. > > Fact is: we still don't care about 3rd party packages or "unpackaged" > > end-user installations. > > So what is the problem with releasing partial packagesets again ? Either you're interested in improving the situation or not. In case you're not, don't enter a loop. > > We only care where cooperation and collaboration has been agreed on _actively_. > > Which is why I proposed to allow 3rd-paties interested in cooperation to > request a non-extendable grace period in the review. This requires them > to explicitely implicate themselves, instead of relying passively on the > glacial pace of FE Ah, a proposal. Now we come to something. ;) I'm not fond of the idea that arbitray people could request such a grace-period, as in fact anybody can add a comment in bugzilla already and express concerns or point out problems, provided that the chance is given (aka no blitz-reviews after sudden upgrades to beta releases!). It would be different if it were fellow FE contributors who could demand a grace-period. Earlier in this thread I've asked whether FESCo has looked at this conflict. My suggestion is that upgrades to beta releases must be explained in both the review ticket and within FE in spec %changelog. From bugs.michael at gmx.net Tue Oct 31 10:55:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 11:55:16 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> Message-ID: <20061031115516.649b27a2.bugs.michael@gmx.net> On Tue, 31 Oct 2006 10:55:05 +0100 (CET), Nicolas Mailhot wrote: > So the FE review should approve the known-broken version of some software > instead of the known-fixed/improved beta is that what you are saying ? What are you talking about? Nothing in https://bugzilla.redhat.com/177603 mentions anything which is broken. There has been a stable release offered for review for quite a long time, and it even has seen positive feedback. Can you explain what has happened in that ticket? The bottom half of your message adds some FUD, and I refuse to take the bait. From nicolas.mailhot at laposte.net Tue Oct 31 12:00:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 31 Oct 2006 13:00:35 +0100 (CET) Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031115516.649b27a2.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> Message-ID: <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> Le Mar 31 octobre 2006 11:55, Michael Schwendt a ?crit : > On Tue, 31 Oct 2006 10:55:05 +0100 (CET), Nicolas Mailhot wrote: > >> So the FE review should approve the known-broken version of some >> software >> instead of the known-fixed/improved beta is that what you are saying ? > > What are you talking about? I'm talking about the answer caillon wrote and you dismissed as irrelevant without exhibiting any sign of understanding. Since it does not seem I'm getting through and I'm getting fed up with being accused of FUD-ing I'll let other people pick up the exercise (the ones who didn't /dev/null the whole thread that is) -- Nicolas Mailhot From bugs.michael at gmx.net Tue Oct 31 12:46:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 13:46:20 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> Message-ID: <20061031134620.ac78b0df.bugs.michael@gmx.net> On Tue, 31 Oct 2006 13:00:35 +0100 (CET), Nicolas Mailhot wrote: > > Le Mar 31 octobre 2006 11:55, Michael Schwendt a ?crit : > > On Tue, 31 Oct 2006 10:55:05 +0100 (CET), Nicolas Mailhot wrote: > > > >> So the FE review should approve the known-broken version of some > >> software > >> instead of the known-fixed/improved beta is that what you are saying ? > > > > What are you talking about? > > I'm talking about the answer caillon wrote and you dismissed as irrelevant > without exhibiting any sign of understanding. Since it does not seem I'm > getting through and I'm getting fed up with being accused of FUD-ing I'll > let other people pick up the exercise (the ones who didn't /dev/null the > whole thread that is) It takes longer for me to get fed up with your style of putting words into my mouth. ;) Christopher Aillon pointed out some _general_ examples for why it may be necessary to package a beta release (e.g. because back-porting security fixes is not feasible or too time-consuming, or because a new major version replaces one or several build requirements which have legal issues). He did not explain why these packages, which _did not_ exist as older releases in Fedora Extras, were approved and built for the stable trees in less than a day. Most likely because too many pieces of this thread are ripped out of the context, it is not always clear whether we discuss general things or specific incidents. And whether the packages that started this thread were affected by major security problems or legal issues cannot be seen by reading the review tickets. Once they are included in FE, caillon's comment applies just fine. From nicolas.mailhot at laposte.net Tue Oct 31 12:59:04 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 31 Oct 2006 13:59:04 +0100 (CET) Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031112139.685abc2d.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <1162277167.16192.109.camel@rousalka.dyndns.org> <20061031112139.685abc2d.bugs.michael@gmx.net> Message-ID: <58223.192.54.193.51.1162299544.squirrel@rousalka.dyndns.org> Le Mar 31 octobre 2006 11:21, Michael Schwendt a ?crit : > Hence the stuff has NOT been given a chance to mature in devel, not even a > few days, for observers to take notice of their addition to FE. Hence it should have been put in devel to mature, instead of creating beta version rules or packageset freezes. I'll take a partial packageset composed of beta versions that took a beating in an actual repo any day over full packagesets of "stable" software fresh out of review. -- Nicolas Mailhot From buildsys at fedoraproject.org Tue Oct 31 13:45:24 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 Oct 2006 08:45:24 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-10-31 Message-ID: <20061031134524.93027152139@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 25 awstats-6.6-0.3.beta.fc7 brasero-0.5.0-1.fc7 childsplay-0.84.1-1.fc7 childsplay_plugins-0.84-1.fc7 codeblocks-1.0-0.11.20061029svn3157.fc7 contacts-0.1-6.20060813svn.fc7 dates-0.1-5.20060813svn.fc7 fslint-2.16-2.fc7 fuse-2.5.3-5.fc7 gaim-meanwhile-2.0.0-0.5.beta4.fc7 gnome-applet-timer-1.3.1-1.fc7 grhino-0.15.2-3.fc7 gtkwave-3.0.15-1.fc7 hugs98-2006.09-1.fc7 jd-1.8.0-0.4.cvs061030.fc7 kompose-0.5.3-7.fc7 liferea-1.0.25-3.fc7 mock-0.6.8-1.fc7 php-pecl-xdebug-2.0.0-0.2.RC1.fc7 plone-2.5.1-2.fc7 python-mutagen-1.8-1.fc7 python-tgfastdata-0.9a6-5.fc7 revelation-0.4.7-6.fc7 xfce4-genmon-plugin-3.0-1.fc7 yakuake-2.7.5-4.fc7 Packages built and released for Fedora Extras 6: 20 awstats-6.6-0.3.beta.fc6 brasero-0.5.0-1.fc6 childsplay-0.84.1-1.fc6 childsplay_plugins-0.84-1.fc6 codeblocks-1.0-0.11.20061029svn3157.fc6 fluxstyle-1.0.1-1.fc6 fslint-2.16-2.fc6 fuse-2.5.3-5.fc6 gaim-meanwhile-2.0.0-0.5.beta4.fc6 gnome-applet-timer-1.3.1-1.fc6 grhino-0.15.2-3.fc6 gtkwave-3.0.15-1.fc6 hugs98-2006.09-1.fc6 mock-0.6.8-1.fc6 php-pecl-xdebug-2.0.0-0.2.RC1.fc6 php-shout-0.9.1-1.fc6 plone-2.5.1-2.fc6 poedit-1.3.6-1.fc6 python-mutagen-1.8-1.fc6 python-tgfastdata-0.9a6-5.fc6 Packages built and released for Fedora Extras 5: 17 Invalid rebuild: php-eaccelerator-5.1.6_0.9.5-1.fc5 awstats-6.5-6.fc5 childsplay-0.84.1-1.fc5 childsplay_plugins-0.84-1.fc5 codeblocks-1.0-0.11.20061029svn3157.fc5 flumotion-0.2.2-2.fc5 fluxstyle-1.0.1-1.fc5 fslint-2.16-2.fc5 fuse-2.5.3-5.fc5 grhino-0.15.2-3.fc5 gtkwave-3.0.15-1.fc5 hugs98-2006.09-1.fc5 mock-0.6.8-1.fc5 php-pecl-xdebug-2.0.0-0.2.RC1.fc5 plone-2.5.1-2.fc5 poedit-1.3.6-1.fc5 python-mutagen-1.8-1.fc5 Packages built and released for Fedora Extras 4: 3 fuse-2.5.3-5.fc4 grhino-0.15.2-3.fc4 gtkwave-3.0.15-1.fc4 Packages built and released for Fedora Extras 3: 1 grhino-0.15.2-3.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Oct 31 13:59:56 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Oct 2006 14:59:56 +0100 Subject: Fedora Extras Package Build Report 2006-10-31 In-Reply-To: <20061031134524.93027152139@buildsys.fedoraproject.org> References: <20061031134524.93027152139@buildsys.fedoraproject.org> Message-ID: <20061031145956.378ec2aa@python3.es.egwn.lan> buildsys at fedoraproject.org wrote : > Packages built and released for Fedora Extras 5: 17 > > Invalid rebuild: php-eaccelerator-5.1.6_0.9.5-1.fc5 Hmm, seems like ugly hack in the version doesn't play nice with the build system. For FC5 I can see a 5.1.6_* source package, but only 5.1.4_* binary packages :-/ The Oct 16 5.1.6_* rebuild should have produced matching binary packages... Either manual cleanup should be done, or I can just bump the release and see how things go now... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2798.fc6 Load : 2.94 3.94 4.33 From buildsys at fedoraproject.org Tue Oct 31 14:51:40 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 31 Oct 2006 14:51:40 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-10-31 Message-ID: <20061031145140.28305.37664@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de blender - 2.42a-4.fc6.i386 (4 days) blender - 2.42a-4.fc6.ppc (4 days) blender - 2.42a-4.fc6.x86_64 (4 days) adrian AT lisas.de fbida - 2.06-2.fc6.i386 fbida - 2.06-2.fc6.ppc fbida - 2.06-2.fc6.x86_64 grip - 1:3.2.0-13.fc6.i386 grip - 1:3.2.0-13.fc6.ppc grip - 1:3.2.0-13.fc6.x86_64 andreas.bierfert AT lowlatency.de centericq - 4.21.0-8.fc6.i386 centericq - 4.21.0-8.fc6.ppc centericq - 4.21.0-8.fc6.x86_64 libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (3 days) libopensync-plugin-evolution2 - 0.19-1.fc6.i386 (3 days) libopensync-plugin-evolution2 - 0.19-1.fc6.ppc (3 days) libopensync-plugin-evolution2 - 0.19-1.fc6.x86_64 (3 days) orange - 0.3-3.cvs20051118.fc6.i386 (7 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.i386 (31 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.ppc (31 days) sylpheed-claws-plugins-etpan-privacy - 2.3.0-2.fc4.x86_64 (31 days) sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 andreas AT bawue.net icecast - 2.3.1-3.fc6.i386 icecast - 2.3.1-3.fc6.ppc icecast - 2.3.1-3.fc6.x86_64 xmms-scrobbler - 0.3.8.1-2.fc6.i386 xmms-scrobbler - 0.3.8.1-2.fc6.ppc xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 chabotc AT xs4all.nl rtorrent - 0.6.2-4.fc6.i386 rtorrent - 0.6.2-4.fc6.ppc rtorrent - 0.6.2-4.fc6.x86_64 chrisw AT redhat.com git-core - 1.4.2.4-1.fc6.i386 git-core - 1.4.2.4-1.fc6.ppc git-core - 1.4.2.4-1.fc6.x86_64 dakingun AT gmail.com gnomesword - 2.1.6-5.fc6.i386 gnomesword - 2.1.6-5.fc6.ppc gnomesword - 2.1.6-5.fc6.x86_64 sword - 1.5.8-10.fc6.i386 sword - 1.5.8-10.fc6.i386 sword - 1.5.8-10.fc6.ppc sword - 1.5.8-10.fc6.x86_64 dcbw AT redhat.com plague - 0.4.4.1-2.fc3.noarch (46 days) plague - 0.4.4.1-2.fc3.noarch (46 days) plague - 0.4.4.1-2.fc4.noarch (46 days) plague - 0.4.4.1-2.fc4.noarch (46 days) plague - 0.4.4.1-2.fc4.noarch (46 days) endur AT bennewitz.com streamtuner - 0.99.99-13.fc6.i386 streamtuner - 0.99.99-13.fc6.i386 streamtuner - 0.99.99-13.fc6.ppc streamtuner - 0.99.99-13.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de xmlrpc-c - 1.06.05-2.fc6.i386 xmlrpc-c - 1.06.05-2.fc6.i386 xmlrpc-c - 1.06.05-2.fc6.ppc xmlrpc-c - 1.06.05-2.fc6.x86_64 xmlrpc-c-apps - 1.06.05-2.fc6.i386 xmlrpc-c-apps - 1.06.05-2.fc6.ppc xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 gemi AT bluewin.ch q - 7.4-1.fc6.i386 q - 7.4-1.fc6.ppc green AT redhat.com raptor - 1.4.9-5.fc6.i386 raptor - 1.4.9-5.fc6.i386 raptor - 1.4.9-5.fc6.ppc raptor - 1.4.9-5.fc6.x86_64 hamzy AT us.ibm.com sblim-wbemcli - 1.5.1-4.fc6.i386 sblim-wbemcli - 1.5.1-4.fc6.ppc sblim-wbemcli - 1.5.1-4.fc6.x86_64 hugo AT devin.com.br xmoto - 0.2.0-1.fc6.i386 xmoto - 0.2.0-1.fc6.ppc xmoto - 0.2.0-1.fc6.x86_64 ianburrell AT gmail.com jigdo - 0.7.3-2.fc6.i386 jigdo - 0.7.3-2.fc6.ppc jigdo - 0.7.3-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-ide_smart - 1.4.3-20.fc4.i386 (6 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.ppc (6 days) nagios-plugins-ide_smart - 1.4.3-20.fc4.x86_64 (6 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (22 days) linphone - 1.2.0-4.fc5.ppc (22 days) linphone - 1.2.0-4.fc5.x86_64 (22 days) linphone - 1.2.0-7.fc6.i386 (7 days) linphone - 1.2.0-7.fc6.ppc (7 days) linphone - 1.2.0-7.fc6.x86_64 (7 days) lmacken AT redhat.com deskbar-applet - 2.16.0-1.fc6.i386 (3 days) deskbar-applet - 2.16.0-1.fc6.ppc (3 days) deskbar-applet - 2.16.0-1.fc6.x86_64 (3 days) matthias AT rpmforge.net camE - 1.9-7.fc6.i386 (6 days) camE - 1.9-7.fc6.ppc (6 days) camE - 1.9-7.fc6.x86_64 (6 days) mr.ecik AT gmail.com kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.i386 kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.ppc kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.x86_64 nphilipp AT redhat.com bzflag - 2.0.8-3.fc6.i386 bzflag - 2.0.8-3.fc6.ppc bzflag - 2.0.8-3.fc6.x86_64 oliver AT linux-kernel.at syck-php - 0.55-9.fc5.i386 (12 days) syck-php - 0.55-9.fc5.ppc (12 days) syck-php - 0.55-9.fc5.x86_64 (12 days) paul AT city-fan.org gtorrentviewer - 0.2b-12.fc6.i386 gtorrentviewer - 0.2b-12.fc6.ppc gtorrentviewer - 0.2b-12.fc6.x86_64 pertusus AT free.fr dap-freeform_handler - 3.7.2-2.fc6.i386 dap-freeform_handler - 3.7.2-2.fc6.ppc dap-freeform_handler - 3.7.2-2.fc6.x86_64 dap-hdf4_handler - 3.7.2-3.fc6.i386 dap-hdf4_handler - 3.7.2-3.fc6.ppc dap-hdf4_handler - 3.7.2-3.fc6.x86_64 dap-netcdf_handler - 3.7.3-2.fc6.i386 dap-netcdf_handler - 3.7.3-2.fc6.ppc dap-netcdf_handler - 3.7.3-2.fc6.x86_64 dap-server - 3.7.1-3.fc6.i386 dap-server - 3.7.1-3.fc6.ppc dap-server - 3.7.1-3.fc6.x86_64 grads - 1.9b4-17.fc6.i386 grads - 1.9b4-17.fc6.ppc grads - 1.9b4-17.fc6.x86_64 libdap - 3.7.2-2.fc6.i386 libdap - 3.7.2-2.fc6.i386 libdap - 3.7.2-2.fc6.ppc libdap - 3.7.2-2.fc6.x86_64 libnc-dap - 3.6.2-4.fc6.i386 libnc-dap - 3.6.2-4.fc6.i386 libnc-dap - 3.6.2-4.fc6.ppc libnc-dap - 3.6.2-4.fc6.x86_64 petersen AT redhat.com darcs - 1.0.8-3.fc6.i386 darcs - 1.0.8-3.fc6.ppc darcs - 1.0.8-3.fc6.x86_64 qspencer AT ieee.org octave-forge - 2006.07.09-7.fc6.i386 octave-forge - 2006.07.09-7.fc6.ppc octave-forge - 2006.07.09-7.fc6.x86_64 rdieter AT math.unl.edu gift - 0.11.8.1-6.fc7.i386 (2 days) libtunepimp - 0.5.2-3.fc6.i386 libtunepimp - 0.5.2-3.fc6.i386 libtunepimp - 0.5.2-3.fc6.ppc libtunepimp - 0.5.2-3.fc6.x86_64 redhat-bugzilla AT camperquake.de audacious - 1.1.2-2.fc6.i386 audacious - 1.1.2-2.fc6.i386 audacious - 1.1.2-2.fc6.ppc audacious - 1.1.2-2.fc6.x86_64 stickster AT gmail.com drivel - 2.1.0-0.3.20060527cvs.fc6.i386 drivel - 2.1.0-0.3.20060527cvs.fc6.ppc drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 tcallawa AT redhat.com evolution-bogofilter - 0.2.0-3.fc6.i386 (3 days) evolution-bogofilter - 0.2.0-3.fc6.ppc (3 days) evolution-bogofilter - 0.2.0-3.fc6.x86_64 (3 days) gambas-gb-net-curl - 1.0.17-3.fc6.i386 (4 days) gambas-gb-net-curl - 1.0.17-3.fc6.ppc (4 days) gambas-runtime - 1.0.17-3.fc6.i386 (4 days) gambas-runtime - 1.0.17-3.fc6.ppc (4 days) wart AT kobold.org manaworld - 0.0.21-1.fc6.i386 manaworld - 0.0.21-1.fc6.ppc manaworld - 0.0.21-1.fc6.x86_64 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.ppc requires libcurl.so.3 blender-2.42a-4.fc6.ppc requires libgettextlib-0.14.6.so bzflag-2.0.8-3.fc6.ppc requires libcurl.so.3 camE-1.9-7.fc6.ppc requires libcurl.so.3 centericq-4.21.0-8.fc6.ppc requires libcurl.so.3 dap-freeform_handler-3.7.2-2.fc6.ppc requires libcurl.so.3 dap-hdf4_handler-3.7.2-3.fc6.ppc requires libcurl.so.3 dap-netcdf_handler-3.7.3-2.fc6.ppc requires libcurl.so.3 dap-server-3.7.1-3.fc6.ppc requires libcurl.so.3 darcs-1.0.8-3.fc6.ppc requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.ppc requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.ppc requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.ppc requires libedataserver-1.2.so.7 fbida-2.06-2.fc6.ppc requires libcurl.so.3 gambas-gb-net-curl-1.0.17-3.fc6.ppc requires libcurl.so.3 gambas-runtime-1.0.17-3.fc6.ppc requires libgettextlib-0.14.6.so git-core-1.4.2.4-1.fc6.ppc requires libcurl.so.3 gnomesword-2.1.6-5.fc6.ppc requires libcurl.so.3 grads-1.9b4-17.fc6.ppc requires libcurl.so.3 grip-1:3.2.0-13.fc6.ppc requires libcurl.so.3 gtorrentviewer-0.2b-12.fc6.ppc requires libcurl.so.3 icecast-2.3.1-3.fc6.ppc requires libcurl.so.3 jigdo-0.7.3-2.fc6.ppc requires libcurl.so.3 kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.ppc requires libcurl.so.3 libdap-3.7.2-2.fc6.ppc requires libcurl.so.3 libnc-dap-3.6.2-4.fc6.ppc requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.ppc requires libedataserver-1.2.so.7 libtunepimp-0.5.2-3.fc6.ppc requires libcurl.so.3 manaworld-0.0.21-1.fc6.ppc requires libcurl.so.3 octave-forge-2006.07.09-7.fc6.ppc requires libcurl.so.3 q-7.4-1.fc6.ppc requires libcurl.so.3 raptor-1.4.9-5.fc6.ppc requires libcurl.so.3 rtorrent-0.6.2-4.fc6.ppc requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.ppc requires libcurl.so.3 streamtuner-0.99.99-13.fc6.ppc requires libcurl.so.3 sword-1.5.8-10.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.ppc requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.ppc requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.ppc requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.ppc requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.ppc requires libcurl.so.3 xmoto-0.2.0-1.fc6.ppc requires libcurl.so.3 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 audacious-1.1.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) blender-2.42a-4.fc6.x86_64 requires libgettextlib-0.14.6.so()(64bit) bzflag-2.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) camE-1.9-7.fc6.x86_64 requires libcurl.so.3()(64bit) centericq-4.21.0-8.fc6.x86_64 requires libcurl.so.3()(64bit) dap-freeform_handler-3.7.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) dap-hdf4_handler-3.7.2-3.fc6.x86_64 requires libcurl.so.3()(64bit) dap-netcdf_handler-3.7.3-2.fc6.x86_64 requires libcurl.so.3()(64bit) dap-server-3.7.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) darcs-1.0.8-3.fc6.x86_64 requires libcurl.so.3()(64bit) deskbar-applet-2.16.0-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) drivel-2.1.0-0.3.20060527cvs.fc6.x86_64 requires libcurl.so.3()(64bit) evolution-bogofilter-0.2.0-3.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) fbida-2.06-2.fc6.x86_64 requires libcurl.so.3()(64bit) gift-0.11.8.1-6.fc7.i386 requires libmagic.so.1 git-core-1.4.2.4-1.fc6.x86_64 requires libcurl.so.3()(64bit) gnomesword-2.1.6-5.fc6.x86_64 requires libcurl.so.3()(64bit) grads-1.9b4-17.fc6.x86_64 requires libcurl.so.3()(64bit) grip-1:3.2.0-13.fc6.x86_64 requires libcurl.so.3()(64bit) gtorrentviewer-0.2b-12.fc6.x86_64 requires libcurl.so.3()(64bit) icecast-2.3.1-3.fc6.x86_64 requires libcurl.so.3()(64bit) jigdo-0.7.3-2.fc6.x86_64 requires libcurl.so.3()(64bit) kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.x86_64 requires libcurl.so.3()(64bit) libdap-3.7.2-2.fc6.i386 requires libcurl.so.3 libdap-3.7.2-2.fc6.x86_64 requires libcurl.so.3()(64bit) libnc-dap-3.6.2-4.fc6.i386 requires libcurl.so.3 libnc-dap-3.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libopensync-plugin-evolution2-0.19-1.fc6.x86_64 requires libedataserver-1.2.so.7()(64bit) libtunepimp-0.5.2-3.fc6.i386 requires libcurl.so.3 libtunepimp-0.5.2-3.fc6.x86_64 requires libcurl.so.3()(64bit) manaworld-0.0.21-1.fc6.x86_64 requires libcurl.so.3()(64bit) octave-forge-2006.07.09-7.fc6.x86_64 requires libcurl.so.3()(64bit) orange-0.3-3.cvs20051118.fc6.i386 requires libmagic.so.1 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.x86_64 requires libcurl.so.3()(64bit) rtorrent-0.6.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sblim-wbemcli-1.5.1-4.fc6.x86_64 requires libcurl.so.3()(64bit) streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.x86_64 requires libcurl.so.3()(64bit) sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmlrpc-c-apps-1.06.05-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmms-scrobbler-0.3.8.1-2.fc6.x86_64 requires libcurl.so.3()(64bit) xmoto-0.2.0-1.fc6.x86_64 requires libcurl.so.3()(64bit) Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- audacious-1.1.2-2.fc6.i386 requires libcurl.so.3 blender-2.42a-4.fc6.i386 requires libgettextlib-0.14.6.so bzflag-2.0.8-3.fc6.i386 requires libcurl.so.3 camE-1.9-7.fc6.i386 requires libcurl.so.3 centericq-4.21.0-8.fc6.i386 requires libcurl.so.3 dap-freeform_handler-3.7.2-2.fc6.i386 requires libcurl.so.3 dap-hdf4_handler-3.7.2-3.fc6.i386 requires libcurl.so.3 dap-netcdf_handler-3.7.3-2.fc6.i386 requires libcurl.so.3 dap-server-3.7.1-3.fc6.i386 requires libcurl.so.3 darcs-1.0.8-3.fc6.i386 requires libcurl.so.3 deskbar-applet-2.16.0-1.fc6.i386 requires libedataserver-1.2.so.7 drivel-2.1.0-0.3.20060527cvs.fc6.i386 requires libcurl.so.3 evolution-bogofilter-0.2.0-3.fc6.i386 requires libedataserver-1.2.so.7 fbida-2.06-2.fc6.i386 requires libcurl.so.3 gambas-gb-net-curl-1.0.17-3.fc6.i386 requires libcurl.so.3 gambas-runtime-1.0.17-3.fc6.i386 requires libgettextlib-0.14.6.so git-core-1.4.2.4-1.fc6.i386 requires libcurl.so.3 gnomesword-2.1.6-5.fc6.i386 requires libcurl.so.3 grads-1.9b4-17.fc6.i386 requires libcurl.so.3 grip-1:3.2.0-13.fc6.i386 requires libcurl.so.3 gtorrentviewer-0.2b-12.fc6.i386 requires libcurl.so.3 icecast-2.3.1-3.fc6.i386 requires libcurl.so.3 jigdo-0.7.3-2.fc6.i386 requires libcurl.so.3 kadu-miastoplusa_sms-0.5.0-0.15.20060915svn.fc6.i386 requires libcurl.so.3 libdap-3.7.2-2.fc6.i386 requires libcurl.so.3 libnc-dap-3.6.2-4.fc6.i386 requires libcurl.so.3 libopensync-plugin-evolution2-0.19-1.fc6.i386 requires libedataserver-1.2.so.7 libtunepimp-0.5.2-3.fc6.i386 requires libcurl.so.3 manaworld-0.0.21-1.fc6.i386 requires libcurl.so.3 octave-forge-2006.07.09-7.fc6.i386 requires libcurl.so.3 q-7.4-1.fc6.i386 requires libcurl.so.3 raptor-1.4.9-5.fc6.i386 requires libcurl.so.3 rtorrent-0.6.2-4.fc6.i386 requires libcurl.so.3 sblim-wbemcli-1.5.1-4.fc6.i386 requires libcurl.so.3 streamtuner-0.99.99-13.fc6.i386 requires libcurl.so.3 sword-1.5.8-10.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-gtkhtml2-viewer-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-rssyl-2.5.2-4.fc6.i386 requires libcurl.so.3 sylpheed-claws-plugins-vcalendar-2.5.2-4.fc6.i386 requires libcurl.so.3 xmlrpc-c-1.06.05-2.fc6.i386 requires libcurl.so.3 xmlrpc-c-apps-1.06.05-2.fc6.i386 requires libcurl.so.3 xmms-scrobbler-0.3.8.1-2.fc6.i386 requires libcurl.so.3 xmoto-0.2.0-1.fc6.i386 requires libcurl.so.3 Broken packages in fedora-extras-6-ppc: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.ppc requires libortp.so.2 Broken packages in fedora-extras-6-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.x86_64 requires libortp.so.2()(64bit) Broken packages in fedora-extras-6-i386: ---------------------------------------------------------------------- linphone-1.2.0-7.fc6.i386 requires libortp.so.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.ppc requires libortp.so.2 syck-php-0.55-9.fc5.ppc requires php = 0:5.1.4 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) syck-php-0.55-9.fc5.x86_64 requires php = 0:5.1.4 Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- linphone-1.2.0-4.fc5.i386 requires libortp.so.2 syck-php-0.55-9.fc5.i386 requires php = 0:5.1.4 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.ppc requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.ppc requires libetpan.so.6 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.x86_64 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.x86_64 requires libetpan.so.6()(64bit) Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- nagios-plugins-ide_smart-1.4.3-20.fc4.i386 requires nagios-plugins = 0:1.4.3-20.fc4 plague-0.4.4.1-2.fc4.noarch requires createrepo >= 0:0.4.3 sylpheed-claws-plugins-etpan-privacy-2.3.0-2.fc4.i386 requires libetpan.so.6 Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- plague-0.4.4.1-2.fc3.noarch requires createrepo >= 0:0.4.3 ====================================================================== New report for: stickster AT gmail.com package: drivel - 2.1.0-0.3.20060527cvs.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: drivel - 2.1.0-0.3.20060527cvs.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: drivel - 2.1.0-0.3.20060527cvs.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: hugo AT devin.com.br package: xmoto - 0.2.0-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: xmoto - 0.2.0-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: xmoto - 0.2.0-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: hamzy AT us.ibm.com package: sblim-wbemcli - 1.5.1-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sblim-wbemcli - 1.5.1-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: sblim-wbemcli - 1.5.1-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: qspencer AT ieee.org package: octave-forge - 2006.07.09-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: octave-forge - 2006.07.09-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: octave-forge - 2006.07.09-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: dakingun AT gmail.com package: gnomesword - 2.1.6-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sword - 1.5.8-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sword - 1.5.8-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: sword - 1.5.8-10.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: gnomesword - 2.1.6-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: gnomesword - 2.1.6-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: sword - 1.5.8-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: rdieter AT math.unl.edu package: libtunepimp - 0.5.2-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: libtunepimp - 0.5.2-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: libtunepimp - 0.5.2-3.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: libtunepimp - 0.5.2-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: chabotc AT xs4all.nl package: rtorrent - 0.6.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: rtorrent - 0.6.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: rtorrent - 0.6.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: ianburrell AT gmail.com package: jigdo - 0.7.3-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: jigdo - 0.7.3-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: jigdo - 0.7.3-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: endur AT bennewitz.com package: streamtuner - 0.99.99-13.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: streamtuner - 0.99.99-13.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: streamtuner - 0.99.99-13.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: streamtuner - 0.99.99-13.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: green AT redhat.com package: raptor - 1.4.9-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: raptor - 1.4.9-5.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: raptor - 1.4.9-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: raptor - 1.4.9-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: adrian AT lisas.de package: fbida - 2.06-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: grip - 1:3.2.0-13.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: fbida - 2.06-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: grip - 1:3.2.0-13.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: grip - 1:3.2.0-13.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: fbida - 2.06-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: gemi AT bluewin.ch package: q - 7.4-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: q - 7.4-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: nphilipp AT redhat.com package: bzflag - 2.0.8-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: bzflag - 2.0.8-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: bzflag - 2.0.8-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: paul AT city-fan.org package: gtorrentviewer - 0.2b-12.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: gtorrentviewer - 0.2b-12.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: gtorrentviewer - 0.2b-12.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: andreas AT bawue.net package: icecast - 2.3.1-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: xmms-scrobbler - 0.3.8.1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: xmms-scrobbler - 0.3.8.1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: icecast - 2.3.1-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: xmms-scrobbler - 0.3.8.1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: icecast - 2.3.1-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: mr.ecik AT gmail.com package: kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: kadu-miastoplusa_sms - 0.5.0-0.15.20060915svn.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: chrisw AT redhat.com package: git-core - 1.4.2.4-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: git-core - 1.4.2.4-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: git-core - 1.4.2.4-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: enrico.scholz AT informatik.tu-chemnitz.de package: xmlrpc-c - 1.06.05-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: xmlrpc-c-apps - 1.06.05-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: xmlrpc-c - 1.06.05-2.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: xmlrpc-c - 1.06.05-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: xmlrpc-c-apps - 1.06.05-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: xmlrpc-c - 1.06.05-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: xmlrpc-c-apps - 1.06.05-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: centericq - 4.21.0-8.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: centericq - 4.21.0-8.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: centericq - 4.21.0-8.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-rssyl - 2.5.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-vcalendar - 2.5.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: sylpheed-claws-plugins-gtkhtml2-viewer - 2.5.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: wart AT kobold.org package: manaworld - 0.0.21-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: manaworld - 0.0.21-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: manaworld - 0.0.21-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: petersen AT redhat.com package: darcs - 1.0.8-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: darcs - 1.0.8-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: darcs - 1.0.8-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: pertusus AT free.fr package: dap-hdf4_handler - 3.7.2-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: libnc-dap - 3.6.2-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: dap-server - 3.7.1-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: grads - 1.9b4-17.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: libdap - 3.7.2-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: dap-freeform_handler - 3.7.2-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: dap-netcdf_handler - 3.7.3-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: dap-freeform_handler - 3.7.2-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: dap-server - 3.7.1-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: dap-netcdf_handler - 3.7.3-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: libnc-dap - 3.6.2-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: libdap - 3.7.2-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: dap-hdf4_handler - 3.7.2-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: grads - 1.9b4-17.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: libdap - 3.7.2-2.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: libnc-dap - 3.6.2-4.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: dap-netcdf_handler - 3.7.3-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: libnc-dap - 3.6.2-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: dap-freeform_handler - 3.7.2-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: dap-server - 3.7.1-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: libdap - 3.7.2-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: grads - 1.9b4-17.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 package: dap-hdf4_handler - 3.7.2-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 ====================================================================== New report for: redhat-bugzilla AT camperquake.de package: audacious - 1.1.2-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcurl.so.3 package: audacious - 1.1.2-2.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3 package: audacious - 1.1.2-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcurl.so.3()(64bit) package: audacious - 1.1.2-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcurl.so.3 From caillon at redhat.com Tue Oct 31 15:29:57 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 31 Oct 2006 10:29:57 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031134620.ac78b0df.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> <20061031134620.ac78b0df.bugs.michael@gmx.net> Message-ID: <45476BF5.7040300@redhat.com> Michael Schwendt wrote: > On Tue, 31 Oct 2006 13:00:35 +0100 (CET), Nicolas Mailhot wrote: > > >> Le Mar 31 octobre 2006 11:55, Michael Schwendt a ?crit : >> >>> On Tue, 31 Oct 2006 10:55:05 +0100 (CET), Nicolas Mailhot wrote: >>> >>> >>>> So the FE review should approve the known-broken version of some >>>> software >>>> instead of the known-fixed/improved beta is that what you are saying ? >>>> >>> What are you talking about? >>> >> I'm talking about the answer caillon wrote and you dismissed as irrelevant >> without exhibiting any sign of understanding. Since it does not seem I'm >> getting through and I'm getting fed up with being accused of FUD-ing I'll >> let other people pick up the exercise (the ones who didn't /dev/null the >> whole thread that is) >> > > It takes longer for me to get fed up with your style of putting words into > my mouth. ;) > > Christopher Aillon pointed out some _general_ examples for why it may be > necessary to package a beta release (e.g. because back-porting security > fixes is not feasible or too time-consuming, or because a new major > version replaces one or several build requirements which have legal > issues). > > He did not explain why these packages, which _did not_ exist as older > releases in Fedora Extras, were approved and built for the stable trees in > less than a day. > Because you are arguing about beta software. You seem to have no problem with non-beta software getting approved and built in a day. So once it's approved and built, it is the package owner's discretion to build a different version of a package, which may include so-called beta software. Argue about all software; don't single out beta software. From buildsys at fedoraproject.org Tue Oct 31 15:57:12 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 31 Oct 2006 10:57:12 -0500 (EST) Subject: Fedora Extras Package Build Report 2006-10-31 Message-ID: <20061031155712.476D6152139@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 1 php-eaccelerator-5.1.6_0.9.5-1.fc5 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 Tue Oct 31 16:00:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 17:00:42 +0100 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <45476BF5.7040300@redhat.com> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> <20061031134620.ac78b0df.bugs.michael@gmx.net> <45476BF5.7040300@redhat.com> Message-ID: <20061031170042.ee074675.bugs.michael@gmx.net> On Tue, 31 Oct 2006 10:29:57 -0500, Christopher Aillon wrote: > > Christopher Aillon pointed out some _general_ examples for why it may be > > necessary to package a beta release (e.g. because back-porting security > > fixes is not feasible or too time-consuming, or because a new major > > version replaces one or several build requirements which have legal > > issues). > > > > He did not explain why these packages, which _did not_ exist as older > > releases in Fedora Extras, were approved and built for the stable trees in > > less than a day. > > > Because you are arguing about beta software. You seem to have no > problem with non-beta software getting approved and built in a day. What makes you think so? I do dislike rushed reviews in general as often they are error-prone. That does not mean that I need to mix all that in this discussion. > So > once it's approved and built, it is the package owner's discretion to > build a different version of a package, which may include so-called beta > software. Yes, which is questionable and asks for adjusted guidelines. > Argue about all software; don't single out beta software. But we need to start somewhere... unless we want to see many more pre-release snapshots in Fedora Extras. From j.w.r.degoede at hhs.nl Tue Oct 31 16:42:12 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 31 Oct 2006 17:42:12 +0100 Subject: gkrellm update, please check your plugins Message-ID: <45477CE4.5050401@hhs.nl> Hi All, I've just requested a build of gkrellm-2.2.10 a new upstream release, for the devel branch only for now. The content of gkrellm-devel has no relevant changes, so I assume that plugins will keep working without problems, but if anything breaks please let me know, then I won't push this for FC-6. Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Oct 31 17:12:48 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Oct 2006 18:12:48 +0100 Subject: Fedora Extras Package Build Report 2006-10-31 In-Reply-To: <20061031155712.476D6152139@buildsys.fedoraproject.org> References: <20061031155712.476D6152139@buildsys.fedoraproject.org> Message-ID: <20061031181248.749a7ada@python3.es.egwn.lan> buildsys at fedoraproject.org wrote : > Packages built and released for Fedora Extras 5: 1 > > php-eaccelerator-5.1.6_0.9.5-1.fc5 To whoever pushed this package though : Thanks! :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2798.fc6 Load : 1.44 1.43 1.60 From peter at thecodergeek.com Tue Oct 31 20:07:39 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 31 Oct 2006 12:07:39 -0800 (PST) Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> Message-ID: <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> Piotr wrote: > Author: raven > [...] > Added Files: > dead.package > Log Message: > Added dead.package > > > --- NEW FILE dead.package --- > Obsolete package. No disrespect, but you really should explicate on this a bit more. I.e., Was it renamed? If so, what package supersedes it? If not, was its functionality incorporated into a another package? Did upstream disappear? Are there any Bugzilla references, etc.? Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From gemi at bluewin.ch Tue Oct 31 20:18:26 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 31 Oct 2006 21:18:26 +0100 Subject: gemi yum repository rebuilt for FC6 Message-ID: <1162325906.14333.2.camel@scriabin.tannenrauch.ch> The packages in the gemi repository at http://math.ifi.unizh.ch/fedora/ have been rebuilt for FC6. They are waiting for being picked up and submitted to FE. Some packages, such as Squeak, would have to go to livna or dribble, however. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jfontain at free.fr Tue Oct 31 20:20:16 2006 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 31 Oct 2006 21:20:16 +0100 Subject: is fc5 building closed? Message-ID: <4547B000.5050906@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just got the following result, whereas fc6 and fc7 work just fine: Prep Error (Job 20664): moodss-21_4-1_fc5 on fedora-5-extras Error: could not make srpm for moodss-21_4-1_fc5 - output was: make: *** No rule to make target `srpm'. Stop. Is that normal? - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFR6//kG/MMvcT1qQRAsczAJ4pZrMW0noDiwY+UVpR/+qBpQ3VVQCgkzTX 2J3MNC5rEnAYU3VHAoP2BS8= =5Pu7 -----END PGP SIGNATURE----- From raven at pmail.pl Tue Oct 31 20:32:34 2006 From: raven at pmail.pl (=?UTF-8?B?IlBpb3RyIFwiUmF2ZW5cIiBEcsSFZyI=?=) Date: Tue, 31 Oct 2006 21:32:34 +0100 Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> Message-ID: <4547B2E2.5070108@pmail.pl> Peter Gordon napisa?(a): > No disrespect, but you really should explicate on this a bit more. > I.e., Was it renamed? If so, what package supersedes it? If not, was > its functionality incorporated into a another package? Did upstream > disappear? Are there any Bugzilla references, etc.? > Gadu-Gadu support is now included in gaim package, so gaim-gadugadu is unnecessary. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209000 -- Piotr "Raven" Dr?g From ville.skytta at iki.fi Tue Oct 31 20:43:42 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 31 Oct 2006 22:43:42 +0200 Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <4547B2E2.5070108@pmail.pl> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> <4547B2E2.5070108@pmail.pl> Message-ID: <1162327422.20102.3.camel@viper.local> On Tue, 2006-10-31 at 21:32 +0100, "Piotr \"Raven\" Dr?g" wrote: > Peter Gordon napisa?(a): > > No disrespect, but you really should explicate on this a bit more. > > I.e., Was it renamed? If so, what package supersedes it? If not, was > > its functionality incorporated into a another package? Did upstream > > disappear? Are there any Bugzilla references, etc.? > > > > Gadu-Gadu support is now included in gaim package, so gaim-gadugadu is > unnecessary. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209000 Adding this information to the dead.package files in CVS would not be a bad idea. From raven at pmail.pl Tue Oct 31 20:59:46 2006 From: raven at pmail.pl (=?UTF-8?B?IlBpb3RyIFwiUmF2ZW5cIiBEcsSFZyI=?=) Date: Tue, 31 Oct 2006 21:59:46 +0100 Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <1162327422.20102.3.camel@viper.local> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> <4547B2E2.5070108@pmail.pl> <1162327422.20102.3.camel@viper.local> Message-ID: <4547B942.1000709@pmail.pl> Ville Skytt? napisa?(a): > Adding this information to the dead.package files in CVS would not be a > bad idea. > It's OK now? -- Piotr "Raven" Dr?g From rdieter at math.unl.edu Tue Oct 31 21:22:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 31 Oct 2006 15:22:40 -0600 Subject: is fc5 building closed? References: <4547B000.5050906@free.fr> Message-ID: Jean-Luc Fontaine wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I just got the following result, whereas fc6 and fc7 work just fine: > > Prep Error (Job 20664): moodss-21_4-1_fc5 on fedora-5-extras > Error: could not make srpm for moodss-21_4-1_fc5 - output was: > make: *** No rule to make target `srpm'. Stop. > > Is that normal? Not normal, buildsys make be borked. -- Rex From ville.skytta at iki.fi Tue Oct 31 22:08:01 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 01 Nov 2006 00:08:01 +0200 Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <4547B942.1000709@pmail.pl> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> <4547B2E2.5070108@pmail.pl> <1162327422.20102.3.camel@viper.local> <4547B942.1000709@pmail.pl> Message-ID: <1162332481.20102.8.camel@viper.local> On Tue, 2006-10-31 at 21:59 +0100, "Piotr \"Raven\" Dr?g" wrote: > Ville Skytt? napisa?(a): > > Adding this information to the dead.package files in CVS would not be a > > bad idea. > > > > It's OK now? Yep, looks good to me. From dcbw at redhat.com Tue Oct 31 22:22:14 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 17:22:14 -0500 Subject: is fc5 building closed? In-Reply-To: References: <4547B000.5050906@free.fr> Message-ID: <1162333334.3404.1.camel@localhost.localdomain> On Tue, 2006-10-31 at 15:22 -0600, Rex Dieter wrote: > Jean-Luc Fontaine wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I just got the following result, whereas fc6 and fc7 work just fine: > > > > Prep Error (Job 20664): moodss-21_4-1_fc5 on fedora-5-extras > > Error: could not make srpm for moodss-21_4-1_fc5 - output was: > > make: *** No rule to make target `srpm'. Stop. > > > > Is that normal? > > Not normal, buildsys make be borked. Seems to be building now; I call intermittent breakage of Extras package CVS. Dan > -- Rex > From jfontain at free.fr Tue Oct 31 22:26:53 2006 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 31 Oct 2006 23:26:53 +0100 Subject: is fc5 building closed? In-Reply-To: <1162333334.3404.1.camel@localhost.localdomain> References: <4547B000.5050906@free.fr> <1162333334.3404.1.camel@localhost.localdomain> Message-ID: <4547CDAD.5020707@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Williams wrote: > On Tue, 2006-10-31 at 15:22 -0600, Rex Dieter wrote: >> Jean-Luc Fontaine wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I just got the following result, whereas fc6 and fc7 work just fine: >>> >>> Prep Error (Job 20664): moodss-21_4-1_fc5 on fedora-5-extras >>> Error: could not make srpm for moodss-21_4-1_fc5 - output was: >>> make: *** No rule to make target `srpm'. Stop. >>> >>> Is that normal? >> Not normal, buildsys make be borked. > > Seems to be building now; I call intermittent breakage of Extras package > CVS. It may have been my fault: $ TAG_OPTS=-F make tag fixed it. Thanks for your help, - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFR82skG/MMvcT1qQRAv9CAJ41nEbiexbItPoSckQac23nDfLL7wCeLxv0 7y8nvM8vV9o1o9gHw9Sd1qQ= =Tut5 -----END PGP SIGNATURE----- From peter at thecodergeek.com Tue Oct 31 22:42:38 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 31 Oct 2006 14:42:38 -0800 (PST) Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <4547B942.1000709@pmail.pl> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> <4547B2E2.5070108@pmail.pl> <1162327422.20102.3.camel@viper.local> <4547B942.1000709@pmail.pl> Message-ID: <59593.65.223.36.19.1162334558.squirrel@thecodergeek.com> Piotr wrote: > Ville Skytt?? napisa??(a): >> Adding this information to the dead.package files in CVS would not be a >> bad idea. >> > It's OK now? Much better. Thanks! :) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From caillon at redhat.com Tue Oct 31 23:07:31 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 31 Oct 2006 18:07:31 -0500 Subject: Fedora Extras packaging beta software into production repos, why? In-Reply-To: <20061031170042.ee074675.bugs.michael@gmx.net> References: <200610300131.k9U1VsTY022199@laptop13.inf.utfsm.cl> <4545DADA.3040600@poolshark.org> <20061030125400.119558d6.bugs.michael@gmx.net> <45460C41.7030007@poolshark.org> <20061030161826.f408f106.bugs.michael@gmx.net> <1162231246.16192.37.camel@rousalka.dyndns.org> <20061030200216.dbeca49b.bugs.michael@gmx.net> <1162239832.16192.89.camel@rousalka.dyndns.org> <20061030232640.b0029775.bugs.michael@gmx.net> <4546849D.8020600@redhat.com> <20061031003055.d6aae014.bugs.michael@gmx.net> <56640.192.54.193.51.1162288505.squirrel@rousalka.dyndns.org> <20061031115516.649b27a2.bugs.michael@gmx.net> <11721.192.54.193.51.1162296035.squirrel@rousalka.dyndns.org> <20061031134620.ac78b0df.bugs.michael@gmx.net> <45476BF5.7040300@redhat.com> <20061031170042.ee074675.bugs.michael@gmx.net> Message-ID: <4547D733.3070807@redhat.com> Michael Schwendt wrote: > On Tue, 31 Oct 2006 10:29:57 -0500, Christopher Aillon wrote: > >> So >> once it's approved and built, it is the package owner's discretion to >> build a different version of a package, which may include so-called beta >> software. >> > > Yes, which is questionable and asks for adjusted guidelines. > wireless-tools-28-0.pre13.5.1 shipped in FC5 final because there was no other version that would work with the shipped kernel + NM combination and a "release" hadn't yet been made. Firefox in FC3 GOLD was shipped as a beta (firefox-0.10.1-1.0PR1.20), as the default web browser even when there were other web browsers which were not beta in the distribution. NetworkManager in FC4 shipped as a beta (NetworkManager-0.4-15.cvs20050404) because it worked better in Fedora than the latest release. And those are just a small set of the packages I own. > >> Argue about all software; don't single out beta software. >> > > But we need to start somewhere... unless we want to see many more > pre-release snapshots in Fedora Extras. > I think this entire thread is tackling the wrong problem. "Beta" versions can be as useful if not more useful at times than "release" versions as I've demonstrated. Honestly, version numbers are completely useless other than to identify the specific set of features/code/bugs in a given package. People just want software that works and don't really care for the most part what the version number is. Our goal should be looking to avoid broken software not refusing to play with the packages who are wearing a strange shirt. That CAN mean shipping "beta" software. It can ALSO mean actively not shipping "release" software if it is known broken. Playing version police will probably end up wasting people's time in explaining things that don't need to be explained, monitoring software versions, going through removal processes of packages, maybe bumping epochs, and who knows what else! So, how do you address the real problem of making sure the software isn't broken before it goes out? How about a Fedora QA/QE initiative? Maybe build some automated tools to help. There has to be a way to attract people to testing packages before they go out. Honestly it really is fun and rewarding. If I weren't an engineer, I'd move over to QE. I'm sure lots of people would enjoy it if we sell it right and make it easy for them to perform things which make them feel like a part of the community. It can give them something to do for packages they care about which already have maintainers. Or maybe even the feeling of getting to use the software first, before it's released. Either way, if done right, it will be extremely valuable for the community, the distribution, and most importantly the individuals involved. From pertusus at free.fr Tue Oct 31 23:39:29 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 1 Nov 2006 00:39:29 +0100 Subject: desktop files for dockapp apps? In-Reply-To: <20061015082813.GB2323@free.fr> References: <20061012201411.GC2358@free.fr> <1160704345.2619.598.camel@localhost.localdomain> <20061014181252.GA8216@free.fr> <1160858658.2619.714.camel@localhost.localdomain> <20061015082813.GB2323@free.fr> Message-ID: <20061031233929.GB2278@free.fr> > > Could it be possible to add this explicitely to the packaging guidelines, > please (that it in the desktop section state the exception for dockapps)? Could it be possible to add that to the GuidelineTodo? Otherwise it will be forgotten. -- Pat From michel.salim at gmail.com Tue Oct 31 23:49:47 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 31 Oct 2006 18:49:47 -0500 Subject: rpms/gaim-gadugadu/devel dead.package,NONE,1.1 In-Reply-To: <4547B2E2.5070108@pmail.pl> References: <200610311914.k9VJEv6P016332@cvs-int.fedora.redhat.com> <28843.65.223.36.19.1162325259.squirrel@thecodergeek.com> <4547B2E2.5070108@pmail.pl> Message-ID: <883cfe6d0610311549y2f27777x678808ce58350767@mail.gmail.com> On 10/31/06, "Piotr \"Raven\" Dr?g" wrote: > Peter Gordon napisa?(a): > > No disrespect, but you really should explicate on this a bit more. > > I.e., Was it renamed? If so, what package supersedes it? If not, was > > its functionality incorporated into a another package? Did upstream > > disappear? Are there any Bugzilla references, etc.? > > > > Gadu-Gadu support is now included in gaim package, so gaim-gadugadu is > unnecessary. > How stable is the gadu-gadu support? I recall reading a review of Gaim 2.0 that mentioned gadu-gadu is disabled by default. -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/