From chris.stone at gmail.com Thu Jun 1 03:42:39 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 May 2006 20:42:39 -0700 Subject: CVS branching In-Reply-To: <447DC766.6070208@lsd.di.uminho.pt> References: <447DC766.6070208@lsd.di.uminho.pt> Message-ID: On 5/31/06, Jose Pedro Oliveira wrote: > Could someone start processing the CVS request branches > in http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ? > Some of them are 4 days old. I think the people that do this normally are all at the redhat summit meeting so it may be a few more days until this is done. :( From Matt_Domsch at dell.com Thu Jun 1 04:52:16 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 23:52:16 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 #2 Message-ID: <20060601045216.GC9004@lists.us.dell.com> After applying the selinux mock fix to my build servers, I rebuilt everything that had previously failed, just in case. That addressed several packages (like pygame). Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. extras Rawhide-in-Mock Build Results for i386 Wed May 31 23:28:31 CDT 2006 Number failed to build: 157 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 156 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 153 ---------------------------------- alacarte amaya balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp clearsilver colorscheme contact-lookup-applet cowbell dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget Hermes ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife MagicPoint mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc OpenSceneGraph paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl pypoker-eval python-cheetah python-goopy python-TestGears qemu qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp With bugs filed: 3 ---------------------------------- anjuta-gdl ['193675 CLOSED'] gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Thu Jun 1 04:53:32 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 23:53:32 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-05-31 #2 Message-ID: <20060601045332.GD9004@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. extras Rawhide-in-Mock Build Results for x86_64 Wed May 31 23:27:02 CDT 2006 Number failed to build: 182 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 171 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 168 ---------------------------------- alacarte amaya apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife Macaulay2 MagicPoint mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc new OpenSceneGraph pam_mount paps perl-HTML-Mason perl-Image-Info perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl pypoker-eval python-cheetah python-dateutil python-goopy python-reportlab python-TestGears qemu qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint uqm ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp z88dk With bugs filed: 3 ---------------------------------- anjuta-gdl ['193675 CLOSED'] gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From fedora at leemhuis.info Thu Jun 1 06:13:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 08:13:40 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <20060531223829.43fb77dc.bugs.michael@gmx.net> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> Message-ID: <1149142420.21132.22.camel@thl.ct.heise.de> Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt: > On Wed, 31 May 2006 20:49:52 +0200, Thorsten Leemhuis wrote: > > Am Mittwoch, den 31.05.2006, 20:31 +0200 schrieb Michael Schwendt: > > > On Wed, 31 May 2006 19:36:38 +0200, Thorsten Leemhuis wrote: > > > > * scop> | nirik, I assume that buildsys checks md5sums from the > > > > "sources" file for everything in lookaside cache > > > > * that wrong -> the sums are not checked (that has problems when > > > > upstream servers are down or rearrange their layout or ...) and we have > > > > modified tarballs (mp3 stuff removed) > > > scop is right. The buildsys runs "make srpm" which in turn fetches the > > > md5 sums from the "sources" file and only succeeds in downloading > > > tarballs from the lookaside cache if they match the md5 sums. You > > > cannot simply replace a tarball in the lookaside cache, because when > > > its md5 sum differs, you need to update also the "sources" file. > > Ohh, sorry, yes, that was a bit misleading. The problem simply is: who > > checks that the md5 sums stored in CVS are fine / those from upstream? > > Nobody. I can upload a new version of package "foo" at any time and > > include a rootkit in the tarball I upload. No one would notice. > *sigh* I see you've put that old topic onto your plate. Have fun with it! ;) Well, I'm guilty with bringing up some topics where others think they are not worth debatting. But this time it was someone else who started the this topic with the words "as someone pointed out, you can just upload a new .tar.gz to the lookaside with your evil changes in them... no one is likely to catch that." ;-) But to be fair: Yes, I think it is a problem. IMHO it's currently way to easy to bring in something nasty to Fedora Extras. And it might be a big problem as soon as someone does something nasty because users will automatically download it with yum. In other words: I really fear the news entry "Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected until somebody noticed an removed the package." Is that really what we want? I don't want that. > No, really, it's has to do with "level of trust". You cannot open the > gates (for almost everyone to enter) and at the same time lock them. In > the past I've pointed this out several times both internally and in the > public. The system where stock contributors sponsor the membership and > access of new contributors is not bullet-proof. Even if we required all > sponsors to verify each and every CVS commit and upload done by their > sponsored contributors, weaknesses would remain. Because for instance, you > could argue that the sometimes huge tarballs are not checked painstakingly > by any packager prior to using them in a package. Or software, which > targets only a marginal group, possibly is not checked by any upstream > community at all. [The single upstream developer might become hostile > eventually. :)] Some contributors are both upstream and packager at the > same time. The chain is as weak as its weakest link. You may be able to > protect key areas, key infrastructure, and key packages with special > access privilege requirements. But you cannot protect everything from the > ground up without putting up too many hurdles which would reduce > productivity. Further, it is a bold venture for anyone to work on > acquiring access through sponsorship with the uncertainty whether really > nobody is watching at the time it is tried to do something nasty. You have some points here. But what do you suggest? Leave everything as it is? CU thl From fedora at leemhuis.info Thu Jun 1 07:25:11 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 09:25:11 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149142420.21132.22.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> Message-ID: <1149146711.21132.34.camel@thl.ct.heise.de> Am Donnerstag, den 01.06.2006, 08:13 +0200 schrieb Thorsten Leemhuis: > Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt: > But to be fair: Yes, I think it is a problem. IMHO it's currently way to > easy to bring in something nasty to Fedora Extras. Just a quick howto in case if people don't know how easy it is: 1. create a package, prepare it for review 2. get it reviewed and yourself sponsored 3. import it and build 4. checkout some popular packages, upload new tarballs with a slightly different names and a root-kit in it. Modify the "Source0" accordingly 5. commit the changes, hit "CTRL-C" at the right point of time so the commit-message is not send to commits-list 6. wait until the maintainer fixes something else in the package an rebuilds it without noticing the changes done to CVS in between There are slightly variants that even might work better. E.g. - have a popular package in Extras and do it with that directly (that the easiest solution) - instead of "6.": build the modified packages yourself -- chances are quite low that somebody will notice it - instead of "6.": file a bug against the package you modified with a spec-file patch that fixes something in the package without requiring a new version -- the maintainer might apply it and request a rebuild (that is done with the modified tarball you imported to cvs earlier) CU thl From tjikkun at xs4all.nl Thu Jun 1 07:49:19 2006 From: tjikkun at xs4all.nl (Sander Hoentjen) Date: Thu, 01 Jun 2006 09:49:19 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149146711.21132.34.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> Message-ID: <1149148160.13607.0.camel@tjikkun.hoentjen.eu> On Thu, 2006-06-01 at 09:25 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 08:13 +0200 schrieb Thorsten Leemhuis: > > Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt: > > > But to be fair: Yes, I think it is a problem. IMHO it's currently way to > > easy to bring in something nasty to Fedora Extras. > > Just a quick howto in case if people don't know how easy it is: > CU > thl > Hey cool, let me try that! From laurent.rineau__fedora_extras at normalesup.org Thu Jun 1 08:11:36 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 1 Jun 2006 10:11:36 +0200 Subject: devel: "Require %{name} = %{version}-%{release}"? Message-ID: <200606011011.36530@rineau.schtroumpfette> For a package which ships an alpha/beta/devel version of a library, the actual version of the library is encoded in the release tag (according to the package guidelines). In this case, shouldn't the "devel" sub-package have: Require %{name} = %{version}-%{release} instead of the usual: Require %{name} = %{version} ? I found this problem in a rpmforge package (ffmpeg), but maybe some Fedora Extras packages suffer from the same problem, as it is not in the guidelines. From toshio at tiki-lounge.com Thu Jun 1 08:13:06 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 01 Jun 2006 01:13:06 -0700 Subject: Hula history? Message-ID: <1149149586.3336.38.camel@localhost> mschwendt, or anyone else, Does anyone know what's going on with hula? I was researching it and ran across its strange history in Extras. Checked it out of cvs and saw a bunch of interesting stuff in the spec file. I was curious if there was any record of why things were that way but didn't dig up anything enlightening with bugzilla or googling the fedora mailing lists. I did find this point of confusion, though (note the dates): https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00439.html https://www.redhat.com/archives/fedora-extras-commits/2005-April/msg00882.html Kevin Gray -- hula-kevin iprone.com appears to be the former maintainer and is currently maintaining upstream's packages for Fedora Core: http://www.hula-project.org/Downloads At this point I'm unclear whether this package was approved for inclusion into Extras or if the maintainer was sponsored and mistakenly thought he should import the package into cvs at that point. If it's a legitimate orphan I'll look into contacting Kevin and picking it up if he doesn't want to continue. -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 paul at all-the-johnsons.co.uk Thu Jun 1 08:40:09 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 01 Jun 2006 09:40:09 +0100 Subject: Newer versions of mono for extras Message-ID: <1149151209.21980.10.camel@mrwibble.mrwobble> Hi, Much as we have QT4 now in FE for rawhide users, would there be a problem in doing the same for newer versions of mono? 1.1.15 has been out for quite a while with quite a lot of fixes over 1.1.13-x which is currently the base release. What I'm proposing is a build based on a nightly svn until a release is made in which case, the FC maintainer can build and release and I'll carry on with the nightly builds. The naming would be along the lines of mono-1.1.15-svn-%{release} Would there be any objection to me doing this? It would only be available in the rawhide branch. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dragoran at feuerpokemon.de Thu Jun 1 09:03:18 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 01 Jun 2006 11:03:18 +0200 Subject: Newer versions of mono for extras In-Reply-To: <1149151209.21980.10.camel@mrwibble.mrwobble> References: <1149151209.21980.10.camel@mrwibble.mrwobble> Message-ID: <447EAD56.2000705@feuerpokemon.de> PFJ wrote: > Hi, > > Much as we have QT4 now in FE for rawhide users, would there be a > problem in doing the same for newer versions of mono? 1.1.15 has been > out for quite a while with quite a lot of fixes over 1.1.13-x which is > currently the base release. > > What I'm proposing is a build based on a nightly svn until a release is > made in which case, the FC maintainer can build and release and I'll > carry on with the nightly builds. > > The naming would be along the lines of > > mono-1.1.15-svn-%{release} > > Would there be any objection to me doing this? It would only be > available in the rawhide branch. > > TTFN > > Paul > qt4 can be installed parallel with qt3 extras packages should not override core ones. why not getting this into rawhide? if the release is scheduled to be out before FC6 so why not? From paul at all-the-johnsons.co.uk Thu Jun 1 09:10:55 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 01 Jun 2006 10:10:55 +0100 Subject: Newer versions of mono for extras In-Reply-To: <447EAD56.2000705@feuerpokemon.de> References: <1149151209.21980.10.camel@mrwibble.mrwobble> <447EAD56.2000705@feuerpokemon.de> Message-ID: <1149153055.21980.14.camel@mrwibble.mrwobble> Hi, > qt4 can be installed parallel with qt3 > extras packages should not override core ones. > why not getting this into rawhide? I've asked on the test list a number of times for the rawhide version to be based on the current developer tarball of mono, but nothing has ever come from it. At least this way, the testing can be done by a larger community on the developer version rather than release an old version on a new distro (I'd hate to see 1.1.13 with it's problems in FC6 and would, rather akin to OOo2 see a stable beta released in Core) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dragoran at feuerpokemon.de Thu Jun 1 09:14:29 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 01 Jun 2006 11:14:29 +0200 Subject: Newer versions of mono for extras In-Reply-To: <1149153055.21980.14.camel@mrwibble.mrwobble> References: <1149151209.21980.10.camel@mrwibble.mrwobble> <447EAD56.2000705@feuerpokemon.de> <1149153055.21980.14.camel@mrwibble.mrwobble> Message-ID: <447EAFF5.9040002@feuerpokemon.de> PFJ wrote: > Hi, > > >> qt4 can be installed parallel with qt3 >> extras packages should not override core ones. >> why not getting this into rawhide? >> > > I've asked on the test list a number of times for the rawhide version to > be based on the current developer tarball of mono, but nothing has ever > come from it. have you tryed to fill a bug against mono (RFE) ? > At least this way, the testing can be done by a larger > community on the developer version rather than release an old version on > a new distro (I'd hate to see 1.1.13 with it's problems in FC6 and > would, rather akin to OOo2 see a stable beta released in Core) > > TTFN > > Paul > From rc040203 at freenet.de Thu Jun 1 09:15:59 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Jun 2006 11:15:59 +0200 Subject: devel: "Require %{name} = %{version}-%{release}"? In-Reply-To: <200606011011.36530@rineau.schtroumpfette> References: <200606011011.36530@rineau.schtroumpfette> Message-ID: <1149153360.27733.384.camel@mccallum.corsepiu.local> On Thu, 2006-06-01 at 10:11 +0200, Laurent Rineau wrote: > For a package which ships an alpha/beta/devel version of a library, the actual > version of the library is encoded in the release tag (according to the > package guidelines). In this case, shouldn't the "devel" sub-package have: > Require %{name} = %{version}-%{release} > instead of the usual: Usual? A devel package should always use Require: %{name} = %{version}-%{release} > Require %{name} = %{version} Such are "Require" is rarely correct, because rpms by default provide "%{name} = %{version}-%{release}" and do not provide "%{name} = %{version}" unless such a provide had explicitly been added somewhere. Ralf From pertusus at free.fr Thu Jun 1 09:22:19 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Jun 2006 11:22:19 +0200 Subject: devel: "Require %{name} = %{version}-%{release}"? In-Reply-To: <200606011011.36530@rineau.schtroumpfette> References: <200606011011.36530@rineau.schtroumpfette> Message-ID: <20060601092219.GA2417@free.fr> On Thu, Jun 01, 2006 at 10:11:36AM +0200, Laurent Rineau wrote: > For a package which ships an alpha/beta/devel version of a library, the actual > version of the library is encoded in the release tag (according to the > package guidelines). In this case, shouldn't the "devel" sub-package have: > Require %{name} = %{version}-%{release} > instead of the usual: > Require %{name} = %{version} The guideline in fedora extras is to use Require: %{name} = %{version}-%{release} It was discussed on the list and I believe it is on the template for libraries. I havent found it in the wiki, maybe it should be there too. -- Pat From bugs.michael at gmx.net Thu Jun 1 09:38:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Jun 2006 11:38:48 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149146711.21132.34.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> Message-ID: <20060601113848.54f8f55a.bugs.michael@gmx.net> On Thu, 01 Jun 2006 09:25:11 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 08:13 +0200 schrieb Thorsten Leemhuis: > > Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt: > > > But to be fair: Yes, I think it is a problem. IMHO it's currently way to > > easy to bring in something nasty to Fedora Extras. > > Just a quick howto in case if people don't know how easy it is: > > 1. create a package, prepare it for review > 2. get it reviewed and yourself sponsored > 3. import it and build > 4. checkout some popular packages, upload new tarballs with a slightly > different names and a root-kit in it. Modify the "Source0" accordingly > 5. commit the changes, hit "CTRL-C" at the right point of time so the > commit-message is not send to commits-list > 6. wait until the maintainer fixes something else in the package an > rebuilds it without noticing the changes done to CVS in between All fine, step-by-step instructions for any weird person out there, who might want to try this for a bit of "fame". I can only repeat, you are not the first one to express a paranoid view without proposing a feasible solution. Theoretically, it is possible with ACLs to tighten the access to "some popular packages" in CVS. And it would also be possible to lock down the buildsys in a similar way. Though, this would make it more complicated for a security team. Hey, isn't this fun? A security team which we need to trust as they should be able to touch many if not all packages without jumping over extra hurdles. Package maintainers ought to make sure they cvs tag only those files in their working copy which they agree with. The majority of package maintainers probably never runs "cvs up", but only commits and tags from within a local working copy anyway. Others don't even use plain cvs too often and cvs-import.sh full src.rpms, which can overwrite/revert changes accidentally, too. "cvs log" does catch all commit activity, doesn't it? So, packagers, start using it if you want to contribute a bit more safety. > There are slightly variants that even might work better. E.g. > > - have a popular package in Extras and do it with that directly (that > the easiest solution) > - instead of "6.": build the modified packages yourself -- chances are > quite low that somebody will notice it > - instead of "6.": file a bug against the package you modified with a > spec-file patch that fixes something in the package without requiring a > new version -- the maintainer might apply it and request a rebuild (that > is done with the modified tarball you imported to cvs earlier) In a more shiny world, popular packages ought to be maintained and monitored by multiple people. The more popular, the more maintainers (and the more monitoring from within the community, e.g. people who cvs co a package when they see a new build or who examine cvs log and cvs diff). Don't get me wrong. I'm not opposed to any thoughts about this. But even if a mighty ACL implementation were available (also in the buildsys), it would not be me who could guarantee that over time nobody would acquire the necessary access privileges to do something nasty eventually. Look, there are people already today who would not need to go through steps 1-6 at all if they wanted to replace a binary (!) package in the repository. From paul at all-the-johnsons.co.uk Thu Jun 1 09:41:23 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 01 Jun 2006 10:41:23 +0100 Subject: Newer versions of mono for extras In-Reply-To: <447EAFF5.9040002@feuerpokemon.de> References: <1149151209.21980.10.camel@mrwibble.mrwobble> <447EAD56.2000705@feuerpokemon.de> <1149153055.21980.14.camel@mrwibble.mrwobble> <447EAFF5.9040002@feuerpokemon.de> Message-ID: <1149154883.21980.16.camel@mrwibble.mrwobble> Hi, > > I've asked on the test list a number of times for the rawhide version to > > be based on the current developer tarball of mono, but nothing has ever > > come from it. > have you tryed to fill a bug against mono (RFE) ? I have in the past and have done again - 193751 TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugs.michael at gmx.net Thu Jun 1 09:46:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Jun 2006 11:46:38 +0200 Subject: devel: "Require %{name} = %{version}-%{release}"? In-Reply-To: <200606011011.36530@rineau.schtroumpfette> References: <200606011011.36530@rineau.schtroumpfette> Message-ID: <20060601114638.7252ac01.bugs.michael@gmx.net> On Thu, 1 Jun 2006 10:11:36 +0200, Laurent Rineau wrote: > For a package which ships an alpha/beta/devel version of a library, the actual > version of the library is encoded in the release tag (according to the > package guidelines). In this case, shouldn't the "devel" sub-package have: > Require %{name} = %{version}-%{release} The majority of -devel packages ought to do this in order to keep the packages in sync strictly. > instead of the usual: > Require %{name} = %{version} > ? This is lax packaging. It breaks in several cases and particularly when the number of patches and changes increase. Most -devel packages include an API, constants, generated headers, config helper scripts, all possibly patched, and the result ought to match what's compiled into the main package. Hence %{release} in the dependency is beneficial. In some cases you can argue that requiring the major library version is enough, until you find out that it's not worth the risks. > I found this problem in a rpmforge package (ffmpeg), but maybe some Fedora > Extras packages suffer from the same problem, as it is not in the guidelines. > From paul at all-the-johnsons.co.uk Thu Jun 1 09:47:59 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 01 Jun 2006 10:47:59 +0100 Subject: Monodevelop etc into FE Message-ID: <1149155279.21980.23.camel@mrwibble.mrwobble> Hi, I've been working on getting these into FE for a while now[1] and there is some movement on monodoc which is pretty close to being accepted. Before Monodevelop can go into extras, gtksourceview-sharp and boo both have to be reviewed and accepted. Could some kind soul have a look at BZ 178901 (gtksourceview-sharp), 178904 (MonoDevelop) and 189092 (boo)? ikvm is already in FE, so that's a good thing! I do have other mono based packages waiting for review if anyone is interested in them... 189093 - mono-debugger 177512 - mysql-connector-net Monodoc's BZ is 178900 if anyone wants to join the fun! TTFN Paul [1] I'll hold my hands up and say now that quite a few delays have been my fault due to work committments -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugs.michael at gmx.net Thu Jun 1 10:01:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Jun 2006 12:01:14 +0200 Subject: Hula history? In-Reply-To: <1149149586.3336.38.camel@localhost> References: <1149149586.3336.38.camel@localhost> Message-ID: <20060601120114.5de37770.bugs.michael@gmx.net> On Thu, 01 Jun 2006 01:13:06 -0700, Toshio Kuratomi wrote: > mschwendt, or anyone else, > > Does anyone know what's going on with hula? I was researching it and > ran across its strange history in Extras. Checked it out of cvs and saw > a bunch of interesting stuff in the spec file. I was curious if there > was any record of why things were that way but didn't dig up anything > enlightening with bugzilla or googling the fedora mailing lists. > > I did find this point of confusion, though (note the dates): > https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00439.html > https://www.redhat.com/archives/fedora-extras-commits/2005-April/msg00882.html > > Kevin Gray -- hula-kevin iprone.com appears to be the former maintainer > and is currently maintaining upstream's packages for Fedora Core: > http://www.hula-project.org/Downloads > > At this point I'm unclear whether this package was approved for > inclusion into Extras or if the maintainer was sponsored and mistakenly > thought he should import the package into cvs at that point. If it's a > legitimate orphan I'll look into contacting Kevin and picking it up if > he doesn't want to continue. Compare with: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg02216.html Notice Cc. No response. In my Sent folder I see I mailed him 2005-07-23, but I don't think I've seen a reply ever. From i at stingr.net Thu Jun 1 12:19:15 2006 From: i at stingr.net (Paul P Komkoff Jr) Date: Thu, 1 Jun 2006 16:19:15 +0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149146711.21132.34.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> Message-ID: <20060601121914.GF2122@stingr.net> Replying to Thorsten Leemhuis: > 4. checkout some popular packages, upload new tarballs with a slightly > different names and a root-kit in it. Modify the "Source0" accordingly > 5. commit the changes, hit "CTRL-C" at the right point of time so the > commit-message is not send to commits-list Either I am wrong or this clearly shows a major flaw in current infrastructure when any with commit access can modify anything in the extras tree? -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From j.w.r.degoede at hhs.nl Thu Jun 1 12:47:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 Jun 2006 14:47:35 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <20060601121914.GF2122@stingr.net> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <20060601121914.GF2122@stingr.net> Message-ID: <447EE1E7.10106@hhs.nl> Paul P Komkoff Jr wrote: > Replying to Thorsten Leemhuis: >> 4. checkout some popular packages, upload new tarballs with a slightly >> different names and a root-kit in it. Modify the "Source0" accordingly >> 5. commit the changes, hit "CTRL-C" at the right point of time so the >> commit-message is not send to commits-list > > Either I am wrong or this clearly shows a major flaw in current > infrastructure when any with commit access can modify anything in the > extras tree? > Flaw, more of a feature. I like the current openness of FE and I think we should be very carefull to not loose this openness. I share Thl's worries, actually I kinda wisphered them into his ear, but I was wisphering because I didn't want my worries to lead to a discussion which in turn could lead to a much more closed FE. We're a community distro, trust is important if not vital! I personally I'm trying to be carefull with whom I sponsor, checking for privious oss work, etc and monitoring every move they make for sometime after I sponsor them untill I'm comfortable that they can be trusted. I think people who want to inject malware into OSS will always find a way, the fact that this currently hasn't happened much shows that we're appearantly a healty community and that the riscs of getting caught are big enough to scare people away. Regards, Hans From icon at fedoraproject.org Thu Jun 1 12:51:44 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 1 Jun 2006 08:51:44 -0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149146711.21132.34.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> Message-ID: On 6/1/06, Thorsten Leemhuis wrote: > 1. create a package, prepare it for review > 2. get it reviewed and yourself sponsored > 3. import it and build > 4. checkout some popular packages, upload new tarballs with a slightly > different names and a root-kit in it. Modify the "Source0" accordingly > 5. commit the changes, hit "CTRL-C" at the right point of time so the > commit-message is not send to commits-list > 6. wait until the maintainer fixes something else in the package an > rebuilds it without noticing the changes done to CVS in between Most of us have locally checked out copies of our packages in the extras CVS, so this won't work -- cvs commit will bail with "uptodate check failed for foo.spec". The maintainer will go "whaaaa?", run CVS diff, notice the updated Source0, go "that's funny, I don't remember changing that," and then there will be a lot of ass-whoopin', as the new source is downloaded and examined. The system is less broken than you think. -- Konstantin Ryabitsev Montr?al, Qu?bec From fedora at leemhuis.info Thu Jun 1 13:03:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 15:03:02 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> Message-ID: <1149166983.21132.65.camel@thl.ct.heise.de> Am Donnerstag, den 01.06.2006, 08:51 -0400 schrieb Konstantin Ryabitsev: > On 6/1/06, Thorsten Leemhuis wrote: > > 1. create a package, prepare it for review > > 2. get it reviewed and yourself sponsored > > 3. import it and build > > 4. checkout some popular packages, upload new tarballs with a slightly > > different names and a root-kit in it. Modify the "Source0" accordingly > > 5. commit the changes, hit "CTRL-C" at the right point of time so the > > commit-message is not send to commits-list > > 6. wait until the maintainer fixes something else in the package an > > rebuilds it without noticing the changes done to CVS in between > Most of us have locally checked out copies of our packages [...] What makes your sure that "most of us" do it like that? I for example don't have them because I work on my packages from multiple machines. So I always do a fresh checkout (that way I always get a up2date common directory, too). And in any case: "- instead of "6.": build the modified packages yourself -- chances are quite low that somebody will notice it" remains. Cu thl From j.w.r.degoede at hhs.nl Thu Jun 1 13:10:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 Jun 2006 15:10:11 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149166983.21132.65.camel@thl.ct.heise.de> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> Message-ID: <447EE733.2040709@hhs.nl> Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 08:51 -0400 schrieb Konstantin Ryabitsev: >> On 6/1/06, Thorsten Leemhuis wrote: >>> 1. create a package, prepare it for review >>> 2. get it reviewed and yourself sponsored >>> 3. import it and build >>> 4. checkout some popular packages, upload new tarballs with a slightly >>> different names and a root-kit in it. Modify the "Source0" accordingly >>> 5. commit the changes, hit "CTRL-C" at the right point of time so the >>> commit-message is not send to commits-list >>> 6. wait until the maintainer fixes something else in the package an >>> rebuilds it without noticing the changes done to CVS in between >> Most of us have locally checked out copies of our packages [...] > > What makes your sure that "most of us" do it like that? I for example > don't have them because I work on my packages from multiple machines. So > I always do a fresh checkout (that way I always get a up2date common > directory, too). > > And in any case: "- instead of "6.": build the modified packages > yourself -- chances are quite low that somebody will notice it" remains. > What I do is I have a checkout on each of the machines I develop on and do cvs update as needed, when I do an update I check that only files which I expect to change change. Making it quite hard (but not impossible) to sneak something in unseen. As for the immediatly build it trick, I would notice this in the build report which I always read. I'm not saying its impossible, I'm saying its not _that_ easy. Maybe we should write a couple of guidelines for packagerss on how they can check that there packages aren't modified by someone else without them knowing? Combine this with having more then one packager for the really popular packages and I think we're ok. Regards, Hans From fedora at leemhuis.info Thu Jun 1 13:46:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 15:46:44 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <447EE733.2040709@hhs.nl> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <447EE733.2040709@hhs.nl> Message-ID: <1149169604.21132.76.camel@thl.ct.heise.de> Am Donnerstag, den 01.06.2006, 15:10 +0200 schrieb Hans de Goede: > Thorsten Leemhuis wrote: > > Am Donnerstag, den 01.06.2006, 08:51 -0400 schrieb Konstantin Ryabitsev: > >> On 6/1/06, Thorsten Leemhuis wrote: > >>> 1. create a package, prepare it for review > >>> 2. get it reviewed and yourself sponsored > >>> 3. import it and build > >>> 4. checkout some popular packages, upload new tarballs with a slightly > >>> different names and a root-kit in it. Modify the "Source0" accordingly > >>> 5. commit the changes, hit "CTRL-C" at the right point of time so the > >>> commit-message is not send to commits-list > >>> 6. wait until the maintainer fixes something else in the package an > >>> rebuilds it without noticing the changes done to CVS in between > >> Most of us have locally checked out copies of our packages [...] > > What makes your sure that "most of us" do it like that? I for example > > don't have them because I work on my packages from multiple machines. So > > I always do a fresh checkout (that way I always get a up2date common > > directory, too). > > And in any case: "- instead of "6.": build the modified packages > > yourself -- chances are quite low that somebody will notice it" remains. > What I do is I have a checkout on each of the machines I develop on and > do cvs update as needed, when I do an update I check that only files > which I expect to change change. Making it quite hard (but not > impossible) to sneak something in unseen. > > As for the immediatly build it trick, I would notice this in the build > report which I always read. And yum would have installed it already on some machines if you were asleep when the packages were pushed (not to mention that the packages would be on several mirrors in between, too; and also ignoring the fact we're all offline for longer now and then -- weekends, holidays, illness, ...). > I'm not saying its impossible, I'm saying its not _that_ easy. I'm saying we can't make it impossible that something bad sneaks in, but currently it's IMHO to easy and we should make it harder without making it much harder for the contributors. > Maybe we > should write a couple of guidelines for packagerss on how they can check > that there packages aren't modified by someone else without them > knowing? Combine this with having more then one packager for the really > popular packages and I think we're ok. That's a lot of work for the contributors, overloads them and has a high risk that at least some contributors simply ignore the "guidelines" and don't check there stuff properly IMHO. CU thl From icon at fedoraproject.org Thu Jun 1 14:06:54 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 1 Jun 2006 10:06:54 -0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> Message-ID: On 6/1/06, Thorsten Leemhuis wrote: > What makes your sure that "most of us" do it like that? I for example > don't have them because I work on my packages from multiple machines. So > I always do a fresh checkout (that way I always get a up2date common > directory, too). Then maybe YOUR practices should be questioned, not everyone's. If you don't zealously track CVS commits to your packages, then you are the broken part, not the system. > And in any case: "- instead of "6.": build the modified packages > yourself -- chances are quite low that somebody will notice it" remains. You can check out my packages, trojan them, cvs commit them, and build them. They will get signed and get released. However, since I follow the new releases for Extras, I will quickly notice that something went wrong, and perform the needed steps to pull it. 1. Yes, you will succeed in trojaning my packages for a brief while 2. This won't take very long to get noticed 3. You will be dealt with accordingly -- most likely involving the police/fbi/etc We are not working in a fully anonymous environment -- there is a certain level of trust between the members of the Extras packaging community. Getting CVS commit access requires certain steps that usually weed out your regular pranksters (including sending a signed fax to RH HQ), and if you are totally hell-bent on poisoning the system, then there's little we can do short of making the process even more arduous and slow for everyone who wants to participate. In any case, this isn't a contingency we should really be spending that much time over, short of potentially developing a system of ACLs that would restrict CVS commits only to the actual package owners. We can safely assume that as time passes, the chances of having a trojaned package in Extras approacheth 100%. Therefore, instead of hand-wringing and self-flagellating, let's work out a coarse of actions to take if someone, indeed, manages to sneak through a trojaned package. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From jonathan.underwood at gmail.com Thu Jun 1 14:41:40 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Jun 2006 15:41:40 +0100 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> Message-ID: <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> On 01/06/06, Konstantin Ryabitsev wrote: > In any case, this isn't a contingency we should really be spending > that much time over, short of potentially developing a system of ACLs > that would restrict CVS commits only to the actual package owners. Would it help this discussion if the technicalities of developing such a system were put on the table (apologies if this has been discussed before and I missed it) ? This discussion would also be useful in the context of developing a mechanism for having a team of people responsible for a package, rather than a single owner. Do the problems with the apprach alluded to by Konstantin have their roots in the limitations of CVS permissions, or are there other issues? Jonathan From fedora at leemhuis.info Thu Jun 1 15:00:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 17:00:12 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> Message-ID: <1149174012.2329.11.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 15:41 +0100 schrieb Jonathan Underwood: > On 01/06/06, Konstantin Ryabitsev wrote: > > In any case, this isn't a contingency we should really be spending > > that much time over, short of potentially developing a system of ACLs > > that would restrict CVS commits only to the actual package owners. > > Would it help this discussion if the technicalities of developing such > a system were put on the table (apologies if this has been discussed > before and I missed it)? The biggest problem probably is: There are plans to switch away from CVS to something else after FC6 (no, that's all I know). So investing to much time in the current system probably is not worth the trouble. I would sleep already a lot better if at least the issue with "hit CTRL +C at the right moment and no commit mail with the changes will be send" would be fixed. But I don't know CVS enough and would be really glad if someone could look into that. I would even sleep really good if there would be a mechanism that checks md5sum's against upstream packages. But that's quite complicated to implement and might be to much overhead. > This discussion would also be useful in the > context of developing a mechanism for having a team of people > responsible for a package, rather than a single owner. We really need that. But that's stalled mostly because nobody in FESCo really works on driving it forward and the proposal from Patrice is still in my Todo-Inbox. :-(( > Do the problems > with the apprach alluded to by Konstantin have their roots in the > limitations of CVS permissions, or are there other issues? I don't know. It was started with the current scheme and I don't know the details why every packager has access everywhere. And it seems a lot of people don't want fine-graded ACLs. CU thl -- Thorsten Leemhuis From skvidal at linux.duke.edu Thu Jun 1 15:09:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 01 Jun 2006 11:09:49 -0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174012.2329.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> Message-ID: <1149174590.10389.20.camel@cutter> On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > The biggest problem probably is: There are plans to switch away from CVS > to something else after FC6 (no, that's all I know). So investing to > much time in the current system probably is not worth the trouble. > > I would sleep already a lot better if at least the issue with "hit CTRL > +C at the right moment and no commit mail with the changes will be send" > would be fixed. But I don't know CVS enough and would be really glad if > someone could look into that. > > I would even sleep really good if there would be a mechanism that checks > md5sum's against upstream packages. But that's quite complicated to > implement and might be to much overhead. > Actually, is it all that complicated? for each package in cvs: 1. download the spec file 2. download the tarball that's been uploaded 3. download link in Source0 or Source 4. compare checksum to tarball's checksum 5. keep track of url to Source0 or Source and emit a notice whenever it changes wouldn't that really be all there is to it?. it'd require a fair bit of bandwidth but not much else. -sv From jamatos at fc.up.pt Thu Jun 1 15:07:27 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 1 Jun 2006 16:07:27 +0100 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174012.2329.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> Message-ID: <200606011607.27930.jamatos@fc.up.pt> On Thursday 01 June 2006 16:00, Thorsten Leemhuis wrote: > I would even sleep really good if there would be a mechanism that checks > md5sum's against upstream packages. But that's quite complicated to > implement and might be to much overhead. Then change that from md5 to sha1 if you want to be in the safe side. :-) -- Jos? Ab?lio From fedora at leemhuis.info Thu Jun 1 15:30:27 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 17:30:27 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174590.10389.20.camel@cutter> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149174590.10389.20.camel@cutter> Message-ID: <1149175827.2329.16.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 11:09 -0400 schrieb seth vidal: > On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > > The biggest problem probably is: There are plans to switch away from CVS > > to something else after FC6 (no, that's all I know). So investing to > > much time in the current system probably is not worth the trouble. > > > > I would sleep already a lot better if at least the issue with "hit CTRL > > +C at the right moment and no commit mail with the changes will be send" > > would be fixed. But I don't know CVS enough and would be really glad if > > someone could look into that. > > > > I would even sleep really good if there would be a mechanism that checks > > md5sum's against upstream packages. But that's quite complicated to > > implement and might be to much overhead. > > > Actually, is it all that complicated? > > for each package in cvs: > 1. download the spec file > 2. download the tarball that's been uploaded > 3. download link in Source0 or Source > 4. compare checksum to tarball's checksum > 5. keep track of url to Source0 or Source and emit a notice whenever it > changes > > wouldn't that really be all there is to it?. Who says that the link to Source0 or Source is correct and not faked, too? We would have to manage a whitelist for the script. CU thl -- Thorsten Leemhuis From skvidal at linux.duke.edu Thu Jun 1 15:36:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 01 Jun 2006 11:36:39 -0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149175827.2329.16.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149174590.10389.20.camel@cutter> <1149175827.2329.16.camel@localhost.localdomain> Message-ID: <1149176200.10389.27.camel@cutter> On Thu, 2006-06-01 at 17:30 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 11:09 -0400 schrieb seth vidal: > > On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > > > The biggest problem probably is: There are plans to switch away from CVS > > > to something else after FC6 (no, that's all I know). So investing to > > > much time in the current system probably is not worth the trouble. > > > > > > I would sleep already a lot better if at least the issue with "hit CTRL > > > +C at the right moment and no commit mail with the changes will be send" > > > would be fixed. But I don't know CVS enough and would be really glad if > > > someone could look into that. > > > > > > I would even sleep really good if there would be a mechanism that checks > > > md5sum's against upstream packages. But that's quite complicated to > > > implement and might be to much overhead. > > > > > Actually, is it all that complicated? > > > > for each package in cvs: > > 1. download the spec file > > 2. download the tarball that's been uploaded > > 3. download link in Source0 or Source > > 4. compare checksum to tarball's checksum > > 5. keep track of url to Source0 or Source and emit a notice whenever it > > changes > > > > wouldn't that really be all there is to it?. > > Who says that the link to Source0 or Source is correct and not faked, > too? We would have to manage a whitelist for the script. > Which is why it emits a notice about changes to that value. -sv From fedora at leemhuis.info Thu Jun 1 15:43:11 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 17:43:11 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149176200.10389.27.camel@cutter> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149174590.10389.20.camel@cutter> <1149175827.2329.16.camel@localhost.localdomain> <1149176200.10389.27.camel@cutter> Message-ID: <1149176591.2329.22.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 11:36 -0400 schrieb seth vidal: > On Thu, 2006-06-01 at 17:30 +0200, Thorsten Leemhuis wrote: > > Am Donnerstag, den 01.06.2006, 11:09 -0400 schrieb seth vidal: > > > On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > > > > The biggest problem probably is: There are plans to switch away from CVS > > > > to something else after FC6 (no, that's all I know). So investing to > > > > much time in the current system probably is not worth the trouble. > > > > > > > > I would sleep already a lot better if at least the issue with "hit CTRL > > > > +C at the right moment and no commit mail with the changes will be send" > > > > would be fixed. But I don't know CVS enough and would be really glad if > > > > someone could look into that. > > > > > > > > I would even sleep really good if there would be a mechanism that checks > > > > md5sum's against upstream packages. But that's quite complicated to > > > > implement and might be to much overhead. > > > > > > > Actually, is it all that complicated? > > > > > > for each package in cvs: > > > 1. download the spec file > > > 2. download the tarball that's been uploaded > > > 3. download link in Source0 or Source > > > 4. compare checksum to tarball's checksum > > > 5. keep track of url to Source0 or Source and emit a notice whenever it > > > changes > > > wouldn't that really be all there is to it?. > > Who says that the link to Source0 or Source is correct and not faked, > > too? We would have to manage a whitelist for the script. > Which is why it emits a notice about changes to that value. Well, yeah, a external script that looks out for changes in that value and checks the checksum could do the trick for 99% of the packages -- 1% are still problematic because we have some modified tarballs where for example mp3 support was removed (but that another problem and shouldn't happen that often). CU thl -- Thorsten Leemhuis From toshio at tiki-lounge.com Thu Jun 1 15:57:45 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 01 Jun 2006 08:57:45 -0700 Subject: Will take Hula (was Re: Hula history?) In-Reply-To: <20060601120114.5de37770.bugs.michael@gmx.net> References: <1149149586.3336.38.camel@localhost> <20060601120114.5de37770.bugs.michael@gmx.net> Message-ID: <1149177465.3118.4.camel@localhost> On Thu, 2006-06-01 at 12:01 +0200, Michael Schwendt wrote: > > Compare with: > > https://www.redhat.com/archives/fedora-extras-list/2006-February/msg02216.html > > Notice Cc. No response. > > In my Sent folder I see I mailed him 2005-07-23, but I don't think I've > seen a reply ever. > Okay. So maintainer is definitely AWOL. I'll unorphan hula if no one else speaks up. It could use a co-maintainer, though, as I'm not going to be running it with a lot of users trying to break it, just for me to try out. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonathan.underwood at gmail.com Thu Jun 1 16:07:42 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Jun 2006 17:07:42 +0100 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149176591.2329.22.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149174590.10389.20.camel@cutter> <1149175827.2329.16.camel@localhost.localdomain> <1149176200.10389.27.camel@cutter> <1149176591.2329.22.camel@localhost.localdomain> Message-ID: <645d17210606010907j39f72007gc3253ca82de58df9@mail.gmail.com> As a related aside, how do other community distributions deal with this issue (eg. Debian, Ubuntu)? Could we learn something from them? I am looking through all the Ubuntu pages currently, and it seems they have a similar approach, but with a more stringent approach to electing people as developers. Jonathan. From ville.skytta at iki.fi Thu Jun 1 16:26:44 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 01 Jun 2006 19:26:44 +0300 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174012.2329.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> Message-ID: <1149179204.22041.45.camel@localhost.localdomain> On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 15:41 +0100 schrieb Jonathan Underwood: > > This discussion would also be useful in the > > context of developing a mechanism for having a team of people > > responsible for a package, rather than a single owner. > > We really need that. But that's stalled mostly because nobody in FESCo > really works on driving it forward and the proposal from Patrice is > still in my Todo-Inbox. :-(( This topic surfaces every now and then, often to be quickly countered with "what do you need, just do it", which to my knowledge has not been really answered. Come on, what is there really to "drive forward" in this? Just agree with the current maintainer of a package that you'll start co-maintaining it, and add your email address to initialcclist in owners.list, and start doing it. > > Do the problems > > with the apprach alluded to by Konstantin have their roots in the > > limitations of CVS permissions, or are there other issues? > > I don't know. It was started with the current scheme and I don't know > the details why every packager has access everywhere. And it seems a lot > of people don't want fine-graded ACLs. CVS ACLs are already deployed, but they're not currently fine grained at all. It should be possible to get them to be as fine grained as the requirements are, but I guess maintaining them for a project like FE (number of committers, number of packages) manually probably isn't fun at all. OTOH, some parts of the ACLs could be autogenerated from other sources, such as allowing commit access to owners.list to a restricted group only, and generating per-package ACLs from it + something that maps bugzilla accounts to CVS accounts. Also, providing broader commit access for the security response team should be a no-brainer. From fedora at leemhuis.info Thu Jun 1 16:31:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 18:31:23 +0200 Subject: status of "freenx" in Extras Message-ID: <1149179483.2329.36.camel@localhost.localdomain> Hi all! Now that hula has been solved: Does anyone know what's up with freenx in extras? According to owners.list: Fedora Extras|freenx|freenx application/thin-client serve|zipsonic at gmail.com|extras-qa at fedoraproject.org zipsonic at gmail.com is zipsonic aka Richard A. Stout The import was done one year ago and nothing changed since then: http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/devel/?root=extras http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/FC-5/?root=extras But it was never build for Extras afais. He seems to still maintain the package outside Fedora Extras: http://fedoranews.org/contributors/rick_stout/freenx/ http://mail.kde.org/pipermail/freenx-knx/2006-May/003431.html I send him a private mail two and a half weeks ago --> no reply. http://www.redhat.com/archives/fedora-extras-list/2005-October/msg00214.html also got no reply. CC'ing him to this mail, too (and Spot, his sponsor). Shall we call him AWOL and the package orphaned if nothing happens in the next five days? CU thl -- Thorsten Leemhuis From skvidal at linux.duke.edu Thu Jun 1 16:36:55 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 01 Jun 2006 12:36:55 -0400 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149179204.22041.45.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149179204.22041.45.camel@localhost.localdomain> Message-ID: <1149179815.10389.29.camel@cutter> On Thu, 2006-06-01 at 19:26 +0300, Ville Skytt? wrote: > On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > > Am Donnerstag, den 01.06.2006, 15:41 +0100 schrieb Jonathan Underwood: > > > > This discussion would also be useful in the > > > context of developing a mechanism for having a team of people > > > responsible for a package, rather than a single owner. > > > > We really need that. But that's stalled mostly because nobody in FESCo > > really works on driving it forward and the proposal from Patrice is > > still in my Todo-Inbox. :-(( > > This topic surfaces every now and then, often to be quickly countered > with "what do you need, just do it", which to my knowledge has not been > really answered. Come on, what is there really to "drive forward" in > this? > > Just agree with the current maintainer of a package that you'll start > co-maintaining it, and add your email address to initialcclist in > owners.list, and start doing it. +1 -sv From tcallawa at redhat.com Thu Jun 1 16:36:08 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 01 Jun 2006 11:36:08 -0500 Subject: status of "freenx" in Extras In-Reply-To: <1149179483.2329.36.camel@localhost.localdomain> References: <1149179483.2329.36.camel@localhost.localdomain> Message-ID: <1149179768.9740.23.camel@localhost.localdomain> On Thu, 2006-06-01 at 18:31 +0200, Thorsten Leemhuis wrote: > Hi all! > > Now that hula has been solved: Does anyone know what's up with freenx in > extras? According to owners.list: > > Fedora Extras|freenx|freenx application/thin-client serve|zipsonic at gmail.com|extras-qa at fedoraproject.org > > zipsonic at gmail.com is zipsonic aka Richard A. Stout > > The import was done one year ago and nothing changed since then: > > http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/devel/?root=extras > http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/FC-5/?root=extras > > But it was never build for Extras afais. He seems to still maintain the > package outside Fedora Extras: It never built cleanly for x86_64, and originally, it was all or nothing in FE (its not the case anymore). I think this discouraged him from working with it, I have no idea if Richard wants to keep maintaining it in FE or not. If he doesn't (and no one else wants it), I'll take it. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Thu Jun 1 16:36:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Jun 2006 18:36:52 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174012.2329.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> Message-ID: <20060601183652.5b123e9e.bugs.michael@gmx.net> On Thu, 01 Jun 2006 17:00:12 +0200, Thorsten Leemhuis wrote: > I would even sleep really good if there would be a mechanism that checks > md5sum's against upstream packages. But that's quite complicated to > implement and might be to much overhead. Do you also want to check patches and compressed patches? > > This discussion would also be useful in the > > context of developing a mechanism for having a team of people > > responsible for a package, rather than a single owner. > > We really need that. But that's stalled mostly because nobody in FESCo > really works on driving it forward and the proposal from Patrice is > still in my Todo-Inbox. :-(( Well, some packagers do it already. They simply talk to eachother and then add themselves to the Cc field in owners.list, since bugzilla cannot handle more than a single assignee. From fedora at leemhuis.info Thu Jun 1 16:46:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 18:46:22 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149179204.22041.45.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149179204.22041.45.camel@localhost.localdomain> Message-ID: <1149180382.2329.52.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 19:26 +0300 schrieb Ville Skytt?: > On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote: > > Am Donnerstag, den 01.06.2006, 15:41 +0100 schrieb Jonathan Underwood: > > > This discussion would also be useful in the > > > context of developing a mechanism for having a team of people > > > responsible for a package, rather than a single owner. > > We really need that. But that's stalled mostly because nobody in FESCo > > really works on driving it forward and the proposal from Patrice is > > still in my Todo-Inbox. :-(( > This topic surfaces every now and then, often to be quickly countered > with "what do you need, just do it", which to my knowledge has not been > really answered. Come on, what is there really to "drive forward" in > this? Mainly this (or parts of it; or parts now, others later): - Allow new contributors to start as Co-Maintainers: https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00506.html - Proposal from Patrice with a lot of good ideas: https://www.redhat.com/archives/fedora-extras-list/2006-April/msg00962.html - a way to mark "Maintainer foo works on FC5 and devel, Maintainer bar on FC3 and FC4" in owners.list - A proper policy in the wiki. Did I miss anything? > Just agree with the current maintainer of a package that you'll start > co-maintaining it, and add your email address to initialcclist in > owners.list, and start doing it. Well, that's one part of the whole idea it and that's possible already. > > > Do the problems > > > with the apprach alluded to by Konstantin have their roots in the > > > limitations of CVS permissions, or are there other issues? > > I don't know. It was started with the current scheme and I don't know > > the details why every packager has access everywhere. And it seems a lot > > of people don't want fine-graded ACLs. > > CVS ACLs are already deployed, but they're not currently fine grained at > all. It should be possible to get them to be as fine grained as the > requirements are, but I guess maintaining them for a project like FE > (number of committers, number of packages) manually probably isn't fun > at all. > > OTOH, some parts of the ACLs could be autogenerated from other sources, > such as allowing commit access to owners.list to a restricted group > only, and generating per-package ACLs from it + something that maps > bugzilla accounts to CVS accounts. > > Also, providing broader commit access for the security response team > should be a no-brainer. Sounds really good to me. BTW, I'd say sponsors should also get access everywhere. But the scripts need to be written and somebody has to do the work. If we could fix the CTRL+C problem also I would be mostly satisfied. Cu thl -- Thorsten Leemhuis From fedora at leemhuis.info Thu Jun 1 16:51:50 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jun 2006 18:51:50 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <20060601183652.5b123e9e.bugs.michael@gmx.net> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <20060601183652.5b123e9e.bugs.michael@gmx.net> Message-ID: <1149180710.2329.58.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 18:36 +0200 schrieb Michael Schwendt: > On Thu, 01 Jun 2006 17:00:12 +0200, Thorsten Leemhuis wrote: > > > I would even sleep really good if there would be a mechanism that checks > > md5sum's against upstream packages. But that's quite complicated to > > implement and might be to much overhead. > Do you also want to check patches and compressed patches? Well, as I said: "I would even sleep really good" -- We would have to, but I don't think we have the man-power to do that. > > > This discussion would also be useful in the > > > context of developing a mechanism for having a team of people > > > responsible for a package, rather than a single owner. > > We really need that. But that's stalled mostly because nobody in FESCo > > really works on driving it forward and the proposal from Patrice is > > still in my Todo-Inbox. :-(( > Well, some packagers do it already. They simply talk to eachother and then > add themselves to the Cc field in owners.list, since bugzilla cannot > handle more than a single assignee. That's only one small and easy part of the whole Co-Maintainers idea. See my other mail I send in reply to scop I send ten minutes ago. CU thl -- Thorsten Leemhuis From ville.skytta at iki.fi Thu Jun 1 17:24:42 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 01 Jun 2006 20:24:42 +0300 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149180382.2329.52.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149179204.22041.45.camel@localhost.localdomain> <1149180382.2329.52.camel@localhost.localdomain> Message-ID: <1149182682.22041.66.camel@localhost.localdomain> On Thu, 2006-06-01 at 18:46 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 19:26 +0300 schrieb Ville Skytt?: > > This topic surfaces every now and then, often to be quickly countered > > with "what do you need, just do it", which to my knowledge has not been > > really answered. Come on, what is there really to "drive forward" in > > this? > > Mainly this (or parts of it; or parts now, others later): (I don't feel like reading the linked messages right now, so I'll throw some off-the-cuff solutions.) > - Allow new contributors to start as Co-Maintainers: > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00506.html Existing maintainer proxies the newcomer's commits for a while, then starts to sponsor him at which point the newcomer gets commit access, then proceed as usual. > - Proposal from Patrice with a lot of good ideas: > https://www.redhat.com/archives/fedora-extras-list/2006-April/msg00962.html Much too long for me to read now. > - a way to mark "Maintainer foo works on FC5 and devel, Maintainer bar > on FC3 and FC4" in owners.list Assuming this is only for being auto-Cc'd/assigned in Bugzilla for new reports: how many packages are there that receive that many bug reports that it wouldn't work to just be Cc'd/assigned on all of them, even if one is maintaining only specific branch(es)? Why wouldn't someone who maintains a package only for a subset of branches be insterested in hearing about all bug reports on the package? > - A proper policy in the wiki. Link to this post :) > [about CVS ACLs:] Sounds really good to me. BTW, I'd say sponsors should also get access > everywhere. But the scripts need to be written and somebody has to do > the work. And with change to another scm looming, the number of folks potentially interested in spending time with that is rapidly approaching zero -> back to square one, I'm afraid... From ville.skytta at iki.fi Thu Jun 1 17:35:52 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 01 Jun 2006 20:35:52 +0300 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149180382.2329.52.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149179204.22041.45.camel@localhost.localdomain> <1149180382.2329.52.camel@localhost.localdomain> Message-ID: <1149183352.22041.72.camel@localhost.localdomain> On Thu, 2006-06-01 at 18:46 +0200, Thorsten Leemhuis wrote: > Did I miss anything? Missed replying to this question in my previous reply, d'oh: dunno, but possibly apart from the question regarding newcomer co-maintainership, I'd put all of the things you mentioned under the "just do it"/"common sense" umbrella. From ifoox at redhat.com Thu Jun 1 20:27:17 2006 From: ifoox at redhat.com (Igor Foox) Date: Thu, 01 Jun 2006 16:27:17 -0400 Subject: Packaging Jython and its dependencies for Extras Message-ID: <1149193638.2736.13.camel@tool.toronto.redhat.com> Hi, I would like to submit Jython and it's dependencies[1] to Extras, I need Jython as a dependency for another package I plan to submit shortly (the Eclipse PyDev plugin[2]). However I won't have the resources to maintain the Jython-related packages. I'm almost finished with making the SRPMS based on SRPMS from jpackage.org, and will submit them shortly. Is there anyone that would be interested in ownership of these packages thereafter? Thanks Igor [1] Jython: http://www.jpackage.org/rpm.php?id=1147 ht2html: http://www.jpackage.org/rpm.php?id=1382 ant-contrib: http://www.jpackage.org/rpm.php?id=913 mysql-connector-java: http://www.jpackage.org/rpm.php?id=3365 libreadline-java: http://www.jpackage.org/rpm.php?id=2369 [2] http://pydev.sourceforge.net/ From michael at knox.net.nz Thu Jun 1 20:35:34 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 02 Jun 2006 08:35:34 +1200 Subject: Packaging Jython and its dependencies for Extras In-Reply-To: <1149193638.2736.13.camel@tool.toronto.redhat.com> References: <1149193638.2736.13.camel@tool.toronto.redhat.com> Message-ID: <447F4F96.1050801@knox.net.nz> I am happy to help maintain some of these. Michael Igor Foox wrote: > Hi, > > I would like to submit Jython and it's dependencies[1] to Extras, > I need Jython as a dependency for another package I plan to submit > shortly (the Eclipse PyDev plugin[2]). However I won't have the > resources > to maintain the Jython-related packages. I'm almost finished with making > the SRPMS based on SRPMS from jpackage.org, and will submit them > shortly. > > Is there anyone that would be interested in ownership of these packages > thereafter? > > Thanks > Igor > > [1] > Jython: http://www.jpackage.org/rpm.php?id=1147 > ht2html: http://www.jpackage.org/rpm.php?id=1382 > ant-contrib: http://www.jpackage.org/rpm.php?id=913 > mysql-connector-java: http://www.jpackage.org/rpm.php?id=3365 > libreadline-java: http://www.jpackage.org/rpm.php?id=2369 > > [2] http://pydev.sourceforge.net/ > > From nicolas.mailhot at laposte.net Thu Jun 1 20:01:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 Jun 2006 22:01:36 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149174012.2329.11.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> Message-ID: <1149192099.15393.16.camel@rousalka.dyndns.org> Hi, You don't need complex ACL features to make the current system a lot more secure. Just : - ironclad the mail sending on commit - systematically send a copy of the commit message to the list of maintainers associated with a package (most maintainers do not have time to follow the full FE commit list) - when a package build is requested, send a magic cookie to all the associated maintainers and the security team and do not push the build till the cookie is returned by mail by one of them - setup a webscm somewhere and automatically create user profiles which include history views of all the packages associated with each individual FE member. Because, you know, if we make sure everything which happens is communicated to the right people before the result is pushed to users there is absolutely no need to protect against malicious users. Besides re-reading their changes this will help maintainers catch their own honest mistakes. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Thu Jun 1 20:52:28 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 01 Jun 2006 23:52:28 +0300 Subject: Packaging Jython and its dependencies for Extras In-Reply-To: <1149193638.2736.13.camel@tool.toronto.redhat.com> References: <1149193638.2736.13.camel@tool.toronto.redhat.com> Message-ID: <1149195148.22041.79.camel@localhost.localdomain> On Thu, 2006-06-01 at 16:27 -0400, Igor Foox wrote: > I would like to submit Jython and it's dependencies[1] to Extras, > I need Jython as a dependency for another package I plan to submit > shortly (the Eclipse PyDev plugin[2]). Is [2] something different than the eclipse-pydev package which is already in Core since FC4? From chris.stone at gmail.com Thu Jun 1 20:55:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 1 Jun 2006 13:55:53 -0700 Subject: MySQL user install possible? In-Reply-To: <1149078934.3252.2.camel@tameshk.farsiweb.info> References: <1149078934.3252.2.camel@tameshk.farsiweb.info> Message-ID: On 5/31/06, Roozbeh Pournader wrote: > ??? ??????? 2006-05-30 ???? 22:14 -0700? Christopher Stone ????: > > I have a package that requires a MySQL user and database be set up in > > order for the package to function properly. > > > > Ideally I would like to do this during the install if possible. What > > is the best way to handle this problem? Is it possible to handle this > > within a spec file or must it be done manually by the user installing > > the software? > > Does the software strictly *require* the MySQL server to be on the same > machine? If not (which is the most probable case), please do not do > anything about it. Just add a README.fedora or INSTALL.fedora file and > explain what should the user do after installing the RPM. I don't like this solution. Adding a readme file to tell people how to properly install the thing is primitive. How come Fedora doesn't have anything like debian's dbconfig? http://people.debian.org/~seanius/policy/dbconfig-common.html/ From ifoox at redhat.com Thu Jun 1 20:59:33 2006 From: ifoox at redhat.com (Igor Foox) Date: Thu, 01 Jun 2006 16:59:33 -0400 Subject: Packaging Jython and its dependencies for Extras In-Reply-To: <1149195148.22041.79.camel@localhost.localdomain> References: <1149193638.2736.13.camel@tool.toronto.redhat.com> <1149195148.22041.79.camel@localhost.localdomain> Message-ID: <1149195573.2736.16.camel@tool.toronto.redhat.com> On Thu, 2006-06-01 at 23:52 +0300, Ville Skytt? wrote: > On Thu, 2006-06-01 at 16:27 -0400, Igor Foox wrote: > > > I would like to submit Jython and it's dependencies[1] to Extras, > > I need Jython as a dependency for another package I plan to submit > > shortly (the Eclipse PyDev plugin[2]). > > Is [2] something different than the eclipse-pydev package which is > already in Core since FC4? No, it's the same package. However I'm planning to update it to a much newer version, which I backported from using Java 1.5 to Java 1.4, and this new version depends on Jython (for its Jython-related functionality). I've searched around and saw that several people talked in the past about including Jython in Extras, so I thought this might be a good time to do that. :) I'm planning to push eclipse-pydev from Core to Extras, and to split it into (at least) 2 binary RPMS, one of which will be eclipse-pydev-jython and be dependant on Jython. Igor From buildsys at fedoraproject.org Thu Jun 1 20:49:58 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 1 Jun 2006 16:49:58 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-01 Message-ID: <20060601204958.1548515216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 34 asymptote-1.06-5.fc5 bigloo-2.8a-2.fc5 gnomad2-2.8.5-1.fc5 gtklp-1.2.2-1.fc5 ikvm-0.22-7.fc5 itcl-3.3-0.5.RC1.fc5 itk-3.3-0.3.RC1.fc5 jack-audio-connection-kit-0.101.1-9.fc5 kerry-0.1.1-2.fc5 kipi-plugins-0.1.0-0.10.rc2.fc5 knemo-0.4.0-4.fc5 lua-5.1-4.fc5 mod_cband-0.9.7.4-1.fc5 opensc-0.11.1-1.fc5 perl-Expect-1.17-1.fc5 perl-IO-Tty-1.04-1.fc5 perl-Math-Pari-2.010705-1.fc5 perl-Net-Jabber-2.0-6.fc5 perl-Net-XMPP-1.0-5.fc5 perl-XML-Stream-1.22-5.fc5 plplot-5.6.1-1.fc5 pypoker-eval-131.0-4.fc5 python-ogg-1.3-2.fc5 python-sqlalchemy-0.2.1-1.fc5 qucs-0.0.9-2.fc5 showimg-0.9.5-6.fc5 stellarium-0.8.0-4.fc5 tcldom-3.1-5.fc5 tclxml-3.1-8.fc5 texmaker-1.3-3.fc5 utrac-0.3.0-7.fc5 workrave-1.8.3-1.fc5 xmms-arts-0.7.1-3 xmms-lirc-1.4-8.fc5 Packages built and released for Fedora Extras 4: 32 asymptote-1.06-5.fc4 bigloo-2.8a-2.fc4 gnomad2-2.8.5-1.fc4 gtklp-1.2.2-1.fc4 itcl-3.3-0.4.RC1.fc4 itk-3.3-0.3.RC1.fc4 jack-audio-connection-kit-0.101.1-9.fc4 kipi-plugins-0.1.0-0.10.rc2.fc4 knemo-0.4.0-4.fc4 libtranslate-0.99-6.fc4 lua-5.1-4.fc4 mod_cband-0.9.7.4-1.fc4 paraview-2.4.3-6.fc4 perl-IO-Tty-1.04-1.fc4 perl-Math-Pari-2.010705-1.fc4 perl-Net-Jabber-2.0-5.fc4 perl-Net-XMPP-1.0-5.fc4 perl-String-CRC32-1.4-1.fc4 perl-XML-Stream-1.22-5.fc4 plplot-5.6.1-1.fc4 pypoker-eval-131.0-4.fc4 python-ogg-1.3-2.fc4 python-sqlalchemy-0.2.1-1.fc4 python-vorbis-1.3-2.fc4 showimg-0.9.5-6.fc4 tcldom-3.1-3.fc4 tclxml-3.1-3.fc4 texmaker-1.3-3.fc4 utrac-0.3.0-7.fc4 workrave-1.8.3-1.fc4 xfce4-taskmanager-0.3.1-3.fc4 xfce4-weather-plugin-0.4.9-5.fc4 Packages built and released for Fedora Extras 3: 3 gnomad2-2.8.5-1.fc3 kipi-plugins-0.1.0-0.10.rc2.fc3 perl-String-CRC32-1.4-1.fc3 Packages built and released for Fedora Extras development: 39 anjuta-gdl-0.6.1-2.fc6 bigloo-2.8a-2.fc6 bsd-games-2.17-12.fc6 csmash-0.6.6-12.fc6 gcfilms-6.2-1.fc6 gnomad2-2.8.5-1.fc6 gparted-0.2.5-2.fc6 gtklp-1.2.2-1.fc6 ikvm-0.22-7.fc6 itcl-3.3-0.5.RC1.fc6 itk-3.3-0.3.RC1.fc6 kipi-plugins-0.1.0-0.10.rc2.fc6 libapreq2-2.08-0.rc2.3.fc6 lua-5.1-4.fc6 openct-0.6.7-3.fc6 opensc-0.11.1-1.fc6 perl-Expect-1.17-1.fc6 perl-IO-Tty-1.04-1.fc6 perl-Math-Pari-2.010705-1.fc6 perl-Net-Jabber-2.0-5.fc6 perl-Net-XMPP-1.0-5.fc6 perl-XML-Stream-1.22-5.fc6 plplot-5.6.1-1.fc6 pypoker-eval-131.0-4.fc6 python-sqlalchemy-0.2.1-1.fc6 qucs-0.0.9-2.fc6 shorewall-3.2.0-0.1.Beta8.fc6 splint-3.1.1-14.fc6 stellarium-0.8.0-4.fc6 sylpheed-claws-plugins-2.2.0-1.fc6 tcldom-3.1-5.fc6 tclxml-3.1-8.fc6 texmaker-1.3-3.fc6 utrac-0.3.0-7.fc6 workrave-1.8.3-1.fc6 xgalaxy-2.0.34-4.fc6 xmms-arts-0.7.1-3.fc6 xmms-lirc-1.4-8.fc6 xscreensaver-5.00-4.2.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jun 1 21:36:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 01 Jun 2006 21:36:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-01 Message-ID: <20060601213644.18598.16884@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg ====================================================================== New report for: rdieter AT math.unl.edu package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Thu Jun 1 21:36:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 01 Jun 2006 21:36:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-01 Message-ID: <20060601213644.18611.3842@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-6.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-6.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- showimg-pgsql 0.9.5-6.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-6.fc5.i386 from fedora-extras-5-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-6.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: showimg-pgsql - 0.9.5-6.fc5.ppc from fedora-extras-5-ppc unresolved deps: libpqxx-2.5.5.so ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Thu Jun 1 21:36:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 01 Jun 2006 21:36:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-01 Message-ID: <20060601213645.18614.63802@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gtktalog 1.0.4-7.fc5.i386 qtparted 0.4.5-5.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gtktalog 1.0.4-7.fc5.ppc qtparted 0.4.5-5.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gtktalog 1.0.4-7.fc5.x86_64 qtparted 0.4.5-5.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Thu Jun 1 21:36:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 01 Jun 2006 21:36:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-01 Message-ID: <20060601213644.18606.18047@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-6.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-6.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch showimg-pgsql 0.9.5-6.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-6.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-6.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: showimg-pgsql - 0.9.5-6.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpqxx-2.5.5.so ====================================================================== package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 From jwboyer at jdub.homelinux.org Fri Jun 2 00:21:24 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 01 Jun 2006 19:21:24 -0500 Subject: gnome-yum soon to be orphaned In-Reply-To: <20060601213645.18614.63802@extras64.linux.duke.edu> References: <20060601213645.18614.63802@extras64.linux.duke.edu> Message-ID: <1149207684.27356.3.camel@vader.jdub.homelinux.org> On Thu, 2006-06-01 at 21:36 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-development-i386: > gnome-yum 0.1.3-1.i386 Ok, gnome-yum has been broken in -devel for quite some time and the maintainer hasn't responded to emails or bug 191614. If there is no response in another week, gnome-yum will be orphaned. josh From lists at forevermore.net Fri Jun 2 02:35:06 2006 From: lists at forevermore.net (Chris Petersen) Date: Thu, 01 Jun 2006 19:35:06 -0700 Subject: bug with `make tag` Message-ID: <447FA3DA.5060805@forevermore.net> Wasn't sure where to file a bug report like this, so hopefully someone here can point me in the right direction. I just tried `make tag` but had forgotten to commit the changes to my spec and I got an error. After I committed the changes, I ran `make tag` again but it complained that there was already a tag made with that number. I tried `make build` but it failed and complained that my spec wasn't tagged properly. -Chris From rdieter at math.unl.edu Fri Jun 2 03:13:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 Jun 2006 22:13:05 -0500 Subject: bug with `make tag` In-Reply-To: <447FA3DA.5060805@forevermore.net> References: <447FA3DA.5060805@forevermore.net> Message-ID: Chris Petersen wrote: > Wasn't sure where to file a bug report like this, so hopefully someone > here can point me in the right direction. > > I just tried `make tag` but had forgotten to commit the changes to my > spec and I got an error. After I committed the changes, I ran `make > tag` again but it complained that there was already a tag made with that > number. I tried `make build` but it failed and complained that my spec > wasn't tagged properly. Easiest fix: Increment Release, cvs checkin, make tag -- Rex From chris.stone at gmail.com Fri Jun 2 03:36:41 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 1 Jun 2006 20:36:41 -0700 Subject: bug with `make tag` In-Reply-To: <447FA3DA.5060805@forevermore.net> References: <447FA3DA.5060805@forevermore.net> Message-ID: On 6/1/06, Chris Petersen wrote: > Wasn't sure where to file a bug report like this, so hopefully someone > here can point me in the right direction. > > I just tried `make tag` but had forgotten to commit the changes to my > spec and I got an error. After I committed the changes, I ran `make > tag` again but it complained that there was already a tag made with that > number. I tried `make build` but it failed and complained that my spec > wasn't tagged properly. This happens to everybody atleast once. It's the reason why pygame on devel isn't up to date. There really needs to be a make untag or something to fix this IMO. From j.w.r.degoede at hhs.nl Fri Jun 2 08:21:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 02 Jun 2006 10:21:30 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <1149192099.15393.16.camel@rousalka.dyndns.org> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149192099.15393.16.camel@rousalka.dyndns.org> Message-ID: <447FF50A.5000203@hhs.nl> Nicolas Mailhot wrote: > Hi, > > You don't need complex ACL features to make the current system a lot > more secure. Just : > - ironclad the mail sending on commit > - systematically send a copy of the commit message to the list of > maintainers associated with a package (most maintainers do not have time > to follow the full FE commit list) > - when a package build is requested, send a magic cookie to all the > associated maintainers and the security team and do not push the build > till the cookie is returned by mail by one of them > - setup a webscm somewhere and automatically create user profiles which > include history views of all the packages associated with each > individual FE member. > > Because, you know, if we make sure everything which happens is > communicated to the right people before the result is pushed to users > there is absolutely no need to protect against malicious users. Besides > re-reading their changes this will help maintainers catch their own > honest mistakes. > > Very very good idea! + a zillion. One note though: > - systematically send a copy of the commit message to the list of > maintainers associated with a package (most maintainers do not have time > to follow the full FE commit list) I thinks this should include the sponsor too (for a sponsor configurable amount of time from the sponsering). Regards, Hans From fedora at leemhuis.info Fri Jun 2 08:36:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Jun 2006 10:36:46 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: <447FF50A.5000203@hhs.nl> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> <20060531223829.43fb77dc.bugs.michael@gmx.net> <1149142420.21132.22.camel@thl.ct.heise.de> <1149146711.21132.34.camel@thl.ct.heise.de> <1149166983.21132.65.camel@thl.ct.heise.de> <645d17210606010741l3d28031dt4891fd4b36ea4f9f@mail.gmail.com> <1149174012.2329.11.camel@localhost.localdomain> <1149192099.15393.16.camel@rousalka.dyndns.org> <447FF50A.5000203@hhs.nl> Message-ID: <1149237406.30245.14.camel@thl.ct.heise.de> Am Freitag, den 02.06.2006, 10:21 +0200 schrieb Hans de Goede: > Nicolas Mailhot wrote: [...] > > One note though: > > - systematically send a copy of the commit message to the list of > > maintainers associated with a package (most maintainers do not have time > > to follow the full FE commit list) > I thinks this should include the sponsor too (for a sponsor configurable > amount of time from the sponsering). This ideas is around since months and on the FESCo schedule also. Nobody actually is working on it. Any volunteers? CU thl From Christian.Iseli at licr.org Fri Jun 2 08:45:11 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 02 Jun 2006 10:45:11 +0200 Subject: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting) In-Reply-To: Your message of "Fri, 02 Jun 2006 10:21:30 +0200." <447FF50A.5000203@hhs.nl> Message-ID: <200606020845.k528jBNb022286@ludwig-alpha.unil.ch> Nicolas Mailhot wrote: > - when a package build is requested, send a magic cookie to all the > associated maintainers and the security team and do not push the build > till the cookie is returned by mail by one of them I rather like the idea. I wonder how hard it'd be for that email to contain a diff between: - the spec file of the package currently in the repo - the spec file that'll be used in the build request That way, nasty changes in the spec would become fairly obvious... Cheers, Christian From bugs.michael at gmx.net Fri Jun 2 10:34:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 2 Jun 2006 12:34:15 +0200 Subject: bug with `make tag` In-Reply-To: References: <447FA3DA.5060805@forevermore.net> Message-ID: <20060602123415.d1707fe2.bugs.michael@gmx.net> On Thu, 1 Jun 2006 20:36:41 -0700, Christopher Stone wrote: > > Wasn't sure where to file a bug report like this, so hopefully someone > > here can point me in the right direction. > > > > I just tried `make tag` but had forgotten to commit the changes to my > > spec and I got an error. After I committed the changes, I ran `make > > tag` again but it complained that there was already a tag made with that > > number. I tried `make build` but it failed and complained that my spec > > wasn't tagged properly. > > This happens to everybody atleast once. It's the reason why pygame on > devel isn't up to date. There really needs to be a make untag or > something to fix this IMO. That this comes up every now and then only proves that packagers are not careful enough when they work on their packages. It is already too easy to move an existing tag. Too easy to damage something in CVS, because we use these tags as the build source. "man cvs" and reading Makefile.common gives a clue. If you're not willing to look under the hood, simply bump release, commit and run make tag once more. From jbloodworth at sc.rr.com Fri Jun 2 12:41:46 2006 From: jbloodworth at sc.rr.com (Jay Bloodworth) Date: Fri, 02 Jun 2006 08:41:46 -0400 Subject: Building wine on x86_64 Message-ID: <1149252106.21213.31.camel@localhost.localdomain> Hi, Can anyone tell me how to set up my build environment to rebuild wine-0.9.13-2.fc5 (slightly patched) on my amd64 box? I'm trying to install i386 versions of all the BuildRequires, but I'm running into errors like: Transaction Check Error: file /usr/bin/artsc-config from install of arts-devel-1.5.2-0.1.fc5 conflicts with file from package arts-devel-1.5.2-0.1.fc5 file /usr/include/kde/arts/gsl/gslconfig.h from install of arts-devel-1.5.2-0.1.fc5 conflicts with file from package arts-devel-1.5.2-0.1.fc5 file /usr/bin/esd-config from install of esound-devel-0.2.36-2.2.1 conflicts with file from package esound-devel-0.2.36-2.2.1 file /usr/bin/audiofile-config from install of audiofile-devel-0.2.6-2.2.1 conflicts with file from package audiofile-devel-0.2.6-2.2.1 Is there any way to nicely resolve conflicts like this? Are there general guidelines for setting up a sane cross compile environment, preferably without resorting to dual boot? Assuming I get the appropriate packages installed, any other issues I should look out for when it is time to build? Thanks, Jay From Matt_Domsch at dell.com Fri Jun 2 13:04:22 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 2 Jun 2006 08:04:22 -0500 Subject: Building wine on x86_64 In-Reply-To: <1149252106.21213.31.camel@localhost.localdomain> References: <1149252106.21213.31.camel@localhost.localdomain> Message-ID: <20060602130422.GA12461@lists.us.dell.com> On Fri, Jun 02, 2006 at 08:41:46AM -0400, Jay Bloodworth wrote: > Hi, > > Can anyone tell me how to set up my build environment to rebuild > wine-0.9.13-2.fc5 (slightly patched) on my amd64 box? I'm trying to > install i386 versions of all the BuildRequires, but I'm running into > errors like: > > Transaction Check Error: file /usr/bin/artsc-config from install of > arts-devel-1.5.2-0.1.fc5 conflicts with file from package > arts-devel-1.5.2-0.1.fc5 > file /usr/include/kde/arts/gsl/gslconfig.h from install of > arts-devel-1.5.2-0.1.fc5 conflicts with file from package > arts-devel-1.5.2-0.1.fc5 > file /usr/bin/esd-config from install of esound-devel-0.2.36-2.2.1 > conflicts with file from package esound-devel-0.2.36-2.2.1 > file /usr/bin/audiofile-config from install of > audiofile-devel-0.2.6-2.2.1 conflicts with file from package > audiofile-devel-0.2.6-2.2.1 > > Is there any way to nicely resolve conflicts like this? Are there > general guidelines for setting up a sane cross compile environment, > preferably without resorting to dual boot? Assuming I get the > appropriate packages installed, any other issues I should look out for > when it is time to build? mock is your friend. really. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/wine-0.9.13-2.fc6.src.rpm/ has current wine i386 built on an x86_64 system using mock. http://fedoraproject.org/wiki/Extras/MockTricks -- 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 paul at all-the-johnsons.co.uk Fri Jun 2 13:31:17 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Fri, 02 Jun 2006 14:31:17 +0100 Subject: Help - any got some spare ftp space? Message-ID: <1149255077.7498.21.camel@mrwibble.mrwobble> Hi, I'm going to be leaving my employer in the nearish future for pastures new (and closer to home). This will mean that the URL I've been using for my extra packages will no longer be available to me from roughly the start of September (though I will need the packages shifted before then). Can anyone offer me some ftp space for the development packages? Other than monodoc, none of the packages I maintain are that huge, though they do mount up. Thanks TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dwmw2 at infradead.org Fri Jun 2 13:56:28 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 02 Jun 2006 14:56:28 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531151520.GC30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> Message-ID: <1149256588.5053.42.camel@pmac.infradead.org> Would it be useful to do this on PowerPC too, or are most of the results not arch-specific? Could you share the scripts you're using to do it? Or should I just give you an account on a decent PPC64 machine so you can do it there? -- dwmw2 From Matt_Domsch at dell.com Fri Jun 2 14:06:49 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 2 Jun 2006 09:06:49 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <1149256588.5053.42.camel@pmac.infradead.org> References: <20060531151520.GC30021@lists.us.dell.com> <1149256588.5053.42.camel@pmac.infradead.org> Message-ID: <20060602140648.GA2281@humbolt.us.dell.com> On Fri, Jun 02, 2006 at 02:56:28PM +0100, David Woodhouse wrote: > Would it be useful to do this on PowerPC too, or are most of the results > not arch-specific? I was wondering that; I suspect most aren't arch-specific, but there are a few packages that ExcludeArch / ExclusiveArch would build on PPC but not i386/x86_64. > Could you share the scripts you're using to do it? Or should I just give > you an account on a decent PPC64 machine so you can do it there? Either way; I'm happy to post the scripts, though they're somewhat specific to my environment. The only real trick is having a full rawhide / extras dev mirror available nearby (the scripts assume on locally mounted storage). http://linux.dell.com/files/fedora/FixBuildRequires/mdomsch_buildsys.tgz http://linux.dell.com/files/fedora/FixBuildRequires/mdomsch_buildsys.tgz.sign For these, create a user (e.g. 'build'), and extract this into that user's home dir. There's a config file bin/env-common where most of the environment-specific stuff like directories can be changed. To run it: $ nohup bin/autobuild_rawhide & $ tail -f rawhide-build.log 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 dwmw2 at infradead.org Fri Jun 2 14:34:39 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 02 Jun 2006 15:34:39 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060602140648.GA2281@humbolt.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <1149256588.5053.42.camel@pmac.infradead.org> <20060602140648.GA2281@humbolt.us.dell.com> Message-ID: <1149258879.5053.47.camel@pmac.infradead.org> On Fri, 2006-06-02 at 09:06 -0500, Matt Domsch wrote: > Either way; I'm happy to post the scripts, though they're somewhat > specific to my environment. The only real trick is having a full > rawhide / extras dev mirror available nearby (the scripts assume on > locally mounted storage). Yeah, I'm working on that, slowly -- my DSL line is limited by telco incompetence to 512Kb/s at the moment, and a bandwidth cap applies between the hours of 8 and 6 so it didn't finish downloading rawhide SRPMS before I killed it... Extras will take a little longer :) Thanks for the scripts -- I'll have a play with those later. It'll have to be on a G5; our POWER5 box has had to visit the US, allegedly for tax reasons. It should be back in a week or so :) -- dwmw2 From paul at all-the-johnsons.co.uk Fri Jun 2 14:36:34 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Fri, 02 Jun 2006 15:36:34 +0100 Subject: Broken packages Message-ID: <1149258994.7498.41.camel@mrwibble.mrwobble> Hi, I've noticed on the nightly broken packages lists that a number keep cropping up for the rawhide builds, amongst them is qparted. Is there any mechanism for flagging these and saying that unless they're fixed in a reasonable amount of time [1], they're up for adoption? TTFN Paul [1] Obviously, if the problem is a long standing one with the main source which is being worked on, then this can be ignored - however, if it is something which is just reliant on a rebuild... -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dragoran at feuerpokemon.de Fri Jun 2 14:44:31 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 02 Jun 2006 16:44:31 +0200 Subject: Fedora Extras Package Build Report 2006-05-31 In-Reply-To: <20060531101835.187AA15216B@buildsys.fedoraproject.org> References: <20060531101835.187AA15216B@buildsys.fedoraproject.org> Message-ID: <44804ECF.90300@feuerpokemon.de> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 5: 24 > > Coin2-2.4.5-1.fc5 > SoQt-1.3.0-3.fc5 > freehdl-0.0.2-1.fc5 > gobby-0.3.1-1.fc5 > gossip-0.11.1-2.fc5 > gtkwave-3.0.3-1.fc5 > gurlchecker-0.10.0-1.fc5 > jpgraph-2.1.2-1.fc5 > koffice-1.5.1-1.fc5 > koffice-langpack-1.5.1-1.fc5 > libchmxx-0.1-2.fc5 > libpqxx-2.6.6-1.fc5 > perl-GSSAPI-0.22-1.fc5 > perl-Pipeline-3.12-2.fc5 > poker-eval-131.0-1.fc5 > qps-1.9.16-1.fc5 > qt4-4.1.3-6.fc5 > qucs-0.0.9-1.fc5 > rapidsvn-0.9.2-1.fc5 > texmaker-1.3-2.fc5 > uuid-1.4.2-4.fc5 > vpnc-0.3.3-7.1 > wine-docs-0.9.14-1.fc5 > and where is wine 0.9.14 ? why are only the docs updated? has the build failed? > xbindkeys-1.7.3-1.fc5 > > > Packages built and released for Fedora Extras 4: 20 > > Coin2-2.4.5-1.fc4 > SoQt-1.3.0-3.fc4 > freehdl-0.0.2-1.fc4 > gcl-2.6.7-6.fc4 > gtkwave-3.0.3-1.fc4 > gurlchecker-0.10.0-1.fc4 > koffice-1.5.1-1.fc4 > koffice-langpack-1.5.1-1.fc4 > libpqxx-2.6.6-1.fc4 > mhonarc-2.6.12-1.fc4 > perl-GSSAPI-0.22-1.fc4 > perl-Pipeline-3.12-2.fc4 > poker-eval-131.0-1.fc4 > qps-1.9.16-1.fc4 > qt4-4.1.3-6.fc4 > qucs-0.0.9-1.fc4 > scim-qtimm-0.9.4-1.fc4 > texmaker-1.3-2.fc4 > uuid-1.4.2-4.fc4 > wine-docs-0.9.14-0.1.fc4 > > > Packages built and released for Fedora Extras 3: 6 > > Coin2-2.4.5-1.fc3 > SoQt-1.3.0-3.fc3 > freehdl-0.0.2-1.fc3 > gtkwave-3.0.3-1.fc3 > qucs-0.0.9-1.fc3 > wine-docs-0.9.14-1.fc3 > > > Packages built and released for Fedora Extras development: 33 > > Coin2-2.4.5-1.fc6 > SoQt-1.3.0-3.fc6 > anjuta-gdl-0.6.1-1.fc6 > dbus-qt-0.61-3.fc6 > freehdl-0.0.2-1.fc6 > gossip-0.11.1-3.fc6 > gtkwave-3.0.3-1.fc6 > gurlchecker-0.10.0-1.fc6 > jpgraph-2.1.2-1.fc6 > knemo-0.4.0-4.fc6 > koffice-1.5.1-1.fc6 > koffice-langpack-1.5.1-1.fc6 > libpqxx-2.6.6-1.fc6 > libqalculate-0.9.3-2.fc6 > mail-notification-2.0-13.fc6 > maxima-5.9.3-4.fc6 > nautilus-actions-1.2-2.fc6 > perl-GSSAPI-0.22-1.fc6 > perl-Pipeline-3.12-2.fc6 > poker-eval-131.0-1.fc6 > python-ogg-1.3-2.fc6 > python-vorbis-1.3-2.fc6 > qps-1.9.16-1.fc6 > qt4-4.1.3-6.fc6 > qucs-0.0.9-1.fc6 > rapidsvn-0.9.2-1.fc6 > sbcl-0.9.13-2.fc6 > scim-bridge-0.1.12-1.fc6 > scribus-1.3.3.2-1.fc6 > sylpheed-2.2.5-1.fc6 > texmaker-1.3-2.fc6 > vpnc-0.3.3-8 > wine-docs-0.9.14-1.fc6 > > > > For more information about the built packages please see the repository > or the Fedora Info Feed: http://fedoraproject.org/infofeed/ > > From steve at silug.org Fri Jun 2 14:45:47 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 2 Jun 2006 09:45:47 -0500 Subject: Broken packages In-Reply-To: <1149258994.7498.41.camel@mrwibble.mrwobble> References: <1149258994.7498.41.camel@mrwibble.mrwobble> Message-ID: <20060602144547.GA30472@osiris.silug.org> On Fri, Jun 02, 2006 at 03:36:34PM +0100, PFJ wrote: > I've noticed on the nightly broken packages lists that a number keep > cropping up for the rawhide builds, amongst them is qparted. Since you bring up qtparted, it fails to build on rawhide right now. I haven't had time to figure out why yet. > Is there any mechanism for flagging these and saying that unless they're > fixed in a reasonable amount of time [1], they're up for adoption? On releases, sure, but on rawhide? That seems a bit excessive. 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 paul at all-the-johnsons.co.uk Fri Jun 2 14:49:29 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Fri, 02 Jun 2006 15:49:29 +0100 Subject: Broken packages In-Reply-To: <20060602144547.GA30472@osiris.silug.org> References: <1149258994.7498.41.camel@mrwibble.mrwobble> <20060602144547.GA30472@osiris.silug.org> Message-ID: <1149259770.7498.44.camel@mrwibble.mrwobble> Hi, > > I've noticed on the nightly broken packages lists that a number keep > > cropping up for the rawhide builds, amongst them is qparted. > > Since you bring up qtparted, it fails to build on rawhide right now. > I haven't had time to figure out why yet. Is it not building at all or just in mock? > > Is there any mechanism for flagging these and saying that unless they're > > fixed in a reasonable amount of time [1], they're up for adoption? > > On releases, sure, but on rawhide? That seems a bit excessive. Not really - there are some which have been there for quite a while now. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From steve at silug.org Fri Jun 2 15:02:59 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 2 Jun 2006 10:02:59 -0500 Subject: Broken packages In-Reply-To: <1149259770.7498.44.camel@mrwibble.mrwobble> References: <1149258994.7498.41.camel@mrwibble.mrwobble> <20060602144547.GA30472@osiris.silug.org> <1149259770.7498.44.camel@mrwibble.mrwobble> Message-ID: <20060602150259.GB30472@osiris.silug.org> On Fri, Jun 02, 2006 at 03:49:29PM +0100, PFJ wrote: > > > I've noticed on the nightly broken packages lists that a number keep > > > cropping up for the rawhide builds, amongst them is qparted. > > > > Since you bring up qtparted, it fails to build on rawhide right now. > > I haven't had time to figure out why yet. > > Is it not building at all or just in mock? It appears to not build at all, but, again, I haven't really had the time to look into it. > > > Is there any mechanism for flagging these and saying that unless they're > > > fixed in a reasonable amount of time [1], they're up for adoption? > > > > On releases, sure, but on rawhide? That seems a bit excessive. > > Not really - there are some which have been there for quite a while now. Again, it's rawhide... I have a hard time being too concerned until we get into test releases. 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 nicolas.mailhot at laposte.net Fri Jun 2 16:11:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 2 Jun 2006 18:11:53 +0200 (CEST) Subject: Broken packages In-Reply-To: <20060602144547.GA30472@osiris.silug.org> References: <1149258994.7498.41.camel@mrwibble.mrwobble> <20060602144547.GA30472@osiris.silug.org> Message-ID: <7496.192.54.193.53.1149264713.squirrel@rousalka.dyndns.org> Le Ven 2 juin 2006 16:45, Steven Pritchard a ?crit : >> Is there any mechanism for flagging these and saying that unless they're >> fixed in a reasonable amount of time [1], they're up for adoption? > > On releases, sure, but on rawhide? That seems a bit excessive. Because we don't want to test FE for a given FC release at the FC release time? Sure you have more leaway to fix things for devel - that does not mean it's ok to have packages broken for looong times just because it's rawhide. Lowering rawhide support means lowering number of rawhide testers, which in turn makes FCt releases less testable, and the vicious circle can spin up till FC release itself is half-baked at release time. Remember, a single package breakage won't sink devel, but lots of aggregated broken packages will -- Nicolas Mailhot From fedora at leemhuis.info Fri Jun 2 17:09:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Jun 2006 19:09:03 +0200 Subject: status of "freenx" in Extras In-Reply-To: <1149179483.2329.36.camel@localhost.localdomain> References: <1149179483.2329.36.camel@localhost.localdomain> Message-ID: <1149268143.2316.15.camel@localhost.localdomain> Am Donnerstag, den 01.06.2006, 18:31 +0200 schrieb Thorsten Leemhuis: > Hi all! > > Now that hula has been solved: Does anyone know what's up with freenx in > extras? According to owners.list: > > Fedora Extras|freenx|freenx application/thin-client serve|zipsonic at gmail.com|extras-qa at fedoraproject.org > > zipsonic at gmail.com is zipsonic aka Richard A. Stout > > The import was done one year ago and nothing changed since then: > > http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/devel/?root=extras > http://cvs.fedora.redhat.com/viewcvs/rpms/freenx/FC-5/?root=extras > > But it was never build for Extras afais. He seems to still maintain the > package outside Fedora Extras: > > http://fedoranews.org/contributors/rick_stout/freenx/ > http://mail.kde.org/pipermail/freenx-knx/2006-May/003431.html > > I send him a private mail two and a half weeks ago --> no reply. > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg00214.html also got no reply. > CC'ing him to this mail, too (and Spot, his sponsor). Shall we call him > AWOL and the package orphaned if nothing happens in the next five days? Short status update: Richard replied in private to me and spot (his sponsor). Looks like he will start to maintain it again. More details later. CU thl -- Thorsten Leemhuis From paul at city-fan.org Fri Jun 2 17:15:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 02 Jun 2006 18:15:39 +0100 Subject: Broken packages In-Reply-To: <20060602150259.GB30472@osiris.silug.org> References: <1149258994.7498.41.camel@mrwibble.mrwobble> <20060602144547.GA30472@osiris.silug.org> <1149259770.7498.44.camel@mrwibble.mrwobble> <20060602150259.GB30472@osiris.silug.org> Message-ID: <4480723B.7060701@city-fan.org> Steven Pritchard wrote: > On Fri, Jun 02, 2006 at 03:49:29PM +0100, PFJ wrote: >>>> I've noticed on the nightly broken packages lists that a number keep >>>> cropping up for the rawhide builds, amongst them is qparted. >>> Since you bring up qtparted, it fails to build on rawhide right now. >>> I haven't had time to figure out why yet. >> Is it not building at all or just in mock? > > It appears to not build at all, but, again, I haven't really had the > time to look into it. It's failing to build because of a change in parted-devel between FC5 and rawhide. On FC5, the file /usr/include/parted/unit.h has: #define PED_SECTOR_SIZE 512LL On rawhide, the equivalent is: #define PED_SECTOR_SIZE_DEFAULT 512LL qtparted uses the PED_SECTOR_SIZE symbol, which on rawhide is undefined, so it fails. The attached patch gets it building again. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: qtparted-0.4.5-PED_SECTOR_SIZE.patch Type: text/x-patch Size: 368 bytes Desc: not available URL: From jbloodworth at sc.rr.com Fri Jun 2 17:16:17 2006 From: jbloodworth at sc.rr.com (Jay Bloodworth) Date: Fri, 02 Jun 2006 13:16:17 -0400 Subject: Building wine on x86_64 In-Reply-To: <20060602130422.GA12461@lists.us.dell.com> References: <1149252106.21213.31.camel@localhost.localdomain> <20060602130422.GA12461@lists.us.dell.com> Message-ID: <1149268577.2822.1.camel@localhost.localdomain> On Fri, 2006-06-02 at 08:04 -0500, Matt Domsch wrote: > > mock is your friend. really. > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/wine-0.9.13-2.fc6.src.rpm/ > has current wine i386 built on an x86_64 system using mock. > > http://fedoraproject.org/wiki/Extras/MockTricks > mock is in fact my new best friend. That did exactly what I needed. Thanks so much. Jay From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jun 2 17:19:01 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sat, 03 Jun 2006 02:19:01 +0900 Subject: Broken packages In-Reply-To: <4480723B.7060701@city-fan.org> References: <1149258994.7498.41.camel@mrwibble.mrwobble> <20060602144547.GA30472@osiris.silug.org> <1149259770.7498.44.camel@mrwibble.mrwobble> <20060602150259.GB30472@osiris.silug.org> <4480723B.7060701@city-fan.org> Message-ID: <44807305.6040308@ioa.s.u-tokyo.ac.jp> Paul Howarth wrote: > Steven Pritchard wrote: >> On Fri, Jun 02, 2006 at 03:49:29PM +0100, PFJ wrote: >>>>> I've noticed on the nightly broken packages lists that a number keep >>>>> cropping up for the rawhide builds, amongst them is qparted. >>>> Since you bring up qtparted, it fails to build on rawhide right now. >>>> I haven't had time to figure out why yet. >>> Is it not building at all or just in mock? >> >> It appears to not build at all, but, again, I haven't really had the >> time to look into it. > > It's failing to build because of a change in parted-devel between FC5 > and rawhide. > > Ah, I just reported to bugzilla 193870. From orion at cora.nwra.com Fri Jun 2 17:48:01 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 02 Jun 2006 11:48:01 -0600 Subject: Fedora Extras Package Build Report 2006-05-31 In-Reply-To: <44804ECF.90300@feuerpokemon.de> References: <20060531101835.187AA15216B@buildsys.fedoraproject.org> <44804ECF.90300@feuerpokemon.de> Message-ID: <448079D1.6030406@cora.nwra.com> dragoran wrote: > buildsys at fedoraproject.org wrote: >> Packages built and released for Fedora Extras 5: 24 >> wine-docs-0.9.14-1.fc5 >> > and where is wine 0.9.14 ? why are only the docs updated? has the build > failed? Separate packages: $ grep wine ~/fedora/extras/owners/owners.list Fedora Extras|wine|A Windows 16/32/64 bit emulator|andreas.bierfert at lowlatency.de|extras-qa at fedoraproject.org| Fedora Extras|wine-docs|Documentation for wine|andreas.bierfert at lowlatency.de|extras-qa at fedoraproject.org| Also, please trim your replies. Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From buildsys at fedoraproject.org Fri Jun 2 18:40:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 2 Jun 2006 14:40:09 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-02 Message-ID: <20060602184009.526A615216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 29 AGReader-1.1-9.fc5 DevIL-1.6.8-0.7.rc1.fc5 blam-1.8.2-5.fc5 dbus-qt-0.61-3.fc5 gtkwave-3.0.4-1.fc5 libapreq2-2.07-2.fc5 nucleo-0.5-3.fc5 openalpp-20060405-3.fc5 perl-CPANPLUS-0.061-3.fc5 perl-Graphics-ColorNames-1.06-2.fc5 perl-Math-Pari-2.010706-1.fc5 poker-engine-1.0.15-2.fc5 python-dns-1.3.5-1.fc5 python-durus-3.4.1-1.fc5 python-lxml-1.0-1.fc5 python-paramiko-1.6-1.fc5 python-vorbis-1.3-2.fc5 python-xmpp-0.3.1-1.fc5 rrdtool-1.0.49-6.fc5 rss-glx-0.8.1.p-2.fc5 scim-bridge-0.1.12-1.fc5 scim-fcitx-3.1.1-4.1.fc5 scim-input-pad-0.1.1-4.fc5.1 showimg-0.9.5-7.fc5 snort-2.4.4-4.fc5 svn2cl-0.7-1.fc5 tcltls-1.5.0-10.fc5 tile-0.7.2-4.fc5 xgalaxy-2.0.34-4.fc5 Packages built and released for Fedora Extras 4: 22 AGReader-1.1-9.fc4 DevIL-1.6.8-0.7.rc1.fc4 dbus-qt-0.33-6.fc4 gtkwave-3.0.4-1.fc4 kasumi-2.0-1.fc4 libchmxx-0.1-2.fc4 nucleo-0.5-3.fc4 openalpp-20060405-3.fc4 perl-CPANPLUS-0.061-3.fc4 perl-Graphics-ColorNames-1.06-2.fc4 perl-Math-Pari-2.010706-1.fc4 poker-engine-1.0.15-2.fc4 python-dns-1.3.5-1.fc4 python-durus-3.4.1-1.fc4 python-lxml-1.0-1.fc4 python-paramiko-1.6-1.fc4 python-xmpp-0.3.1-1.fc4 scim-bridge-0.1.12-1.fc4 showimg-0.9.5-7.fc4 snort-2.4.4-4.fc4 tcltls-1.5.0-10.fc4 tile-0.7.2-4.fc4 Packages built and released for Fedora Extras 3: 2 gtkwave-3.0.4-1.fc3 snort-2.4.4-4.fc3 Packages built and released for Fedora Extras development: 21 AGReader-1.1-9.fc6 DevIL-1.6.8-0.7.rc1.fc6 blam-1.8.2-5.fc6 clearsilver-0.10.3-4.fc6 fftw-3.1.1-1.fc6 gtkwave-3.0.4-1.fc6 lineakd-0.9-4.fc6 monodoc-1.1.13-9.fc6 nucleo-0.5-3.fc6 openalpp-20060405-3.fc6 perl-CPANPLUS-0.061-3.fc6 perl-Graphics-ColorNames-1.06-2.fc6 perl-Math-Pari-2.010706-1.fc6 python-durus-3.4.1-1.fc6 python-lxml-1.0-1.fc6 python-paramiko-1.6-1.fc6 rss-glx-0.8.1.p-2.fc6 snort-2.4.4-5.fc6 svn2cl-0.7-1.fc6 tile-0.7.2-4.fc6 xscreensaver-5.00-5.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Jun 2 18:50:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 18:50:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-02 Message-ID: <20060602185036.26677.65520@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Fri Jun 2 18:50:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 18:50:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-02 Message-ID: <20060602185036.26673.41398@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 ====================================================================== New report for: petersen AT redhat.com package: scim-bridge-gtkimm - 0.1.12-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: gtk2 > 0:2.8 package: scim-bridge-gtkimm - 0.1.12-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: gtk2 > 0:2.8 package: scim-bridge-gtkimm - 0.1.12-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: gtk2 > 0:2.8 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Fri Jun 2 18:50:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 18:50:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-02 Message-ID: <20060602185036.26680.58543@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gtktalog 1.0.4-7.fc5.i386 lineak-defaultplugin 0.8.4-5.fc6.i386 qtparted 0.4.5-5.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gtktalog 1.0.4-7.fc5.ppc lineak-defaultplugin 0.8.4-5.fc6.ppc qtparted 0.4.5-5.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gtktalog 1.0.4-7.fc5.x86_64 lineak-defaultplugin 0.8.4-5.fc6.x86_64 qtparted 0.4.5-5.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: lists AT forevermore.net package: lineak-defaultplugin - 0.8.4-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: lineakd = 0:0.8.4 package: lineak-defaultplugin - 0.8.4-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: lineakd = 0:0.8.4 package: lineak-defaultplugin - 0.8.4-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: lineakd = 0:0.8.4 ====================================================================== package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: qtparted - 0.4.5-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libparted-1.6.so.13 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: qtparted - 0.4.5-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libparted-1.6.so.13()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: qtparted - 0.4.5-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libparted-1.6.so.13 From buildsys at fedoraproject.org Fri Jun 2 18:50:36 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 18:50:36 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-02 Message-ID: <20060602185036.26663.22272@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From peter at thecodergeek.com Fri Jun 2 19:07:20 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 02 Jun 2006 12:07:20 -0700 Subject: Help - any got some spare ftp space? In-Reply-To: <1149255077.7498.21.camel@mrwibble.mrwobble> References: <1149255077.7498.21.camel@mrwibble.mrwobble> Message-ID: <44808C68.5010501@thecodergeek.com> PFJ wrote: > Can anyone offer me some ftp space for the development packages? Other > than monodoc, none of the packages I maintain are that huge, though they > do mount up. I'd be happy to lend you a chunk of web/FTP space on my hosting. Email me off-list if you're further interested and I'll get you the details. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From orion at cora.nwra.com Fri Jun 2 21:01:17 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 02 Jun 2006 15:01:17 -0600 Subject: install-info question Message-ID: <4480A71D.2040009@cora.nwra.com> My recent release of plplot resulted in the following being output during the yum update: install-info: menu item `The PLplot Plotting Library' already exists, for file `(none)' The %post script is: /sbin/install-info %{_infodir}/plplotdoc.info %{_infodir}/dir || : Which is pretty much straight from http://fedoraproject.org/wiki/ScriptletSnippets?highlight=%28install-info%29 Here is the head of plplotdoc.info: This is info/plplotdoc.info, produced by makeinfo version 4.8 from plplotdoc.texi. START-INFO-DIR-ENTRY * The PLplot Plotting Library: . ??? END-INFO-DIR-ENTRY So, what's wrong here? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From seg at haxxed.com Fri Jun 2 21:21:26 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 02 Jun 2006 16:21:26 -0500 Subject: Summary from last weeks FESCo meeting In-Reply-To: <1149101392.2313.25.camel@localhost.localdomain> References: <1149096999.2313.11.camel@localhost.localdomain> <20060531203113.c97223a4.bugs.michael@gmx.net> <1149101392.2313.25.camel@localhost.localdomain> Message-ID: <1149283286.1780.8.camel@localhost> On Wed, 2006-05-31 at 20:49 +0200, Thorsten Leemhuis wrote: > Ohh, sorry, yes, that was a bit misleading. The problem simply is: who > checks that the md5 sums stored in CVS are fine / those from upstream? > Nobody. I can upload a new version of package "foo" at any time and > include a rootkit in the tarball I upload. No one would notice. Any new entries to the lookaside cache should be logged to the commits list. (Are they already?) Any direct uploads not being grabbed directly from upstream should be watched particularly closely. This is a social problem. Looking for a technical solution to a social problem is barking up the wrong tree. The solution is to ensure reliable accounting is available for the community to monitor. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri Jun 2 22:19:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Jun 2006 00:19:03 +0200 Subject: Test push coming -- Re: Fedora Extras Package Build Report 2006-06-02 In-Reply-To: <20060602184009.526A615216B@buildsys.fedoraproject.org> References: <20060602184009.526A615216B@buildsys.fedoraproject.org> Message-ID: <20060603001903.5d6a1289.bugs.michael@gmx.net> On Fri, 2 Jun 2006 14:40:09 -0400 (EDT), buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 5: 29 I'm going to push a few more builds as a final test for changes applied to the push script. Sorry if that will trigger another set of repoclosure reports. ;) From buildsys at fedoraproject.org Fri Jun 2 23:04:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 2 Jun 2006 19:04:26 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-02 Message-ID: <20060602230426.AE7C815216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 4 ctorrent-1.3.2-3.fc5 environment-modules-3.2.3-1.fc5 itcl-3.3-0.6.RC1.fc5 rrdtool-1.0.50-1.fc5 Packages built and released for Fedora Extras 4: 3 ctorrent-1.3.2-3.fc4 environment-modules-3.2.3-1.fc4 itcl-3.3-0.5.RC1.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 5 environment-modules-3.2.3-1.fc6 itcl-3.3-0.6.RC1.fc6 mail-notification-3.0-0.1.rc2.fc6 poker-engine-1.0.15-2.fc6 qtparted-0.4.5-8.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Jun 2 23:14:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 23:14:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-02 Message-ID: <20060602231423.1044.42149@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw From buildsys at fedoraproject.org Fri Jun 2 23:14:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 23:14:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-02 Message-ID: <20060602231423.1058.90193@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gnome-yum 0.1.3-1.i386 gtktalog 1.0.4-7.fc5.i386 lineak-defaultplugin 0.8.4-5.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gnome-yum 0.1.3-1.ppc gtktalog 1.0.4-7.fc5.ppc lineak-defaultplugin 0.8.4-5.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gnome-yum 0.1.3-1.x86_64 gtktalog 1.0.4-7.fc5.x86_64 lineak-defaultplugin 0.8.4-5.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: lineak-defaultplugin - 0.8.4-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: lineakd = 0:0.8.4 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gnome-yum - 0.1.3-1.i386 from fedora-extras-development-i386 unresolved deps: libvte.so.4 package: lineak-defaultplugin - 0.8.4-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: lineakd = 0:0.8.4 package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gnome-yum - 0.1.3-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvte.so.4()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gnome-yum - 0.1.3-1.ppc from fedora-extras-development-ppc unresolved deps: libvte.so.4 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: lineak-defaultplugin - 0.8.4-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: lineakd = 0:0.8.4 From buildsys at fedoraproject.org Fri Jun 2 23:14:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 23:14:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-02 Message-ID: <20060602231423.1053.62388@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.i386 sylpheed-claws 2.0.0-3.fc4.i386 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.ppc sylpheed-claws 2.0.0-3.fc4.ppc Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch scim-bridge-gtkimm 0.1.12-1.fc4.x86_64 sylpheed-claws 2.0.0-3.fc4.x86_64 ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: sylpheed-claws - 2.0.0-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libpisock.so.9 package: scim-bridge-gtkimm - 0.1.12-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: gtk2 > 0:2.8 package: sylpheed-claws - 2.0.0-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libpisock.so.9()(64bit) package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: scim-bridge-gtkimm - 0.1.12-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: gtk2 > 0:2.8 package: sylpheed-claws - 2.0.0-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libpisock.so.9 package: scim-bridge-gtkimm - 0.1.12-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: gtk2 > 0:2.8 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Fri Jun 2 23:14:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 02 Jun 2006 23:14:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-02 Message-ID: <20060602231423.1056.67722@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From chris.stone at gmail.com Sat Jun 3 02:48:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 2 Jun 2006 19:48:45 -0700 Subject: Mock Problems with OpenSceneGraph Package Message-ID: I am trying to make a spec file which uses OpenSceneGraph, but some really strange things are happening. When the Producer package is installed under mock, it appears that ldconfig is not called which creates a mock build error for my package. I have examined the OpenSceneGraph spec file here: http://cvs.fedora.redhat.com/viewcvs/devel/OpenSceneGraph/OpenSceneGraph.spec?root=extras&rev=1.11&view=markup I notice that in one place they use "%name" instead of "%{name}" but I don't know if that causes any harm because the dependency seems to work regardless. In addition in the Producer section, they call ldconfig in the %install section, is this bad, and could this be causing the problems? The package I am building which is failing under mock is located here: SPEC: http://tkmame.retrogames.com/fedora-extras/osgal.spec SRPM: http://tkmame.retrogames.com/fedora-extras/osgal-20060410-2.src.rpm Please any help on this issue would be appreciated. Thanks in advance, -Chris From rdieter at math.unl.edu Sat Jun 3 02:07:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 02 Jun 2006 22:07:41 -0400 Subject: Mock Problems with OpenSceneGraph Package In-Reply-To: References: Message-ID: Christopher Stone wrote: > I am trying to make a spec file which uses OpenSceneGraph, but some > really strange things are happening. When the Producer package is > installed under mock, it appears that ldconfig is not called which > creates a mock build error for my package. What makes you think that? What was the error? AFAICT, the OpenSceneGraph spec looks ok to me. -- Rex From wart at kobold.org Sat Jun 3 03:10:10 2006 From: wart at kobold.org (Wart) Date: Fri, 02 Jun 2006 20:10:10 -0700 Subject: Mock Problems with OpenSceneGraph Package In-Reply-To: References: Message-ID: <4480FD92.5080703@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rex Dieter wrote: > Christopher Stone wrote: > >> I am trying to make a spec file which uses OpenSceneGraph, but some >> really strange things are happening. When the Producer package is >> installed under mock, it appears that ldconfig is not called which >> creates a mock build error for my package. > > > What makes you think that? What was the error? > > AFAICT, the OpenSceneGraph spec looks ok to me. The error is that the build of this dependent package complains about missing libProducer.so.0, which is in fact missing during a mock build even though the package requires Producer, which provides libProducer.so.0. However, if you chroot to your mock environment and run 'ldconfig', the libProducer.so.0 is created. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEgP2RDeYlPfs40g8RAmLcAJ97iLuFY+vymp4/UdJX9M0XB/yphgCdEaFm afn/NXrW78WYg7hh7ijl+9k= =m7WR -----END PGP SIGNATURE----- From chris.stone at gmail.com Sat Jun 3 03:11:41 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 2 Jun 2006 20:11:41 -0700 Subject: Mock Problems with OpenSceneGraph Package In-Reply-To: References: Message-ID: On 6/2/06, Rex Dieter wrote: > Christopher Stone wrote: > > I am trying to make a spec file which uses OpenSceneGraph, but some > > really strange things are happening. When the Producer package is > > installed under mock, it appears that ldconfig is not called which > > creates a mock build error for my package. > > What makes you think that? What was the error? > > AFAICT, the OpenSceneGraph spec looks ok to me. This may be a mock error. If you try building my srpm file (under mock) you will notice in the build log that it fails to find libProducer. Simply running ldconfig in the chroot environment fixes this error. Michael Thomas helped me diagnose the problem on IRC: 19:31:07 _wart_ | XulChris: Interesting. It seems like ldconfig is not called after Producer is installed, even though the spec file has %post -n Producer -p /sbin/ldconfig 19:31:23 _wart_ | If you chroot into your mock root and run ldconfig -v, you'll see that it fixes the problem. From rc040203 at freenet.de Sat Jun 3 02:44:44 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 03 Jun 2006 04:44:44 +0200 Subject: install-info question In-Reply-To: <4480A71D.2040009@cora.nwra.com> References: <4480A71D.2040009@cora.nwra.com> Message-ID: <1149302685.27733.419.camel@mccallum.corsepiu.local> On Fri, 2006-06-02 at 15:01 -0600, Orion Poplawski wrote: > This is info/plplotdoc.info, produced by makeinfo version 4.8 from > plplotdoc.texi. > > START-INFO-DIR-ENTRY > * The PLplot Plotting Library: . ??? > END-INFO-DIR-ENTRY > > > > So, what's wrong here? I am not a texinfo specialist, but the INFO-DIR-ENTRY section above seems broken to me. It should be something of this kind: START-INFO-DIR-ENTRY * The PLplot Plotting Library: (plplotdoc). ??? END-INFO-DIR-ENTRY Note the ": (XXX)." [1] The origin is the corresponding @direntry section in plplotdoc.texi. As this seems to be a generated file, I have no idea how to fix this. Also, c.f. info texinfo 'Installing Dir Entries' Ralf [1] I had been hit by a similar bug in a package, I maintain. Without having investigated in depth, it seems to me, as if the XXX in ": (XXX)." is required by newer install-info. From Matt_Domsch at dell.com Sat Jun 3 04:15:28 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 2 Jun 2006 23:15:28 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-02 Message-ID: <20060603041528.GE20566@lists.us.dell.com> compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Fri Jun 2 23:00:55 CDT 2006 Number failed to build: 152 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 151 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 150 ---------------------------------- Gtk-Perl GtkAda Hermes MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_ttf Terminal WindowMaker alacarte amaya balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool ncmpc nco paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl python-TestGears python-cheetah python-goopy qemu qtparted quarry rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly ser serpentine sloccount stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool tetex-eurofont tuxpaint ushare verbiste wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp With bugs filed: 3 ---------------------------------- clearsilver ['193795 CLOSED'] gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Sat Jun 3 04:16:13 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 2 Jun 2006 23:16:13 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-02 Message-ID: <20060603041613.GF20566@lists.us.dell.com> Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Fri Jun 2 22:59:08 CDT 2006 Number failed to build: 178 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 167 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 166 ---------------------------------- Gtk-Perl GtkAda Macaulay2 MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_ttf Terminal WindowMaker alacarte amaya apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco new pam_mount paps perl-HTML-Mason perl-Image-Info perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl python-TestGears python-cheetah python-dateutil python-goopy python-reportlab qemu qtparted quarry rpmDirectoryCheck sabayon scmxx scponly ser serpentine sloccount stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool tetex-eurofont tuxpaint uqm ushare verbiste wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp z88dk With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From rc040203 at freenet.de Sat Jun 3 04:46:21 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 03 Jun 2006 06:46:21 +0200 Subject: Mock Problems with OpenSceneGraph Package In-Reply-To: References: Message-ID: <1149309982.27733.428.camel@mccallum.corsepiu.local> On Fri, 2006-06-02 at 19:48 -0700, Christopher Stone wrote: > I am trying to make a spec file which uses OpenSceneGraph, but some > really strange things are happening. When the Producer package is > installed under mock, it appears that ldconfig is not called which > creates a mock build error for my package. > > I have examined the OpenSceneGraph spec file here: > http://cvs.fedora.redhat.com/viewcvs/devel/OpenSceneGraph/OpenSceneGraph.spec?root=extras&rev=1.11&view=markup > > I notice that in one place they use "%name" instead of "%{name}" but I > don't know if that causes any harm because the dependency seems to > work regardless. Nope, this doesn't apply. %{name} is the escaped form of %name. Both are supposed to be equivalent. > In addition in the Producer section, they call ldconfig in the > %install section, is this bad, In a perfect world: No. > and could this be causing the problems? No, it isn't the cause, but ... the links appear reversed, which causes *.so to be the actual library, and *.so.1 to be links to *.so. => Something is broken in this package's libraries' SONAMES handling. ... to be investigated ... Ralf From mpeters at mac.com Sat Jun 3 09:08:17 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 02:08:17 -0700 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <20060228.123250.647505333.kevin@scrye.com> References: <20060228.123250.647505333.kevin@scrye.com> Message-ID: <1149325698.2615.37.camel@atlantis.mpeters.local> On Tue, 2006-02-28 at 12:32 -0700, Kevin Fenzi wrote: > Come one, Come all... it's the 2nd Fedora Extras Review day. > > More information at: > > http://fedoraproject.org/wiki/Extras/ReviewDay > > The last review day was pretty slow and poorly attended, so this might > be the last one if there isn't more interest. > > What better way to spend a sunday afternoon that reviewing some > packages? Come join us on #fedora-extras on irc.freenode.net. Having the irc howto links on the bottom of the page was a good idea. :) This may seem odd, but I haven't used Mac OS 8.1 was my primary OS. I'll try to be there on Sunday. From mpeters at mac.com Sat Jun 3 09:13:04 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 02:13:04 -0700 Subject: 2nd Fedora Extras Review Day - 2006-03-05 (sunday) In-Reply-To: <1149325698.2615.37.camel@atlantis.mpeters.local> References: <20060228.123250.647505333.kevin@scrye.com> <1149325698.2615.37.camel@atlantis.mpeters.local> Message-ID: <1149325985.2615.40.camel@atlantis.mpeters.local> On Sat, 2006-06-03 at 02:08 -0700, Michael A. Peters wrote: > I'll try to be there on Sunday. > Ah geez - I'll also try not to reply to messages that are months old. I'll still try to be there on Sunday if anyone wants something reviewed :) From gemi at bluewin.ch Sat Jun 3 09:14:37 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 03 Jun 2006 11:14:37 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-02 In-Reply-To: <20060603041528.GE20566@lists.us.dell.com> References: <20060603041528.GE20566@lists.us.dell.com> Message-ID: <1149326078.8462.1.camel@scriabin.tannenrauch.ch> On Fri, 2006-06-02 at 23:15 -0500, Matt Domsch wrote: > graveman checking for intltool >= 0.22... 0.33 found checking for perl... /usr/bin/perl checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool error: Bad exit status from /var/tmp/rpm-tmp.12973 (%build) I would say, that intltool must have "Requires: perl-XML-Parser" -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From ville.skytta at iki.fi Sat Jun 3 09:20:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 03 Jun 2006 12:20:53 +0300 Subject: Extras i386 rawhide rebuild in mock status 2006-06-02 In-Reply-To: <1149326078.8462.1.camel@scriabin.tannenrauch.ch> References: <20060603041528.GE20566@lists.us.dell.com> <1149326078.8462.1.camel@scriabin.tannenrauch.ch> Message-ID: <1149326453.2853.4.camel@localhost.localdomain> On Sat, 2006-06-03 at 11:14 +0200, G?rard Milmeister wrote: > checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool > error: Bad exit status from /var/tmp/rpm-tmp.12973 (%build) > > I would say, that intltool must have "Requires: perl-XML-Parser" $ rpm -qR intltool | grep XML perl-XML-Parser From lists at forevermore.net Sat Jun 3 09:31:08 2006 From: lists at forevermore.net (Chris Petersen) Date: Sat, 03 Jun 2006 02:31:08 -0700 Subject: new and updated plugins: lineak (claiming ownership of finally-complete package set) Message-ID: <448156DC.5090404@forevermore.net> lineakd and lineak-defaultplugin have both been updated to version .9 I have also just added lineak-xosdplugin: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191607 and lineak-kdeplugins: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191606 -Chris From mpeters at mac.com Sat Jun 3 10:12:24 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 03:12:24 -0700 Subject: segmentation fault on buildsystem Message-ID: <1149329545.2615.56.camel@atlantis.mpeters.local> While attempting to fix bug #193476 (missing BuildRequires) - build failed with a segmentation fault: http://buildsys.fedoraproject.org/logs/fedora-development-extras/10383-gtkhtml36-3.6.2-5.fc6/i386/build.log ranlib .libs/libgtkhtml-a11y.a /usr/bin/libtool: line 5906: 7510 Segmentation fault ranlib .libs/libgtkhtml-a11y.a make[2]: *** [libgtkhtml-a11y.la] Error 139 make[2]: Leaving directory `/builddir/build/BUILD/gtkhtml-3.6.2/a11y' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/gtkhtml-3.6.2' make: *** [all] Error 2 -=- Is that a Build System issue? From rdieter at math.unl.edu Sat Jun 3 09:25:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 03 Jun 2006 05:25:47 -0400 Subject: segmentation fault on buildsystem In-Reply-To: <1149329545.2615.56.camel@atlantis.mpeters.local> References: <1149329545.2615.56.camel@atlantis.mpeters.local> Message-ID: Michael A. Peters wrote: > While attempting to fix bug #193476 (missing BuildRequires) - build > failed with a segmentation fault: > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/10383-gtkhtml36-3.6.2-5.fc6/i386/build.log > > ranlib .libs/libgtkhtml-a11y.a > /usr/bin/libtool: line 5906: 7510 Segmentation fault ranlib .libs/libgtkhtml-a11y.a > make[2]: *** [libgtkhtml-a11y.la] Error 139 > make[2]: Leaving directory `/builddir/build/BUILD/gtkhtml-3.6.2/a11y' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/gtkhtml-3.6.2' > make: *** [all] Error 2 > > -=- > > Is that a Build System issue? Probably. Try requeue'ing the job, to see if the error is repeatable. -- Rex From mpeters at mac.com Sat Jun 3 10:46:18 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 03:46:18 -0700 Subject: segmentation fault on buildsystem In-Reply-To: References: <1149329545.2615.56.camel@atlantis.mpeters.local> Message-ID: <1149331579.17122.1.camel@atlantis.mpeters.local> On Sat, 2006-06-03 at 05:25 -0400, Rex Dieter wrote: > > Probably. Try requeue'ing the job, to see if the error is repeatable. > > -- Rex > It succeeded on x86_64 - failed again on i386 w/ same failure. I'll wait a week and try again. From bugs.michael at gmx.net Sat Jun 3 12:02:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Jun 2006 14:02:33 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-02 In-Reply-To: <1149326078.8462.1.camel@scriabin.tannenrauch.ch> References: <20060603041528.GE20566@lists.us.dell.com> <1149326078.8462.1.camel@scriabin.tannenrauch.ch> Message-ID: <20060603140233.dc53e90d.bugs.michael@gmx.net> On Sat, 03 Jun 2006 11:14:37 +0200, G?rard Milmeister wrote: > On Fri, 2006-06-02 at 23:15 -0500, Matt Domsch wrote: > > graveman > checking for intltool >= 0.22... 0.33 found > checking for perl... /usr/bin/perl > checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool > error: Bad exit status from /var/tmp/rpm-tmp.12973 (%build) > > I would say, that intltool must have "Requires: perl-XML-Parser" It does already. $ rpm -qR intltool | grep Par perl-XML-Parser Verify whether you really have BR intltool and not just an included copy of intltool. From gemi at bluewin.ch Sat Jun 3 12:10:42 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 03 Jun 2006 14:10:42 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-02 In-Reply-To: <20060603140233.dc53e90d.bugs.michael@gmx.net> References: <20060603041528.GE20566@lists.us.dell.com> <1149326078.8462.1.camel@scriabin.tannenrauch.ch> <20060603140233.dc53e90d.bugs.michael@gmx.net> Message-ID: <1149336643.13869.0.camel@scriabin.tannenrauch.ch> On Sat, 2006-06-03 at 14:02 +0200, Michael Schwendt wrote: > On Sat, 03 Jun 2006 11:14:37 +0200, G?rard Milmeister wrote: > > > On Fri, 2006-06-02 at 23:15 -0500, Matt Domsch wrote: > > > graveman > > checking for intltool >= 0.22... 0.33 found > > checking for perl... /usr/bin/perl > > checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool > > error: Bad exit status from /var/tmp/rpm-tmp.12973 (%build) > > > > I would say, that intltool must have "Requires: perl-XML-Parser" > > It does already. > > $ rpm -qR intltool | grep Par > perl-XML-Parser > > Verify whether you really have BR intltool and not just an included > copy of intltool. You were right, so I added BuildReq intltool. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From cw-lists at arcor.de Sat Jun 3 13:29:38 2006 From: cw-lists at arcor.de (Christoph Wickert) Date: Sat, 03 Jun 2006 15:29:38 +0200 Subject: require foo or bar? Message-ID: <1149341378.2956.30.camel@hal9000.local.lan> Hi there, what if a package requires ether foo or bar to work? I'd like to package computertemp ( http://computertemp.berlios.de/ ), a gnome panel applet that shows - the the temperature of the computer through lm_sensors and/or - the disk's temperature with hddtemp. So my question is: Should I require lm_sensors or hddtemp or both? The package can be build and used with only lm_sensors or hddtemp, nevertheless it's whole functionality can only be used with both of them. On the other hand: What about ppc users? There's no lm_sensors for ppc, so these people are not able to use the package if I make it depend on lm_sensors. Another question: This is a noarch python package. > BuildArch: noarch > ExcludeArch: ppc looks a bit silly to me. **Confused** Chris P.S.: The files are @ http://home.arcor.de/christoph.wickert/fedora/extras/review/ From mpeters at mac.com Sat Jun 3 13:43:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 06:43:45 -0700 Subject: require foo or bar? In-Reply-To: <1149341378.2956.30.camel@hal9000.local.lan> References: <1149341378.2956.30.camel@hal9000.local.lan> Message-ID: <1149342225.17122.14.camel@atlantis.mpeters.local> On Sat, 2006-06-03 at 15:29 +0200, Christoph Wickert wrote: > > On the other hand: What about ppc users? There's no lm_sensors for ppc, > so these people are not able to use the package if I make it depend on > lm_sensors. > > Another question: This is a noarch python package. > > BuildArch: noarch > > ExcludeArch: ppc > looks a bit silly to me. Don't require lm_sensors Users who need that functionality will have to know to install it - but there's no clean way to do it otherwise. Not that I am aware of. From andy at smile.org.ua Sat Jun 3 14:13:42 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 03 Jun 2006 17:13:42 +0300 Subject: segmentation fault on buildsystem In-Reply-To: <1149331579.17122.1.camel@atlantis.mpeters.local> References: <1149329545.2615.56.camel@atlantis.mpeters.local> <1149331579.17122.1.camel@atlantis.mpeters.local> Message-ID: <44819916.7070103@smile.org.ua> Michael A. Peters ?????: >>Probably. Try requeue'ing the job, to see if the error is repeatable. > It succeeded on x86_64 - failed again on i386 w/ same failure. > I'll wait a week and try again. I've similar bug when building jack-audio-connection-kit. But in my case -O3 and something like that was issue (in other words incorrect CFLAGS variable setting). -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From ville.skytta at iki.fi Sat Jun 3 14:15:00 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 03 Jun 2006 17:15:00 +0300 Subject: require foo or bar? In-Reply-To: <1149342225.17122.14.camel@atlantis.mpeters.local> References: <1149341378.2956.30.camel@hal9000.local.lan> <1149342225.17122.14.camel@atlantis.mpeters.local> Message-ID: <1149344100.2853.15.camel@localhost.localdomain> On Sat, 2006-06-03 at 06:43 -0700, Michael A. Peters wrote: > On Sat, 2006-06-03 at 15:29 +0200, Christoph Wickert wrote: > > > > On the other hand: What about ppc users? There's no lm_sensors for ppc, > > so these people are not able to use the package if I make it depend on > > lm_sensors. > > > > Another question: This is a noarch python package. > > > BuildArch: noarch > > > ExcludeArch: ppc > > looks a bit silly to me. > > Don't require lm_sensors > > Users who need that functionality will have to know to install it - but > there's no clean way to do it otherwise. Not that I am aware of. Depending on the target distro versions and how well depsolvers for those cope with it, Requires(hint) could be worth considering for both dependencies. From mpeters at mac.com Sat Jun 3 14:41:33 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 03 Jun 2006 07:41:33 -0700 Subject: require foo or bar? In-Reply-To: <1149344100.2853.15.camel@localhost.localdomain> References: <1149341378.2956.30.camel@hal9000.local.lan> <1149342225.17122.14.camel@atlantis.mpeters.local> <1149344100.2853.15.camel@localhost.localdomain> Message-ID: <1149345693.17122.26.camel@atlantis.mpeters.local> On Sat, 2006-06-03 at 17:15 +0300, Ville Skytt? wrote: > > Depending on the target distro versions and how well depsolvers for > those cope with it, Requires(hint) could be worth considering for both > dependencies. > Last time I tried, that wasn't yet in rawhide rpm. That was some time ago though. I'm not sure yum would do the correct thing either. What is the correct thing for yum to do? I'm guessing ignore it, unless the user configures it to not ignore it - but then it should still ignore if not available? Guess that's a yum list question. From bugzilla at redhat.com Sat Jun 3 15:41:02 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 3 Jun 2006 11:41:02 -0400 Subject: [Bug 171915] Review Request: texmaker - LaTeX editor In-Reply-To: Message-ID: <200606031541.k53Ff2U0024941@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: texmaker - LaTeX editor https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171915 fedora.wickert at arcor.de 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 paul at all-the-johnsons.co.uk Sat Jun 3 16:24:53 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 03 Jun 2006 17:24:53 +0100 Subject: Not come across this one - any advice? Message-ID: <1149351893.30373.22.camel@T7.Linux> Hi, I'm fixing a package (fuse-emulator - I've noticed a problem), but when I come to build it, I'm getting the following during the install step. I've not come across it before, so what does it mean? /var/tmp/fuse-emulator-0.7.0-8-root-paul/usr/share/applications/fedora-fuse.desktop: error: key "GenericName" is translated, but no untranslated version exists desktop-file-install created an invalid desktop file! TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sat Jun 3 17:04:18 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 3 Jun 2006 17:04:18 +0000 (UTC) Subject: Not come across this one - any advice? References: <1149351893.30373.22.camel@T7.Linux> Message-ID: Paul writes: > /var/tmp/.../applications/fedora-fuse.desktop: error: > key "GenericName" is translated, but no untranslated version exists > desktop-file-install created an invalid desktop file! Well, this means there is a GenericName(language) entry, e.g. GenericName(en_US), but no plain GenericName. Either you add a GenericName (if there's a GenericName(en_US), just rename that) or you remove the translated ones. Kevin Kofler From fedora at leemhuis.info Sat Jun 3 17:11:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 03 Jun 2006 19:11:43 +0200 Subject: Summary from this weeks FESCo Meeting Message-ID: <1149354703.2321.60.camel@localhost.localdomain> Full log at http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060601 == Summary == Present from FESCo: thl, skvidal, warren, f13, mschwendt, scop * kmod's (once again) * Jon Masters (jcm) is working on integrating and enhancing the Fedora kmod-scheme for RHEL; more details will probably follow soon on fedora-packaging-list (there was a post there on Friday after the meeting) * buildsys-build (reduced packageset in default mock buildroot) * spot's was not around, but we wanted to solve this * we agreed on the [http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Exceptions list] from the wiki and added "which" to it; with all deps rpms pulls in the minimal buildroot for FE5/devel will contain the packages in [http://fedoraproject.org/wiki/Extras/FullExceptionList this list] (and buildsys-macros). * this list will be used for all targets (e.g. also for FE[345])! That might break some packages on the next rebuild in stable releases! Be careful! * skvidal will prepare a new mock with a default buildroot that contains only the packages from http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions , buildsys-macros (and rpm will pull all the deps in) * Encourage Extras reviews * tibbs> | No comments received yet on my proposals. I'm happy to just start working and let folks kick me if I'm going in the wrong direction. * warren> | tibbs, that might just be a good idea. * MIA/AWOL maintainers (mschwendt, jwb and Michael J Knox) * mschwendt> | thl: topic on extras-list has come to a sudden halt -- but we've discovered another AWOL * mschwendt> | would it be a start to track these maintainers in a list e.g. in CVS owners/mia.list? * we'll try that for now and change it later if we need something better * Some discussions if we can require that maintainers answer some sort of periodic ping; some liked the idea, other not, other liked the scheme where all maintainers had to rebuild their packages for FE5 (and thus show up), others simply want to ping those that were inactive for X (X=24 ?) weeks * thl> | does anyone want to work out a solution? * mschwendt> | I think we create a Wiki page which gives guidelines on how to take over packages and at the same time we add some information about AWOL/MIA maintainers * Co-maintainership * People seem to have different exception on this topic. The easy "Packager A) I would like to have Packager B help me. Packager B) Ok." is possible already. But others want more from it; see [https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00040.html this mail] for some of the other, more complicated ideas. * thl> | let's continue this on the list * CVS * thl> | I know I'm paranoid ;-) * tibbs> | We already have an ACL system for CVS; it seems relatively simple to just use it. * tibbs> | s/relatively simple/simpler than solving the halting problem/ ? * thl> | tibbs, yeah, especially if the scripts that manage the ACL could easily be adjusted to the new system later * thl> | and the CTRL+C problem is still unfixed (that's really annoying me) * thl> | warren, from last weeks meeting: "thomasvs> | it's easily doable - add an ampersand to the trigger, if it runs in the background it can't be interrupted"; warren, somebody would have to try that * warren> | Okay, I'll look into that. * mschwendt> | in the package build report it would be interesting to see who requested a build * a request for a system that sends a mail to package owners if one of their packages was changed/build is on the FESCo-Schedule/Todo-List for a long time already, but nobody started to work on it yet. Any volunteers? BTW, sponsors should also get direct mails for all changes from people they sponsored. * warren> | We must keep things as open as possible to keep down overhead, and add in safety automation elsewhere. * warren> | Seems like package database would be a big step toward many of these goals. Would anyone like to work with me in designing the package database? * warren> | Maybe we should put together a list of goals and prioritize which to do first. * Please use [http://www.fedoraproject.org/wiki/Extras/Schedule/PackageDatabase this page] for the goals; one of the goals is to that this DB replaces owners.list -- Thorsten Leemhuis From tibbs at math.uh.edu Sat Jun 3 18:31:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 03 Jun 2006 13:31:47 -0500 Subject: rpmlint no-soname warning Message-ID: I'm looking at the ejabberd review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192958 rpmlint has several no-soname warnings like: W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so I can't figure out if these are problematic. They're internal to ejabberd so ldconfig will never see them, and of course the package works fine. The warning is not in error; objdump --private-headers does indeed not show a SONAME entry. So, is there consensus that this is a blocker, and if so, how would you go about fixing it? - J< From packages at amiga-hardware.com Sat Jun 3 19:16:46 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 03 Jun 2006 20:16:46 +0100 Subject: Not come across this one - any advice? In-Reply-To: <1149351893.30373.22.camel@T7.Linux> References: <1149351893.30373.22.camel@T7.Linux> Message-ID: <4481E01E.6090500@amiga-hardware.com> Paul wrote: > Hi, > > I'm fixing a package (fuse-emulator - I've noticed a problem), but when > I come to build it, I'm getting the following during the install step. > I've not come across it before, so what does it mean? > > /var/tmp/fuse-emulator-0.7.0-8-root-paul/usr/share/applications/fedora-fuse.desktop: error: key "GenericName" is translated, but no untranslated version exists > desktop-file-install created an invalid desktop file! You probably have a GenericName key with a locale tag, e.g. GenericName[de]= but are missing the default GenericName= key without the locale tag. The default I believe is American English. -- Ian Chapman. From sean.bruno at dsl-only.net Sat Jun 3 19:26:17 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sat, 03 Jun 2006 12:26:17 -0700 Subject: kmod template? Message-ID: <1149362777.13771.3.camel@home-desk> Hey all...I was looking for a good example RPM to use as a base to begin a kmod package for the UVC webcam driver. I looked over the wiki page for the kmod RPM's and I just wanted a bit of guidance before I start whacking on a spec file. Sean From packages at amiga-hardware.com Sat Jun 3 19:26:37 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 03 Jun 2006 20:26:37 +0100 Subject: rpmlint no-soname warning In-Reply-To: References: Message-ID: <4481E26D.1040208@amiga-hardware.com> Jason L Tibbitts III wrote: > rpmlint has several no-soname warnings like: > > W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so > So, is there consensus that this is a blocker, and if so, how would > you go about fixing it? If it was simply in a standard lib location such as /usr/lib or /usr/lib64 then it probably is a blocker, otherwise I'm not sure but have a look at the following which should point you in the right direction for getting it fixed. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193884 This might be useful from the man page of ld. "-soname=name When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker." -- Ian Chapman. From packages at amiga-hardware.com Sat Jun 3 19:27:37 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 03 Jun 2006 20:27:37 +0100 Subject: rpmlint no-soname warning In-Reply-To: References: Message-ID: <4481E2A9.2060309@amiga-hardware.com> Jason L Tibbitts III wrote: > rpmlint has several no-soname warnings like: > > W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so > So, is there consensus that this is a blocker, and if so, how would > you go about fixing it? If it was simply in a standard lib location such as /usr/lib or /usr/lib64 then it probably is a blocker, otherwise I'm not sure but have a look at the following which should point you in the right direction for getting it fixed. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193884 This might be useful from the man page of ld. "-soname=name When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker." -- Ian Chapman. From michael at knox.net.nz Sat Jun 3 20:19:48 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 04 Jun 2006 08:19:48 +1200 Subject: Summary from this weeks FESCo Meeting In-Reply-To: <1149354703.2321.60.camel@localhost.localdomain> References: <1149354703.2321.60.camel@localhost.localdomain> Message-ID: <4481EEE4.1070304@knox.net.nz> Thorsten Leemhuis wrote: > * MIA/AWOL maintainers (mschwendt, jwb and Michael J Knox) > * mschwendt> | thl: topic on extras-list has come to a sudden halt -- > but we've discovered another AWOL > * mschwendt> | would it be a start to track these maintainers in a > list e.g. in CVS owners/mia.list? > * we'll try that for now and change it later if we need something > better > * Some discussions if we can require that maintainers answer some sort > of periodic ping; some liked the idea, other not, other liked the scheme > where all maintainers had to rebuild their packages for FE5 (and thus > show up), others simply want to ping those that were inactive for X > (X=24 ?) weeks > * thl> | does anyone want to work out a solution? > * mschwendt> | I think we create a Wiki page which gives guidelines on > how to take over packages and at the same time we add some information > about AWOL/MIA maintainers > I have been caught up with some Uni assignments and preparing for an exam. I should be able to pick this back up next week. Sorry. Michael From paul at all-the-johnsons.co.uk Sat Jun 3 21:38:05 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 03 Jun 2006 22:38:05 +0100 Subject: desktop-file-install problem Message-ID: <1149370685.30373.36.camel@T7.Linux> Hi, It looks like monodevelop is finally almost ready for acceptance, but I've hit a problem which can be gotten around, but I'm not happy with it. I have in the spec file the following desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ %{SOURCE1} where Source1 is monodevelop.desktop When it builds, both the fedora-monodevelop.desktop and monodevelop.desktop are installed into %{buildroot}%{_datadir}/applications which is wrong - only the fedora-monodevelop one should be there. If I add --delete-original after the vendor, the build breaks as it can no longer find monodevelop.desktop. To get around this, after the file install, I just have a line rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop and all is happy in the world. Have I found a problem with desktop-file-install or am I simply not doing things correctly? TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Sun Jun 4 02:12:56 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 03 Jun 2006 21:12:56 -0500 Subject: desktop-file-install problem In-Reply-To: <1149370685.30373.36.camel@T7.Linux> References: <1149370685.30373.36.camel@T7.Linux> Message-ID: Paul wrote: > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > --add-category X-Fedora \ > %{SOURCE1} > > where Source1 is monodevelop.desktop > > When it builds, both the fedora-monodevelop.desktop and > monodevelop.desktop are installed into > %{buildroot}%{_datadir}/applications which is wrong - only the > fedora-monodevelop one should be there. ... > To get around this, after the file install, I just have a line > > rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop > > and all is happy in the world. > > Have I found a problem with desktop-file-install or am I simply not > doing things correctly? I'd venture to guess the regular install process 'make install ...' is installing it's own .desktop file. -- Rex From j.w.r.degoede at hhs.nl Sun Jun 4 05:13:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 04 Jun 2006 07:13:17 +0200 Subject: remove rpmlint no-documentation warning on -devel subpackages? Message-ID: <44826BED.3000703@hhs.nl> Hi all, Yesterday I reproted the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193952 And Ville asked to discuss this publicy, so here we are. From the bug report: For almost each review I do where there is a -devel subpackage I get the following warning from rpmlint: W: xxx-devel no-documentation I would like rpmlint to not emit this warning for -devel subpackages (when coding this better make that an array of possible subpackages for which to not emit this, I'm sure once this is in people will think up other subpackages which usualy don't have docs). Comment #1 From Ville Skytt? (ville.skytta at iki.fi): I don't see that warning as spurious, but rather a reminder to check if there are some docs available that would be good to have included in the devel subpackage, just like all other packages. One warning per such a package isn't exactly an amount of noise that would make it harder to spot other problems, so I'm inclined to leave this as is. --- So what do you think? Regards, Hans From chris.stone at gmail.com Sun Jun 4 05:23:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 3 Jun 2006 22:23:18 -0700 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: <44826BED.3000703@hhs.nl> References: <44826BED.3000703@hhs.nl> Message-ID: On 6/3/06, Hans de Goede wrote: > One warning per such a package isn't exactly an amount of noise that > would make it harder to spot other problems, so I'm inclined to leave > this as is. +1 Packagers need to double check the source tarball for any documentation that should go in devel. Keep the rpmlint warning. The fact is rpmlint is going to give warnings all the time on stuff. You just need to know when to ignore them much like any C programmer would ignore warnings from lint. From paul at city-fan.org Sun Jun 4 08:52:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 04 Jun 2006 09:52:35 +0100 Subject: desktop-file-install problem In-Reply-To: <1149370685.30373.36.camel@T7.Linux> References: <1149370685.30373.36.camel@T7.Linux> Message-ID: <1149411156.766.10.camel@laurel.intra.city-fan.org> On Sat, 2006-06-03 at 22:38 +0100, Paul wrote: > Hi, > > It looks like monodevelop is finally almost ready for acceptance, but > I've hit a problem which can be gotten around, but I'm not happy with > it. > > I have in the spec file the following > > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > --add-category X-Fedora \ > %{SOURCE1} > > where Source1 is monodevelop.desktop > > When it builds, both the fedora-monodevelop.desktop and > monodevelop.desktop are installed into > %{buildroot}%{_datadir}/applications which is wrong - only the > fedora-monodevelop one should be there. > > If I add --delete-original after the vendor, the build breaks as it can > no longer find monodevelop.desktop. > > To get around this, after the file install, I just have a line > > rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop > > and all is happy in the world. > > Have I found a problem with desktop-file-install or am I simply not > doing things correctly? Why not just do the desktop-file-install *after* the "make install" or equivalent? Paul. From paul at all-the-johnsons.co.uk Sun Jun 4 08:53:11 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 04 Jun 2006 09:53:11 +0100 Subject: desktop-file-install problem In-Reply-To: <1149411156.766.10.camel@laurel.intra.city-fan.org> References: <1149370685.30373.36.camel@T7.Linux> <1149411156.766.10.camel@laurel.intra.city-fan.org> Message-ID: <1149411191.30373.55.camel@T7.Linux> > Hi, > > > Have I found a problem with desktop-file-install or am I simply not > > doing things correctly? > > Why not just do the desktop-file-install *after* the "make install" or > equivalent? It is %define _libdir %{_exec_prefix}/lib Summary: A full-featured IDE for Mono and Gtk sharp Name: monodevelop %install %{__rm} -rf %{buildroot} export MONO_SHARED_DIR=%{_builddir}/%{?buildsubdir} make DESTDIR=%{buildroot} install %find_lang %{name} desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ %{SOURCE1} rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sun Jun 4 10:36:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 4 Jun 2006 12:36:27 +0200 Subject: desktop-file-install problem In-Reply-To: <1149370685.30373.36.camel@T7.Linux> References: <1149370685.30373.36.camel@T7.Linux> Message-ID: <20060604123627.85a47239.bugs.michael@gmx.net> On Sat, 03 Jun 2006 22:38:05 +0100, Paul wrote: > Hi, > > It looks like monodevelop is finally almost ready for acceptance, but > I've hit a problem which can be gotten around, but I'm not happy with > it. > > I have in the spec file the following > > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > --add-category X-Fedora \ > %{SOURCE1} > > where Source1 is monodevelop.desktop > > When it builds, both the fedora-monodevelop.desktop and > monodevelop.desktop are installed into > %{buildroot}%{_datadir}/applications which is wrong - only the > fedora-monodevelop one should be there. > > If I add --delete-original after the vendor, the build breaks as it can > no longer find monodevelop.desktop. What breaks? The %files section? In that case, why does the %files section contain an entry for a monodevelop.desktop file? It only expects files you specified. If you only want to package %{_datadir}/applications/fedora-*.desktop don't include a %files entry for a different .desktop file. Also note that --delete-original on %{SOURCE1} is a DON'T. %{SOURCE1} is the input file (= the "original"), and you never want the spec to delete it. > To get around this, after the file install, I just have a line > > rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop This indicates that make install created this file. Examine its contents, then use: desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ --delete-original \ %{buildroot}%{_datadir}/applications/monodevelop.desktop instead. From Liste at FamilleCollet.com Sun Jun 4 10:00:10 2006 From: Liste at FamilleCollet.com (Remi Collet) Date: Sun, 04 Jun 2006 12:00:10 +0200 Subject: desktop-file-install problem In-Reply-To: <1149411191.30373.55.camel@T7.Linux> References: <1149370685.30373.36.camel@T7.Linux> <1149411156.766.10.camel@laurel.intra.city-fan.org> <1149411191.30373.55.camel@T7.Linux> Message-ID: <4482AF2A.6020909@FamilleCollet.com> Paul a ?crit : > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > --add-category X-Fedora \ > %{SOURCE1} > rm -f %{buildroot}%{_datadir}/applications/monodevelop.desktop > > Or use the "delete-original" option. desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ --delete-original \ %{buildroot}%{_datadir}/applications/monodevelop.desktop Remi. From fedora at leemhuis.info Sun Jun 4 12:29:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Jun 2006 14:29:22 +0200 Subject: kmod template? In-Reply-To: <1149362777.13771.3.camel@home-desk> References: <1149362777.13771.3.camel@home-desk> Message-ID: <1149424162.2318.41.camel@localhost.localdomain> Am Samstag, den 03.06.2006, 12:26 -0700 schrieb Sean Bruno: > Hey all...I was looking for a good example RPM to use as a base to begin > a kmod package for the UVC webcam driver. > > I looked over the wiki page for the kmod RPM's and I just wanted a bit > of guidance before I start whacking on a spec file. What do you need precisely? There are some examples (lirc, thinkpad) linked on the bottom of the page (and a well know 3rd-party repo has also some packages where you can take a look) and there is a template on the page itself. CU thl -- Thorsten Leemhuis From buildsys at fedoraproject.org Sun Jun 4 12:46:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 4 Jun 2006 08:46:46 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-04 Message-ID: <20060604124646.AC58E15216B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 17 PyX-0.9-1.fc5 R-2.3.1-1.fc5 cacti-0.8.6h-6.fc5 emelfm2-0.1.7-1.fc5 exiv2-0.10-1.fc5 fftw-3.1.1-1.fc5 gdome2-0.8.1-4.fc5 libtasn1-0.3.4-1.fc5 maxima-5.9.3-4.fc5 nucleo-0.5-5.fc5 openalpp-20060405-4.fc5 perl-GD-2.34-1.fc5 perl-SOAP-Lite-0.67-2.1.fc5 sbcl-0.9.13-2.fc5.1 sylpheed-2.2.5-2.fc5 tuxpaint-0.9.15b-1.fc5 xfce4-mount-plugin-0.3.3-4.fc5 Packages built and released for Fedora Extras 4: 12 PyX-0.9-1.fc4 R-2.3.1-1.fc4 emelfm2-0.1.7-1.fc4 exiv2-0.10-1.fc4 fftw-3.1.1-1.fc4 gdome2-0.8.1-4.fc4 libtasn1-0.3.4-1.fc4 maxima-5.9.3-4.fc4 nucleo-0.5-5.fc4 openalpp-20060405-4.fc4 sbcl-0.9.13-2.fc4 xfce4-mount-plugin-0.3.3-4.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 31 PyX-0.9-1.fc6 R-2.3.1-1.fc6 bsd-games-2.17-13.fc6 cacti-0.8.6h-6.fc6 cfs-1.4.1-9.fc6 emelfm2-0.1.7-1.fc6 exiv2-0.10-1.fc6 gnochm-0.9.8-1.fc6 gnome-ppp-0.3.23-2.fc6 htmldoc-1.8.26-4.fc6 kphotoalbum-2.2-3.fc6 lft-2.5-4.fc6 libtasn1-0.3.4-1.fc6 lineak-defaultplugin-0.9-1.fc6 lineak-kdeplugins-0.9-1.fc6 lineak-xosdplugin-0.9-1.fc6 nucleo-0.5-5.fc6 openalpp-20060405-4.fc6 pan-0.99-2.fc6 perl-GD-2.34-1.fc6 perl-SOAP-Lite-0.67-2.1.fc6 plib-1.8.4-4.fc6 renrot-0.20-2.fc6 supertux-0.1.3-4.fc6 sword-1.5.8-8.fc6 sylpheed-2.2.5-2.fc6 tuxpaint-0.9.15b-1.fc6 ucblogo-5.5-3.fc6 xfce4-modemlights-plugin-0.1.1-8.fc6 xfce4-mount-plugin-0.3.3-4.fc6 xfce4-taskmanager-0.3.1-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From alcapcom at gmail.com Sun Jun 4 14:03:31 2006 From: alcapcom at gmail.com (alcapcom) Date: Sun, 4 Jun 2006 16:03:31 +0200 Subject: What's the best practice for packaging java apps on FC Message-ID: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> I wrote a utility to configure a 3D Desktop on fedora (Aiglx, Xgl, compiz, gdm and kdm for the moment). The sources are available at http://fedora-xgl.org, i will rename this site and the utility fedora-3ddesktop or some thing like that. This new app will replace old fedora-xgl-settings dirty scripts (192438), it contain a gui (java-gnome) + a command line tools. I hope to be able to release the first version next week. I am new here, so hello everyone. ps: If somebody has an idea concerning the name for the app or the web site, it's welcome ;) Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Sun Jun 4 14:12:47 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 4 Jun 2006 15:12:47 +0100 Subject: What's the best practice for packaging java apps on FC In-Reply-To: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> Message-ID: <645d17210606040712ob694c9era4d9261d0eb24c50@mail.gmail.com> On 04/06/06, alcapcom wrote: > I wrote a utility to configure a 3D Desktop on fedora (Aiglx, Xgl, compiz, > gdm and kdm for the moment). The sources are available at > http://fedora-xgl.org, Server not found... typo? > I am new here, so hello everyone. Hello. :) Jonathan. From alcapcom at gmail.com Sun Jun 4 14:18:02 2006 From: alcapcom at gmail.com (alcapcom) Date: Sun, 4 Jun 2006 16:18:02 +0200 Subject: What's the best practice for packaging java apps on FC In-Reply-To: <645d17210606040712ob694c9era4d9261d0eb24c50@mail.gmail.com> References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> <645d17210606040712ob694c9era4d9261d0eb24c50@mail.gmail.com> Message-ID: <4ccd9dcb0606040718w5f40670bs951375f69a6febb5@mail.gmail.com> Sorry for wrong link, that's the good: http://fedoraxgl.tuxfamily.org 2006/6/4, Jonathan Underwood : > > On 04/06/06, alcapcom wrote: > > I wrote a utility to configure a 3D Desktop on fedora (Aiglx, Xgl, > compiz, > > gdm and kdm for the moment). The sources are available at > > http://fedora-xgl.org, > > Server not found... typo? > > > I am new here, so hello everyone. > > Hello. :) > > Jonathan. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Sun Jun 4 15:53:21 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 04 Jun 2006 10:53:21 -0500 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: (Christopher Stone's message of "Sat, 3 Jun 2006 22:23:18 -0700") References: <44826BED.3000703@hhs.nl> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> The fact is rpmlint is going to give warnings all the time on CS> stuff. You just need to know when to ignore them much like any C CS> programmer would ignore warnings from lint. Unfortunately that makes it rather difficult on submitters and reviewers, since they then have to ask about each rpmlint issue. Part of my plan for encouraging reviews is to have a Wiki page that lists each rpmlint warning/error and how to deal with it. Obviously that's a bit of work; would you care to assist? - J< From packages at amiga-hardware.com Sun Jun 4 16:25:21 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 04 Jun 2006 17:25:21 +0100 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: References: <44826BED.3000703@hhs.nl> Message-ID: <44830971.4010302@amiga-hardware.com> Jason L Tibbitts III wrote: > Part of my plan for encouraging reviews is to have a Wiki page that > lists each rpmlint warning/error and how to deal with it. Obviously > that's a bit of work; would you care to assist? I've been thinking of doing something exactly like that for the last few days, I'd be interested in helping out. -- Ian Chapman. From chitlesh at fedoraproject.org Sun Jun 4 17:17:55 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 4 Jun 2006 19:17:55 +0200 Subject: rpath fails rpmbuild Message-ID: <13dbfe4f0606041017m2aef356bn89be0263ab4446af@mail.gmail.com> Hello, I am trying to push knetstats to FE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 but with rpmbuild -ba knetstats.spec, Im failing on to ERROR 0001: file '/usr/bin/knetstats' contains a standard rpath '/usr/lib' in [/usr/lib/qt-3.3/lib:/usr/lib/kde3:/usr/lib] error: Bad exit status from /var/tmp/rpm-tmp.38355 (%install) and I have to do QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba knetstats.spec so that It builds successfully. What I should do in order not to fall on this again ? Chitlesh -- http://clunixchit.blogspot.com From packages at amiga-hardware.com Sun Jun 4 18:17:01 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 04 Jun 2006 19:17:01 +0100 Subject: rpath fails rpmbuild In-Reply-To: <13dbfe4f0606041017m2aef356bn89be0263ab4446af@mail.gmail.com> References: <13dbfe4f0606041017m2aef356bn89be0263ab4446af@mail.gmail.com> Message-ID: <4483239D.5060904@amiga-hardware.com> Chitlesh GOORAH wrote: > Hello, > > I am trying to push knetstats to FE. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 > > but with rpmbuild -ba knetstats.spec, Im failing on to > > ERROR 0001: file '/usr/bin/knetstats' contains a standard rpath > '/usr/lib' in [/usr/lib/qt-3.3/lib:/usr/lib/kde3:/usr/lib] > error: Bad exit status from /var/tmp/rpm-tmp.38355 (%install) > > and I have to do QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba > knetstats.spec so that It builds successfully. Using QA_RPATHS just masks the problem, it doesn't fix it. You could probably patch the SConstruct file to disable rpath, in other words this line: env.KDEuse("environ rpath") might be better as env.KDEuse("environ") On first glance, I've noticed other problems with the spec, but see your BZ page for that. -- Ian Chapman. From ville.skytta at iki.fi Sun Jun 4 18:29:05 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jun 2006 21:29:05 +0300 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: <44830971.4010302@amiga-hardware.com> References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> Message-ID: <1149445745.2853.50.camel@localhost.localdomain> On Sun, 2006-06-04 at 17:25 +0100, Ian Chapman wrote: > Jason L Tibbitts III wrote: > > > Part of my plan for encouraging reviews is to have a Wiki page that > > lists each rpmlint warning/error and how to deal with it. Obviously > > that's a bit of work; would you care to assist? > > I've been thinking of doing something exactly like that for the last few > days, I'd be interested in helping out. Note that rpmlint itself contains some instructions and explanations for its findings, improvements to those are welcome. In fact IMHO it would be better to direct the effort at those first, then add a Wiki page if still needed. Too bad lots of people don't seem to be aware of rpmlint's -i and -I options (see the man page), ideas how to make them more prominent? From sean.bruno at dsl-only.net Sun Jun 4 18:50:25 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 04 Jun 2006 11:50:25 -0700 Subject: kmod template? In-Reply-To: <1149424162.2318.41.camel@localhost.localdomain> References: <1149362777.13771.3.camel@home-desk> <1149424162.2318.41.camel@localhost.localdomain> Message-ID: <1149447025.31873.0.camel@home-desk> On Sun, 2006-06-04 at 14:29 +0200, Thorsten Leemhuis wrote: > Am Samstag, den 03.06.2006, 12:26 -0700 schrieb Sean Bruno: > > Hey all...I was looking for a good example RPM to use as a base to begin > > a kmod package for the UVC webcam driver. > > > > I looked over the wiki page for the kmod RPM's and I just wanted a bit > > of guidance before I start whacking on a spec file. > > What do you need precisely? There are some examples (lirc, thinkpad) > linked on the bottom of the page (and a well know 3rd-party repo has > also some packages where you can take a look) and there is a template on > the page itself. > duh, never mind. I guess I could just go a look at some of the '3rd party repo' rpms...he he. Sean From tibbs at math.uh.edu Sun Jun 4 18:51:22 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 04 Jun 2006 13:51:22 -0500 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: <1149445745.2853.50.camel@localhost.localdomain> (Ville Skytt's message of "Sun, 04 Jun 2006 21:29:05 +0300") References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> <1149445745.2853.50.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> Note that rpmlint itself contains some instructions and VS> explanations for its findings, improvements to those are welcome. VS> In fact IMHO it would be better to direct the effort at those VS> first, then add a Wiki page if still needed. I don't think it's reasonable to include such a large amount of documentation within rpmlint; it is nearly impossible to edit since one has to go through a complete release cycle just to get additional things in. Plus, if I review a package and see something I haven't seen before, it's reasonable for me to drop by the wiki and add some info but it's kind of pointless to open up a bugzilla ticket and keep modifying it as I get new input via IRC or the list. Finally, do you really want to include the daily method for getting rid of the rpath warning directly in rpmlint? I think it would be much more reasonable to let the Wiki page stew and then digest the useful bits into rpmlint. That page will of course recommend the use of -i to extract additional information from rpmlint. - J< From tibbs at math.uh.edu Sun Jun 4 19:02:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 04 Jun 2006 14:02:36 -0500 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: <44830971.4010302@amiga-hardware.com> (Ian Chapman's message of "Sun, 04 Jun 2006 17:25:21 +0100") References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> Message-ID: >>>>> "IC" == Ian Chapman writes: IC> I've been thinking of doing something exactly like that for the IC> last few days, I'd be interested in helping out. I've created http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues and am adding a sample entry now. I'll try to go back through my previous reviews and see if I can find additional sticking points to add. Also, as to the original question, note that rpmlint does have an exception to the warning for libfoo-devel packages: if doc_files == [] and not (pkg.name[:3] == 'lib' and string.find(pkg.name, '-devel')): printWarning(pkg, 'no-documentation') - J< From ville.skytta at iki.fi Sun Jun 4 19:14:03 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jun 2006 22:14:03 +0300 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> <1149445745.2853.50.camel@localhost.localdomain> Message-ID: <1149448443.2853.71.camel@localhost.localdomain> On Sun, 2006-06-04 at 13:51 -0500, Jason L Tibbitts III wrote: > I don't think it's reasonable to include such a large amount of > documentation within rpmlint; [...] Finally, do you > really want to include the daily method for getting rid of the rpath > warning directly in rpmlint? No, but do you really want to try to document bits and pieces like this somewhere and keep it up to date for N distro versions, where the method how to do it properly most likely varies between packages? The fundamental problem with a page containing large amounts of such information I see is that will have to be *huge* to cover an useful amount of cases, and when it's that huge, it may very well be indigestible by the intended target audience, ie. those who actually need guidance in fixing something like a rpath problem. I claim that a Wiki page for this purpose is not a reasonable substitute for human assistance, and thus fear that it may end up as a big pile of confusion and a maintenance nightmare. A list of links to documents covering specific problem areas would be more useful and help people to actually learn about the issues instead of parroting recipes. But by all means, please prove me wrong ;) > I think it would be much more reasonable to let the Wiki page stew and > then digest the useful bits into rpmlint. Yep, that would be cool, although I don't quite agree with "more reasonable" at the moment. From packages at amiga-hardware.com Sun Jun 4 19:25:57 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 04 Jun 2006 20:25:57 +0100 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: <1149445745.2853.50.camel@localhost.localdomain> References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> <1149445745.2853.50.camel@localhost.localdomain> Message-ID: <448333C5.3000803@amiga-hardware.com> Ville Skytt? wrote: >>I've been thinking of doing something exactly like that for the last few >>days, I'd be interested in helping out. > > > Note that rpmlint itself contains some instructions and explanations for > its findings, improvements to those are welcome. In fact IMHO it would > be better to direct the effort at those first, then add a Wiki page if > still needed. > > Too bad lots of people don't seem to be aware of rpmlint's -i and -I > options (see the man page), ideas how to make them more prominent? > I'm largely in agreement with Jason. I think the more dynamic nature of a wiki would mean that people could edit the info and have access to it quicker without waiting for rpmlint releases. A wiki probably has the luxury of allowing explanations and resolutions to be more verbose. This doesn't mean of course that the information can't eventually make its way into rpmlint. I think the wiki would also expose what's consider common or good practice for fixing many issues. I'm not sure you could make the -i/-I options more prominent. Perhaps if rpmlint finds a problem and these options haven't been used, it could print a message saying something like "use -i / -I for more information" although that might be considered as being too noisy. -- Ian Chapman. From ville.skytta at iki.fi Sun Jun 4 19:28:27 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jun 2006 22:28:27 +0300 Subject: remove rpmlint no-documentation warning on -devel subpackages? In-Reply-To: References: <44826BED.3000703@hhs.nl> <44830971.4010302@amiga-hardware.com> Message-ID: <1149449307.2853.77.camel@localhost.localdomain> On Sun, 2006-06-04 at 14:02 -0500, Jason L Tibbitts III wrote: > Also, as to the original question, note that rpmlint does have an > exception to the warning for libfoo-devel packages: > > if doc_files == [] and not (pkg.name[:3] == 'lib' and string.find(pkg.name, '-devel')): > printWarning(pkg, 'no-documentation') Huh, thanks for pointing that out, I've just got rid of it: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1181 From skvidal at linux.duke.edu Sun Jun 4 20:32:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 04 Jun 2006 16:32:26 -0400 Subject: extras buildsys/plague downtime Message-ID: <1149453146.21779.12.camel@cutter> Hi folks, We've got to swap out a disk in the buildmaster (buildsys.fedoraproject.org) in order to increase available space. Therefore, we'll be taking plague down while they're swapped. This will happen Monday June 5th at 13:00 GMT-4. Ideally it will only take 20 minutes to do everything but give me until at least 14:00 before sending out the hatemail. :) thanks, -sv From chris.stone at gmail.com Sun Jun 4 21:40:32 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 4 Jun 2006 14:40:32 -0700 Subject: Need Help from a C expert Message-ID: I have a package I'm trying to compile and it gives an error when -Wp,-D_FORTIFY_SOURCE=2 is defined in the CFLAGS which is what happens when you try to compile with rpmbuild. The offending line is: vsnprintf(char *str, size_t n, char const *fmt, va_list ap) And the errors given are: main/vsnprintf.c:109: error: expected declaration specifiers or '...' before numeric constant main/vsnprintf.c:109: error: expected declaration specifiers or '...' before '__builtin_object_size These errors do not show up if -Wp,-D_FORTIFY_SOURCE=2 is not used. Can anyone here please help me? I have uploaded the complete source file here: http://tkmame.retrogames.com/fedora-extras/vsnprintf.c Any help on how to fix this would be greatly appreciated. Please let me know if you need any more information. Thanks in advance, -Chris From mpeters at mac.com Sun Jun 4 21:44:54 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 04 Jun 2006 14:44:54 -0700 Subject: rpmlint non executable script Message-ID: <1149457495.26070.7.camel@atlantis.mpeters.local> Files marked as documentation should not be executable. But if a file marked as documentation is a non executable shell script, rpmlint complains. I do not think this happens when a shell script is installed by the %doc macro - IE - source TLD has examples/foo.sh which is bundled via %doc examples/ but it DOES happen if/when the script is already in the filesystem - IE %doc /usr/share/texmf/doc/latex/bar/foo.rb where foo.rb is an example ruby script. A dependency on ruby (and dependency resulting from documentation file) would result if it were made executable, which is bad because documentation files should not add dependencies. But removing the shell bang IMHO is wrong, and is altering (even though slightly) the upstream documentation when it does not need to be altered. Should rpmlint suppress the warnings on non executable shell script that are specifically flagged as documentation? From chris.stone at gmail.com Sun Jun 4 22:24:21 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 4 Jun 2006 15:24:21 -0700 Subject: Need Help from a C expert In-Reply-To: References: Message-ID: On 6/4/06, Christopher Stone wrote: > I have a package I'm trying to compile and it gives an error when > -Wp,-D_FORTIFY_SOURCE=2 is defined in the CFLAGS which is what happens > when you try to compile with rpmbuild. Nevermind, I fixed this problem by simply removing the vsnprintf function from the source file. It seems vsnprintf is a builtin system function and there is no need to compile a new one. From jamatos at fc.up.pt Sun Jun 4 22:34:48 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sun, 4 Jun 2006 23:34:48 +0100 Subject: Build system problems for x86_64 in development Message-ID: <200606042334.49129.jamatos@fc.up.pt> All my requested build for x86_64 (and only in this arch) in development have failled: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-x86_64-core-3b41e5a8163cb20c44749cf4f5c5198c0c70dbb3/root groupinstall build file:///pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/core/development/x86_64/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. Cleaning up... -- Jos? Ab?lio From bugs.michael at gmx.net Sun Jun 4 22:45:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Jun 2006 00:45:25 +0200 Subject: Build system problems for x86_64 in development In-Reply-To: <200606042334.49129.jamatos@fc.up.pt> References: <200606042334.49129.jamatos@fc.up.pt> Message-ID: <20060605004525.daa642e6.bugs.michael@gmx.net> On Sun, 4 Jun 2006 23:34:48 +0100, Jose' Matos wrote: > All my requested build for x86_64 (and only in this arch) in development have > failled: > > Executing /usr/sbin/mock-helper > yum --installroot /var/lib/mock/fedora-development-x86_64-core-3b41e5a8163cb20c44749cf4f5c5198c0c70dbb3/root > groupinstall build > file:///pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml: > [Errno 5] OSError: [Errno 2] No such file or > directory: '/pub/fedora/linux/core/development/x86_64/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. > Cleaning up... see fedora-devel-list, the repodata directory is missing for x86_64 From dgregor at redhat.com Sun Jun 4 23:32:12 2006 From: dgregor at redhat.com (Dennis Gregorovic) Date: Sun, 04 Jun 2006 19:32:12 -0400 Subject: Build system problems for x86_64 in development In-Reply-To: <20060605004525.daa642e6.bugs.michael@gmx.net> References: <200606042334.49129.jamatos@fc.up.pt> <20060605004525.daa642e6.bugs.michael@gmx.net> Message-ID: <1149463933.10267.15.camel@localhost.localdomain> On Mon, 2006-06-05 at 00:45 +0200, Michael Schwendt wrote: > On Sun, 4 Jun 2006 23:34:48 +0100, Jose' Matos wrote: > > > All my requested build for x86_64 (and only in this arch) in development have > > failled: > > > > Executing /usr/sbin/mock-helper > > yum --installroot /var/lib/mock/fedora-development-x86_64-core-3b41e5a8163cb20c44749cf4f5c5198c0c70dbb3/root > > groupinstall build > > file:///pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml: > > [Errno 5] OSError: [Errno 2] No such file or > > directory: '/pub/fedora/linux/core/development/x86_64/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. > > Cleaning up... > > see fedora-devel-list, the repodata directory is missing for x86_64 I went ahead and pushed a repodata directory manually for x86_64. I apologize that it got removed in the first place. Let me know if you run into any issues with it. -- Dennis From jspaleta at gmail.com Mon Jun 5 01:33:03 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 4 Jun 2006 21:33:03 -0400 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <4471E231.1070409@thecodergeek.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> Message-ID: <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> On 5/22/06, Peter Gordon wrote: > Jeff Spaleta wrote: > > glabels in fedora extras is currently tracking the stable glabels > > branch, and its pretty straight forward. Just get on the low traffic > > upstream glabels mailinglist and watch for any "stable" release > > announcements or upstream bugs. > > I've been using gLabels a lot as of recent. If no one has any > outstanding complaints thereof, I'd be happy to take it off your hands > for a while. Okay, sorry I've been really busy in the best 2 weeks.... Sooooo if you want to take co-ownership all i think you need to do is update the owners list file in cvs to add your email next to glabels. -jef From andy at smile.org.ua Mon Jun 5 03:42:52 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 05 Jun 2006 06:42:52 +0300 Subject: Need Help from a C expert In-Reply-To: References: Message-ID: <4483A83C.2000106@smile.org.ua> Christopher Stone ?????: > Nevermind, I fixed this problem by simply removing the vsnprintf > function from the source file. It seems vsnprintf is a builtin system > function and there is no need to compile a new one. Due to security reasons the built in source function may be better than system one. I think the security audit of that code should be passed. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From Matt_Domsch at dell.com Mon Jun 5 04:48:20 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 4 Jun 2006 23:48:20 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-04 Message-ID: <20060605044820.GC6822@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. extras Rawhide-in-Mock Build Results for i386 Sun Jun 4 18:09:21 CDT 2006 Number failed to build: 146 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 145 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 142 ---------------------------------- alacarte amaya balsa banshee baobab bidiv bmp byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget Hermes ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife MagicPoint mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc OpenSceneGraph paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl python-cheetah python-goopy python-TestGears qemu quarry R-gnomeGUI rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly SDL_ttf ser serpentine sloccount stow stratagus swh-plugins synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-panel xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp With bugs filed: 3 ---------------------------------- gtkhtml36 ['193476 ASSIGNED'] xfce4-weather-plugin ['193973 ASSIGNED'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Jun 5 04:48:49 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 4 Jun 2006 23:48:49 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-04 Message-ID: <20060605044848.GD6822@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Sun Jun 4 18:07:51 CDT 2006 Number failed to build: 202 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 191 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 184 ---------------------------------- alacarte amaya apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz cacti camstream ccrtp cfs colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables emelfm2 epiphany-extensions epylog exim exiv2 exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnochm gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hercules htmldoc ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover kphotoalbum ladspa leafpad lft libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtasn1 libtomoe-gtk libtranslate libxfcegui4 licq lighttpd lineak-defaultplugin lineak-kdeplugins lineak-xosdplugin linkchecker logjam lucidlife Macaulay2 MagicPoint mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc new nucleo openalpp OpenSceneGraph pam_mount pan paps perl-GD perl-HTML-Mason perl-Image-Info perl-SOAP-Lite perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl plib python-cheetah python-dateutil python-goopy python-reportlab python-TestGears PyX qemu quarry R renrot R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount stow stratagus supertux swh-plugins sword sylpheed synaptic synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint ucblogo uqm ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-panel xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp z88dk With bugs filed: 7 ---------------------------------- gnome-ppp ['193968 CLOSED'] gtkhtml36 ['193476 ASSIGNED'] xfce4-modemlights-plugin ['193970 CLOSED'] xfce4-mount-plugin ['193971 CLOSED'] xfce4-taskmanager ['193972 CLOSED'] xfce4-weather-plugin ['193973 ASSIGNED'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From chris.stone at gmail.com Mon Jun 5 04:59:19 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 4 Jun 2006 21:59:19 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-04 In-Reply-To: <20060605044848.GD6822@lists.us.dell.com> References: <20060605044848.GD6822@lists.us.dell.com> Message-ID: Here is the build error from one of my packages on this list: Cannot open/read repomd.xml file for repository: core http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/nucleo-0.5-5.fc6.src.rpm/result/root.log From mpeters at mac.com Mon Jun 5 08:20:24 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 05 Jun 2006 01:20:24 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-04 In-Reply-To: <20060605044848.GD6822@lists.us.dell.com> References: <20060605044848.GD6822@lists.us.dell.com> Message-ID: <1149495624.26070.19.camel@atlantis.mpeters.local> On Sun, 2006-06-04 at 23:48 -0500, Matt Domsch wrote: > Of those expected to have worked... > Without a bug filed: 184 > ---------------------------------- OK - I'm a little confused > pan http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/pan-0.99-2.fc6.src.rpm/result/build.log Looks like it built the rpm to me. x86_64 has an empty build log - which seems like a build system error, not a packaging error. For what it is worth - I've been pushing the .9x releases through rawhide build about once a week, w/ successful builds. Since it worked on x86 with your config, and the x86_64 build log is empty, can I assume that it actually is probably fine? From andy at smile.org.ua Mon Jun 5 08:58:27 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 05 Jun 2006 11:58:27 +0300 Subject: 'CVS sync need' proposition Message-ID: <4483F233.9070908@smile.org.ua> Hi! For the injection to some stable branch some package a requrement should be posted to following link: http://fedoraproject.org/wiki/Extras/CVSSyncNeeded My proposition is to add automatical announce to this list after request is approved. It's save a bit of time for packagers. Opinions? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From paul at city-fan.org Mon Jun 5 09:01:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Jun 2006 10:01:12 +0100 Subject: 'CVS sync need' proposition In-Reply-To: <4483F233.9070908@smile.org.ua> References: <4483F233.9070908@smile.org.ua> Message-ID: <4483F2D8.3000207@city-fan.org> Andy Shevchenko wrote: > Hi! > > For the injection to some stable branch some package a requrement should > be posted to following link: > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > > My proposition is to add automatical announce to this list after request > is approved. It's save a bit of time for packagers. > > Opinions? An alternative would be for you to subscribe to this wiki page and you'll get notifications when it changes. Paul. From cranium2003 at yahoo.com Mon Jun 5 11:16:52 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 04:16:52 -0700 (PDT) Subject: unable to use mock Message-ID: <20060605111652.40949.qmail@web38010.mail.mud.yahoo.com> hi, I am new to mock tool i followed whats given on wiki of fedoraproject.org. According to that i set mock. installed it. then i did su - build then in build user i gave mock -r fedora-5-i386-core.cfg foo-0.1.1.src.rpm and i got output as ============================= init clean prep This may take a while Error peforming yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build ending done ============================= whats wrong happened?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From skvidal at linux.duke.edu Mon Jun 5 11:34:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 05 Jun 2006 07:34:46 -0400 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-04 In-Reply-To: <1149495624.26070.19.camel@atlantis.mpeters.local> References: <20060605044848.GD6822@lists.us.dell.com> <1149495624.26070.19.camel@atlantis.mpeters.local> Message-ID: <1149507286.21779.33.camel@cutter> On Mon, 2006-06-05 at 01:20 -0700, Michael A. Peters wrote: > On Sun, 2006-06-04 at 23:48 -0500, Matt Domsch wrote: > > > Of those expected to have worked... > > Without a bug filed: 184 > > ---------------------------------- > > OK - I'm a little confused > > > pan > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/pan-0.99-2.fc6.src.rpm/result/build.log > > Looks like it built the rpm to me. > x86_64 has an empty build log - which seems like a build system error, > not a packaging error. > > For what it is worth - I've been pushing the .9x releases through > rawhide build about once a week, w/ successful builds. Since it worked > on x86 with your config, and the x86_64 build log is empty, can I assume > that it actually is probably fine? > rawhide's repo was broken over the weekend. -sv From skvidal at linux.duke.edu Mon Jun 5 11:36:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 05 Jun 2006 07:36:29 -0400 Subject: unable to use mock In-Reply-To: <20060605111652.40949.qmail@web38010.mail.mud.yahoo.com> References: <20060605111652.40949.qmail@web38010.mail.mud.yahoo.com> Message-ID: <1149507389.21779.35.camel@cutter> On Mon, 2006-06-05 at 04:16 -0700, cranium2003 wrote: > hi, > I am new to mock tool i followed whats given on wiki > of fedoraproject.org. According to that i set mock. > installed it. then i did su - build > then in build user i gave mock -r > fedora-5-i386-core.cfg foo-0.1.1.src.rpm > and i got output as > ============================= > init > clean > prep > This may take a while > Error peforming yum command: /usr/sbin/mock-helper yum > --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > ending > done > ============================= > whats wrong happened?? > > what happens when you run this, as root: yum --installroot /var/lib/mock/fedora-development-i386-core/root \ groupinstall build-minimal build-base build -sv From cranium2003 at yahoo.com Mon Jun 5 11:45:14 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 04:45:14 -0700 (PDT) Subject: unable to use mock In-Reply-To: <1149507389.21779.35.camel@cutter> Message-ID: <20060605114514.99759.qmail@web38014.mail.mud.yahoo.com> Hi, --- seth vidal wrote: > On Mon, 2006-06-05 at 04:16 -0700, cranium2003 > wrote: > > hi, > > I am new to mock tool i followed whats given on > wiki > > of fedoraproject.org. According to that i set > mock. > > installed it. then i did su - build > > then in build user i gave mock -r > > fedora-5-i386-core.cfg foo-0.1.1.src.rpm > > and i got output as > > ============================= > > init > > clean > > prep > > This may take a while > > Error peforming yum command: /usr/sbin/mock-helper > yum > > --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > ending > > done > > ============================= > > whats wrong happened?? > > > > > > what happens when you run this, as root: > > yum --installroot > /var/lib/mock/fedora-development-i386-core/root \ > groupinstall build-minimal build-base build > > when i gave yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Content-Length: 345 Date: Mon, 05 Jun 2006 11:43:37 GMT Accept-Ranges: bytes Content-Type: text/html Server: lighttpd/1.3.16 Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From skvidal at linux.duke.edu Mon Jun 5 11:54:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 05 Jun 2006 07:54:00 -0400 Subject: unable to use mock In-Reply-To: <20060605114514.99759.qmail@web38014.mail.mud.yahoo.com> References: <20060605114514.99759.qmail@web38014.mail.mud.yahoo.com> Message-ID: <1149508440.21779.37.camel@cutter> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 wrote: > Hi, > --- seth vidal wrote: > > > On Mon, 2006-06-05 at 04:16 -0700, cranium2003 > > wrote: > > > hi, > > > I am new to mock tool i followed whats given on > > wiki > > > of fedoraproject.org. According to that i set > > mock. > > > installed it. then i did su - build > > > then in build user i gave mock -r > > > fedora-5-i386-core.cfg foo-0.1.1.src.rpm > > > and i got output as > > > ============================= > > > init > > > clean > > > prep > > > This may take a while > > > Error peforming yum command: /usr/sbin/mock-helper > > yum > > > --installroot > > > /var/lib/mock/fedora-development-i386-core/root > > > groupinstall build-minimal build-base build > > > ending > > > done > > > ============================= > > > whats wrong happened?? > > > > > > > > > > what happens when you run this, as root: > > > > yum --installroot > > /var/lib/mock/fedora-development-i386-core/root \ > > groupinstall build-minimal build-base build > > > > > when i gave > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Content-Length: 345 > Date: Mon, 05 Jun 2006 11:43:37 GMT > Accept-Ranges: bytes > Content-Type: text/html > Server: lighttpd/1.3.16 > Trying other mirror. > Cannot open/read repomd.xml file for repository: core > failure: repodata/repomd.xml from core: [Errno 256] No > more mirrors to try. > Error: failure: repodata/repomd.xml from core: [Errno > 256] No more mirrors to try. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > rawhide's repository was broken this weekend and the fix hasn't propagated out to all of the mirrors. -sv From cranium2003 at yahoo.com Mon Jun 5 11:55:36 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 04:55:36 -0700 (PDT) Subject: unable to use mock In-Reply-To: <1149508440.21779.37.camel@cutter> Message-ID: <20060605115536.39848.qmail@web38013.mail.mud.yahoo.com> Hi, --- seth vidal wrote: > On Mon, 2006-06-05 at 04:45 -0700, cranium2003 > wrote: > > Hi, > > --- seth vidal wrote: > > > > > On Mon, 2006-06-05 at 04:16 -0700, cranium2003 > > > wrote: > > > > hi, > > > > I am new to mock tool i followed whats given > on > > > wiki > > > > of fedoraproject.org. According to that i set > > > mock. > > > > installed it. then i did su - build > > > > then in build user i gave mock -r > > > > fedora-5-i386-core.cfg foo-0.1.1.src.rpm > > > > and i got output as > > > > ============================= > > > > init > > > > clean > > > > prep > > > > This may take a while > > > > Error peforming yum command: > /usr/sbin/mock-helper > > > yum > > > > --installroot > > > > > /var/lib/mock/fedora-development-i386-core/root > > > > groupinstall build-minimal build-base build > > > > ending > > > > done > > > > ============================= > > > > whats wrong happened?? > > > > > > > > > > > > > > what happens when you run this, as root: > > > > > > yum --installroot > > > /var/lib/mock/fedora-development-i386-core/root > \ > > > groupinstall build-minimal build-base build > > > > > > > > when i gave > > yum --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > > [Errno 14] HTTP Error 404: Content-Length: 345 > > Date: Mon, 05 Jun 2006 11:43:37 GMT > > Accept-Ranges: bytes > > Content-Type: text/html > > Server: lighttpd/1.3.16 > > Trying other mirror. > > Cannot open/read repomd.xml file for repository: > core > > failure: repodata/repomd.xml from core: [Errno > 256] No > > more mirrors to try. > > Error: failure: repodata/repomd.xml from core: > [Errno > > 256] No more mirrors to try. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > rawhide's repository was broken this weekend and the > fix hasn't > propagated out to all of the mirrors. No but its happening to me since last Monday and i was assuming that it was down so daily i tried 5 times and then gave up. So in that situation do u suggest me to check any other settings in my system. I followed all wiki pages as it is excluding squid setup to set up Mock tool. > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Mon Jun 5 12:05:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Jun 2006 13:05:50 +0100 Subject: unable to use mock In-Reply-To: <20060605115536.39848.qmail@web38013.mail.mud.yahoo.com> References: <20060605115536.39848.qmail@web38013.mail.mud.yahoo.com> Message-ID: <44841E1E.5010904@city-fan.org> cranium2003 wrote: > Hi, > --- seth vidal wrote: > >> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 >> wrote: >>> Hi, >>> --- seth vidal wrote: >>> >>>> On Mon, 2006-06-05 at 04:16 -0700, cranium2003 >>>> wrote: >>>>> hi, >>>>> I am new to mock tool i followed whats given >> on >>>> wiki >>>>> of fedoraproject.org. According to that i set >>>> mock. >>>>> installed it. then i did su - build >>>>> then in build user i gave mock -r >>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm >>>>> and i got output as >>>>> ============================= >>>>> init >>>>> clean >>>>> prep >>>>> This may take a while >>>>> Error peforming yum command: >> /usr/sbin/mock-helper >>>> yum >>>>> --installroot >>>>> >> /var/lib/mock/fedora-development-i386-core/root >>>>> groupinstall build-minimal build-base build >>>>> ending >>>>> done >>>>> ============================= >>>>> whats wrong happened?? >>>>> >>>>> >>>> what happens when you run this, as root: >>>> >>>> yum --installroot >>>> /var/lib/mock/fedora-development-i386-core/root >> \ >>>> groupinstall build-minimal build-base build >>>> >>>> >>> when i gave >>> yum --installroot >>> /var/lib/mock/fedora-development-i386-core/root >>> groupinstall build-minimal build-base build >>> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: >>> [Errno 14] HTTP Error 404: Content-Length: 345 >>> Date: Mon, 05 Jun 2006 11:43:37 GMT >>> Accept-Ranges: bytes >>> Content-Type: text/html >>> Server: lighttpd/1.3.16 >>> Trying other mirror. >>> Cannot open/read repomd.xml file for repository: >> core >>> failure: repodata/repomd.xml from core: [Errno >> 256] No >>> more mirrors to try. >>> Error: failure: repodata/repomd.xml from core: >> [Errno >>> 256] No more mirrors to try. >> rawhide's repository was broken this weekend and the >> fix hasn't >> propagated out to all of the mirrors. > No but its happening to me since last Monday and i > was assuming that it was down so daily i tried 5 times > and then gave up. So in that situation do u suggest me > to check any other settings in my system. I followed > all wiki pages as it is excluding squid setup to set > up Mock tool. The other problem you have is that the repository layout has changed. You need to change the baseurl: baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 to: baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os Paul. From bugs.michael at gmx.net Mon Jun 5 12:12:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Jun 2006 14:12:18 +0200 Subject: unable to use mock In-Reply-To: <20060605114514.99759.qmail@web38014.mail.mud.yahoo.com> References: <1149507389.21779.35.camel@cutter> <20060605114514.99759.qmail@web38014.mail.mud.yahoo.com> Message-ID: <20060605141218.f03e4133.bugs.michael@gmx.net> On Mon, 5 Jun 2006 04:45:14 -0700 (PDT), cranium2003 wrote: > when i gave > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Content-Length: 345 The repository URL is wrong. The "/os" is missing in your config.Should be: http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/ Could it be that there's a mock package which needs an update for the changed Rawhide repository layout? From cranium2003 at yahoo.com Mon Jun 5 12:20:44 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 05:20:44 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44841E1E.5010904@city-fan.org> Message-ID: <20060605122044.51867.qmail@web38008.mail.mud.yahoo.com> Hi, --- Paul Howarth wrote: > cranium2003 wrote: > > Hi, > > --- seth vidal wrote: > > > >> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 > >> wrote: > >>> Hi, > >>> --- seth vidal wrote: > >>> > >>>> On Mon, 2006-06-05 at 04:16 -0700, cranium2003 > >>>> wrote: > >>>>> hi, > >>>>> I am new to mock tool i followed whats given > >> on > >>>> wiki > >>>>> of fedoraproject.org. According to that i set > >>>> mock. > >>>>> installed it. then i did su - build > >>>>> then in build user i gave mock -r > >>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm > >>>>> and i got output as > >>>>> ============================= > >>>>> init > >>>>> clean > >>>>> prep > >>>>> This may take a while > >>>>> Error peforming yum command: > >> /usr/sbin/mock-helper > >>>> yum > >>>>> --installroot > >>>>> > >> /var/lib/mock/fedora-development-i386-core/root > >>>>> groupinstall build-minimal build-base build > >>>>> ending > >>>>> done > >>>>> ============================= > >>>>> whats wrong happened?? > >>>>> > >>>>> > >>>> what happens when you run this, as root: > >>>> > >>>> yum --installroot > >>>> /var/lib/mock/fedora-development-i386-core/root > >> \ > >>>> groupinstall build-minimal build-base build > >>>> > >>>> > >>> when i gave > >>> yum --installroot > >>> /var/lib/mock/fedora-development-i386-core/root > >>> groupinstall build-minimal build-base build > >>> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>> > > > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > >>> [Errno 14] HTTP Error 404: Content-Length: 345 > >>> Date: Mon, 05 Jun 2006 11:43:37 GMT > >>> Accept-Ranges: bytes > >>> Content-Type: text/html > >>> Server: lighttpd/1.3.16 > >>> Trying other mirror. > >>> Cannot open/read repomd.xml file for repository: > >> core > >>> failure: repodata/repomd.xml from core: [Errno > >> 256] No > >>> more mirrors to try. > >>> Error: failure: repodata/repomd.xml from core: > >> [Errno > >>> 256] No more mirrors to try. > >> rawhide's repository was broken this weekend and > the > >> fix hasn't > >> propagated out to all of the mirrors. > > No but its happening to me since last Monday and > i > > was assuming that it was down so daily i tried 5 > times > > and then gave up. So in that situation do u > suggest me > > to check any other settings in my system. I > followed > > all wiki pages as it is excluding squid setup to > set > > up Mock tool. > > The other problem you have is that the repository > layout has changed. > > You need to change the baseurl: > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > > to: > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os I dont know what happened. I am attaching my current fedora-5-i386-core.cfg under /etc/mock > > Paul. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 2109 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: From paul at city-fan.org Mon Jun 5 12:36:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Jun 2006 13:36:57 +0100 Subject: unable to use mock In-Reply-To: <20060605122044.51867.qmail@web38008.mail.mud.yahoo.com> References: <20060605122044.51867.qmail@web38008.mail.mud.yahoo.com> Message-ID: <44842569.8010701@city-fan.org> cranium2003 wrote: > Hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> Hi, >>> --- seth vidal wrote: >>> >>>> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 >>>> wrote: >>>>> Hi, >>>>> --- seth vidal wrote: >>>>> >>>>>> On Mon, 2006-06-05 at 04:16 -0700, cranium2003 >>>>>> wrote: >>>>>>> hi, >>>>>>> I am new to mock tool i followed whats given >>>> on >>>>>> wiki >>>>>>> of fedoraproject.org. According to that i set >>>>>> mock. >>>>>>> installed it. then i did su - build >>>>>>> then in build user i gave mock -r >>>>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm >>>>>>> and i got output as >>>>>>> ============================= >>>>>>> init >>>>>>> clean >>>>>>> prep >>>>>>> This may take a while >>>>>>> Error peforming yum command: >>>> /usr/sbin/mock-helper >>>>>> yum >>>>>>> --installroot >>>>>>> >>>> /var/lib/mock/fedora-development-i386-core/root >>>>>>> groupinstall build-minimal build-base build >>>>>>> ending >>>>>>> done >>>>>>> ============================= >>>>>>> whats wrong happened?? >>>>>>> >>>>>>> >>>>>> what happens when you run this, as root: >>>>>> >>>>>> yum --installroot >>>>>> /var/lib/mock/fedora-development-i386-core/root >>>> \ >>>>>> groupinstall build-minimal build-base build >>>>>> >>>>>> >>>>> when i gave >>>>> yum --installroot >>>>> /var/lib/mock/fedora-development-i386-core/root >>>>> groupinstall build-minimal build-base build >>>>> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: >>>>> [Errno 14] HTTP Error 404: Content-Length: 345 >>>>> Date: Mon, 05 Jun 2006 11:43:37 GMT >>>>> Accept-Ranges: bytes >>>>> Content-Type: text/html >>>>> Server: lighttpd/1.3.16 >>>>> Trying other mirror. >>>>> Cannot open/read repomd.xml file for repository: >>>> core >>>>> failure: repodata/repomd.xml from core: [Errno >>>> 256] No >>>>> more mirrors to try. >>>>> Error: failure: repodata/repomd.xml from core: >>>> [Errno >>>>> 256] No more mirrors to try. >>>> rawhide's repository was broken this weekend and >> the >>>> fix hasn't >>>> propagated out to all of the mirrors. >>> No but its happening to me since last Monday and >> i >>> was assuming that it was down so daily i tried 5 >> times >>> and then gave up. So in that situation do u >> suggest me >>> to check any other settings in my system. I >> followed >>> all wiki pages as it is excluding squid setup to >> set >>> up Mock tool. >> The other problem you have is that the repository >> layout has changed. >> >> You need to change the baseurl: >> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 >> to: >> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os > I dont know what happened. I am attaching my current > fedora-5-i386-core.cfg under /etc/mock This does not appear to be the config you were using that caused the error you posted about earlier. That one was for rawhide, this one's for FC5. You do appear to have a missing newline though, before "enabled=1" for the [extras-i386] repo. Paul. From cranium2003 at yahoo.com Mon Jun 5 12:46:17 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 05:46:17 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44842569.8010701@city-fan.org> Message-ID: <20060605124618.21180.qmail@web38014.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > Hi, > > --- Paul Howarth wrote: > > > >> cranium2003 wrote: > >>> Hi, > >>> --- seth vidal wrote: > >>> > >>>> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 > >>>> wrote: > >>>>> Hi, > >>>>> --- seth vidal wrote: > >>>>> > >>>>>> On Mon, 2006-06-05 at 04:16 -0700, > cranium2003 > >>>>>> wrote: > >>>>>>> hi, > >>>>>>> I am new to mock tool i followed whats > given > >>>> on > >>>>>> wiki > >>>>>>> of fedoraproject.org. According to that i > set > >>>>>> mock. > >>>>>>> installed it. then i did su - build > >>>>>>> then in build user i gave mock -r > >>>>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm > >>>>>>> and i got output as > >>>>>>> ============================= > >>>>>>> init > >>>>>>> clean > >>>>>>> prep > >>>>>>> This may take a while > >>>>>>> Error peforming yum command: > >>>> /usr/sbin/mock-helper > >>>>>> yum > >>>>>>> --installroot > >>>>>>> > >>>> /var/lib/mock/fedora-development-i386-core/root > >>>>>>> groupinstall build-minimal build-base build > >>>>>>> ending > >>>>>>> done > >>>>>>> ============================= > >>>>>>> whats wrong happened?? > >>>>>>> > >>>>>>> > >>>>>> what happens when you run this, as root: > >>>>>> > >>>>>> yum --installroot > >>>>>> > /var/lib/mock/fedora-development-i386-core/root > >>>> \ > >>>>>> groupinstall build-minimal build-base > build > >>>>>> > >>>>>> > >>>>> when i gave > >>>>> yum --installroot > >>>>> > /var/lib/mock/fedora-development-i386-core/root > >>>>> groupinstall build-minimal build-base build > >>>>> > Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> > > > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > >>>>> [Errno 14] HTTP Error 404: Content-Length: 345 > >>>>> Date: Mon, 05 Jun 2006 11:43:37 GMT > >>>>> Accept-Ranges: bytes > >>>>> Content-Type: text/html > >>>>> Server: lighttpd/1.3.16 > >>>>> Trying other mirror. > >>>>> Cannot open/read repomd.xml file for > repository: > >>>> core > >>>>> failure: repodata/repomd.xml from core: [Errno > >>>> 256] No > >>>>> more mirrors to try. > >>>>> Error: failure: repodata/repomd.xml from core: > >>>> [Errno > >>>>> 256] No more mirrors to try. > >>>> rawhide's repository was broken this weekend > and > >> the > >>>> fix hasn't > >>>> propagated out to all of the mirrors. > >>> No but its happening to me since last Monday > and > >> i > >>> was assuming that it was down so daily i tried 5 > >> times > >>> and then gave up. So in that situation do u > >> suggest me > >>> to check any other settings in my system. I > >> followed > >>> all wiki pages as it is excluding squid setup to > >> set > >>> up Mock tool. > >> The other problem you have is that the repository > >> layout has changed. > >> > >> You need to change the baseurl: > >> > > > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > >> to: > >> > > > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os > > I dont know what happened. I am attaching my > current > > fedora-5-i386-core.cfg under /etc/mock > > This does not appear to be the config you were using > that caused the > error you posted about earlier. That one was for > rawhide, this one's for > FC5. > > You do appear to have a missing newline though, > before "enabled=1" for > the [extras-i386] repo. > Oops i remove mock package and again install it thru' yum and now my errors are yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 12:32:12 GMT Server: Apache/2.0.52 Content-Length: 324 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Cannot open/read repomd.xml file for repository: local failure: repodata/repomd.xml from local: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from local: [Errno 256] No more mirrors to try. Attaching my /var/lib/mock/fedora-development-i386-core/root/etc/yum.conf file. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: yum.conf Type: application/octet-stream Size: 496 bytes Desc: 2662009895-yum.conf URL: From cranium2003 at yahoo.com Mon Jun 5 13:14:30 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 06:14:30 -0700 (PDT) Subject: unable to use mock In-Reply-To: <20060605124618.21180.qmail@web38014.mail.mud.yahoo.com> Message-ID: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> hi, On fresh install of mock when i run yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build i got following error http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Content-Length: 345 Date: Mon, 05 Jun 2006 13:04:21 GMT Accept-Ranges: bytes Content-Type: text/html Server: lighttpd/1.3.16 Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. then i found that i need to change fedora-5-i386-core.cfg file from http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 to http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/ i did that. Also i change similar changes at /var/lib/mock/fedora-5-i386-core/root/etc/yum.conf but still i am getting errors as yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 12:54:57 GMT Server: Apache/2.0.52 Content-Length: 324 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Cannot open/read repomd.xml file for repository: local failure: repodata/repomd.xml from local: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from local: [Errno 256] No more mirrors to try. why such things are happening? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Mon Jun 5 13:17:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Jun 2006 14:17:24 +0100 Subject: unable to use mock In-Reply-To: <20060605124618.21180.qmail@web38014.mail.mud.yahoo.com> References: <20060605124618.21180.qmail@web38014.mail.mud.yahoo.com> Message-ID: <44842EE4.4010802@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> Hi, >>> --- Paul Howarth wrote: >>> >>>> cranium2003 wrote: >>>>> Hi, >>>>> --- seth vidal wrote: >>>>> >>>>>> On Mon, 2006-06-05 at 04:45 -0700, cranium2003 >>>>>> wrote: >>>>>>> Hi, >>>>>>> --- seth vidal wrote: >>>>>>> >>>>>>>> On Mon, 2006-06-05 at 04:16 -0700, >> cranium2003 >>>>>>>> wrote: >>>>>>>>> hi, >>>>>>>>> I am new to mock tool i followed whats >> given >>>>>> on >>>>>>>> wiki >>>>>>>>> of fedoraproject.org. According to that i >> set >>>>>>>> mock. >>>>>>>>> installed it. then i did su - build >>>>>>>>> then in build user i gave mock -r >>>>>>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm >>>>>>>>> and i got output as >>>>>>>>> ============================= >>>>>>>>> init >>>>>>>>> clean >>>>>>>>> prep >>>>>>>>> This may take a while >>>>>>>>> Error peforming yum command: >>>>>> /usr/sbin/mock-helper >>>>>>>> yum >>>>>>>>> --installroot >>>>>>>>> >>>>>> /var/lib/mock/fedora-development-i386-core/root >>>>>>>>> groupinstall build-minimal build-base build >>>>>>>>> ending >>>>>>>>> done >>>>>>>>> ============================= >>>>>>>>> whats wrong happened?? >>>>>>>>> >>>>>>>>> >>>>>>>> what happens when you run this, as root: >>>>>>>> >>>>>>>> yum --installroot >>>>>>>> >> /var/lib/mock/fedora-development-i386-core/root >>>>>> \ >>>>>>>> groupinstall build-minimal build-base >> build >>>>>>>> >>>>>>> when i gave >>>>>>> yum --installroot >>>>>>> >> /var/lib/mock/fedora-development-i386-core/root >>>>>>> groupinstall build-minimal build-base build >>>>>>> >> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: >>>>>>> [Errno 14] HTTP Error 404: Content-Length: 345 >>>>>>> Date: Mon, 05 Jun 2006 11:43:37 GMT >>>>>>> Accept-Ranges: bytes >>>>>>> Content-Type: text/html >>>>>>> Server: lighttpd/1.3.16 >>>>>>> Trying other mirror. >>>>>>> Cannot open/read repomd.xml file for >> repository: >>>>>> core >>>>>>> failure: repodata/repomd.xml from core: [Errno >>>>>> 256] No >>>>>>> more mirrors to try. >>>>>>> Error: failure: repodata/repomd.xml from core: >>>>>> [Errno >>>>>>> 256] No more mirrors to try. >>>>>> rawhide's repository was broken this weekend >> and >>>> the >>>>>> fix hasn't >>>>>> propagated out to all of the mirrors. >>>>> No but its happening to me since last Monday >> and >>>> i >>>>> was assuming that it was down so daily i tried 5 >>>> times >>>>> and then gave up. So in that situation do u >>>> suggest me >>>>> to check any other settings in my system. I >>>> followed >>>>> all wiki pages as it is excluding squid setup to >>>> set >>>>> up Mock tool. >>>> The other problem you have is that the repository >>>> layout has changed. >>>> >>>> You need to change the baseurl: >>>> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 >>>> to: >>>> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os >>> I dont know what happened. I am attaching my >> current >>> fedora-5-i386-core.cfg under /etc/mock >> This does not appear to be the config you were using >> that caused the >> error you posted about earlier. That one was for >> rawhide, this one's for >> FC5. >> >> You do appear to have a missing newline though, >> before "enabled=1" for >> the [extras-i386] repo. >> > Oops i remove mock package and again install it > thru' yum and now my errors are > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 > 12:32:12 GMT > Server: Apache/2.0.52 > Content-Length: 324 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. > Cannot open/read repomd.xml file for repository: local > failure: repodata/repomd.xml from local: [Errno 256] > No more mirrors to try. > Error: failure: repodata/repomd.xml from local: [Errno > 256] No more mirrors to try. > > Attaching my > /var/lib/mock/fedora-development-i386-core/root/etc/yum.conf > file. The configuration for the "local" repository is also broken (as indicated in the error message). Try changing the baseurl for that repo from: baseurl=http://extras64.linux.duke.edu/plague-results/development/ to: baseurl=http://extras64.linux.duke.edu/plague-results/fedora-development-extras/ Paul. From dtimms at bigpond.net.au Mon Jun 5 13:19:54 2006 From: dtimms at bigpond.net.au (David Timms) Date: Mon, 05 Jun 2006 23:19:54 +1000 Subject: unable to use mock In-Reply-To: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> References: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> Message-ID: <44842F7A.2070906@bigpond.net.au> cranium2003 wrote: > hi, > On fresh install of mock when i run > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > i got following error > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Content-Length: 345 > Date: Mon, 05 Jun 2006 13:04:21 GMT > Accept-Ranges: bytes > Content-Type: text/html > Server: lighttpd/1.3.16 > Trying other mirror. > Cannot open/read repomd.xml file for repository: core > failure: repodata/repomd.xml from core: [Errno 256] No > more mirrors to try. > Error: failure: repodata/repomd.xml from core: [Errno > 256] No more mirrors to try. > > then i found that i need to change > fedora-5-i386-core.cfg file from > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > to > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/ > > i did that. Also i change similar changes at > /var/lib/mock/fedora-5-i386-core/root/etc/yum.conf > but still i am getting errors as > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 > 12:54:57 GMT > Server: Apache/2.0.52 > Content-Length: 324 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. > Cannot open/read repomd.xml file for repository: local > failure: repodata/repomd.xml from local: [Errno 256] > No more mirrors to try. > Error: failure: repodata/repomd.xml from local: [Errno > 256] No more mirrors to try. > > why such things are happening? Can you get to the above URL ? - I can't either, I think this may be an internal one; comment out that section of the .cfg to get past the error. DaveT. From dtimms at bigpond.net.au Mon Jun 5 13:21:46 2006 From: dtimms at bigpond.net.au (David Timms) Date: Mon, 05 Jun 2006 23:21:46 +1000 Subject: unable to use mock In-Reply-To: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> References: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> Message-ID: <44842FEA.60308@bigpond.net.au> cranium2003 wrote: > hi, > On fresh install of mock when i run > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > i got following error > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Content-Length: 345 > Date: Mon, 05 Jun 2006 13:04:21 GMT > Accept-Ranges: bytes > Content-Type: text/html > Server: lighttpd/1.3.16 > Trying other mirror. > Cannot open/read repomd.xml file for repository: core > failure: repodata/repomd.xml from core: [Errno 256] No > more mirrors to try. > Error: failure: repodata/repomd.xml from core: [Errno > 256] No more mirrors to try. > > then i found that i need to change > fedora-5-i386-core.cfg file from ... > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: ... > Error: failure: repodata/repomd.xml from local: [Errno > 256] No more mirrors to try. > > why such things are happening? Can you get to the above URL ? - I can't either, I think this may be an internal one, ie it doesn't apply to general extras development; comment out that whole section of the .cfg to get past the error. DaveT. From cranium2003 at yahoo.com Mon Jun 5 13:42:37 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Mon, 5 Jun 2006 06:42:37 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44842EE4.4010802@city-fan.org> Message-ID: <20060605134237.79777.qmail@web38013.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > hi, > > --- Paul Howarth wrote: > > > >> cranium2003 wrote: > >>> Hi, > >>> --- Paul Howarth wrote: > >>> > >>>> cranium2003 wrote: > >>>>> Hi, > >>>>> --- seth vidal wrote: > >>>>> > >>>>>> On Mon, 2006-06-05 at 04:45 -0700, > cranium2003 > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> --- seth vidal > wrote: > >>>>>>> > >>>>>>>> On Mon, 2006-06-05 at 04:16 -0700, > >> cranium2003 > >>>>>>>> wrote: > >>>>>>>>> hi, > >>>>>>>>> I am new to mock tool i followed whats > >> given > >>>>>> on > >>>>>>>> wiki > >>>>>>>>> of fedoraproject.org. According to that i > >> set > >>>>>>>> mock. > >>>>>>>>> installed it. then i did su - build > >>>>>>>>> then in build user i gave mock -r > >>>>>>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm > >>>>>>>>> and i got output as > >>>>>>>>> ============================= > >>>>>>>>> init > >>>>>>>>> clean > >>>>>>>>> prep > >>>>>>>>> This may take a while > >>>>>>>>> Error peforming yum command: > >>>>>> /usr/sbin/mock-helper > >>>>>>>> yum > >>>>>>>>> --installroot > >>>>>>>>> > >>>>>> > /var/lib/mock/fedora-development-i386-core/root > >>>>>>>>> groupinstall build-minimal build-base > build > >>>>>>>>> ending > >>>>>>>>> done > >>>>>>>>> ============================= > >>>>>>>>> whats wrong happened?? > >>>>>>>>> > >>>>>>>>> > >>>>>>>> what happens when you run this, as root: > >>>>>>>> > >>>>>>>> yum --installroot > >>>>>>>> > >> /var/lib/mock/fedora-development-i386-core/root > >>>>>> \ > >>>>>>>> groupinstall build-minimal build-base > >> build > >>>>>>>> > >>>>>>> when i gave > >>>>>>> yum --installroot > >>>>>>> > >> /var/lib/mock/fedora-development-i386-core/root > >>>>>>> groupinstall build-minimal build-base build > >>>>>>> > >> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: > >>>>>>> [Errno 14] HTTP Error 404: Content-Length: > 345 > >>>>>>> Date: Mon, 05 Jun 2006 11:43:37 GMT > >>>>>>> Accept-Ranges: bytes > >>>>>>> Content-Type: text/html > >>>>>>> Server: lighttpd/1.3.16 > >>>>>>> Trying other mirror. > >>>>>>> Cannot open/read repomd.xml file for > >> repository: > >>>>>> core > >>>>>>> failure: repodata/repomd.xml from core: > [Errno > >>>>>> 256] No > >>>>>>> more mirrors to try. > >>>>>>> Error: failure: repodata/repomd.xml from > core: > >>>>>> [Errno > >>>>>>> 256] No more mirrors to try. > >>>>>> rawhide's repository was broken this weekend > >> and > >>>> the > >>>>>> fix hasn't > >>>>>> propagated out to all of the mirrors. > >>>>> No but its happening to me since last Monday > >> and > >>>> i > >>>>> was assuming that it was down so daily i tried > 5 > >>>> times > >>>>> and then gave up. So in that situation do u > >>>> suggest me > >>>>> to check any other settings in my system. I > >>>> followed > >>>>> all wiki pages as it is excluding squid setup > to > >>>> set > >>>>> up Mock tool. > >>>> The other problem you have is that the > repository > >>>> layout has changed. > >>>> > >>>> You need to change the baseurl: > >>>> > > > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > >>>> to: > >>>> > > > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os > >>> I dont know what happened. I am attaching my > >> current > >>> fedora-5-i386-core.cfg under /etc/mock > >> This does not appear to be the config you were > using > >> that caused the > >> error you posted about earlier. That one was for > >> rawhide, this one's for > >> FC5. > >> > >> You do appear to have a missing newline though, > >> before "enabled=1" for > >> the [extras-i386] repo. > >> > > Oops i remove mock package and again install it > > thru' yum and now my errors are > > yum --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: > > [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 > > 12:32:12 GMT > > Server: Apache/2.0.52 > > Content-Length: 324 > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > Trying other mirror. > > Cannot open/read repomd.xml file for repository: > local > > failure: repodata/repomd.xml from local: [Errno > 256] > > No more mirrors to try. > > Error: failure: repodata/repomd.xml from local: > [Errno > > 256] No more mirrors to try. > > > > Attaching my > > > /var/lib/mock/fedora-development-i386-core/root/etc/yum.conf > > file. > > The configuration for the "local" repository is also > broken (as > indicated in the error message). Try changing the > baseurl for that repo > > from: > baseurl=http://extras64.linux.duke.edu/plague-results/development/ > > to: > baseurl=http://extras64.linux.duke.edu/plague-results/fedora-development-extras/ did that and then i gave yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build and since 20 min its doing nothing neither show any error nor any messages. Also nobody here is talking about where to change exactly in /etc/mock/fedora-5-i386-core.cfg OR in /var/lib/mock/fedora-development-i386/root/etc/yum.conf as chnage in one is not going to propogate in other, so i chnaged at both files local section with keeping other as it is with change of adding os in mirror ohh while writing this mail i finally got some output from that command and its nothing but its chosen to update 140 packages of 116M. so whats that command doing exactly? and does that mean when i do su - build and will give mock -r fedora-5-i385-core.cfg foo.src.rpm will give me some output and not a error? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Mon Jun 5 13:55:40 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Jun 2006 14:55:40 +0100 Subject: unable to use mock In-Reply-To: <20060605134237.79777.qmail@web38013.mail.mud.yahoo.com> References: <20060605134237.79777.qmail@web38013.mail.mud.yahoo.com> Message-ID: <448437DC.4040404@city-fan.org> cranium2003 wrote: > i gave > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > > and since 20 min its doing nothing neither show any > error nor any messages. It will take a long time because it's downloading and installing all the packages needed for a minimal build environment, and setting it up under /var/lib/mock/fedora-development-i386/root. It will do this again every time you run mock, so it's a good idea to have a local mirror or a decent cache as described on the MockTricks wiki page. > Also nobody here is talking about where to change > exactly in /etc/mock/fedora-5-i386-core.cfg OR in > /var/lib/mock/fedora-development-i386/root/etc/yum.conf > as chnage in one is not going to propogate in other, Everything under /var/lib/mock/fedora-development-i386/root will be blown away and re-creeted every time you run mock with that configuration, so it's pointless editing anything there. The /etc/mock/fedora-5-i386-core.cfg file is the one you need to tweak. > ohh while writing this mail i finally got some output > from that command and its nothing but its chosen to > update 140 packages of 116M. so whats that command > doing exactly? and does that mean when i do > su - build > and will give > mock -r fedora-5-i385-core.cfg foo.src.rpm will give > me some output and not a error? It'll do the same download as before, then install all the buildreqs and their dependencies for foo.src.rpm, then try to rebuild that SRPM. Paul. From dtimms at bigpond.net.au Mon Jun 5 14:01:04 2006 From: dtimms at bigpond.net.au (David Timms) Date: Tue, 06 Jun 2006 00:01:04 +1000 Subject: unable to use mock In-Reply-To: <20060605134237.79777.qmail@web38013.mail.mud.yahoo.com> References: <20060605134237.79777.qmail@web38013.mail.mud.yahoo.com> Message-ID: <44843920.2070308@bigpond.net.au> cranium2003 wrote: > hi, > > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> hi, >>> --- Paul Howarth wrote: >>> >>>> cranium2003 wrote: >>>>> Hi, >>>>> --- Paul Howarth wrote: >>>>> >>>>>> cranium2003 wrote: >>>>>>> Hi, >>>>>>> --- seth vidal wrote: >>>>>>> >>>>>>>> On Mon, 2006-06-05 at 04:45 -0700, >> cranium2003 >>>>>>>> wrote: >>>>>>>>> Hi, >>>>>>>>> --- seth vidal >> wrote: >>>>>>>>>> On Mon, 2006-06-05 at 04:16 -0700, >>>> cranium2003 >>>>>>>>>> wrote: >>>>>>>>>>> hi, >>>>>>>>>>> I am new to mock tool i followed whats >>>> given >>>>>>>> on >>>>>>>>>> wiki >>>>>>>>>>> of fedoraproject.org. According to that i >>>> set >>>>>>>>>> mock. >>>>>>>>>>> installed it. then i did su - build >>>>>>>>>>> then in build user i gave mock -r >>>>>>>>>>> fedora-5-i386-core.cfg foo-0.1.1.src.rpm >>>>>>>>>>> and i got output as >>>>>>>>>>> ============================= >>>>>>>>>>> init >>>>>>>>>>> clean >>>>>>>>>>> prep >>>>>>>>>>> This may take a while >>>>>>>>>>> Error peforming yum command: >>>>>>>> /usr/sbin/mock-helper >>>>>>>>>> yum >>>>>>>>>>> --installroot >>>>>>>>>>> >> /var/lib/mock/fedora-development-i386-core/root >>>>>>>>>>> groupinstall build-minimal build-base >> build >>>>>>>>>>> ending >>>>>>>>>>> done >>>>>>>>>>> ============================= >>>>>>>>>>> whats wrong happened?? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> what happens when you run this, as root: >>>>>>>>>> >>>>>>>>>> yum --installroot >>>>>>>>>> >>>> /var/lib/mock/fedora-development-i386-core/root >>>>>>>> \ >>>>>>>>>> groupinstall build-minimal build-base >>>> build >>>>>>>>> when i gave >>>>>>>>> yum --installroot >>>>>>>>> >>>> /var/lib/mock/fedora-development-i386-core/root >>>>>>>>> groupinstall build-minimal build-base build >>>>>>>>> >>>> Output->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/repodata/repomd.xml: >>>>>>>>> [Errno 14] HTTP Error 404: Content-Length: >> 345 >>>>>>>>> Date: Mon, 05 Jun 2006 11:43:37 GMT >>>>>>>>> Accept-Ranges: bytes >>>>>>>>> Content-Type: text/html >>>>>>>>> Server: lighttpd/1.3.16 >>>>>>>>> Trying other mirror. >>>>>>>>> Cannot open/read repomd.xml file for >>>> repository: >>>>>>>> core >>>>>>>>> failure: repodata/repomd.xml from core: >> [Errno >>>>>>>> 256] No >>>>>>>>> more mirrors to try. >>>>>>>>> Error: failure: repodata/repomd.xml from >> core: >>>>>>>> [Errno >>>>>>>>> 256] No more mirrors to try. >>>>>>>> rawhide's repository was broken this weekend >>>> and >>>>>> the >>>>>>>> fix hasn't >>>>>>>> propagated out to all of the mirrors. >>>>>>> No but its happening to me since last Monday >>>> and >>>>>> i >>>>>>> was assuming that it was down so daily i tried >> 5 >>>>>> times >>>>>>> and then gave up. So in that situation do u >>>>>> suggest me >>>>>>> to check any other settings in my system. I >>>>>> followed >>>>>>> all wiki pages as it is excluding squid setup >> to >>>>>> set >>>>>>> up Mock tool. >>>>>> The other problem you have is that the >> repository >>>>>> layout has changed. >>>>>> >>>>>> You need to change the baseurl: >>>>>> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 >>>>>> to: >>>>>> > baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os >>>>> I dont know what happened. I am attaching my >>>> current >>>>> fedora-5-i386-core.cfg under /etc/mock >>>> This does not appear to be the config you were >> using >>>> that caused the >>>> error you posted about earlier. That one was for >>>> rawhide, this one's for >>>> FC5. >>>> >>>> You do appear to have a missing newline though, >>>> before "enabled=1" for >>>> the [extras-i386] repo. >>>> >>> Oops i remove mock package and again install it >>> thru' yum and now my errors are >>> yum --installroot >>> /var/lib/mock/fedora-development-i386-core/root >>> groupinstall build-minimal build-base build >>> > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: >>> [Errno 14] HTTP Error 404: Date: Mon, 05 Jun 2006 >>> 12:32:12 GMT >>> Server: Apache/2.0.52 >>> Content-Length: 324 >>> Connection: close >>> Content-Type: text/html; charset=iso-8859-1 >>> Trying other mirror. >>> Cannot open/read repomd.xml file for repository: >> local >>> failure: repodata/repomd.xml from local: [Errno >> 256] >>> No more mirrors to try. >>> Error: failure: repodata/repomd.xml from local: >> [Errno >>> 256] No more mirrors to try. >>> >>> Attaching my >>> > /var/lib/mock/fedora-development-i386-core/root/etc/yum.conf >>> file. >> The configuration for the "local" repository is also >> broken (as >> indicated in the error message). Try changing the >> baseurl for that repo >> >> from: >> > baseurl=http://extras64.linux.duke.edu/plague-results/development/ >> to: >> > baseurl=http://extras64.linux.duke.edu/plague-results/fedora-development-extras/ > > did that and then i gave > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > > and since 20 min its doing nothing neither show any > error nor any messages. > Also nobody here is talking about where to change > exactly in /etc/mock/fedora-5-i386-core.cfg OR in I think mock with no parameters will use /etc/mock/default.conf, or you can choose to use a particular one by specifying it on the command line. > /var/lib/mock/fedora-development-i386/root/etc/yum.conf Mock erases and rebuilds the /var/lib/mock build root every time you do a mock rebuild. This is how it can be sure that the rebuild process isn't sneakily pulling in files/libraries that can not be assumed to be present. > ohh while writing this mail i finally got some output # yum install gkrellm # gkrellm Use it to monitor you CPU/disk/network usage, realtime; it gives a better idea that something is indeed happening. > from that command and its nothing but its chosen to > update 140 packages of 116M. so whats that command > doing exactly? Installs the minimal build system packages in a mock chroot jail. Then it installs the buildrequires specified in the .srpm that you are getting mock to test build. > and does that mean when i do > su - build > and will give > mock -r fedora-5-i385-core.cfg foo.src.rpm will give > me some output and not a error? Look in /var/lib/mock/fed.../result/ files to see what it did. You need a caching mechanism to speed up the process of mock reconstructing the build root each time you run it. (Either squid proxy, or rsync/mirroring of the site). DaveT. From Matt_Domsch at dell.com Mon Jun 5 14:18:35 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Jun 2006 09:18:35 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-04 In-Reply-To: <1149495624.26070.19.camel@atlantis.mpeters.local> References: <20060605044848.GD6822@lists.us.dell.com> <1149495624.26070.19.camel@atlantis.mpeters.local> Message-ID: <20060605141835.GA25454@lists.us.dell.com> On Mon, Jun 05, 2006 at 01:20:24AM -0700, Michael A. Peters wrote: > Looks like it built the rpm to me. > x86_64 has an empty build log - which seems like a build system error, > not a packaging error. I'll rebuild everything that's presently failed now that rawhide is back to normal. -- 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 ville.skytta at iki.fi Mon Jun 5 15:48:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 05 Jun 2006 18:48:19 +0300 Subject: rpmlint non executable script In-Reply-To: <1149457495.26070.7.camel@atlantis.mpeters.local> References: <1149457495.26070.7.camel@atlantis.mpeters.local> Message-ID: <1149522499.2853.91.camel@localhost.localdomain> On Sun, 2006-06-04 at 14:44 -0700, Michael A. Peters wrote: > Should rpmlint suppress the warnings on non executable shell script that > are specifically flagged as documentation? I think so, yes. The problem seems to be in FilesCheck.py where too many checks use a regexp based heuristic [0] for deciding whether something is a doc file, but should base that decision on whether the file is actually marked as %doc in the package. Will take a closer look. [0] ^/usr(/share|/X11R6)?/(doc|man|info)/, which misses your /usr/share/texmf/doc/... test case From bugs.michael at gmx.net Mon Jun 5 15:54:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Jun 2006 17:54:58 +0200 Subject: unable to use mock In-Reply-To: <44842FEA.60308@bigpond.net.au> References: <20060605131430.18652.qmail@web38001.mail.mud.yahoo.com> <44842FEA.60308@bigpond.net.au> Message-ID: <20060605175458.153083d2.bugs.michael@gmx.net> On Mon, 05 Jun 2006 23:21:46 +1000, David Timms wrote: > > then i found that i need to change > > fedora-5-i386-core.cfg file from > ... > > http://extras64.linux.duke.edu/plague-results/development/repodata/repomd.xml: > ... > > Error: failure: repodata/repomd.xml from local: [Errno > > 256] No more mirrors to try. > > > > why such things are happening? > Can you get to the above URL ? > - I can't either, I think this may be an internal one, ie it doesn't > apply to general extras development; comment out that whole section of > the .cfg to get past the error. No, this is severe misconfiguration of mock. From fedora at leemhuis.info Mon Jun 5 16:09:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Jun 2006 18:09:55 +0200 Subject: new wiki-page: Packaging/FrequentlyMadeMistakes Message-ID: <1149523795.5767.11.camel@localhost.localdomain> Hi! Just FYI: I created a new page in the wiki at http://www.fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes I'd like to collect and describe some common and frequently made mistakes there that happen while packaging RPM-Files and putting them under review for Extras. Maybe that helps one or two packagers to avoid those mistakes. Currently it only lists three common problems that afaics new packagers often make -- but I'm sure there are many others so feel free to add them on the page. There are probably also some general mistakes that even experienced packagers tip into now and then -- please write them up on the page, too. tia CU thl -- Thorsten Leemhuis From skvidal at linux.duke.edu Mon Jun 5 18:30:33 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 05 Jun 2006 14:30:33 -0400 Subject: extras buildsys/plague downtime In-Reply-To: <1149453146.21779.12.camel@cutter> References: <1149453146.21779.12.camel@cutter> Message-ID: <1149532234.18582.0.camel@cutter> On Sun, 2006-06-04 at 16:32 -0400, seth vidal wrote: > Hi folks, > We've got to swap out a disk in the buildmaster > (buildsys.fedoraproject.org) in order to increase available space. > Therefore, we'll be taking plague down while they're swapped. > > This will happen Monday June 5th at 13:00 GMT-4. > > Ideally it will only take 20 minutes to do everything but give me until > at least 14:00 before sending out the hatemail. :) > And we're all back up. Let me know if anything seems hosed. -sv From chris.stone at gmail.com Mon Jun 5 21:10:22 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 5 Jun 2006 14:10:22 -0700 Subject: Unorphan question Message-ID: I wanted to unorphan cksfv, but under the devel/ directory there is a file called dead.package. How do I make cksfv undead? From michael at knox.net.nz Mon Jun 5 21:13:58 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 06 Jun 2006 09:13:58 +1200 Subject: Unorphan question In-Reply-To: References: Message-ID: <44849E96.3080504@knox.net.nz> Christopher Stone wrote: > I wanted to unorphan cksfv, but under the devel/ directory there is a > file called dead.package. > > How do I make cksfv undead? > You need to import the spec file and other bits you may need into the devel branch. The "dead.package" is a marker for an orphaned package. Michael From paul at all-the-johnsons.co.uk Mon Jun 5 22:04:15 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 05 Jun 2006 23:04:15 +0100 Subject: amaya orphaned? Message-ID: <1149545055.24462.16.camel@T7.Linux> Hi, Looking at the orphaned packages and it looks like amaya may be orphaned. Does anyone know if it has or hasn't? TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Mon Jun 5 22:14:17 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Jun 2006 00:14:17 +0200 Subject: Unorphan question In-Reply-To: References: Message-ID: <20060606001417.c80a05eb.bugs.michael@gmx.net> On Mon, 5 Jun 2006 14:10:22 -0700, Christopher Stone wrote: > I wanted to unorphan cksfv, but under the devel/ directory there is a > file called dead.package. > > How do I make cksfv undead? Examine cksfv CVS log and check out the most recent tag, e.g. cksfv-1_3-4 or FC-5-split: cvs co -r cksfv-1_3-4 cksfv Base your changes on those files and check them in. Remove the dead.package file. From tibbs at math.uh.edu Mon Jun 5 22:27:15 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 05 Jun 2006 17:27:15 -0500 Subject: amaya orphaned? In-Reply-To: <1149545055.24462.16.camel@T7.Linux> (paul@all-the-johnsons.co.uk's message of "Mon, 05 Jun 2006 23:04:15 +0100") References: <1149545055.24462.16.camel@T7.Linux> Message-ID: >>>>> "p" == paul writes: p> Looking at the orphaned packages and it looks like amaya may be p> orphaned. Does anyone know if it has or hasn't? I recall that it was semi-orphaned, in that the current maintainer would prefer not to maintain it. However, Aurelien did push a security update when the issue came up. - J< From paul at all-the-johnsons.co.uk Mon Jun 5 22:29:41 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 05 Jun 2006 23:29:41 +0100 Subject: amaya orphaned? In-Reply-To: References: <1149545055.24462.16.camel@T7.Linux> Message-ID: <1149546581.24462.19.camel@T7.Linux> Hi, > p> Looking at the orphaned packages and it looks like amaya may be > p> orphaned. Does anyone know if it has or hasn't? > > I recall that it was semi-orphaned, in that the current maintainer > would prefer not to maintain it. However, Aurelien did push a > security update when the issue came up. Fair enough. I hereby claim it in the name of her royal Highness, Princess Beverley of Haydock and this can of Sprite sitting infront of me. One question - why is it using the fullsrc rather than just src? (22 vs 8Mb in size)? From what I can see, libwww is already in FC as are the other bits it links to. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue Jun 6 01:39:42 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Jun 2006 20:39:42 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-05 Message-ID: <20060606013942.GE25454@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Mon Jun 5 20:14:33 CDT 2006 Number failed to build: 144 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 143 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 132 ---------------------------------- alacarte amaya balsa banshee baobab bidiv bmp byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-schedule gnome-sudoku gnome-themes-extras gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget Hermes ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate licq linkchecker logjam lucidlife MagicPoint mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc OpenSceneGraph paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl python-cheetah python-goopy python-TestGears qemu quarry R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount stow stratagus swh-plugins synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xmms-crossfade xplanet xsp With bugs filed: 11 ---------------------------------- gnupg2 ['194079 NEW'] gtkhtml36 ['193476 ASSIGNED'] libxfcegui4 ['194138 CLOSED'] xfce4-panel ['194139 NEW'] xfce4-weather-plugin ['193973 ASSIGNED'] xfce-utils ['194140 NEW'] xfdesktop ['194142 NEW'] xffm ['194145 NEW'] xfprint ['194147 NEW'] xfwm4 ['194148 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Tue Jun 6 01:40:29 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Jun 2006 20:40:29 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-05 Message-ID: <20060606014029.GF25454@lists.us.dell.com> This was a full rebuild of everything that had previously failed. Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Mon Jun 5 20:12:45 CDT 2006 Number failed to build: 170 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 159 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 148 ---------------------------------- alacarte amaya apt atitvout balsa banshee baobab bidiv bmp byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-schedule gnome-sudoku gnome-themes-extras gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate licq linkchecker logjam lucidlife Macaulay2 MagicPoint mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc new OpenSceneGraph pam_mount paps perl-HTML-Mason perl-Image-Info perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl python-cheetah python-dateutil python-goopy python-reportlab python-TestGears qemu quarry R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount stow stratagus swh-plugins synaptic synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont uqm ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xmms-crossfade xplanet xsp z88dk With bugs filed: 11 ---------------------------------- gnupg2 ['194079 NEW'] gtkhtml36 ['193476 ASSIGNED'] libxfcegui4 ['194138 CLOSED'] xfce4-panel ['194139 NEW'] xfce4-weather-plugin ['193973 ASSIGNED'] xfce-utils ['194140 NEW'] xfdesktop ['194142 NEW'] xffm ['194145 NEW'] xfprint ['194147 NEW'] xfwm4 ['194148 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tibbs at math.uh.edu Tue Jun 6 02:59:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 05 Jun 2006 21:59:08 -0500 Subject: amaya orphaned? In-Reply-To: <1149546581.24462.19.camel@T7.Linux> (paul@all-the-johnsons.co.uk's message of "Mon, 05 Jun 2006 23:29:41 +0100") References: <1149545055.24462.16.camel@T7.Linux> <1149546581.24462.19.camel@T7.Linux> Message-ID: >>>>> "p" == paul writes: p> I hereby claim it in the name of her royal Highness, Princess p> Beverley of Haydock and this can of Sprite sitting infront of me. You might want to ping the current maintainer just to make sure; there's always a chance I have no idea what I'm talking about. Maintainer CC'd just in case he's not reading this. p> One question - why is it using the fullsrc rather than just src? p> (22 vs 8Mb in size)? From what I can see, libwww is already in FC p> as are the other bits it links to. No idea. - J< From gauret at free.fr Tue Jun 6 05:41:04 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 06 Jun 2006 07:41:04 +0200 Subject: amaya orphaned? References: <1149545055.24462.16.camel@T7.Linux> <1149546581.24462.19.camel@T7.Linux> Message-ID: Paul wrote: > I hereby claim it in the name of her royal Highness, Princess Beverley > of Haydock and this can of Sprite sitting infront of me. Yes ! Let it be so ! > One question - why is it using the fullsrc rather than just src? (22 vs > 8Mb in size)? From what I can see, libwww is already in FC as are the > other bits it links to. Because at the time I packaged it, some bits (redland and libwww IIRC) were not available. But you're right, it should use the system libs when available. I'm glad you take this one over :) Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Quand on pense qu'il suffirait que les gens n'ach?tent pas pour que ?a ne se vende plus ! " -- Coluche From cranium2003 at yahoo.com Tue Jun 6 09:56:18 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 02:56:18 -0700 (PDT) Subject: unable to use mock In-Reply-To: <448437DC.4040404@city-fan.org> Message-ID: <20060606095618.63384.qmail@web38011.mail.mud.yahoo.com> Hi, I executed yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build as root and it takes much time and installed 140 packages. Then i restart system. As mock does takes a srpm and builds it in a chroot. So i created as root one SRPM from SPEC file as rpmbuild -bs foo.spec then i did su - build then i gave mock -r fedora-5-i386-core.cfg foo.src.rpm and its output is still init clean prep This may take a while Error peforming yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build build-minimal build-base ending done So i try to execute yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build and its output is Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 97, in main result, resultmsgs = do() File "/usr/share/yum-cli/cli.py", line 565, in doCommands self.doGroupSetup() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 365, in doGroupSetup groupfile = repo.getGroups() File "/usr/lib/python2.4/site-packages/yum/repos.py", line 813, in getGroups file = self._retrieveMD('group') File "/usr/lib/python2.4/site-packages/yum/repos.py", line 784, in _retrieveMD cache=self.http_caching == 'all') File "/usr/lib/python2.4/site-packages/yum/repos.py", line 617, in get http_headers=headers, File "/usr/lib/python2.4/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.4/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 784, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 702, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 772, in retryfunc fo._do_grab() File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 1102, in _do_grab os.utime(self.filename, (modified_stamp, modified_stamp)) OSError: [Errno 2] No such file or directory: '/var/lib/mock/fedora-development-i386-core/root/var/cache/yum/core/comps.xml' why its gave error now?? Then i check ls /var/lib/mock/fedora-development-i386-core/root/var/cache/yum/core/ and found that it contains only headers packages and not comps.xml why?? --- Paul Howarth wrote: > cranium2003 wrote: > > i gave > > yum --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > > > and since 20 min its doing nothing neither show > any > > error nor any messages. > > It will take a long time because it's downloading > and installing all the > packages needed for a minimal build environment, and > setting it up under > /var/lib/mock/fedora-development-i386/root. It will > do this again every > time you run mock, so it's a good idea to have a > local mirror or a > decent cache as described on the MockTricks wiki > page. > > > Also nobody here is talking about where to > change > > exactly in /etc/mock/fedora-5-i386-core.cfg OR in > > > /var/lib/mock/fedora-development-i386/root/etc/yum.conf > > as chnage in one is not going to propogate in > other, > > Everything under > /var/lib/mock/fedora-development-i386/root will be > blown away and re-creeted every time you run mock > with that > configuration, so it's pointless editing anything > there. The > /etc/mock/fedora-5-i386-core.cfg file is the one you > need to tweak. > > > ohh while writing this mail i finally got some > output > > from that command and its nothing but its chosen > to > > update 140 packages of 116M. so whats that command > > doing exactly? and does that mean when i do > > su - build > > and will give > > mock -r fedora-5-i385-core.cfg foo.src.rpm will > give > > me some output and not a error? > > It'll do the same download as before, then install > all the buildreqs and > their dependencies for foo.src.rpm, then try to > rebuild that SRPM. > > Paul. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Tue Jun 6 10:14:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 06 Jun 2006 11:14:10 +0100 Subject: unable to use mock In-Reply-To: <20060606095618.63384.qmail@web38011.mail.mud.yahoo.com> References: <20060606095618.63384.qmail@web38011.mail.mud.yahoo.com> Message-ID: <44855572.6060708@city-fan.org> cranium2003 wrote: > Hi, > I executed yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > as root and it takes much time and installed 140 > packages. Then i restart system. As mock does takes a > srpm and builds it in a chroot. So i created as root > one SRPM from SPEC file as > rpmbuild -bs foo.spec > then i did > su - build > then i gave > mock -r fedora-5-i386-core.cfg foo.src.rpm > and its output is still > init > clean > prep > This may take a while > Error peforming yum command: /usr/sbin/mock-helper yum > --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build build-minimal build-base > ending > done There's still something wrong with your configuration here. You're using fedora-5-i386-core.cfg yet the root is fedora-development-i386-core. What's in /etc/mock/fedora-5-i386-core.cfg? Paul. From cranium2003 at yahoo.com Tue Jun 6 10:17:15 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 03:17:15 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44855572.6060708@city-fan.org> Message-ID: <20060606101715.89034.qmail@web38002.mail.mud.yahoo.com> Hi, --- Paul Howarth wrote: > cranium2003 wrote: > > Hi, > > I executed yum --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > as root and it takes much time and installed 140 > > packages. Then i restart system. As mock does > takes a > > srpm and builds it in a chroot. So i created as > root > > one SRPM from SPEC file as > > rpmbuild -bs foo.spec > > then i did > > su - build > > then i gave > > mock -r fedora-5-i386-core.cfg foo.src.rpm > > and its output is still > > init > > clean > > prep > > This may take a while > > Error peforming yum command: /usr/sbin/mock-helper > yum > > --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build build-minimal build-base > > ending > > done > > There's still something wrong with your > configuration here. You're using > fedora-5-i386-core.cfg yet the root is > fedora-development-i386-core. > What's in /etc/mock/fedora-5-i386-core.cfg? > Attaching /etc/mock/fedora-5-i386-core.cfg file here. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 1356 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: From paul at city-fan.org Tue Jun 6 10:31:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 06 Jun 2006 11:31:49 +0100 Subject: unable to use mock In-Reply-To: <20060606101715.89034.qmail@web38002.mail.mud.yahoo.com> References: <20060606101715.89034.qmail@web38002.mail.mud.yahoo.com> Message-ID: <44855995.90408@city-fan.org> cranium2003 wrote: >> There's still something wrong with your >> configuration here. You're using >> fedora-5-i386-core.cfg yet the root is >> fedora-development-i386-core. >> What's in /etc/mock/fedora-5-i386-core.cfg? >> > Attaching /etc/mock/fedora-5-i386-core.cfg file here. The contents of that file are appropriate for rawhide, not FC5. If you change all occurrences of "development" in the file to "5", you should at least pick up the FC5 repos. Paul. From cranium2003 at yahoo.com Tue Jun 6 10:41:49 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 03:41:49 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44855995.90408@city-fan.org> Message-ID: <20060606104149.7004.qmail@web38003.mail.mud.yahoo.com> Hi, --- Paul Howarth wrote: > cranium2003 wrote: > >> There's still something wrong with your > >> configuration here. You're using > >> fedora-5-i386-core.cfg yet the root is > >> fedora-development-i386-core. > >> What's in /etc/mock/fedora-5-i386-core.cfg? > >> > > Attaching /etc/mock/fedora-5-i386-core.cfg file > here. > > The contents of that file are appropriate for > rawhide, not FC5. > > If you change all occurrences of "development" in > the file to "5", you > should at least pick up the FC5 repos. Did it but still same error. Oh god what a prolmes are in using Fedora Extras. How people can use mock i dont understand. Really finding a good repository is a tough task i feel. mock -r fedora-5-i386-core.cfg foo.src.rpm gave init clean prep This may take a while Error peforming yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-5-i386-core/root groupinstall build build-minimal build-base ending done and yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/python-2.4.3-3.i386.rpm: [Errno 4] Socket Error: (11, 'Resource temporarily unavailable') Trying other mirror. Error: failure: Fedora/RPMS/python-2.4.3-3.i386.rpm from core: [Errno 256] No more mirrors to try. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Tue Jun 6 10:49:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 06 Jun 2006 11:49:22 +0100 Subject: unable to use mock In-Reply-To: <20060606104149.7004.qmail@web38003.mail.mud.yahoo.com> References: <20060606104149.7004.qmail@web38003.mail.mud.yahoo.com> Message-ID: <44855DB2.60606@city-fan.org> cranium2003 wrote: > Hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>>> There's still something wrong with your >>>> configuration here. You're using >>>> fedora-5-i386-core.cfg yet the root is >>>> fedora-development-i386-core. >>>> What's in /etc/mock/fedora-5-i386-core.cfg? >>>> >>> Attaching /etc/mock/fedora-5-i386-core.cfg file >> here. >> >> The contents of that file are appropriate for >> rawhide, not FC5. >> >> If you change all occurrences of "development" in >> the file to "5", you >> should at least pick up the FC5 repos. > Did it but still same error. Oh god what a prolmes > are in using Fedora Extras. How people can use mock i > dont understand. When it works, it works well. I wouldn't dream of using it with a core or updates repository on the Internet myself though - I always use a local mirror, which speeds things up significantly and I can rebuild the metadata myself if it's out of sync. > Really finding a good repository is a > tough task i feel. > mock -r fedora-5-i386-core.cfg foo.src.rpm > gave > init > clean > prep > This may take a while > Error peforming yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-5-i386-core/root > groupinstall build build-minimal build-base > ending > done > > and > yum --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/python-2.4.3-3.i386.rpm: > [Errno 4] Socket Error: (11, 'Resource temporarily > unavailable') > Trying other mirror. > Error: failure: Fedora/RPMS/python-2.4.3-3.i386.rpm > from core: [Errno 256] No more mirrors to try. I'd strongly consider using a local mirror, or at least a decent cache as suggested on the MockTricks wiki page. Paul. From cranium2003 at yahoo.com Tue Jun 6 11:00:29 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 04:00:29 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44855DB2.60606@city-fan.org> Message-ID: <20060606110029.87248.qmail@web38006.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > Hi, > > --- Paul Howarth wrote: > > > >> cranium2003 wrote: > >>>> There's still something wrong with your > >>>> configuration here. You're using > >>>> fedora-5-i386-core.cfg yet the root is > >>>> fedora-development-i386-core. > >>>> What's in /etc/mock/fedora-5-i386-core.cfg? > >>>> > >>> Attaching /etc/mock/fedora-5-i386-core.cfg file > >> here. > >> > >> The contents of that file are appropriate for > >> rawhide, not FC5. > >> > >> If you change all occurrences of "development" in > >> the file to "5", you > >> should at least pick up the FC5 repos. > > Did it but still same error. Oh god what a > prolmes > > are in using Fedora Extras. How people can use > mock i > > dont understand. > > When it works, it works well. I wouldn't dream of > using it with a core > or updates repository on the Internet myself though > - I always use a > local mirror, which speeds things up significantly > and I can rebuild the > metadata myself if it's out of sync. so if i use local mirror then i can work offline also i mean ni need to have connected always to Internet right?? > > > Really finding a good repository is a > > tough task i feel. > > mock -r fedora-5-i386-core.cfg foo.src.rpm > > gave > > init > > clean > > prep > > This may take a while > > Error peforming yum command: /usr/sbin/mock-helper > yum > > --installroot > /var/lib/mock/fedora-5-i386-core/root > > groupinstall build build-minimal build-base > > ending > > done > > > > and > > yum --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/python-2.4.3-3.i386.rpm: > > [Errno 4] Socket Error: (11, 'Resource temporarily > > unavailable') > > Trying other mirror. > > Error: failure: > Fedora/RPMS/python-2.4.3-3.i386.rpm > > from core: [Errno 256] No more mirrors to try. > > I'd strongly consider using a local mirror, or at > least a decent cache > as suggested on the MockTricks wiki page. I already did all things from that page. I added all 3 rules then started squid and also i added http_proxy variable in .bash_profile. Still getting error. How to build local repo/mirror and then how can i use it in build user environment?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Tue Jun 6 11:09:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 06 Jun 2006 12:09:59 +0100 Subject: unable to use mock In-Reply-To: <20060606110029.87248.qmail@web38006.mail.mud.yahoo.com> References: <20060606110029.87248.qmail@web38006.mail.mud.yahoo.com> Message-ID: <44856287.4030406@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> Hi, >>> --- Paul Howarth wrote: >>> >>>> cranium2003 wrote: >>>>>> There's still something wrong with your >>>>>> configuration here. You're using >>>>>> fedora-5-i386-core.cfg yet the root is >>>>>> fedora-development-i386-core. >>>>>> What's in /etc/mock/fedora-5-i386-core.cfg? >>>>>> >>>>> Attaching /etc/mock/fedora-5-i386-core.cfg file >>>> here. >>>> >>>> The contents of that file are appropriate for >>>> rawhide, not FC5. >>>> >>>> If you change all occurrences of "development" in >>>> the file to "5", you >>>> should at least pick up the FC5 repos. >>> Did it but still same error. Oh god what a >> prolmes >>> are in using Fedora Extras. How people can use >> mock i >>> dont understand. >> When it works, it works well. I wouldn't dream of >> using it with a core >> or updates repository on the Internet myself though >> - I always use a >> local mirror, which speeds things up significantly >> and I can rebuild the >> metadata myself if it's out of sync. > so if i use local mirror then i can work offline also > i mean ni need to have connected always to Internet > right?? Only if all of the repos in your configuration file have a local mirror. That would include "extras" and the groups "repo". You could get away without the enabling the "local" repo at all. A local mirror of "core" and "updates" will make a significant difference to mock's performance. A local mirror of "extras" will help, but it won't make as big a difference. >>> Really finding a good repository is a >>> tough task i feel. >>> mock -r fedora-5-i386-core.cfg foo.src.rpm >>> gave >>> init >>> clean >>> prep >>> This may take a while >>> Error peforming yum command: /usr/sbin/mock-helper >> yum >>> --installroot >> /var/lib/mock/fedora-5-i386-core/root >>> groupinstall build build-minimal build-base >>> ending >>> done >>> >>> and >>> yum --installroot >>> /var/lib/mock/fedora-development-i386-core/root >>> groupinstall build-minimal build-base build >>> > http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/python-2.4.3-3.i386.rpm: >>> [Errno 4] Socket Error: (11, 'Resource temporarily >>> unavailable') >>> Trying other mirror. >>> Error: failure: >> Fedora/RPMS/python-2.4.3-3.i386.rpm >>> from core: [Errno 256] No more mirrors to try. >> I'd strongly consider using a local mirror, or at >> least a decent cache >> as suggested on the MockTricks wiki page. > I already did all things from that page. I added all > 3 rules then started squid and also i added http_proxy > variable in .bash_profile. > Still getting error. How to build local > repo/mirror and then how can i use it in build user > environment?? See here for creating a local mirror: http://fedoraproject.org/wiki/Projects/fedora-mirror Once you've built your mirror (don't forget to keep the updates mirror updated, e.g. using a cron job), you just change the baseurl entries in /etc/mock/*.cfg from the default ones to use your local mirrors instead. Paul. From cranium2003 at yahoo.com Tue Jun 6 11:23:11 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 04:23:11 -0700 (PDT) Subject: unable to use mock In-Reply-To: <44856287.4030406@city-fan.org> Message-ID: <20060606112311.49970.qmail@web38008.mail.mud.yahoo.com> Hi, Facing problem in usinf python script from http://fedoraproject.org/wiki/Projects/fedora-mirror [root at buildsys source]# python fedora-mirror.py syncing: Fedora development core i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development core i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development core x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development core x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development core ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development core ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora development extras ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 core ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 extras ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 updates-testing ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy i386 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy x86_64 source to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: No such file or directory syncing: Fedora 5 legacy ppc source to /srv/mirror sh: /usr/bin/reposync: No such file or directory [root at buildsys source]# rep replace repquota Then i downloaded reposync.py from yum-utils cvs and then i did [root at buildsys source]# mv /root/Desktop/reposync.py /usr/bin/reposync [root at buildsys source]# python fedora-mirror.py syncing: Fedora development core i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development core i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development core x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development core x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development core ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development core ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora development extras ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 core ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 extras ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 updates-testing ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy i386 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy i386 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy x86_64 debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy x86_64 source to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy ppc debuginfo to /srv/mirror sh: /usr/bin/reposync: Permission denied syncing: Fedora 5 legacy ppc source to /srv/mirror sh: /usr/bin/reposync: Permission denied whats problem here? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From buildsys at fedoraproject.org Tue Jun 6 11:17:45 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 6 Jun 2006 07:17:45 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-06 Message-ID: <20060606111745.C36C3152151@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 31 AGReader-1.2-1.fc5 R-mAr-1.1-5.fc5 R-waveslim-1.5-3.fc5 R-wavethresh-2.2-3.fc5 gajim-0.10.1-1.fc5 gnome-themes-extras-0.9.0-3.fc5 graveman-0.3.12.5-1.fc5 gtkglextmm-1.2.0-4.fc5 htmldoc-1.8.26-4.fc5 kdesvn-0.8.4-1.fc5 libeXosip2-2.2.3-2.fc5 libxfcegui4-4.2.3-5.fc5 lua-5.1-5.fc5 nagios-2.4-1.fc5 neXtaw-0.15.1-9.fc5 perl-File-Find-Rule-0.30-1.fc5 perl-Params-Validate-0.84-1.fc5 qgit-1.3-1.fc5 renrot-0.20-2.fc5 rpy-0.4.6-11.fc5 rrdtool-1.0.50-3.fc5 sylpheed-claws-2.2.1-1.fc5 tolua++-1.0.92-3.fc5 ucblogo-5.5-3.fc5 v2strip-0.2.10-2.fc5 wine-0.9.14-1.fc5 xbase-2.0.0-5.fc5 xbsql-0.11-6.fc5 xfce-utils-4.2.3-4.fc5 xfce4-panel-4.2.3-4.fc5 xfdesktop-4.2.3-4.fc5 Packages built and released for Fedora Extras 4: 30 AGReader-1.2-1.fc4 R-mAr-1.1-5.fc4 R-waveslim-1.5-3.fc4 R-wavethresh-2.2-3.fc4 gnome-themes-extras-0.9.0-3.fc4 graveman-0.3.12.5-1.fc4 htmldoc-1.8.26-4.fc4.1 kdesvn-0.8.4-1.fc4 libeXosip2-2.2.3-2.fc4 libxfcegui4-4.2.3-3.fc4 lua-5.1-5.fc4 nagios-2.4-1.fc4 paraview-2.4.3-7.fc4 perl-File-Find-Rule-0.30-1.fc4 perl-Params-Validate-0.84-1.fc4 qgit-1.3-1.fc4 renrot-0.20-2.fc4 rpy-0.4.6-11.fc4 scim-bridge-0.1.12-1.fc4.1 sylpheed-claws-2.2.1-1.fc4 sylpheed-claws-plugins-2.2.0-1.fc4 tolua++-1.0.92-3.fc4 ucblogo-5.5-3.fc4 v2strip-0.2.10-2.fc4 wine-0.9.14-1.fc4 xbase-2.0.0-5.fc4 xbsql-0.11-6.fc4 xfce-utils-4.2.3-2.fc4 xfce4-panel-4.2.3-2.fc4 xfdesktop-4.2.3-2.fc4 Packages built and released for Fedora Extras 3: 3 nagios-2.4-1.fc3 perl-File-Find-Rule-0.30-1.fc3 wine-0.9.14-1.fc3 Packages built and released for Fedora Extras development: 35 AGReader-1.2-1.fc6 OpenSceneGraph-1.0-3.fc6 ctorrent-1.3.2-3.fc6 dssi-0.9.1-7.fc6 fuse-emulator-utils-0.7.0-4.fc6 gajim-0.10.1-1.fc6 gdome2-0.8.1-4.fc6 gnome-themes-extras-0.9.0-3.fc6 gnome-yum-0.1.3-3.fc6 graveman-0.3.12.5-1.fc6 gtkglextmm-1.2.0-4.fc6 libeXosip2-2.2.3-2.fc6 libxfcegui4-4.2.3-5.fc6 lua-5.1-5.fc6 nagios-2.4-1.fc6 nagios-plugins-1.4.3-5.fc6 neXtaw-0.15.1-9.fc6 perl-File-Find-Rule-0.30-1.fc6 perl-PPI-1.115-2.fc6 perl-Params-Validate-0.84-1.fc6 plib-1.8.4-5.fc6 qgit-1.3-1.fc6 rrdtool-1.2.13-3.fc6 scite-1.69-3.fc6 sunifdef-1.0.1-4.fc6 sylpheed-claws-2.2.1-1.fc6 syslog-ng-1.6.11-2.fc6 tolua++-1.0.92-3.fc6 v2strip-0.2.10-2.fc6 wine-0.9.14-1.fc6 xbase-2.0.0-5.fc6 xbsql-0.11-6.fc6 xfce-utils-4.2.3-4.fc6 xfce4-panel-4.2.3-4.fc6 xfdesktop-4.2.3-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From cranium2003 at yahoo.com Tue Jun 6 11:32:10 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 04:32:10 -0700 (PDT) Subject: unable to use mock In-Reply-To: <20060606112311.49970.qmail@web38008.mail.mud.yahoo.com> Message-ID: <20060606113210.53028.qmail@web38008.mail.mud.yahoo.com> Hi, --- cranium2003 wrote: > Hi, > Facing problem in usinf python script from > http://fedoraproject.org/wiki/Projects/fedora-mirror > > [root at buildsys source]# python fedora-mirror.py > syncing: Fedora development core i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core i386 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core ppc source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras i386 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras x86_64 debuginfo > to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development extras ppc source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core i386 debuginfo to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core i386 source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core x86_64 source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core ppc debuginfo to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 core ppc source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras i386 source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 extras ppc source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates i386 source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates ppc source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing i386 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing x86_64 debuginfo > to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 updates-testing ppc source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy i386 source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora 5 legacy ppc source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > [root at buildsys source]# rep > replace repquota > Then i downloaded reposync.py from yum-utils cvs > and > then i did > [root at buildsys source]# mv /root/Desktop/reposync.py > /usr/bin/reposync > [root at buildsys source]# python fedora-mirror.py > syncing: Fedora development core i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development core i386 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development core x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development core x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development core ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development core ppc source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras i386 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras x86_64 debuginfo > to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora development extras ppc source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core i386 debuginfo to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core i386 source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core x86_64 source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core ppc debuginfo to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 core ppc source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras i386 source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 extras ppc source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates i386 source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates ppc source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing i386 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing x86_64 debuginfo > to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 updates-testing ppc source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy i386 source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy x86_64 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy x86_64 source to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy ppc debuginfo to > /srv/mirror > sh: /usr/bin/reposync: Permission denied > syncing: Fedora 5 legacy ppc source to /srv/mirror > sh: /usr/bin/reposync: Permission denied > > whats problem here? Oops sorry its permission problem but still after resolving it i am getting python fedora-mirror.py (i made to build only i386) ============================================================= syncing: Fedora development core i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora development core i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora development extras i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora development extras i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 core i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 core i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 extras i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 extras i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates-testing i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates-testing i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 legacy i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 legacy i386 source to /srv/mirror No Repositories Available to Set Up ================================================== Also what flavours i need only from following line?? flavourlist=["core", "extras", "updates", "updates-testing", "legacy"] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Tue Jun 6 11:31:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 06 Jun 2006 12:31:48 +0100 Subject: unable to use mock In-Reply-To: <20060606112311.49970.qmail@web38008.mail.mud.yahoo.com> References: <20060606112311.49970.qmail@web38008.mail.mud.yahoo.com> Message-ID: <448567A4.5090105@city-fan.org> cranium2003 wrote: > Hi, > Facing problem in usinf python script from > http://fedoraproject.org/wiki/Projects/fedora-mirror > > [root at buildsys source]# python fedora-mirror.py > syncing: Fedora development core i386 debuginfo to > /srv/mirror > sh: /usr/bin/reposync: No such file or directory > syncing: Fedora development core i386 source to > /srv/mirror (snip) > syncing: Fedora 5 legacy ppc source to /srv/mirror > sh: /usr/bin/reposync: No such file or directory > [root at buildsys source]# rep > replace repquota > Then i downloaded reposync.py from yum-utils cvs and > then i did > [root at buildsys source]# mv /root/Desktop/reposync.py > /usr/bin/reposync (snip) > whats problem here? Why not install yum-utils, which includes reposync? Paul. From buildsys at fedoraproject.org Tue Jun 6 11:33:21 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 06 Jun 2006 11:33:21 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-06 Message-ID: <20060606113321.1862.52781@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Tue Jun 6 11:33:21 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 06 Jun 2006 11:33:21 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-06 Message-ID: <20060606113321.1869.91018@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc4.i386 plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc4.ppc plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc4.x86_64 plague 0.4.4.1-1.fc4.noarch ====================================================================== New report for: rdieter AT math.unl.edu package: kphotoalbum - 2.2-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libexiv2-0.9.1.so package: kphotoalbum - 2.2-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libexiv2-0.9.1.so()(64bit) package: kphotoalbum - 2.2-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libexiv2-0.9.1.so ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Tue Jun 6 11:33:21 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 06 Jun 2006 11:33:21 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-06 Message-ID: <20060606113321.1877.9515@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 nagios-plugins-ntp 1.4.3-5.fc6.i386 php-rrdtool 1.0.49-5.fc4.i386 rpy 0.4.6-10.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc nagios-plugins-ntp 1.4.3-5.fc6.ppc nagios-plugins-sensors 1.4.3-5.fc6.ppc php-rrdtool 1.0.49-5.fc4.ppc rpy 0.4.6-10.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 nagios-plugins-ntp 1.4.3-5.fc6.x86_64 php-rrdtool 1.0.49-5.fc4.x86_64 rpy 0.4.6-10.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: matthias AT rpmforge.net package: php-rrdtool - 1.0.49-5.fc4.i386 from fedora-extras-development-i386 unresolved deps: librrd.so.0 rrdtool = 0:1.0.49 package: php-rrdtool - 1.0.49-5.fc4.x86_64 from fedora-extras-development-x86_64 unresolved deps: librrd.so.0()(64bit) rrdtool = 0:1.0.49 package: php-rrdtool - 1.0.49-5.fc4.ppc from fedora-extras-development-ppc unresolved deps: librrd.so.0 rrdtool = 0:1.0.49 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-ntp - 1.4.3-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr/sbin/ntpc package: nagios-plugins-ntp - 1.4.3-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/sbin/ntpc package: nagios-plugins-ntp - 1.4.3-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/sbin/ntpc package: nagios-plugins-sensors - 1.4.3-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors ====================================================================== New report for: jamatos AT fc.up.pt package: rpy - 0.4.6-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: R = 0:2.3.0 package: rpy - 0.4.6-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: R = 0:2.3.0 package: rpy - 0.4.6-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: R = 0:2.3.0 ====================================================================== package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Tue Jun 6 11:33:21 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 06 Jun 2006 11:33:21 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-06 Message-ID: <20060606113321.1873.93408@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc5.i386 libopensync-plugin-evolution2 0.18-6.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc5.ppc libopensync-plugin-evolution2 0.18-6.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc5.x86_64 libopensync-plugin-evolution2 0.18-6.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-evolution2 - 0.18-6.fc5.i386 from fedora-extras-5-i386 unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 package: libopensync-plugin-evolution2 - 0.18-6.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libedata-cal-1.2.so.1()(64bit) libecal-1.2.so.3()(64bit) package: libopensync-plugin-evolution2 - 0.18-6.fc5.ppc from fedora-extras-5-ppc unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 ====================================================================== New report for: rdieter AT math.unl.edu package: kphotoalbum - 2.2-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libexiv2-0.9.1.so package: kphotoalbum - 2.2-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libexiv2-0.9.1.so()(64bit) package: kphotoalbum - 2.2-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libexiv2-0.9.1.so ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From cranium2003 at yahoo.com Tue Jun 6 11:51:50 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Tue, 6 Jun 2006 04:51:50 -0700 (PDT) Subject: unable to use mock In-Reply-To: <448567A4.5090105@city-fan.org> Message-ID: <20060606115150.83875.qmail@web38010.mail.mud.yahoo.com> Hi Paul, I did yum install yum-utils and then python fedora-mirror.py syncing: Fedora development core i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora development core i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora development extras i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora development extras i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 core i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 core i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 extras i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 extras i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates-testing i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 updates-testing i386 source to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 legacy i386 debuginfo to /srv/mirror No Repositories Available to Set Up syncing: Fedora 5 legacy i386 source to /srv/mirror No Repositories Available to Set Up whats that mean?? my fedora-mirror.py attached here. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-mirror.py Type: text/x-python Size: 4751 bytes Desc: 2058674682-fedora-mirror.py URL: From toshio at tiki-lounge.com Tue Jun 6 16:54:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 09:54:20 -0700 Subject: Hula -- mixed mono package Message-ID: <1149612860.3413.18.camel@localhost> I'm working on updating the hula spec to the latest version and found that some of the programs within hula now depend on mono. The install currently puts the mono packages in /usr/lib/hula and the normal binaries and libs into %{_libdir} which appears to be the expected outcome. However, it has a helper application hulamonohelper that drops privileges from the server before invoking the mono applications. This is installed in /usr/lib/hula rather than %{_libdir}/hula or %{_libexecdir}/hula. Should I change this or is it actually an allowable practice for mono apps? -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 danjones at us.ibm.com Tue Jun 6 17:31:13 2006 From: danjones at us.ibm.com (Daniel H Jones) Date: Tue, 6 Jun 2006 12:31:13 -0500 Subject: rpmlint warnings/errors Message-ID: I'm receiving various rpmlint warnings/errors but I believe the package is correct and the warning should be disregarded. Is it sufficient to provide some explanation of the warning when a package is submitted? I have not found a list of acceptable/unacceptable rpmlint issues. W: opencryptoki devel-file-in-non-devel-package /usr/lib/libopencryptoki.so E: opencryptoki non-standard-gid /var/lib/opencryptoki pkcs11 W: opencryptoki service-default-enabled /etc/rc.d/init.d/pkcsslotd W: opencryptoki incoherent-init-script-name pkcsslotd Thanks, Dan Jones danjones at us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Tue Jun 6 17:46:31 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 12:46:31 -0500 Subject: rpmlint warnings/errors In-Reply-To: (Daniel H. Jones's message of "Tue, 6 Jun 2006 12:31:13 -0500") References: Message-ID: >>>>> "DHJ" == Daniel H Jones writes: DHJ> Is it sufficient to provide some explanation of the warning when DHJ> a package is submitted? It would help the reviewer if you did so. DHJ> I have not found a list of acceptable/unacceptable rpmlint DHJ> issues. http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues (just getting started). You're free to add things there. Make sure you run "rpmlint -i" if you just need additional information about what rpmlint is complaining about. DHJ> W: opencryptoki devel-file-in-non-devel-package DHJ> /usr/lib/libopencryptoki.so Do you have a versioned .so file there as well (i.e. libopencryptoki.so.1.2)? If so, this is a blocker. DHJ> E: opencryptoki non-standard-gid DHJ> /var/lib/opencryptoki pkcs11 Not a blocker, assuming you properly create that user. DHJ> W: opencryptoki DHJ> service-default-enabled /etc/rc.d/init.d/pkcsslotd This is a blocker. Packages should not install services which are turned on by default; otherwise, someone who installs a bunch of packages ends up with a bunch of enabled services. (Imagine the theoretical "Everything" install.) DHJ> W: opencryptoki incoherent-init-script-name pkcsslotd It helps if the init file is named in such a way that it is associated with the package, but this is not always reasonable. - J< From paul at all-the-johnsons.co.uk Tue Jun 6 17:41:51 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 Jun 2006 18:41:51 +0100 Subject: Hula -- mixed mono package In-Reply-To: <1149612860.3413.18.camel@localhost> References: <1149612860.3413.18.camel@localhost> Message-ID: <1149615711.19529.1.camel@T7.Linux> Hi, > I'm working on updating the hula spec to the latest version and found > that some of the programs within hula now depend on mono. The install > currently puts the mono packages in /usr/lib/hula and the normal > binaries and libs into %{_libdir} which appears to be the expected > outcome. However, it has a helper application hulamonohelper that drops > privileges from the server before invoking the mono applications. This > is installed in /usr/lib/hula rather than %{_libdir}/hula or > %{_libexecdir}/hula. Should I change this or is it actually an > allowable practice for mono apps? Add to the top of the spec %define _libdir %{_exec_prefix}/lib compile and be happy - mono is a strange beast, accept where it goes and when you use rpmlint, you can ignore quite a lot of the errors as rpmlint doesn't understand mono and it's packaging. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Tue Jun 6 17:54:09 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 12:54:09 -0500 Subject: Hula -- mixed mono package In-Reply-To: <1149615711.19529.1.camel@T7.Linux> (paul@all-the-johnsons.co.uk's message of "Tue, 06 Jun 2006 18:41:51 +0100") References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> Message-ID: >>>>> "p" == paul writes: p> Add to the top of the spec p> %define _libdir %{_exec_prefix}/lib p> compile and be happy I'm not so sure. It's true that mono libraries need to live in /usr/lib even on x86_64 (although I admit to not understanding the reasons), but I'm not sure if it's a good idea to put the non-mono parts of a mixed package there as well. So you shouldn't just blindly redefine %{_libdir}. - J< From toshio at tiki-lounge.com Tue Jun 6 18:07:22 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 11:07:22 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149615711.19529.1.camel@T7.Linux> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> Message-ID: <1149617243.3413.31.camel@localhost> On Tue, 2006-06-06 at 18:41 +0100, Paul wrote: > Hi, > > > I'm working on updating the hula spec to the latest version and found > > that some of the programs within hula now depend on mono. The install > > currently puts the mono packages in /usr/lib/hula and the normal > > binaries and libs into %{_libdir} which appears to be the expected > > outcome. However, it has a helper application hulamonohelper that drops > > privileges from the server before invoking the mono applications. This > > is installed in /usr/lib/hula rather than %{_libdir}/hula or > > %{_libexecdir}/hula. Should I change this or is it actually an > > allowable practice for mono apps? > > Add to the top of the spec > > %define _libdir %{_exec_prefix}/lib > > compile and be happy - mono is a strange beast, accept where it goes and > when you use rpmlint, you can ignore quite a lot of the errors as > rpmlint doesn't understand mono and it's packaging. > That won't work. This is a mixed package. Some mono .exe/.dll's and some ELF libs/programs. The upstream hula install seems to be doing the right thing by putting mono .exe/.dll's into /usr/lib/hula and the ELF .so libs into %{_libdir}. But there is one ELF program hulamonohelper that is being put into /usr/lib/hula along with the mono .exe/.dll's. My question is whether I should try to move that program around to a different location since it's going to be a 64bit binary on an x86_64. (Hmmm... and on Fedora it should probably go to %{_libexecdir} rather than %{_libdir}) Also -- a bit more explanation of why mono apps need to go in /usr/lib is in order b/c the Core packages tomboy and beagle end up in /usr/lib64/ on an x86_64. -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 gemi at bluewin.ch Tue Jun 6 18:13:45 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 06 Jun 2006 20:13:45 +0200 Subject: Reverting package to a previous Message-ID: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> Hi, I updated the erlang package to the latest version (R10B->R11B). However it the packages erlang-esdl, and thus, wings do not work correctly. How can I downgrade to the previous version? I know that this has sometimes been done with Core packages, probably using Epoch. If so, what is the procedure for CVS? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From katzj at redhat.com Tue Jun 6 18:43:16 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jun 2006 14:43:16 -0400 Subject: Hula -- mixed mono package In-Reply-To: <1149617243.3413.31.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> Message-ID: <1149619397.10941.0.camel@orodruin.boston.redhat.com> On Tue, 2006-06-06 at 11:07 -0700, Toshio Kuratomi wrote: > My question is whether I should try to move that program around to a > different location since it's going to be a 64bit binary on an x86_64. > (Hmmm... and on Fedora it should probably go to %{_libexecdir} rather > than %{_libdir}) Yeah, libexecdir sounds sane for this. Jeremy From paul at all-the-johnsons.co.uk Tue Jun 6 18:50:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 Jun 2006 19:50:23 +0100 Subject: Hula -- mixed mono package In-Reply-To: References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> Message-ID: <1149619823.19529.6.camel@T7.Linux> Hi, > p> Add to the top of the spec > > p> %define _libdir %{_exec_prefix}/lib > > p> compile and be happy > > I'm not so sure. It's true that mono libraries need to live in > /usr/lib even on x86_64 (although I admit to not understanding the > reasons), but I'm not sure if it's a good idea to put the non-mono > parts of a mixed package there as well. So you shouldn't just blindly > redefine %{_libdir}. From many hours of trying to get things to work with mono packaging, I've found this to be the only sure fire way to ensure that everything works happily with both x86 and x64_64 bit architectures. TTFN Paul "why won't someone please review my packages" Johnson -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Tue Jun 6 18:55:38 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 13:55:38 -0500 Subject: Reverting package to a previous In-Reply-To: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> =?iso-8859-1?q?=28G=E9rard?= Milmeister's message of "Tue, 06 Jun 2006 20:13:45 +0200") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> Message-ID: >>>>> "GM" == G?rard Milmeister writes: GM> I updated the erlang package to the latest version GM> (R10B->R11B). However it the packages erlang-esdl, and thus, wings GM> do not work correctly. Ouch. GM> How can I downgrade to the previous version? You have to release a new package that has a higher epoch:version:release triple than the old package. So you can either increase the epoch, or lie about the version. GM> If so, what is the procedure for CVS? Hmmm. It doesn't look like the epoch is included in the CVS tags. I wonder how well it will work in practice. Anyway, to include an epoch, just add "Epoch: 1" to your spec. But keep in mind that you'll have to keep it around forever. - J< From tibbs at math.uh.edu Tue Jun 6 18:57:48 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 13:57:48 -0500 Subject: Hula -- mixed mono package In-Reply-To: <1149619823.19529.6.camel@T7.Linux> (paul@all-the-johnsons.co.uk's message of "Tue, 06 Jun 2006 19:50:23 +0100") References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149619823.19529.6.camel@T7.Linux> Message-ID: >>>>> "p" == paul writes: p> Paul "why won't someone please review my packages" Johnson Note that I'm not reviewing them because they do things like redefine _libdir. Catch 22, I know, but I can't review what I don't understand. - J< From paul at all-the-johnsons.co.uk Tue Jun 6 18:59:08 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 Jun 2006 19:59:08 +0100 Subject: Hula -- mixed mono package In-Reply-To: <1149617243.3413.31.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> Message-ID: <1149620348.19529.15.camel@T7.Linux> Hi, > > compile and be happy - mono is a strange beast, accept where it goes and > > when you use rpmlint, you can ignore quite a lot of the errors as > > rpmlint doesn't understand mono and it's packaging. > > > That won't work. This is a mixed package. Some mono .exe/.dll's and > some ELF libs/programs. > > The upstream hula install seems to be doing the right thing by putting > mono .exe/.dll's into /usr/lib/hula and the ELF .so libs into > %{_libdir}. Which is correct. You'll find that if you run the spec, if you don't redefine libdir and are on a 64 bit system, then the mono stuff will probably end up a bit messed (I don't know the package, so it's possible the .pc file ends up in /usr/lib64/pkgconfig with the mono stuff also being there or it may all be in /usr/lib) > But there is one ELF program hulamonohelper that is being > put into /usr/lib/hula along with the mono .exe/.dll's. That sounds very odd - is there a symlink back to bindir? > My question is whether I should try to move that program around to a > different location since it's going to be a 64bit binary on an x86_64. > (Hmmm... and on Fedora it should probably go to %{_libexecdir} rather > than %{_libdir}) I wouldn't. If everything is in /usr/lib/hula then it should all be happy. As Jeremy has said though libexecdir does sound sane, but it might not. Are you running a 64 bit system currently (I'm happy to try the package here) or is it available as a BZ FE review package? > Also -- a bit more explanation of why mono apps need to go in /usr/lib > is in order b/c the Core packages tomboy and beagle end up > in /usr/lib64/ on an x86_64. They don't need to go in there. However, if you have a package which builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ] amongst others), the configure script may not pick them up correctly. By having them all in /usr/lib, you can be assured that the package will be found. It's not the best way of doing things, but until things become saner with mono and how it's set up and how it looks for things... TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Tue Jun 6 19:07:03 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 12:07:03 -0700 Subject: Reverting package to a previous In-Reply-To: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> Message-ID: <1149620823.3413.52.camel@localhost> On Tue, 2006-06-06 at 20:13 +0200, G?rard Milmeister wrote: > Hi, > I updated the erlang package to the latest version (R10B->R11B). However > it the packages erlang-esdl, and thus, wings do not work correctly. > How can I downgrade to the previous version? I know that this has > sometimes been done with Core packages, probably using Epoch. If so, > what is the procedure for CVS? Is this just in devel or also in FC5,4,X? Do we have a policy that Extras-devel must always upgrade cleanly or can we revert things like this without bumping epoch? -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 gemi at bluewin.ch Tue Jun 6 19:16:14 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 06 Jun 2006 21:16:14 +0200 Subject: Reverting package to a previous In-Reply-To: References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> Message-ID: <1149621374.28636.1.camel@scriabin.tannenrauch.ch> On Tue, 2006-06-06 at 13:55 -0500, Jason L Tibbitts III wrote: > >>>>> "GM" == G?rard Milmeister writes: > > GM> I updated the erlang package to the latest version > GM> (R10B->R11B). However it the packages erlang-esdl, and thus, wings > GM> do not work correctly. > > Ouch. You describe exactly my feelings :-( > GM> How can I downgrade to the previous version? > > You have to release a new package that has a higher > epoch:version:release triple than the old package. So you can either > increase the epoch, or lie about the version. > > GM> If so, what is the procedure for CVS? > > Hmmm. It doesn't look like the epoch is included in the CVS tags. I > wonder how well it will work in practice. > > Anyway, to include an epoch, just add "Epoch: 1" to your spec. But > keep in mind that you'll have to keep it around forever. Yes, that's the downside. I could wait for the problem to be resolved in esdl and wings. There seems to be an awareness of this, however nothing happened yet. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From tibbs at math.uh.edu Tue Jun 6 19:28:13 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 14:28:13 -0500 Subject: Reverting package to a previous In-Reply-To: <1149620823.3413.52.camel@localhost> (Toshio Kuratomi's message of "Tue, 06 Jun 2006 12:07:03 -0700") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149620823.3413.52.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> Is this just in devel or also in FC5,4,X? Everything from FE3 to devel, it seems. TK> Do we have a policy that Extras-devel must always upgrade cleanly TK> or can we revert things like this without bumping epoch? With -devel I think it might be OK, but for the release branches I think we have to hold ourselves to the same standards we'd expect from Core. - J< From toshio at tiki-lounge.com Tue Jun 6 19:29:56 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 12:29:56 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149620348.19529.15.camel@T7.Linux> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> Message-ID: <1149622197.3413.64.camel@localhost> On Tue, 2006-06-06 at 19:59 +0100, Paul wrote: > Hi, > > > > compile and be happy - mono is a strange beast, accept where it goes and > > > when you use rpmlint, you can ignore quite a lot of the errors as > > > rpmlint doesn't understand mono and it's packaging. > > > > > That won't work. This is a mixed package. Some mono .exe/.dll's and > > some ELF libs/programs. > > > > The upstream hula install seems to be doing the right thing by putting > > mono .exe/.dll's into /usr/lib/hula and the ELF .so libs into > > %{_libdir}. > > Which is correct. You'll find that if you run the spec, if you don't > redefine libdir and are on a 64 bit system, then the mono stuff will > probably end up a bit messed (I don't know the package, so it's possible > the .pc file ends up in /usr/lib64/pkgconfig with the mono stuff also > being there or it may all be in /usr/lib) > Okay. So the pkgconfig is in /usr/lib64/pkgconfig. And it references /usr/lib64/hula which is wrong. So that will have to be changed. Anything else you can think of? > > But there is one ELF program hulamonohelper that is being > > put into /usr/lib/hula along with the mono .exe/.dll's. > > That sounds very odd - is there a symlink back to bindir? > Nope. It is invoked directly from two scripts that hula installs into %{_sbindir}. > > My question is whether I should try to move that program around to a > > different location since it's going to be a 64bit binary on an x86_64. > > (Hmmm... and on Fedora it should probably go to %{_libexecdir} rather > > than %{_libdir}) > > I wouldn't. If everything is in /usr/lib/hula then it should all be > happy. As Jeremy has said though libexecdir does sound sane, but it > might not. Are you running a 64 bit system currently (I'm happy to try > the package here) or is it available as a BZ FE review package? > It sounds like at least pkg-config is not happy. Leaving it in /usr/lib/hula is wrong as it's potentially a 64bit binary in the 32-bit directory. I'm running 64 bit but would be happy if you took a look as well. hula is an orphaned package so it's in cvs. I've checked my changes in to hula/devel. Just don't try to build it as it's still in flux :-) > > Also -- a bit more explanation of why mono apps need to go in /usr/lib > > is in order b/c the Core packages tomboy and beagle end up > > in /usr/lib64/ on an x86_64. > > They don't need to go in there. However, if you have a package which > builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ] > amongst others), the configure script may not pick them up correctly. By > having them all in /usr/lib, you can be assured that the package will be > found. It's not the best way of doing things, but until things become > saner with mono and how it's set up and how it looks for things... So it sounds like using %{_libdir} won't affect the immediate package but it will affect anything that tries to use it when they build. I've updated the wiki. Feel free to modify it if I got it wrong. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Tue Jun 6 19:30:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 14:30:11 -0500 Subject: Reverting package to a previous In-Reply-To: <1149621374.28636.1.camel@scriabin.tannenrauch.ch> =?iso-8859-1?q?=28G=E9rard?= Milmeister's message of "Tue, 06 Jun 2006 21:16:14 +0200") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> Message-ID: >>>>> "GM" == G?rard Milmeister writes: GM> I could wait for the problem to be resolved in esdl and GM> wings. I guess it depends on how bad the breakage is. It may be safe to wait a few days to avoid further pain all around. How many bug reports have you received? - J< From toshio at tiki-lounge.com Tue Jun 6 19:33:48 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 12:33:48 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149622197.3413.64.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149622197.3413.64.camel@localhost> Message-ID: <1149622428.3413.65.camel@localhost> On Tue, 2006-06-06 at 12:29 -0700, Toshio Kuratomi wrote: > I'm running 64 bit but would be happy if you took a look as well. hula > is an orphaned package so it's in cvs. I've checked my changes in to > hula/devel. Just don't try to build it as it's still in flux :-) Err.. Checking my changes into cvs. As we speak. :-) -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 paul at all-the-johnsons.co.uk Tue Jun 6 19:37:33 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 Jun 2006 20:37:33 +0100 Subject: Hula -- mixed mono package In-Reply-To: <1149622197.3413.64.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149622197.3413.64.camel@localhost> Message-ID: <1149622653.19529.24.camel@T7.Linux> Hi, > > > The upstream hula install seems to be doing the right thing by putting > > > mono .exe/.dll's into /usr/lib/hula and the ELF .so libs into > > > %{_libdir}. > > > > Which is correct. You'll find that if you run the spec, if you don't > > redefine libdir and are on a 64 bit system, then the mono stuff will > > probably end up a bit messed (I don't know the package, so it's possible > > the .pc file ends up in /usr/lib64/pkgconfig with the mono stuff also > > being there or it may all be in /usr/lib) > > > Okay. So the pkgconfig is in /usr/lib64/pkgconfig. And it > references /usr/lib64/hula which is wrong. So that will have to be > changed. Anything else you can think of? If pkgconfig is in /usr/lib64, it normally points to things in /usr/lib64 - so if you move the .pc file to /usr/lib, so must everything else. You now can see why explictly setting libdir is important! > > > But there is one ELF program hulamonohelper that is being > > > put into /usr/lib/hula along with the mono .exe/.dll's. > > > > That sounds very odd - is there a symlink back to bindir? > > > Nope. It is invoked directly from two scripts that hula installs into > %{_sbindir}. Same difference - thanks. > > I wouldn't. If everything is in /usr/lib/hula then it should all be > > happy. As Jeremy has said though libexecdir does sound sane, but it > > might not. Are you running a 64 bit system currently (I'm happy to try > > the package here) or is it available as a BZ FE review package? > > > It sounds like at least pkg-config is not happy. Leaving it > in /usr/lib/hula is wrong as it's potentially a 64bit binary in the > 32-bit directory. I'm not sure what the rules are concerning 64 bit stuff in /usr/lib, but I don't recall seeing anything prohibiting it. > I'm running 64 bit but would be happy if you took a look as well. hula > is an orphaned package so it's in cvs. I've checked my changes in to > hula/devel. Just don't try to build it as it's still in flux :-) ;-) > > > Also -- a bit more explanation of why mono apps need to go in /usr/lib > > > is in order b/c the Core packages tomboy and beagle end up > > > in /usr/lib64/ on an x86_64. > > > > They don't need to go in there. However, if you have a package which > > builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ] > > amongst others), the configure script may not pick them up correctly. By > > having them all in /usr/lib, you can be assured that the package will be > > found. It's not the best way of doing things, but until things become > > saner with mono and how it's set up and how it looks for things... > > So it sounds like using %{_libdir} won't affect the immediate package > but it will affect anything that tries to use it when they build. I've > updated the wiki. Feel free to modify it if I got it wrong. Yep, seen the update - looks fine to me. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gemi at bluewin.ch Tue Jun 6 19:42:13 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 06 Jun 2006 21:42:13 +0200 Subject: Reverting package to a previous In-Reply-To: References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> Message-ID: <1149622933.32491.4.camel@scriabin.tannenrauch.ch> On Tue, 2006-06-06 at 14:30 -0500, Jason L Tibbitts III wrote: > >>>>> "GM" == G?rard Milmeister writes: > > GM> I could wait for the problem to be resolved in esdl and > GM> wings. > > I guess it depends on how bad the breakage is. It may be safe to wait > a few days to avoid further pain all around. In fact, I already waited some time, but finally felt, that I could not leave the situation as it is. I periodically check the website of wings and esdl, however it seems that they are not eager to jump to erlang R11B. > How many bug reports > have you received? One, it may of course be possible that others searched for it. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From i.pilcher at comcast.net Tue Jun 6 19:47:46 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 06 Jun 2006 14:47:46 -0500 Subject: Reverting package to a previous In-Reply-To: References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149620823.3413.52.camel@localhost> Message-ID: Jason L Tibbitts III wrote: > With -devel I think it might be OK, but for the release branches I > think we have to hold ourselves to the same standards we'd expect from > Core. Oh come on, we can do better than that! ;-) -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From tibbs at math.uh.edu Tue Jun 6 20:18:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 15:18:36 -0500 Subject: Reverting package to a previous In-Reply-To: <1149622933.32491.4.camel@scriabin.tannenrauch.ch> =?iso-8859-1?q?=28G=E9rard?= Milmeister's message of "Tue, 06 Jun 2006 21:42:13 +0200") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> Message-ID: >>>>> "GM" == G?rard Milmeister writes: GM> In fact, I already waited some time, but finally felt, that I GM> could not leave the situation as it is. Then there is another possibility. Keep the regular erlang packages as is and release "erlangR10B" packages. The update wings3d and erlang_sdl and any other packages that rely on the old erlang version to depend (and link against) on this new package. - J< From toshio at tiki-lounge.com Tue Jun 6 20:29:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 13:29:50 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149622653.19529.24.camel@T7.Linux> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149622197.3413.64.camel@localhost> <1149622653.19529.24.camel@T7.Linux> Message-ID: <1149625790.3413.77.camel@localhost> On Tue, 2006-06-06 at 20:37 +0100, Paul wrote: > > Okay. So the pkgconfig is in /usr/lib64/pkgconfig. And it > > references /usr/lib64/hula which is wrong. So that will have to be > > changed. Anything else you can think of? > > If pkgconfig is in /usr/lib64, it normally points to things > in /usr/lib64 - so if you move the .pc file to /usr/lib, so must > everything else. > > You now can see why explictly setting libdir is important! It would make it easier :-) It still can't be done for this package, though, for the reasons given. When you check out the sources, I think you'll see what I mean. 64bit programs might be okay in %{_libdir} as they aren't multilib. If it won't hurt, I'd be happier moving it out to libexec, though. Since the library has 64 bit libraries, I'm in no position to set %{_libdir} to /usr/lib on x86_64 and will have to figure out all the brokenness and fix it instead. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gemi at bluewin.ch Tue Jun 6 20:37:44 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 06 Jun 2006 22:37:44 +0200 Subject: Reverting package to a previous In-Reply-To: References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> Message-ID: <1149626264.6438.2.camel@scriabin.tannenrauch.ch> On Tue, 2006-06-06 at 15:18 -0500, Jason L Tibbitts III wrote: > >>>>> "GM" == G?rard Milmeister writes: > > GM> In fact, I already waited some time, but finally felt, that I > GM> could not leave the situation as it is. > > Then there is another possibility. Keep the regular erlang packages > as is and release "erlangR10B" packages. The update wings3d and > erlang_sdl and any other packages that rely on the old erlang version > to depend (and link against) on this new package. That would make sense, since it seems that there are really incompatible changes between R10B and R11B. Does this mean that a completely new package has to be imported into CVS? Almost all files reside in %{_libdir}/erlang. Without patching one could use then ${_libdir}/erlang10B/erlang. Using simply %{_libdir}/erlang10B is probably more difficult, since this would entail some patching. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From orion at cora.nwra.com Tue Jun 6 21:10:17 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 06 Jun 2006 15:10:17 -0600 Subject: Running rpm inside mock's chroot Message-ID: <4485EF39.6010901@cora.nwra.com> Sometimes it it useful to chroot into mock's root to test out a failed build. However, on my FC5 x86_64 box, after chrooting to the root, rpm fails with: bash-3.1# rpm -qa rpmdb: Program version 4.3 doesn't match environment version error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm Any ideas why? It works after I delete the __db* files. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ville.skytta at iki.fi Tue Jun 6 21:16:47 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 07 Jun 2006 00:16:47 +0300 Subject: Reverting package to a previous In-Reply-To: <1149626264.6438.2.camel@scriabin.tannenrauch.ch> References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> <1149626264.6438.2.camel@scriabin.tannenrauch.ch> Message-ID: <1149628607.29772.31.camel@localhost.localdomain> On Tue, 2006-06-06 at 22:37 +0200, G?rard Milmeister wrote: > On Tue, 2006-06-06 at 15:18 -0500, Jason L Tibbitts III wrote: > > > > Then there is another possibility. Keep the regular erlang packages > > as is and release "erlangR10B" packages. The update wings3d and > > erlang_sdl and any other packages that rely on the old erlang version > > to depend (and link against) on this new package. > > That would make sense, There's also a precedent of naming stuff like this as compat-foo, and I think it's generally preferred over version based suffixing nowadays, at least when there's no intention to keep permanently shipping many versions of something. > since it seems that there are really incompatible > changes between R10B and R11B. Yet another case to the pile of recent incompatible upgrades :( From ville.skytta at iki.fi Tue Jun 6 21:20:14 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 07 Jun 2006 00:20:14 +0300 Subject: Running rpm inside mock's chroot In-Reply-To: <4485EF39.6010901@cora.nwra.com> References: <4485EF39.6010901@cora.nwra.com> Message-ID: <1149628814.29772.34.camel@localhost.localdomain> On Tue, 2006-06-06 at 15:10 -0600, Orion Poplawski wrote: > bash-3.1# rpm -qa > rpmdb: Program version 4.3 doesn't match environment version > error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database > environment version mismatch > error: cannot open Packages index using db3 - (-30974) > error: cannot open Packages database in /var/lib/rpm > > Any ideas why? The db was probably generated from outside of the chroot with the host's rpm, not the one in the chroot, and the two aren't compatible. You should be able to use the host one for querying, like "rpm --root /var/lib/mock/$dist/root -qa" From paul at all-the-johnsons.co.uk Tue Jun 6 21:43:01 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 Jun 2006 22:43:01 +0100 Subject: mock problem Message-ID: <1149630182.19529.36.camel@T7.Linux> Hi, I'm rebuilding xsp to fix the problem the identified in the last extras repo report, but have hit a problem and I've no idea why - all was well 2 days back... I'm issuing mock like this mock -r fedora-development-i386-core.cfg rpmbuild/SRPMS/xsp-1.1.15-2.src.rpm mocks starts fine and then gives init clean prep This may take a while Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build build-minimal build-base local ending I'm using mock-0.4-8.fc5 TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Tue Jun 6 21:52:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 16:52:57 -0500 Subject: Reverting package to a previous In-Reply-To: <1149626264.6438.2.camel@scriabin.tannenrauch.ch> =?iso-8859-1?q?=28G=E9rard?= Milmeister's message of "Tue, 06 Jun 2006 22:37:44 +0200") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> <1149626264.6438.2.camel@scriabin.tannenrauch.ch> Message-ID: >>>>> "GM" == G?rard Milmeister writes: GM> Does this mean that a completely new package has to be imported GM> into CVS? Yes, I would recommend it. I do not think that you would need to go through a separate package review, although I would review your package quickly if you did so. GM> Almost all files reside in %{_libdir}/erlang. Without patching GM> one could use then ${_libdir}/erlang10B/erlang. I think that's a bit ugly, especially if .../erlang10B would be empty save for that single directory. I guess it's a balance of this ugliness versus the difficulty of patching it. The best possible thing would probably be to have .../erlang/%{version}, with one subdirectory per version, as gcc does. But, again, this requires patching. - J< From tibbs at math.uh.edu Tue Jun 6 21:57:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 06 Jun 2006 16:57:36 -0500 Subject: Reverting package to a previous In-Reply-To: <1149628607.29772.31.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 07 Jun 2006 00:16:47 +0300") References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> <1149626264.6438.2.camel@scriabin.tannenrauch.ch> <1149628607.29772.31.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> There's also a precedent of naming stuff like this as compat-foo, VS> and I think it's generally preferred over version based suffixing VS> nowadays, at least when there's no intention to keep permanently VS> shipping many versions of something. Naming here seems to be ill-defined; we have both compat-libstdc++-33-3.2.3-55.fc5.i386 (compat-name-ver-ver-release} and compat-db-4.2.52-4.i386 (compat-name-ver-release). I guess compat-erlang-R10B-1.fc5.i386 makes the most sense. VS> Yet another case to the pile of recent incompatible upgrades :( Yes, this is OK in rawhide but scary in the release branches. - J< From kevin.kofler at chello.at Tue Jun 6 23:14:55 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 6 Jun 2006 23:14:55 +0000 (UTC) Subject: What's the best practice for packaging java apps on FC References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> Message-ID: Well, the ones I remember: 1. Rebuild everything from source with the tools in Core or Extras at RPM build time, don't just dump binary .class files in the RPM (no matter how they have been built, but definitely not if they have been built with some proprietary Java toolchain). 2. Use aot-compile-rpm to make precompiled .so files for faster operation with GCJ/GIJ and be aware that the resulting packages are NOT noarch packages, but plain old arch-specific packages (just like C/C++ programs). The people working on GCJ on Fedora can certainly tell you more. Kevin Kofler From michael at knox.net.nz Tue Jun 6 23:18:07 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 07 Jun 2006 11:18:07 +1200 Subject: mock problem In-Reply-To: <1149630182.19529.36.camel@T7.Linux> References: <1149630182.19529.36.camel@T7.Linux> Message-ID: <44860D2F.5000603@knox.net.nz> Paul wrote: > Hi, > > I'm rebuilding xsp to fix the problem the identified in the last extras > repo report, but have hit a problem and I've no idea why - all was well > 2 days back... > > I'm issuing mock like this > > mock -r fedora-development-i386-core.cfg > rpmbuild/SRPMS/xsp-1.1.15-2.src.rpm > > mocks starts fine and then gives > > init > clean > prep > This may take a while > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-development-i386-core/root > groupinstall build build-minimal build-base local > ending > > I'm using mock-0.4-8.fc5 Does using the "--debug" flag help show a bit more information? I have just built xsp on FC4 with my local copy of rawhide and it went fine. Wrote: /builddir/build/RPMS/xsp-1.1.15-1.fc6.i386.rpm Wrote: /builddir/build/RPMS/xsp-debuginfo-1.1.15-1.fc6.i386.rpm Michael From kevin.kofler at chello.at Tue Jun 6 23:25:09 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 6 Jun 2006 23:25:09 +0000 (UTC) Subject: Need Help from a C expert References: <4483A83C.2000106@smile.org.ua> Message-ID: Andy Shevchenko writes: > > Nevermind, I fixed this problem by simply removing the vsnprintf > > function from the source file. It seems vsnprintf is a builtin system > > function and there is no need to compile a new one. > Due to security reasons the built in source function may be better than > system one. I think the security audit of that code should be passed. No. Duplicating system functions is never a good idea for security! If you have a function in one location, it can be fixed once if it's broken. Who is going to track down the thousands of broken copies of vsnprintf.c if a bug is found in a commonly-copied implementation? As for why the file doesn't build: -DFORTIFY_SOURCE defines vsnprintf as a macro in order to do additional security checks on it (see again why replacing system functions is not good for security?), so the function declaration (the header of the function definition, actually) gets macro-expanded too, which won't work. (The macro expansion expects to deal only with function uses, not function declarations/definitions.) The easiest fix is exactly what has been done: remove vsnprintf.c and just use the system one. The reason the source code includes its own vsnprintf.c is that not all systems have vsnprintf, it's a C99 function. Fedora does have it, so vsnprintf.c is useless on Fedora. Kevin Kofler From Christian.Iseli at licr.org Tue Jun 6 23:01:16 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Jun 2006 01:01:16 +0200 Subject: FE Package Status of Jun 7, 2006 Message-ID: <200606070001.k5701ZrG029332@mx3.redhat.com> Hi folks, A bit overdue, but here it is: a shiny new report... A few comments: - I stopped using the Extras/PackagesNoLongerInDevel page to determine packages dropped from Extras (as suggested on this list a while ago). The script now tries to determine package status from the content of the devel directory in CVS. This probably leads to some unnecessary noise (e.g. inactive tracker bug reports for the general component)... Please let me know if a few things need to be tuned here. - The bugzilla report listing all the closed FE-ACCEPT tickets is now pretty large, and the web server refuses to let me download the CSV file in one go because the URI is too large. I guess there is a way to directly access bugzilla's database, but I have no experience there. Can anyone lend me a hand there ? - There are a few strange entries in CVS which I'll list here. Any word of advice here ? I guess they mostly miss a dead.package file, but... /extras/scim-chewing/devel/ total 32 drwxr-xr-x 3 chris chris 4096 Jan 16 17:14 . drwxr-xr-x 7 chris chris 4096 Mar 17 08:42 .. drwxr-xr-x 2 chris chris 4096 Jan 16 17:14 CVS -rw-r--r-- 1 chris chris 26 Aug 23 2005 .cvsignore /extras/gconfmm20/devel/ total 32 drwxr-xr-x 3 chris chris 4096 Jan 16 16:31 . drwxr-xr-x 8 chris chris 4096 Mar 17 08:38 .. drwxr-xr-x 2 chris chris 4096 Jan 16 16:31 CVS -rw-r--r-- 1 chris chris 22 Nov 8 2004 .cvsignore /extras/wxPythonGTK2/devel/ total 40 drwxr-xr-x 3 chris chris 4096 Apr 8 22:17 . drwxr-xr-x 10 chris chris 4096 Mar 17 08:42 .. drwxr-xr-x 2 chris chris 4096 Apr 8 22:17 CVS -rw-r--r-- 1 chris chris 27 Nov 8 2004 .cvsignore -rw-r--r-- 1 chris chris 832 Nov 24 2004 Makefile /extras/compat-wxPythonGTK2/devel/ total 56 drwxr-xr-x 3 chris chris 4096 Apr 21 01:43 . drwxr-xr-x 6 chris chris 4096 Apr 21 01:43 .. -rw-r--r-- 1 chris chris 3519 Apr 21 01:43 compat-wxPython.spec drwxr-xr-x 2 chris chris 4096 Apr 21 01:43 CVS -rw-r--r-- 1 chris chris 27 Jan 6 17:23 .cvsignore -rw-r--r-- 1 chris chris 844 Jan 6 17:17 Makefile -rw-r--r-- 1 chris chris 61 Jan 6 17:23 sources /movies/extras/nautilus-sendto/devel/ total 32 drwxr-xr-x 3 chris chris 4096 Jan 16 16:51 . drwxr-xr-x 7 chris chris 4096 Mar 17 08:40 .. drwxr-xr-x 2 chris chris 4096 Jan 16 16:51 CVS -rw-r--r-- 1 chris chris 28 Oct 9 2005 .cvsignore Cheers, Christian ---- FE Package Status of Jun 7, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1833 packages - 41 orphans - 51 packages not available in extras devel or release andreas at bawue dot net dd_rescue bugs dot michael at gmx dot net libgcrypt1 cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode denis at poolshark dot org gtkmm20 denis at poolshark dot org libgnomemm20 denis at poolshark dot org libglademm20 denis at poolshark dot org libgnomecanvasmm20 denis at poolshark dot org libgnomeuimm20 denis at poolshark dot org gconfmm20 dennis at ausil dot us cryptplug dkl at redhat dot com general fedora at leemhuis dot info alsa-firmware fedora at soeterbroek dot com gnubg fredrik at dolda2000 dot com icmpdn gauret at free dot fr elmo gemi at bluewin dot ch xaos ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin mattdm at mattdm dot org wxPythonGTK2 matthias at rpmforge dot net php-pecl-pdo matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net php-pecl-pdo-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache mpeters at mac dot com perl-Spreadsheet-ParseExcel nomis80 at nomis80 dot org juk notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard sgrubb at redhat dot com libsafe skvidal at phy dot duke dot edu buildsystem tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com stripesnoop tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula ville dot skytta at iki dot fi newpg ville dot skytta at iki dot fi cdiff wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 6 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep dakingun at gmail dot com baobab hugo at devin dot com dot br kerry noa at resare dot com vorbisgain wtogami at redhat dot com lvcool - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 SquidGuard oliver at linux-kernel.at webmin jvdias at redhat.com - 5 packages present in the development repo which have no owners entry blam conntrack dbus-qt kimdaba perl-Net-Jabber - 2 orphaned packages, yet available in extras devel gtkglarea2 perl-XML-XQL - 38 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for FC5: tcallawa at redhat dot com check - 3 packages duplicated for devel: rdieter at math dot unl dot edu gtk+ rdieter at math dot unl dot edu glib tcallawa at redhat dot com check FE-ACCEPT packages stats: - 894 accepted, closed package reviews - 7 accepted, closed package reviews not in repo - 9 accepted, closed package reviews not in owners - 9 accepted, open package reviews older than 4 weeks; - 7 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 94 open tickets - 9 tickets with no activity in eight weeks - 24 tickets with no activity in four weeks - 4 closed tickets FE-NEW packages stats: - 198 open tickets - 13 tickets with no activity in eight weeks - 44 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 51 open tickets - 1 tickets with no activity in eight weeks - 19 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 234 open tickets - 138 tickets with no activity in eight weeks - 32 tickets with no activity in four weeks CVS stats: - 1798 packages with a devel directory - 10 packages with no owners entry blam conntrack dbus-qt initng kile-i18n kimdaba muse pcb perl-Maypole perl-Net-Jabber - 4 packages in CVS devel *and* Core check libevent glib gtk+ - 37 packages were dropped from extras Maintainers stats: - 199 maintainers - 3 inactive maintainers with open bugs Dropped FC packages: - 238 packages were dropped from core since FC 1 From fedora at camperquake.de Wed Jun 7 00:41:24 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 7 Jun 2006 02:41:24 +0200 Subject: Need Help from a C expert In-Reply-To: References: <4483A83C.2000106@smile.org.ua> Message-ID: <20060607024124.363e3408@lain> Hi. On Tue, 6 Jun 2006 23:25:09 +0000 (UTC), Kevin Kofler wrote > The reason the source code includes its own vsnprintf.c is that not > all systems have vsnprintf, it's a C99 function. ... which the configure script should detect and build an appropiate makefile for. From gemi at bluewin.ch Wed Jun 7 01:10:12 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 07 Jun 2006 03:10:12 +0200 Subject: Reverting package to a previous In-Reply-To: References: <1149617626.25583.2.camel@scriabin.tannenrauch.ch> <1149621374.28636.1.camel@scriabin.tannenrauch.ch> <1149622933.32491.4.camel@scriabin.tannenrauch.ch> <1149626264.6438.2.camel@scriabin.tannenrauch.ch> Message-ID: <1149642612.30214.2.camel@scriabin.tannenrauch.ch> On Tue, 2006-06-06 at 16:52 -0500, Jason L Tibbitts III wrote: > >>>>> "GM" == G?rard Milmeister writes: > > GM> Does this mean that a completely new package has to be imported > GM> into CVS? > > Yes, I would recommend it. I do not think that you would need to go > through a separate package review, although I would review your > package quickly if you did so. Ok, the bug number is 194300. > GM> Almost all files reside in %{_libdir}/erlang. Without patching > GM> one could use then ${_libdir}/erlang10B/erlang. > > I think that's a bit ugly, especially if .../erlang10B would be empty > save for that single directory. I guess it's a balance of this > ugliness versus the difficulty of patching it. A simple patch was enough to change from %{_libdir}/erlang to %{_libdir}/erlangR10B. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From somlo at cmu.edu Wed Jun 7 02:20:52 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Tue, 6 Jun 2006 22:20:52 -0400 Subject: mock problem In-Reply-To: <1149630182.19529.36.camel@T7.Linux> References: <20060607000144.EA858733FD@hormel.redhat.com> Message-ID: <20060607022052.GA1875@hedwig.net.cmu.edu> Message: 11 To: fedora-extras Content-Type: text/plain; charset="iso-8859-15" On Tue, 06 Jun 2006, paul at all-the-johnsons.co.uk wrote: > > I'm issuing mock like this > > mock -r fedora-development-i386-core.cfg > rpmbuild/SRPMS/xsp-1.1.15-2.src.rpm > > mocks starts fine and then gives > > init > clean > prep > This may take a while > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-development-i386-core/root > groupinstall build build-minimal build-base local > ending > Same here. When I cat /var/lib/mock/fedora-development-i386-core/result/root.log I get ... http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/perl-XML-SAX-0.14-1.noarch.rpm: [Errno 4] IOError: HTTP Error 404: Content-Length: 345 ... This means the repodata xml file lists a version higher than the latest available in the repo itself. Possibly a botched rsync job, but it happens with more than one mirror (I personally tried both extras64.linux.duke.edu and mirrors.kernel.org, with the same results). HTH, Gabriel From Matt_Domsch at dell.com Wed Jun 7 02:24:11 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 6 Jun 2006 21:24:11 -0500 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070001.k5701ZrG029332@mx3.redhat.com> References: <200606070001.k5701ZrG029332@mx3.redhat.com> Message-ID: <20060607022411.GA8458@lists.us.dell.com> On Wed, Jun 07, 2006 at 01:01:16AM +0200, Christian.Iseli at licr.org wrote: > - The bugzilla report listing all the closed FE-ACCEPT tickets is now pretty > large, and the web server refuses to let me download the CSV file in one go > because the URI is too large. I guess there is a way to directly access > bugzilla's database, but I have no experience there. Can anyone lend me a > hand there ? Crediting Bill Nottingham and Jesse Keating here, they figured this out for my rebuild scripts. wget -O fe-accept.csv \ "https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component_text=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&devel_whiteboard_type=allwordssubstr&devel_whiteboard=&keywords_type=allwords&keywords=&cust_facing=&cust_facing_type=substring&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&field0-0-0=blocked&type0-0-0=equals&value0-0-0=163779&ctype=csv" Yes, that's kind of a long URL, but it gets you the CSV file. :-) Note the bug number is 163779 in the URL; you can change that as necessary for other blocker bugs. The other trick is to use a cookie to select your columns. #!/bin/sh COOKIES=~/bin/cookies.txt URL='https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component_text=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&devel_whiteboard_type=allwordssubstr&devel_whiteboard=&keywords_type=allwords&keywords=&cust_facing=&cust_facing_type=substring&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&field0-0-0=blocked&type0-0-0=equals&value0-0-0=163779&ctype=csv' OUTPUT='fe-accept.csv' wget -O ${OUTPUT} "${URL}" where cookies.txt looks like (note the data is all one line): # HTTP Cookie File # http://www.netscape.com/newsref/std/cookie_spec.html # This is a generated file! Do not edit. # To delete cookies, use the Cookie Manager. bugzilla.redhat.com FALSE /bugzilla FALSE 2145917240 COLUMNLIST alias%20bug_severity%20priority%20rep_platform%20assigned_to%20bug_status%20resolution%20component%20short_short_desc 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 overholt at redhat.com Wed Jun 7 04:16:53 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 7 Jun 2006 00:16:53 -0400 Subject: What's the best practice for packaging java apps on FC In-Reply-To: References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> Message-ID: <20060607041652.GB11376@redhat.com> * Kevin Kofler [2006-06-06 19:15]: > 1. Rebuild everything from source [...] > 2. Use aot-compile-rpm to make precompiled .so files [...] Correct and correct. > The people working on GCJ on Fedora can certainly tell you more. Yeah, pop on over to fedora-devel-java-list or #fedora-java. There's also some stuff on the Fedora wiki. In general, follow the JPackage conventions and add the gcj-specific bits. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Wed Jun 7 06:19:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 23:19:50 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149620348.19529.15.camel@T7.Linux> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> Message-ID: <1149661191.5342.6.camel@localhost> On Tue, 2006-06-06 at 19:59 +0100, Paul wrote: > > Also -- a bit more explanation of why mono apps need to go in /usr/lib > > is in order b/c the Core packages tomboy and beagle end up > > in /usr/lib64/ on an x86_64. > > They don't need to go in there. However, if you have a package which > builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ] > amongst others), the configure script may not pick them up correctly. By > having them all in /usr/lib, you can be assured that the package will be > found. It's not the best way of doing things, but until things become > saner with mono and how it's set up and how it looks for things... What's the easiest set of packages (preferably two already in Extras but I'll look at something under review if there isn't a whole stack of dependencies) that shows what the problem is? Since mono applications in Core reside in %{_libdir} and Core's mono libraries only put .dll, .exe, and GAC files in %{_prefix}/lib/ (pkgconfig and ELF .so's go into %{_libdir}) I think there's something not quite right about the wiki's statement of problem and the "%define _libdir %{_prefix}/lib" solution. -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 Christian.Iseli at licr.org Wed Jun 7 06:51:11 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Jun 2006 08:51:11 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: Your message of "Tue, 06 Jun 2006 21:24:11 CDT." <20060607022411.GA8458@lists.us.dell.com> Message-ID: <200606070651.k576pBud009082@ludwig-alpha.unil.ch> Hi Matt, Matt_Domsch at dell.com said: > Crediting Bill Nottingham and Jesse Keating here, they figured this out for > my rebuild scripts. Thanks for sharing the script. Looks just like what I need! > wget -O fe-accept.csv \ "https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&query_format=advanced&... Any reason why the "query_format=advanced" parameter is repeated twice ? That's great. I can now probably automate the script even some more :-) Cheers, Christian From paul at all-the-johnsons.co.uk Wed Jun 7 08:02:07 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 07 Jun 2006 09:02:07 +0100 Subject: Hula -- mixed mono package In-Reply-To: <1149661191.5342.6.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149661191.5342.6.camel@localhost> Message-ID: <1149667327.14694.2.camel@mrwibble.mrwobble> Hi, > > They don't need to go in there. However, if you have a package which > > builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ] > > amongst others), the configure script may not pick them up correctly. By > > having them all in /usr/lib, you can be assured that the package will be > > found. It's not the best way of doing things, but until things become > > saner with mono and how it's set up and how it looks for things... > > What's the easiest set of packages (preferably two already in Extras but > I'll look at something under review if there isn't a whole stack of > dependencies) that shows what the problem is? boo, nant and gtksourceview-sharp are all pretty trivial > Since mono applications > in Core reside in %{_libdir} and Core's mono libraries only > put .dll, .exe, and GAC files in %{_prefix}/lib/ (pkgconfig and > ELF .so's go into %{_libdir}) I think there's something not quite right > about the wiki's statement of problem and the "%define _libdir > %{_prefix}/lib" solution. Not with you there - what do you mean? (sorry, very late night last night - the baby was restless) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From Christian.Iseli at licr.org Wed Jun 7 08:05:44 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Jun 2006 10:05:44 +0200 Subject: FE package database Message-ID: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> Hi Warren, You mentioned you'd like to implement a database for FE packages. Here are some thoughts for your pondering... I think a very simple solution would be to have two tables. The first would simply be an extension of the current owners.list file. It could still be kept in CVS. Here are the fields that could be in there: Package table: 1. product 2. component 3. description 4. initialowner (current package owner) 5. initialqacontact 6. initialcclist (package co-maintainers) 7. review submitter 8. review submit date 9. reviewer 10. accept date 11. review request BZ ticket number 12. current status (Active, Orphaned, Dropped, Moved to Core) Another table (which could be set alongside the owners.list file, also in CVS) would be automatically maintained by the build system (a row is added each time a build is successfully completed, or maybe when the package is signed) and could look like this: Builds table: 1. component 2. e-v-r 3. fedora release number (devel, 5, 4, etc.) 4. build request submitter 5. build request date Combining the two tables would give an accurate view of the current status of all FE packages, and who did what and at what time. Those tables would be pretty small, and can easily be loaded in any kind of DBMS to extract informations. Keeping the basic data in plain text files allows for easy data input and keeps the update process very plain and open through the commits log in the ml. Cheers, Christian From j.w.r.degoede at hhs.nl Wed Jun 7 08:38:15 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 10:38:15 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070001.k5701ZrG029332@mx3.redhat.com> References: <200606070001.k5701ZrG029332@mx3.redhat.com> Message-ID: <44869077.8090404@hhs.nl> Christian, Can you put libgsf113 on some kinda blacklist it was a newer version of libgsf (which is in core) which was needed for a while for some FE packages put no core has upgraded so its obsolete, and has been completly removed from CVS. Regards, Hans From Christian.Iseli at licr.org Wed Jun 7 08:52:51 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Jun 2006 10:52:51 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: Your message of "Wed, 07 Jun 2006 10:38:15 +0200." <44869077.8090404@hhs.nl> Message-ID: <200606070852.k578qpBp012966@ludwig-alpha.unil.ch> Hi Hans, j.w.r.degoede at hhs.nl said: > Can you put libgsf113 on some kinda blacklist it was a newer version of > libgsf (which is in core) which was needed for a while for some FE packages > put no core has upgraded so its obsolete, and has been completly removed > from CVS. Ok, will do. I see two solutions: - add the blacklist in the script - keep the blacklist on the Extras/PackagesNoLongerInDevel page Anyone has a strong preference either way (or some other luminous idea) ? I think I'd prefer the wiki page (more open), but I think some people would prefer that page dead... Christian From j.w.r.degoede at hhs.nl Wed Jun 7 09:16:01 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 11:16:01 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070852.k578qpBp012966@ludwig-alpha.unil.ch> References: <200606070852.k578qpBp012966@ludwig-alpha.unil.ch> Message-ID: <44869951.1060905@hhs.nl> Christian.Iseli at licr.org wrote: > Hi Hans, > > j.w.r.degoede at hhs.nl said: >> Can you put libgsf113 on some kinda blacklist it was a newer version of >> libgsf (which is in core) which was needed for a while for some FE packages >> put no core has upgraded so its obsolete, and has been completly removed >> from CVS. > > Ok, will do. I see two solutions: > - add the blacklist in the script > - keep the blacklist on the Extras/PackagesNoLongerInDevel page > > Anyone has a strong preference either way (or some other luminous idea) ? > > I think I'd prefer the wiki page (more open), but I think some people would > prefer that page dead... > > Christian > > I have no opinion on this as long as somehow I stop being nagged about libgsf113 :) Regards, Hans From cranium2003 at yahoo.com Wed Jun 7 09:54:08 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Wed, 7 Jun 2006 02:54:08 -0700 (PDT) Subject: unable to use mock In-Reply-To: <20060606115150.83875.qmail@web38010.mail.mud.yahoo.com> Message-ID: <20060607095408.10542.qmail@web38001.mail.mud.yahoo.com> hi paul, --- cranium2003 wrote: > Hi Paul, > I did yum install yum-utils and then > python fedora-mirror.py > syncing: Fedora development core i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora development core i386 source to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora development extras i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora development extras i386 source to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 core i386 debuginfo to /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 core i386 source to /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 extras i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 extras i386 source to /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 updates i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 updates i386 source to /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 updates-testing i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 updates-testing i386 source to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 legacy i386 debuginfo to > /srv/mirror > No Repositories Available to Set Up > syncing: Fedora 5 legacy i386 source to /srv/mirror > No Repositories Available to Set Up > > whats that mean?? my fedora-mirror.py attached here. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > #!/usr/bin/python > > ### License: GPL > ### Author: Rudolf Kastl > > ### default target: /srv/mirror > ### how?: use config file and special mirror .repo > files > > ### todo: > > #### code: > ### - ConfigParser > ### - logging > ### - legacy and updates-testing awareness > ### - fix hierachy into the fedora mirror dir scheme > ### - use separate configs for each release > ### - progressbars > ### - eta (complete, per repo, per file(?!)) > > #### support files/packaging/integration: > ### - creation of specially crafted .repo files > ### - cron integration > ### - 0 conf apache serving as split package > ### - mock config files as split package > ### - yum localmirror config files as split package > ### - discuss access rights on /srv/mirror > > ################## > ### special cases: > ### - the fedora core repos differ in logic -> core > repos have updates, updates-testing, legacy -> to be > investigated > ### - development is another special case not having > updates updates-testing and legacy > ### - other repos (3rd party) never have updates and > updates-testing > ### - SRPMS are another special case -> same for > each arch of the same release > ############################# > > > > import os > > flavourlist=["core", "extras", "updates", > "updates-testing", "legacy"] > #versionlist=["development", "5", "4", "3", "2" > ,"1"] > versionlist=["development", "5"] > archlist=["i386" ] > #targetlocation="/home/che/mirror" > subflavourlist=["debuginfo", "source"] > > ##### block for parsing commandline switches > from optparse import OptionParser > > parser = OptionParser() > ### var can be accessed with options.filename > parser.add_option("-d", "--dest", > dest="destination", help="Sync Destination", > metavar="dir", default="/srv/mirror") > parser.add_option("-n", "--newonly", > action="store_true", dest="newonly", help="Sync > Destination", default=False) > parser.add_option("-t", "--testonly" , > action="store_true", dest="testonly", help="No Sync > Transaction", default=False) > parser.add_option("-q", "--quiet", > action="store_false", dest="verbose", default=True, > help="don't print status msgs to stdout") > > (options, args) = parser.parse_args() > ##### end bloc > > targetlocation = options.destination > > def syncMirror (version, flavour, arch, subflavour, > targetlocation): > print "syncing: Fedora " + version, flavour, > arch, subflavour, "to", targetlocation > > ### handling the special cases > if subflavour == "binary": > subflavourid = "" > subflavourpath = "" > elif subflavour == "source": > subflavourid = "-"+subflavour > subflavourpath = "/SRPMS" > else: > subflavourid = "-"+subflavour > subflavourpath = "-"+subflavour > > ### devel is special > if version == "development": > > repoid="mirror-"+flavour+"-"+version+subflavourid > else: > > repoid="mirror-"+flavour+subflavourid > > if subflavour == "source": > > targetdir=targetlocation+"/fedora/"+version+"/"+flavour+subflavourpath > else: > > targetdir=targetlocation+"/fedora/"+version+"/"+flavour+"/"+arch+subflavourpath > > ### handling the newonly option of reposync > if options.newonly == True: > newonly = " -n" > else: > newonly = "" > > ### building the command for syncing a > single repo > syncdistro="mirrorreleasever="+version+" > mirrorbasearch="+arch+" /usr/bin/reposync"+newonly+" > -r "+repoid+" -p "+targetdir > > ### for testing we just print instead of > sync > if options.testonly == True: > print syncdistro > else: > ### create potentially missing paths > try: > if os.path.isdir(targetdir) > == False: > > os.makedirs(targetdir) > except: > print "Error: Cannot create > targetdirectory:", targetdir > > os.system(syncdistro) > > #### main loop > for version in versionlist: > for flavour in flavourlist: > for arch in archlist: > for subflavour in > subflavourlist: > ### stuff that just > doesent happen > if version == > "development" and flavour == "updates": > continue > if version == > "development" and flavour == "legacy": > continue > if version == > "development" and flavour == "updates-testing": > continue > else: > > syncMirror(version, flavour, arch, subflavour, > targetlocation) > What can i do now with my above results?? i am failing to build local repo. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fedora at leemhuis.info Wed Jun 7 10:01:25 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Jun 2006 12:01:25 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070852.k578qpBp012966@ludwig-alpha.unil.ch> References: <200606070852.k578qpBp012966@ludwig-alpha.unil.ch> Message-ID: <1149674485.11052.67.camel@thl.ct.heise.de> Am Mittwoch, den 07.06.2006, 10:52 +0200 schrieb Christian.Iseli at licr.org: > Hi Hans, > > j.w.r.degoede at hhs.nl said: > > Can you put libgsf113 on some kinda blacklist it was a newer version of > > libgsf (which is in core) which was needed for a while for some FE packages > > put no core has upgraded so its obsolete, and has been completly removed > > from CVS. > > Ok, will do. I see two solutions: > - add the blacklist in the script > - keep the blacklist on the Extras/PackagesNoLongerInDevel page The best solution probably would be: - re-import the last package in CVS and place a dead.package file in it. That's probably to much work for a small gain so my vote is "add the blacklist in the script" for this stuff -- it normally should not happen again in the future so this blacklist should be written once and (normally) never extended later. CU thl From thomas at apestaart.org Wed Jun 7 10:02:45 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 07 Jun 2006 12:02:45 +0200 Subject: libdir and python on x86_64 In-Reply-To: <1117827118.3176.48.camel@localhost> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> Message-ID: <1149674566.24971.54.camel@otto.amantes> > So arch specific stuff will go in lib64/, site-independent stuff will > end in lib/ As a follow-up question, there are cases of sets of python packages that expect to be installed in the same tree. Taking the example of Twisted; TwistedCore contains some C-based python modules, and a lot of python code. TwistedNames contains only python code. Both of them expect to end up installed in the same tree in the end, so that both import twisted.python and import twisted.names work. It seems to me that, for a set of packages that are going to share the same module namespace, if any of them contains any arch-dependent code, *ALL* of these packages need to go into sitearch. In Extras, this would apply to both Twisted and Flumotion. Does this seem correct, or am I missing something ? Thomas From j.w.r.degoede at hhs.nl Wed Jun 7 10:06:41 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 12:06:41 +0200 Subject: Buildsys strangeness Message-ID: <4486A531.1030302@hhs.nl> Hi all, I had a job which was building since yesterday evening, so it was clearly stuck hence i killed the job and requeued it now its stuck again in a very strange way: 10586: dia (dia-0_95-4_fc6) j.w.r.degoede at hhs.nl building/in-progress hammer3.fedora.redhat.com(i386): 3524044740cc821119c18f0b86d24a4a99e51884 done/building hammer3.fedora.redhat.com(i386): f70c9a2aea3719453f700a1ac04a1e632fd3b01f running/building hammer3.fedora.redhat.com(x86_64): da9431d21b048c528bcaff326544a1efd4d8a3b0 done/done ppc2.fedora.redhat.com(ppc): 653e112d8edb708fd7f730776e5cf5b6dba318ca done/done Notice how its building for i386 twice (and on the same machine). Regards, Hans From paul at city-fan.org Wed Jun 7 10:21:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 07 Jun 2006 11:21:00 +0100 Subject: unable to use mock In-Reply-To: <20060607095408.10542.qmail@web38001.mail.mud.yahoo.com> References: <20060607095408.10542.qmail@web38001.mail.mud.yahoo.com> Message-ID: <4486A88C.7000905@city-fan.org> cranium2003 wrote: > hi paul, > --- cranium2003 wrote: > >> Hi Paul, >> I did yum install yum-utils and then >> python fedora-mirror.py >> syncing: Fedora development core i386 debuginfo to >> /srv/mirror >> No Repositories Available to Set Up (snip) >> whats that mean?? You need some additional config files. >> my fedora-mirror.py attached here. >> >> >> ### License: GPL >> ### Author: Rudolf Kastl >> (snip) >> import os >> >> flavourlist=["core", "extras", "updates", >> "updates-testing", "legacy"] >> #versionlist=["development", "5", "4", "3", "2" >> ,"1"] >> versionlist=["development", "5"] >> archlist=["i386" ] >> #targetlocation="/home/che/mirror" >> subflavourlist=["debuginfo", "source"] I suggest you start with just one flavour/version/arch and get that working first. Try this: versionlist=["development"] #archlist=["i386", "x86_64", "ppc"] archlist=["i386"] #subflavourlist=["debuginfo", "source"] subflavourlist=["binary"] >> ##### block for parsing commandline switches >> from optparse import OptionParser >> >> parser = OptionParser() >> ### var can be accessed with options.filename >> parser.add_option("-d", "--dest", >> dest="destination", help="Sync Destination", >> metavar="dir", default="/srv/mirror") Change /srv/mirror on this line to where you want you local repos to live. You then need to add a yum configuration for the mirror to use. For rawhide, copy /etc/yum.repos.d/fedora-development.repo to /etc/yum.repos.d/mirror-core-development.repo and edit /etc/yum.repos.d/mirror-core-development.repo. Change the repo names as follows: [root at xy01m005 yum.repos.d]# diff fedora-development.repo mirror-core-development.repo 26c26 < [development] --- > [mirror-core-development] 33c33 < [development-debuginfo] --- > [mirror-core-development-debuginfo] 39c39 < [development-source] --- > [mirror-core-development-source] Then try fedora-mirror again. Once that's working, add other versions/flavours as required. Paul. From alcapcom at gmail.com Wed Jun 7 10:28:49 2006 From: alcapcom at gmail.com (alcapcom) Date: Wed, 7 Jun 2006 12:28:49 +0200 Subject: What's the best practice for packaging java apps on FC In-Reply-To: <20060607041652.GB11376@redhat.com> References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> <20060607041652.GB11376@redhat.com> Message-ID: <4ccd9dcb0606070328g1775c80fpd869d8928b553542@mail.gmail.com> Thank's for all these invaluable informations. That will save me minimum hundred google query, perhaps even two hundreds ;) 2006/6/7, Andrew Overholt : > > * Kevin Kofler [2006-06-06 19:15]: > > 1. Rebuild everything from source [...] > > 2. Use aot-compile-rpm to make precompiled .so files [...] > > Correct and correct. > > > The people working on GCJ on Fedora can certainly tell you more. > > Yeah, pop on over to fedora-devel-java-list or #fedora-java. There's also > some stuff on the Fedora wiki. In general, follow the JPackage > conventions > and add the gcj-specific bits. > > Andrew > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cranium2003 at yahoo.com Wed Jun 7 10:39:39 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Wed, 7 Jun 2006 03:39:39 -0700 (PDT) Subject: unable to use mock In-Reply-To: <4486A88C.7000905@city-fan.org> Message-ID: <20060607103939.36139.qmail@web38001.mail.mud.yahoo.com> Paul, thanks very much it seems it worked and starts downloading RPMs but i have one question and that is instead of waiting for too much to download all rpms can i copy FC5 DVD to mirror directory?? I mean can i create a mirror from FC5 DVD?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From Christian.Iseli at licr.org Wed Jun 7 10:50:44 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Jun 2006 12:50:44 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: Your message of "Wed, 07 Jun 2006 12:01:25 +0200." <1149674485.11052.67.camel@thl.ct.heise.de> Message-ID: <200606071050.k57AoiaJ015249@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > The best solution probably would be: > - re-import the last package in CVS and place a dead.package file in it. Agreed. > That's probably to much work for a small gain so my vote is "add the > blacklist in the script" for this stuff -- it normally should not happen > again in the future so this blacklist should be written once and (normally) > never extended later. I guess this makes sense. Ok, will do. Christian From rc040203 at freenet.de Wed Jun 7 11:20:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Jun 2006 13:20:04 +0200 Subject: Buildsys strangeness In-Reply-To: <4486A531.1030302@hhs.nl> References: <4486A531.1030302@hhs.nl> Message-ID: <1149679204.7500.67.camel@mccallum.corsepiu.local> On Wed, 2006-06-07 at 12:06 +0200, Hans de Goede wrote: > Hi all, > > I had a job which was building since yesterday evening, so it was > clearly stuck hence i killed the job and requeued it now its stuck again > in a very strange way: > > 10586: dia (dia-0_95-4_fc6) j.w.r.degoede at hhs.nl building/in-progress > hammer3.fedora.redhat.com(i386): > 3524044740cc821119c18f0b86d24a4a99e51884 done/building > hammer3.fedora.redhat.com(i386): > f70c9a2aea3719453f700a1ac04a1e632fd3b01f running/building > hammer3.fedora.redhat.com(x86_64): > da9431d21b048c528bcaff326544a1efd4d8a3b0 done/done > ppc2.fedora.redhat.com(ppc): > 653e112d8edb708fd7f730776e5cf5b6dba318ca done/done > > Notice how its building for i386 twice (and on the same machine). I am facing a similar issue: # plague-client detail 10603 Detail for Job ID 10603 (OpenSceneGraph): -------------------------------------------------------------------------------- Source: OpenSceneGraph-0_9_9-5_fc3 Target: fedora-3-extras Submitter: rc040203 at freenet.de Status: building/ Archjobs: i386: hammer1.fedora.redhat.com done/cleanup x86_64: hammer2.fedora.redhat.com running/prepping i386: hammer1.fedora.redhat.com running/prepping Ralf From katzj at redhat.com Wed Jun 7 12:39:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Jun 2006 08:39:49 -0400 Subject: libdir and python on x86_64 In-Reply-To: <1149674566.24971.54.camel@otto.amantes> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> Message-ID: <4486C915.5060702@redhat.com> Thomas Vander Stichele wrote: >> So arch specific stuff will go in lib64/, site-independent stuff will >> end in lib/ > > As a follow-up question, there are cases of sets of python packages that > expect to be installed in the same tree. Taking the example of Twisted; > TwistedCore contains some C-based python modules, and a lot of python > code. TwistedNames contains only python code. Both of them expect to > end up installed in the same tree in the end, so that both [snip] > It seems to me that, for a set of packages that are going to share the > same module namespace, if any of them contains any arch-dependent code, > *ALL* of these packages need to go into sitearch. > > In Extras, this would apply to both Twisted and Flumotion. > > Does this seem correct, or am I missing something ? Hrmm... but how will this work with the non-arch-dependent packages being noarch? Ugh. Too early. Need to think more on this one... Jeremy From rc040203 at freenet.de Wed Jun 7 12:46:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Jun 2006 14:46:06 +0200 Subject: Attn. FESCo: gdal package review deadlocked Message-ID: <1149684367.7500.91.camel@mccallum.corsepiu.local> Hi, Would FESCo or whoever feels legitimated decide on how to proceed with: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168719 In a nutshell: Both the package submitter (Silke Reimer) and the formal package reviewer (Ignacio Vazquez-Abrams) seem to be AWOL. This has left this package review in a deadlocked situation, which ought to be resolved. Please c.f. bugzilla for details. TIA, Ralf From danjones at us.ibm.com Wed Jun 7 12:58:33 2006 From: danjones at us.ibm.com (Daniel H Jones) Date: Wed, 7 Jun 2006 07:58:33 -0500 Subject: rpmlint warnings/errors In-Reply-To: Message-ID: There is a versioned .so file, however, applications that use this package often perform a dlopen(libopencryptoki.so, ...) at runtime. Removing this link from the base package would cause problems for those applications (or force the installer to create the symlinks themselves). The pkcs11 group is created during %pre. The daemon started by the init script is pkcsslotd, but the package is opencryptoki (since it implements the Cryptoki spec). It seems to me more natural to have the script named for the daemon than the package as long as this is acceptable to the reviewers. Thanks ... >>>>> "DHJ" == Daniel H Jones writes: DHJ> Is it sufficient to provide some explanation of the warning when DHJ> a package is submitted? It would help the reviewer if you did so. DHJ> I have not found a list of acceptable/unacceptable rpmlint DHJ> issues. http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues (just getting started). You're free to add things there. Make sure you run "rpmlint -i" if you just need additional information about what rpmlint is complaining about. DHJ> W: opencryptoki devel-file-in-non-devel-package DHJ> /usr/lib/libopencryptoki.so Do you have a versioned .so file there as well (i.e. libopencryptoki.so.1.2)? If so, this is a blocker. DHJ> E: opencryptoki non-standard-gid DHJ> /var/lib/opencryptoki pkcs11 Not a blocker, assuming you properly create that user. DHJ> W: opencryptoki DHJ> service-default-enabled /etc/rc.d/init.d/pkcsslotd This is a blocker. Packages should not install services which are turned on by default; otherwise, someone who installs a bunch of packages ends up with a bunch of enabled services. (Imagine the theoretical "Everything" install.) DHJ> W: opencryptoki incoherent-init-script-name pkcsslotd It helps if the init file is named in such a way that it is associated with the package, but this is not always reasonable. - J< Thanks, Dan Jones IBM Linux Technology Center, Security 512-838-1794 (T/L 678-1794) danjones at us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Jun 7 13:00:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 07 Jun 2006 14:00:55 +0100 Subject: unable to use mock In-Reply-To: <20060607103939.36139.qmail@web38001.mail.mud.yahoo.com> References: <20060607103939.36139.qmail@web38001.mail.mud.yahoo.com> Message-ID: <1149685256.19370.1.camel@laurel.intra.city-fan.org> On Wed, 2006-06-07 at 03:39 -0700, cranium2003 wrote: > Paul, > thanks very much it seems it worked and starts > downloading RPMs but i have one question and that is > instead of waiting for too much to download all rpms > can i copy FC5 DVD to mirror directory?? I mean can i > create a mirror from FC5 DVD?? You can use the FC5 DVD (or an ISO image of it) as a yum repo directly: http://www.city-fan.org/tips/YumRepoFromImages Paul. From skvidal at linux.duke.edu Wed Jun 7 13:37:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 07 Jun 2006 09:37:29 -0400 Subject: Attn. FESCo: gdal package review deadlocked In-Reply-To: <1149684367.7500.91.camel@mccallum.corsepiu.local> References: <1149684367.7500.91.camel@mccallum.corsepiu.local> Message-ID: <1149687450.29446.1.camel@cutter> On Wed, 2006-06-07 at 14:46 +0200, Ralf Corsepius wrote: > Hi, > > Would FESCo or whoever feels legitimated decide on how to proceed with: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168719 > > In a nutshell: Both the package submitter (Silke Reimer) and the formal > package reviewer (Ignacio Vazquez-Abrams) seem to be AWOL. > > This has left this package review in a deadlocked situation, which ought > to be resolved. > > Please c.f. bugzilla for details. > It looks like some folks are now discussing this one and offering to finish it off. So ignore the original submitter and reviewer and let's start over with the new folks. imo close the bug and open a new one for the two new folks. -sv From j.w.r.degoede at hhs.nl Wed Jun 7 13:57:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 15:57:46 +0200 Subject: Attn. FESCo: gdal package review deadlocked In-Reply-To: <1149687450.29446.1.camel@cutter> References: <1149684367.7500.91.camel@mccallum.corsepiu.local> <1149687450.29446.1.camel@cutter> Message-ID: <4486DB5A.8080409@hhs.nl> seth vidal wrote: > On Wed, 2006-06-07 at 14:46 +0200, Ralf Corsepius wrote: >> Hi, >> >> Would FESCo or whoever feels legitimated decide on how to proceed with: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168719 >> >> In a nutshell: Both the package submitter (Silke Reimer) and the formal >> package reviewer (Ignacio Vazquez-Abrams) seem to be AWOL. >> >> This has left this package review in a deadlocked situation, which ought >> to be resolved. >> >> Please c.f. bugzilla for details. >> > > It looks like some folks are now discussing this one and offering to > finish it off. > > So ignore the original submitter and reviewer and let's start over with > the new folks. > > imo close the bug and open a new one for the two new folks. > > -sv > +1 Regards, Hans From paul at all-the-johnsons.co.uk Wed Jun 7 14:07:30 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 07 Jun 2006 15:07:30 +0100 Subject: Binaries in /usr/share Message-ID: <1149689250.14694.51.camel@mrwibble.mrwobble> Hi, One of the packages I'm trying to get into FE (it's a mono one, so don't expect sanity!) currently installs binaries into share with a symlink back to bindir (normally, I'd expect them in /usr/lib/ with symlinks to bindir). I've looked at the Makefile for the package and it seems that it puts the files into share, so I'd say that was the correct behaviour for the makefile. Problem is that to me, stuffing binaries in share is just wrong, but it's a mono package... Can I have some guidance on this one please? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From j.w.r.degoede at hhs.nl Wed Jun 7 14:18:39 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 16:18:39 +0200 Subject: Binaries in /usr/share In-Reply-To: <1149689250.14694.51.camel@mrwibble.mrwobble> References: <1149689250.14694.51.camel@mrwibble.mrwobble> Message-ID: <4486E03F.4010301@hhs.nl> PFJ wrote: > Hi, > > One of the packages I'm trying to get into FE (it's a mono one, so don't > expect sanity!) currently installs binaries into share with a symlink > back to bindir (normally, I'd expect them in /usr/lib/ with > symlinks to bindir). > > I've looked at the Makefile for the package and it seems that it puts > the files into share, so I'd say that was the correct behaviour for the > makefile. > > Problem is that to me, stuffing binaries in share is just wrong, but > it's a mono package... > > Can I have some guidance on this one please? > Putting them in share is just plain wrong, go fix it. Regards, Hans From paul at all-the-johnsons.co.uk Wed Jun 7 14:21:04 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 07 Jun 2006 15:21:04 +0100 Subject: Binaries in /usr/share In-Reply-To: <4486E03F.4010301@hhs.nl> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> Message-ID: <1149690064.14694.60.camel@mrwibble.mrwobble> Hi, > > Can I have some guidance on this one please? > > > > Putting them in share is just plain wrong, go fix it. Will do - I'll try a local install and see if there is a problem just altering the position of the binary and fixing the symlink, though knowing mono, it won't be that simple... TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From bugs.michael at gmx.net Wed Jun 7 14:18:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 7 Jun 2006 16:18:15 +0200 Subject: rpmlint warnings/errors In-Reply-To: References: Message-ID: <20060607161815.0c001d0e.bugs.michael@gmx.net> On Wed, 7 Jun 2006 07:58:33 -0500, Daniel H Jones wrote: > There is a versioned .so file, however, applications that use this package > often perform a dlopen(libopencryptoki.so, ...) at runtime. Removing this > link from the base package would cause problems for those applications > (or force the installer to create the symlinks themselves). No application should ever dlopen the non-versioned .so at run-time. If it does, it needs to be patched. An application is built for a specific API/ABI and must not expect an arbitrary .so to be the right one. > DHJ> W: opencryptoki devel-file-in-non-devel-package > DHJ> /usr/lib/libopencryptoki.so Also note that ldconfig creates a symbolic link from *.so to the most recent versioned *.so.X, which would break such an application badly when multiple versions are installed. From dcbw at redhat.com Wed Jun 7 14:40:49 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 07 Jun 2006 10:40:49 -0400 Subject: Buildsys strangeness In-Reply-To: <1149679204.7500.67.camel@mccallum.corsepiu.local> References: <4486A531.1030302@hhs.nl> <1149679204.7500.67.camel@mccallum.corsepiu.local> Message-ID: <1149691250.3149.8.camel@localhost.localdomain> On Wed, 2006-06-07 at 13:20 +0200, Ralf Corsepius wrote: > On Wed, 2006-06-07 at 12:06 +0200, Hans de Goede wrote: > > Hi all, > > > > I had a job which was building since yesterday evening, so it was > > clearly stuck hence i killed the job and requeued it now its stuck again > > in a very strange way: > > > > 10586: dia (dia-0_95-4_fc6) j.w.r.degoede at hhs.nl building/in-progress > > hammer3.fedora.redhat.com(i386): > > 3524044740cc821119c18f0b86d24a4a99e51884 done/building > > hammer3.fedora.redhat.com(i386): > > f70c9a2aea3719453f700a1ac04a1e632fd3b01f running/building > > hammer3.fedora.redhat.com(x86_64): > > da9431d21b048c528bcaff326544a1efd4d8a3b0 done/done > > ppc2.fedora.redhat.com(ppc): > > 653e112d8edb708fd7f730776e5cf5b6dba318ca done/done > > > > Notice how its building for i386 twice (and on the same machine). > > I am facing a similar issue: > > # plague-client detail 10603 > > Detail for Job ID 10603 (OpenSceneGraph): > -------------------------------------------------------------------------------- > Source: OpenSceneGraph-0_9_9-5_fc3 > Target: fedora-3-extras > Submitter: rc040203 at freenet.de > Status: building/ > Archjobs: > i386: hammer1.fedora.redhat.com done/cleanup > x86_64: hammer2.fedora.redhat.com running/prepping > i386: hammer1.fedora.redhat.com running/prepping Any ideas on how to further debug the following? I looked at tmraz's vpnc build (10608) and the builder's mock buildroot setup processes were waiting on in fcntl() to lock a file somewhere deep in RPM: strace: Process 18882 attached - interrupt to quit fcntl(15, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0} backtrace: #0 0x0000003fdab0b216 in fcntl () from /lib64/tls/libpthread.so.0 #1 0x00002aaaaacc91d4 in rpmcliVerify () from /usr/lib64/librpm-4.3.so #2 0x00002aaaaacc927c in rpmtsAcquireLock () from /usr/lib64/librpm-4.3.so #3 0x00002aaaaacc57cd in rpmtsRun () from /usr/lib64/librpm-4.3.so #4 0x00002aaaaab7987e in rpmte_Wrap () from /usr/lib64/python2.3/site-packages/rpmmodule.so #5 0x0000003fd988973f in _PyEval_SliceIndex () from /usr/lib64/libpython2.3.so.1.0 #6 0x0000003fd9889c01 in _PyEval_SliceIndex () from /usr/lib64/libpython2.3.so.1.0 #7 0x0000003fd988b2b0 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.3.so.1.0 #8 0x0000003fd9889a8a in _PyEval_SliceIndex () from /usr/lib64/libpython2.3.so.1.0 #9 0x0000003fd988b2b0 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.3.so.1.0 #10 0x0000003fd988b512 in PyEval_EvalCode () from /usr/lib64/libpython2.3.so.1.0 #11 0x0000003fd98a4129 in PyErr_Display () from /usr/lib64/libpython2.3.so.1.0 #12 0x0000003fd98a510d in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.3.so.1.0 #13 0x0000003fd98aa808 in Py_Main () from /usr/lib64/libpython2.3.so.1.0 #14 0x0000003fd911c4bb in __libc_start_main () from /lib64/tls/libc.so.6 And 'lsof' output (doesn't look abnormal to me, but I have no idea what to look for): COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME mock-yum 18882 root cwd DIR 9,2 4096 2 / mock-yum 18882 root rtd DIR 9,2 4096 2 / mock-yum 18882 root txt REG 9,2 8344 53479 /usr/bin/python mock-yum 18882 root mem REG 0,0 0 [heap] (stat: No such file or directory) mock-yum 18882 root mem REG 9,2 115168 336007 /lib64/ld-2.3.6.so mock-yum 18882 root mem REG 9,2 1613968 336009 /lib64/tls/libc-2.3.6.so mock-yum 18882 root mem REG 9,2 19880 336029 /lib64/libdl-2.3.6.so mock-yum 18882 root mem REG 9,2 643408 336011 /lib64/tls/libm-2.3.6.so mock-yum 18882 root mem REG 9,2 1138632 49241 /usr/lib64/libpython2.3.so.1.0 mock-yum 18882 root mem REG 9,2 61384 336039 /lib64/tls/librt-2.3.6.so mock-yum 18882 root mem REG 9,2 69080 53421 /usr/lib64/libelf-0.96.so mock-yum 18882 root mem REG 9,2 64192 49170 /usr/lib64/libbz2.so.1.0.2 mock-yum 18882 root mem REG 9,2 34112 49172 /usr/lib64/libpopt.so.0.0.0 mock-yum 18882 root mem REG 9,2 1031496 49174 /usr/lib64/librpmdb-4.3.so mock-yum 18882 root mem REG 9,2 386472 49171 /usr/lib64/librpmio-4.3.so mock-yum 18882 root mem REG 9,2 133424 49169 /usr/lib64/libbeecrypt.so.6.2.0 mock-yum 18882 root mem REG 9,2 130024 336033 /lib64/tls/libpthread-2.3.6.so mock-yum 18882 root mem REG 9,2 19160 336070 /lib64/libutil-2.3.6.so mock-yum 18882 root mem REG 9,2 118816 98887 /usr/lib64/python2.3/site-packages/rpmmodule.so mock-yum 18882 root mem REG 9,2 350760 49175 /usr/lib64/librpm-4.3.so mock-yum 18882 root mem REG 9,2 79240 49159 /usr/lib64/libz.so.1.2.1.2 mock-yum 18882 root mem REG 9,2 62504 336031 /lib64/libselinux.so.1 mock-yum 18882 root mem REG 9,2 24896 98150 /usr/lib64/python2.3/lib-dynload/strop.so mock-yum 18882 root mem REG 9,2 20480 98148 /usr/lib64/python2.3/lib-dynload/timemodule.so mock-yum 18882 root mem REG 9,2 24232 98155 /usr/lib64/python2.3/lib-dynload/structmodule.so mock-yum 18882 root mem REG 9,2 21952 98153 /usr/lib64/python2.3/lib-dynload/zlibmodule.so mock-yum 18882 root mem REG 9,2 21672 98030 /usr/lib64/python2.3/lib-dynload/_localemodule.so mock-yum 18882 root mem REG 9,2 357184 98885 /usr/lib64/python2.3/site-packages/libxml2mod.so mock-yum 18882 root mem REG 9,2 1073016 49167 /usr/lib64/libxml2.so.2.6.16 mock-yum 18882 root mem REG 9,2 51120 98032 /usr/lib64/python2.3/lib-dynload/_socketmodule.so mock-yum 18882 root mem REG 9,2 17824 98033 /usr/lib64/python2.3/lib-dynload/_ssl.so mock-yum 18882 root mem REG 9,2 244320 336040 /lib64/libssl.so.0.9.7a mock-yum 18882 root mem REG 9,2 1221368 336030 /lib64/libcrypto.so.0.9.7a mock-yum 18882 root mem REG 9,2 93832 53341 /usr/lib64/libgssapi_krb5.so.2.2 mock-yum 18882 root mem REG 9,2 464040 53340 /usr/lib64/libkrb5.so.3.2 mock-yum 18882 root mem REG 9,2 10384 336023 /lib64/libcom_err.so.2.1 mock-yum 18882 root mem REG 9,2 145424 49152 /usr/lib64/libk5crypto.so.3.0 mock-yum 18882 root mem REG 9,2 93624 336019 /lib64/libresolv-2.3.6.so mock-yum 18882 root mem REG 9,2 21224 98042 /usr/lib64/python2.3/lib-dynload/binascii.so mock-yum 18882 root mem REG 9,2 18352 98060 /usr/lib64/python2.3/lib-dynload/mathmodule.so mock-yum 18882 root mem REG 9,2 11808 98031 /usr/lib64/python2.3/lib-dynload/_random.so mock-yum 18882 root mem REG 9,2 15528 98053 /usr/lib64/python2.3/lib-dynload/fcntlmodule.so mock-yum 18882 root mem REG 9,2 19096 98045 /usr/lib64/python2.3/lib-dynload/cStringIO.so mock-yum 18882 root mem REG 9,2 13456 98127 /usr/lib64/python2.3/lib-dynload/md5module.so mock-yum 18882 root mem REG 9,2 13008 98142 /usr/lib64/python2.3/lib-dynload/shamodule.so mock-yum 18882 root mem REG 9,2 75544 98044 /usr/lib64/python2.3/lib-dynload/cPickle.so mock-yum 18882 root mem REG 9,2 19936 98136 /usr/lib64/python2.3/lib-dynload/readline.so mock-yum 18882 root mem REG 9,2 229824 49201 /usr/lib64/libreadline.so.4.3 mock-yum 18882 root mem REG 9,2 15744 336225 /lib64/libtermcap.so.2.0.8 mock-yum 18882 root mem REG 9,2 407640 98684 /usr/lib64/python2.3/lib-dynload/unicodedata.so mock-yum 18882 root mem REG 9,2 27800 98058 /usr/lib64/python2.3/lib-dynload/itertools.so mock-yum 18882 root mem REG 9,2 38592 98040 /usr/lib64/python2.3/lib-dynload/arraymodule.so mock-yum 18882 root mem REG 9,2 58840 336105 /lib64/libnss_files-2.3.6.so mock-yum 18882 root mem REG 9,2 24712 336102 /lib64/libnss_dns-2.3.6.so mock-yum 18882 root mem REG 9,3 16384 16369286 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/__db.001 mock-yum 18882 root mem REG 9,3 1318912 16369287 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/__db.002 mock-yum 18882 root mem REG 9,3 663552 16369288 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/__db.003 mock-yum 18882 root 0u CHR 1,3 2442 /dev/null mock-yum 18882 root 1w FIFO 0,6 2493184 pipe mock-yum 18882 root 2w FIFO 0,6 2493184 pipe mock-yum 18882 root 3w REG 9,2 7580121 160431 /var/log/plague-builder.log mock-yum 18882 root 4u REG 9,3 3939 16369251 /mnt/build/builder_work/839bf2f17e49475381b3254433701b5c7d5234c5/result/root.log mock-yum 18882 root 5u IPv4 7990 TCP *:8889 (LISTEN) mock-yum 18882 root 6u IPv4 8396 TCP *:8888 (LISTEN) mock-yum 18882 root 7u REG 9,3 1003 16369244 /mnt/build/builder_work/839bf2f17e49475381b3254433701b5c7d5234c5/result/job.log mock-yum 18882 root 8u REG 9,3 1017 7356641 /mnt/build/builder_work/9de1339d8bff65b824cf4258bc107452768e5d48/result/job.log mock-yum 18882 root 9u REG 9,3 0 16369252 /mnt/build/builder_work/839bf2f17e49475381b3254433701b5c7d5234c5/result/build.log mock-yum 18882 root 10w REG 9,3 0 16369282 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/log/yum.log mock-yum 18882 root 11r REG 9,3 12288 16369289 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/Packages mock-yum 18882 root 12r REG 9,3 12288 16369289 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/Packages mock-yum 18882 root 13r REG 9,3 12288 16369290 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/Providename mock-yum 18882 root 14r REG 9,3 12288 16369376 /var/lib/mock/fedora-development-x86_64-core-839bf2f17e49475381b3254433701b5c7d5234c5/root/var/lib/rpm/Conflictname mock-yum 18882 root 15u REG 9,2 0 160839 /var/lock/rpm/transaction From j.w.r.degoede at hhs.nl Wed Jun 7 14:42:19 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 16:42:19 +0200 Subject: rpmlint warnings/errors In-Reply-To: <20060607161815.0c001d0e.bugs.michael@gmx.net> References: <20060607161815.0c001d0e.bugs.michael@gmx.net> Message-ID: <4486E5CB.5050708@hhs.nl> Michael Schwendt wrote: > On Wed, 7 Jun 2006 07:58:33 -0500, Daniel H Jones wrote: > >> There is a versioned .so file, however, applications that use this package >> often perform a dlopen(libopencryptoki.so, ...) at runtime. Removing this >> link from the base package would cause problems for those applications >> (or force the installer to create the symlinks themselves). > > No application should ever dlopen the non-versioned .so at run-time. If it > does, it needs to be patched. An application is built for a specific > API/ABI and must not expect an arbitrary .so to be the right one. > >> DHJ> W: opencryptoki devel-file-in-non-devel-package >> DHJ> /usr/lib/libopencryptoki.so > > Also note that ldconfig creates a symbolic link from *.so to the most > recent versioned *.so.X, which would break such an application badly when > multiple versions are installed. > I didn't follow the complete thread so I'm not sure if this is relevant but in smartcard land the ctapi is especially designed to be dlopened and to be dlopened by just xxxx.so. See the ctapi-cyberjack review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369 For more on this and on how we solved this in a clean way, which should be followed by other ctapi implementations too. Regards, Hans From jonathan.underwood at gmail.com Wed Jun 7 14:42:10 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 7 Jun 2006 15:42:10 +0100 Subject: Binaries in /usr/share In-Reply-To: <4486E03F.4010301@hhs.nl> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> Message-ID: <645d17210606070742j651f8c8oe988f117f8cdc475@mail.gmail.com> On 07/06/06, Hans de Goede wrote: > > Can I have some guidance on this one please? > > > > Putting them in share is just plain wrong, go fix it. And probably worth grumbling to the upstream maintainer, muttering words like FHS etc. From paul at all-the-johnsons.co.uk Wed Jun 7 14:43:16 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 07 Jun 2006 15:43:16 +0100 Subject: Binaries in /usr/share In-Reply-To: <1149690064.14694.60.camel@mrwibble.mrwobble> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> <1149690064.14694.60.camel@mrwibble.mrwobble> Message-ID: <1149691396.14694.64.camel@mrwibble.mrwobble> Hi, > > > Can I have some guidance on this one please? > > > > > > > Putting them in share is just plain wrong, go fix it. > > Will do - I'll try a local install and see if there is a problem just > altering the position of the binary and fixing the symlink, though > knowing mono, it won't be that simple... And hey presto! it isn't. It's hideously horrid as nant is hideously horrid. It's one of those packages which does as it's told fantastically as long as you don't change where things are (it relies of files being in a specific place from what I can see). Dammit. Suggestions? I've tried fixing nant build files before now and they are deeply unpleasant. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From notting at redhat.com Wed Jun 7 15:10:13 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Jun 2006 11:10:13 -0400 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070651.k576pBud009082@ludwig-alpha.unil.ch> References: <20060607022411.GA8458@lists.us.dell.com> <200606070651.k576pBud009082@ludwig-alpha.unil.ch> Message-ID: <20060607151013.GA6675@nostromo.devel.redhat.com> Christian.Iseli at licr.org (Christian.Iseli at licr.org) said: > Hi Matt, > > Matt_Domsch at dell.com said: > > Crediting Bill Nottingham and Jesse Keating here, they figured this out for > > my rebuild scripts. > > Thanks for sharing the script. Looks just like what I need! > > > wget -O fe-accept.csv \ "https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&query_format=advanced&... > > Any reason why the "query_format=advanced" parameter is repeated twice ? Bugzilla weirdness. I suspect any parameters of the form &= can be left out of the long URL. Bill From yoder1 at us.ibm.com Wed Jun 7 15:04:36 2006 From: yoder1 at us.ibm.com (Kent E Yoder) Date: Wed, 7 Jun 2006 09:04:36 -0600 Subject: rpmlint warnings/errors In-Reply-To: <20060607161815.0c001d0e.bugs.michael@gmx.net> Message-ID: fedora-extras-list-bounces at redhat.com wrote on 06/07/2006 09:18:15 AM: > On Wed, 7 Jun 2006 07:58:33 -0500, Daniel H Jones wrote: > > > There is a versioned .so file, however, applications that use this package > > often perform a dlopen(libopencryptoki.so, ...) at runtime. Removing this > > link from the base package would cause problems for those applications > > (or force the installer to create the symlinks themselves). > > No application should ever dlopen the non-versioned .so at run-time. If it > does, it needs to be patched. An application is built for a specific > API/ABI and must not expect an arbitrary .so to be the right one. You are absolutely correct under normal circumstances, but this is a bit of a special case. libopencryptoki.so implements the PKCS#11 API, which is designed to be used in exactly this way. PKCS#11 apps routinely provide a way for you to specify which PKCS#11 API .so you'd like to use. This is because different PKCS#11 implementations *should* be interchangeable, since they each provide the same API, but may support different hardware under the covers. In fact, fedora already ships one such program with the opensc package, "pkcs11-tool". > > DHJ> W: opencryptoki devel-file-in-non-devel-package > > DHJ> /usr/lib/libopencryptoki.so > > Also note that ldconfig creates a symbolic link from *.so to the most > recent versioned *.so.X, which would break such an application badly when > multiple versions are installed. In this case it shouldn't, and if it does, we have a bug to fix. :-) The PKCS#11 API actually provides an API to get its own list of implemented functions and API version level. PKCS#11 apps must be designed in such a way as to query these in order to keep from breaking. Thanks, Kent > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From toshio at tiki-lounge.com Wed Jun 7 15:19:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 08:19:18 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149667327.14694.2.camel@mrwibble.mrwobble> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149661191.5342.6.camel@localhost> <1149667327.14694.2.camel@mrwibble.mrwobble> Message-ID: <1149693559.5342.29.camel@localhost> On Wed, 2006-06-07 at 09:02 +0100, PFJ wrote: > > What's the easiest set of packages (preferably two already in Extras but > > I'll look at something under review if there isn't a whole stack of > > dependencies) that shows what the problem is? > > boo, nant and gtksourceview-sharp are all pretty trivial > nant doesn't seem to need the %{_libdir} hack. nant is an application. The package up for review puts its files into %{_datadir} and runs fine from there. I've built boo without the _libdir hack. What package should I compile with it that will show if everything works or not? Haven't looked at gtk-sourceview-sharp yet but the same question would apply to it as boo: Once I build it, what do I need to build to test it? > > Since mono applications > > in Core reside in %{_libdir} and Core's mono libraries only > > put .dll, .exe, and GAC files in %{_prefix}/lib/ (pkgconfig and > > ELF .so's go into %{_libdir}) I think there's something not quite right > > about the wiki's statement of problem and the "%define _libdir > > %{_prefix}/lib" solution. > > Not with you there - what do you mean? > Based upon where Core packages are located, I don't think the advice to redefine %{_libdir} is good. I want to figure out what's changed when %{_libdir} is redefined and fix those specific problems. -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 toshio at tiki-lounge.com Wed Jun 7 15:19:19 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 08:19:19 -0700 Subject: Hula -- mixed mono package In-Reply-To: <1149667327.14694.2.camel@mrwibble.mrwobble> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149661191.5342.6.camel@localhost> <1149667327.14694.2.camel@mrwibble.mrwobble> Message-ID: <1149693559.5342.30.camel@localhost> On Wed, 2006-06-07 at 09:02 +0100, PFJ wrote: > > What's the easiest set of packages (preferably two already in Extras but > > I'll look at something under review if there isn't a whole stack of > > dependencies) that shows what the problem is? > > boo, nant and gtksourceview-sharp are all pretty trivial > nant doesn't seem to need the %{_libdir} hack. nant is an application. The package up for review puts its files into %{_datadir} and runs fine from there. I've built boo without the _libdir hack. What package should I compile with it that will show if everything works or not? Haven't looked at gtk-sourceview-sharp yet but the same question would apply to it as boo: Once I build it, what do I need to build to test it? > > Since mono applications > > in Core reside in %{_libdir} and Core's mono libraries only > > put .dll, .exe, and GAC files in %{_prefix}/lib/ (pkgconfig and > > ELF .so's go into %{_libdir}) I think there's something not quite right > > about the wiki's statement of problem and the "%define _libdir > > %{_prefix}/lib" solution. > > Not with you there - what do you mean? > Based upon where Core packages are located, I don't think the advice to redefine %{_libdir} is good. I want to figure out what's changed when %{_libdir} is redefined and fix those specific problems. -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 paul at all-the-johnsons.co.uk Wed Jun 7 15:24:31 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 07 Jun 2006 16:24:31 +0100 Subject: Hula -- mixed mono package In-Reply-To: <1149693559.5342.30.camel@localhost> References: <1149612860.3413.18.camel@localhost> <1149615711.19529.1.camel@T7.Linux> <1149617243.3413.31.camel@localhost> <1149620348.19529.15.camel@T7.Linux> <1149661191.5342.6.camel@localhost> <1149667327.14694.2.camel@mrwibble.mrwobble> <1149693559.5342.30.camel@localhost> Message-ID: <1149693871.14694.78.camel@mrwibble.mrwobble> Hi, > > boo, nant and gtksourceview-sharp are all pretty trivial > > > nant doesn't seem to need the %{_libdir} hack. nant is an application. > The package up for review puts its files into %{_datadir} and runs fine > from there. I know - I've built boo and a few other apps with it. > I've built boo without the _libdir hack. What package should I compile > with it that will show if everything works or not? monodevelop - it won't work without the libdir hack > Haven't looked at gtk-sourceview-sharp yet but the same question would > apply to it as boo: Once I build it, what do I need to build to test > it? monodevelop. gtk is currently broken, but monodevelop will compile and start up. > > > Since mono applications > > > in Core reside in %{_libdir} and Core's mono libraries only > > > put .dll, .exe, and GAC files in %{_prefix}/lib/ (pkgconfig and > > > ELF .so's go into %{_libdir}) I think there's something not quite right > > > about the wiki's statement of problem and the "%define _libdir > > > %{_prefix}/lib" solution. > > > > Not with you there - what do you mean? > > > Based upon where Core packages are located, I don't think the advice to > redefine %{_libdir} is good. I want to figure out what's changed when > %{_libdir} is redefined and fix those specific problems. Fair enough. From the packages I've built using mono (which are quite a few), if something depends on a package (such as monodevelop requiring boo, ikvm, monodoc and gtksourceview-sharp), you really need the libdir hack. If it's a standalone (such as nant), it's not. However, for simplicity, having the hack there just means everything will always build. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From toshio at tiki-lounge.com Wed Jun 7 15:32:03 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 08:32:03 -0700 Subject: libdir and python on x86_64 In-Reply-To: <1149674566.24971.54.camel@otto.amantes> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> Message-ID: <1149694323.5342.38.camel@localhost> On Wed, 2006-06-07 at 12:02 +0200, Thomas Vander Stichele wrote: > > It seems to me that, for a set of packages that are going to share the > same module namespace, if any of them contains any arch-dependent code, > *ALL* of these packages need to go into sitearch. > > In Extras, this would apply to both Twisted and Flumotion. > > Does this seem correct, or am I missing something ? From skimming the python mailing list archives, I think this is correct for the present incarnation of python. Splitting the module is equivalent to having two modules with the same name and one of the modules will replace the other (rather than merging together.) -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 toshio at tiki-lounge.com Wed Jun 7 16:21:39 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 09:21:39 -0700 Subject: Binaries in /usr/share In-Reply-To: <645d17210606070742j651f8c8oe988f117f8cdc475@mail.gmail.com> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> <645d17210606070742j651f8c8oe988f117f8cdc475@mail.gmail.com> Message-ID: <1149697299.2794.2.camel@localhost> On Wed, 2006-06-07 at 15:42 +0100, Jonathan Underwood wrote: > On 07/06/06, Hans de Goede wrote: > > > Can I have some guidance on this one please? > > > > > > > Putting them in share is just plain wrong, go fix it. > > And probably worth grumbling to the upstream maintainer, muttering > words like FHS etc. > Java programs put their jars in /usr/share. Aren't PE's just as portable as java byte code? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Jun 7 16:43:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Jun 2006 18:43:19 +0200 Subject: FE package database In-Reply-To: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> Message-ID: <1149698599.2273.9.camel@localhost.localdomain> Am Mittwoch, den 07.06.2006, 10:05 +0200 schrieb Christian.Iseli at licr.org: > Package table: > > 1. product > 2. component > 3. description > 4. initialowner (current package owner) > 5. initialqacontact > 6. initialcclist (package co-maintainers) If'd prefer a solution where the initial owner (and maybe the initialcc list, too) could be repo-dependent. E.g. "foo" maintains "bar" for FC5 and devel, "baz" maintains it for FE4 and FE3 and also has "foo" in the initialcclist. > 7. review submitter > 8. review submit date > 9. reviewer > 10. accept date Are those really that important? Wouldn't the Bugzilla-ID suffice here? > 11. review request BZ ticket number > 12. current status (Active, Orphaned, Dropped, Moved to Core) > [...] CU thl -- Thorsten Leemhuis From toshio at tiki-lounge.com Wed Jun 7 16:56:30 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 09:56:30 -0700 Subject: Binaries in /usr/share In-Reply-To: <1149697299.2794.2.camel@localhost> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> <645d17210606070742j651f8c8oe988f117f8cdc475@mail.gmail.com> <1149697299.2794.2.camel@localhost> Message-ID: <1149699390.2794.5.camel@localhost> On Wed, 2006-06-07 at 09:21 -0700, Toshio Kuratomi wrote: > On Wed, 2006-06-07 at 15:42 +0100, Jonathan Underwood wrote: > > On 07/06/06, Hans de Goede wrote: > > > > Can I have some guidance on this one please? > > > > > > > > > > Putting them in share is just plain wrong, go fix it. > > > > And probably worth grumbling to the upstream maintainer, muttering > > words like FHS etc. > > > Java programs put their jars in /usr/share. Aren't PE's just as > portable as java byte code? I talked with caillon via IRC and it seems /usr/lib/mono itself should be moved to datadir when someone becomes sufficiently motivated to make it happen. So nant's usage of datadir seems correct. -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 paul at all-the-johnsons.co.uk Wed Jun 7 16:59:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 07 Jun 2006 17:59:23 +0100 Subject: Binaries in /usr/share In-Reply-To: <1149699390.2794.5.camel@localhost> References: <1149689250.14694.51.camel@mrwibble.mrwobble> <4486E03F.4010301@hhs.nl> <645d17210606070742j651f8c8oe988f117f8cdc475@mail.gmail.com> <1149697299.2794.2.camel@localhost> <1149699390.2794.5.camel@localhost> Message-ID: <1149699563.31232.2.camel@T7.Linux> Hi, > > Java programs put their jars in /usr/share. Aren't PE's just as > > portable as java byte code? > > I talked with caillon via IRC and it seems /usr/lib/mono itself should > be moved to datadir when someone becomes sufficiently motivated to make > it happen. So nant's usage of datadir seems correct. Excellent - any chance on some movement with the package reviews? ;-) TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Wed Jun 7 17:05:41 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 07 Jun 2006 11:05:41 -0600 Subject: FE package database In-Reply-To: <1149698599.2273.9.camel@localhost.localdomain> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> Message-ID: <44870765.2050000@cora.nwra.com> Thorsten Leemhuis wrote: > Am Mittwoch, den 07.06.2006, 10:05 +0200 schrieb > Christian.Iseli at licr.org: > >> 7. review submitter >> 8. review submit date >> 9. reviewer >> 10. accept date > > Are those really that important? Wouldn't the Bugzilla-ID suffice here? Do you want to track packages from pre-Bugzilla days? Yeah, I forgot about those days myself, so long ago. If so perhaps a URL to the mailling list archive as well. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From cweyl at alumni.drew.edu Wed Jun 7 17:50:45 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 7 Jun 2006 10:50:45 -0700 Subject: FE package database In-Reply-To: <1149698599.2273.9.camel@localhost.localdomain> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> Message-ID: <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> On 6/7/06, Thorsten Leemhuis wrote: > Am Mittwoch, den 07.06.2006, 10:05 +0200 schrieb > Christian.Iseli at licr.org: > > > Package table: > > > > 1. product > > 2. component > > 3. description > > 4. initialowner (current package owner) > > 5. initialqacontact > > 6. initialcclist (package co-maintainers) > > If'd prefer a solution where the initial owner (and maybe the initialcc > list, too) could be repo-dependent. E.g. "foo" maintains "bar" for FC5 > and devel, "baz" maintains it for FE4 and FE3 and also has "foo" in the > initialcclist. So here's a couple thoughts -- it would have taken more time to type it out than to show the table relationship in dia, so here goes: http://home.comcast.net/~ckweyl/fedora_package_db.dia And yes, it's just a sketch :) It also comes to mind, do we have actual requirements for what we want this database to be able to do? e.g. just track packages & owners, include builddeps, etc, etc? -Chris -- Chris Weyl Ex astris, scientia From j.w.r.degoede at hhs.nl Wed Jun 7 18:01:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 20:01:57 +0200 Subject: rpmlint warnings/errors In-Reply-To: References: Message-ID: <44871495.4040105@hhs.nl> Kent E Yoder wrote: > fedora-extras-list-bounces at redhat.com wrote on 06/07/2006 09:18:15 AM: > >> On Wed, 7 Jun 2006 07:58:33 -0500, Daniel H Jones wrote: >> >>> There is a versioned .so file, however, applications that use this > package >>> often perform a dlopen(libopencryptoki.so, ...) at runtime. Removing > this >>> link from the base package would cause problems for those applications >>> (or force the installer to create the symlinks themselves). >> No application should ever dlopen the non-versioned .so at run-time. If > it >> does, it needs to be patched. An application is built for a specific >> API/ABI and must not expect an arbitrary .so to be the right one. > > You are absolutely correct under normal circumstances, but this is a bit > of a special case. libopencryptoki.so implements the PKCS#11 API, which > is designed to be used in exactly this way. PKCS#11 apps routinely provide > a way for you to specify which PKCS#11 API .so you'd like to use. This is > because different PKCS#11 implementations *should* be interchangeable, > since they each provide the same API, but may support different hardware > under the covers. In fact, fedora already ships one such program with the > opensc package, "pkcs11-tool". > Then this is indeed very similar to the ctapi case, to be more precise, its exactly the same. May I suggest that you take a look at the ctapi-cyberjack review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369 An identical problem has been discussed and solved in this review and Ville, the maintainer of opensc was involved in this fix, I'm sure he is more then willing to "fix" opensc in much the same way he fixed the ctapi part of openct. Regards, Hans From bugs.michael at gmx.net Wed Jun 7 18:11:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 7 Jun 2006 20:11:47 +0200 Subject: rpmlint warnings/errors In-Reply-To: References: <20060607161815.0c001d0e.bugs.michael@gmx.net> Message-ID: <20060607201147.402c29ab.bugs.michael@gmx.net> On Wed, 7 Jun 2006 09:04:36 -0600, Kent E Yoder wrote: > > No application should ever dlopen the non-versioned .so at run-time. If > it > > does, it needs to be patched. An application is built for a specific > > API/ABI and must not expect an arbitrary .so to be the right one. > > You are absolutely correct under normal circumstances, but this is a bit > of a special case. libopencryptoki.so implements the PKCS#11 API, which > is designed to be used in exactly this way. PKCS#11 apps routinely provide > a way for you to specify which PKCS#11 API .so you'd like to use. This is > because different PKCS#11 implementations *should* be interchangeable, > since they each provide the same API, but may support different hardware > under the covers. In fact, fedora already ships one such program with the > opensc package, "pkcs11-tool". Well, then this is the kind of reply the reviewer should get, which explains why the .so is not in the -devel package. However, it would be better if these plugin DSOs were located in a special directory and not in standard library search path. > > > DHJ> W: opencryptoki devel-file-in-non-devel-package > > > DHJ> /usr/lib/libopencryptoki.so From notting at redhat.com Wed Jun 7 18:41:42 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Jun 2006 14:41:42 -0400 Subject: FE package database In-Reply-To: <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> Message-ID: <20060607184142.GA25286@nostromo.devel.redhat.com> Chris Weyl (cweyl at alumni.drew.edu) said: > It also comes to mind, do we have actual requirements for what we want > this database to be able to do? e.g. just track packages & owners, > include builddeps, etc, etc? Build deps would change per package, though. Perhaps keep track of metadata around the package, such as: - license - upstream location - upstream maintainer address - rpmlint exceptions - OIN status I'm sure others can come up with more info. Bill From dwight at supercomputer.org Wed Jun 7 18:12:03 2006 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Wed, 07 Jun 2006 11:12:03 -0700 Subject: taking over tripwire? Message-ID: <200606071812.k57IC3B1016385@lair.supercomputer.org> I'd like to take over the maintenance of the currently orphaned tripwire package, unless there's some objection. Also, for those who are interested in getting the latest version to actually install, I posted a patch up on tripwire's sourceforge site last week. -dwight- From adam at spicenitz.org Wed Jun 7 19:38:59 2006 From: adam at spicenitz.org (Adam Goode) Date: Wed, 07 Jun 2006 15:38:59 -0400 Subject: MLton (SML compiler) bootstrapping Message-ID: <44872B53.8070900@spicenitz.org> I am working on a spec file for MLton, a compiler for Standard ML. http://mlton.org/ Like compilers for C, Java, and Haskell, this SML compiler requires a binary version of itself to compile. I've looked over the situation from last year regarding ghc: http://www.redhat.com/archives/fedora-extras-list/2005-February/msg00387.html http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00450.html It looks like the solution was to provide a special one-time source package with binaries for all 3 platforms inside. Is this still the preferred solution? I have the spec file all worked out with "BuildRequires: mlton", but I can make this kind of bootstrap package if necessary. Alternatively, I can provide initial binary packages that could be injected into the repository. I built these on ppc and i386 using the binary packages from Debian. (MLton will soon, but doesn't yet, support x86_64.) For reference, I have put my current work here: http://www.spicenitz.org/fedora/mlton.spec http://www.spicenitz.org/fedora/mlton-20051202-1.src.rpm Thanks for any advice. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wtogami at redhat.com Wed Jun 7 19:45:27 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Jun 2006 15:45:27 -0400 Subject: FE package database In-Reply-To: <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> Message-ID: <44872CD7.3040707@redhat.com> Chris Weyl wrote: > So here's a couple thoughts -- it would have taken more time to type > it out than to show the table relationship in dia, so here goes: > > http://home.comcast.net/~ckweyl/fedora_package_db.dia > > And yes, it's just a sketch :) > > It also comes to mind, do we have actual requirements for what we want > this database to be able to do? e.g. just track packages & owners, > include builddeps, etc, etc? I'm glad that people are talking about possibilities of how to implement this, but we should step back and first think about what are our goals, what do we actually want out of this? I think a package database system would eventually encompass all kinds of information, but initially we must prioritize implementation of things that we need and dependent data structures. These below are a few higher priority items that we keep discussing as needed in FESCO meetings. - per-package per-branch fine grained ownership - multiple owners possible - package groups, subscription, notification - views of packages, change history and associated bugs - tracking of MIA owners, auto-nag, timeout, notification - tracking of neglected packages, timeout, notification - tracking of orphans The above would allow things like: - Build a package that breaks deps of other things in the distro. A background job detects this, and automatically notifies owners and whoever subscribed to watch affected packages. - Security team could know at-a-glance what is being neglected and step-in. Later we will be able to add things like: - All of the other informational metadata that wasn't required by the above but would be useful to view and search. This includes stuff like dependencies. - ACL access grant and revocation by owners at the package/branch level (this will become more important as we move closer to merging Core and Extras) Warren Togami wtogami at redhat.com From j.w.r.degoede at hhs.nl Wed Jun 7 19:53:31 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 21:53:31 +0200 Subject: rpmlint warnings/errors In-Reply-To: <20060607201147.402c29ab.bugs.michael@gmx.net> References: <20060607161815.0c001d0e.bugs.michael@gmx.net> <20060607201147.402c29ab.bugs.michael@gmx.net> Message-ID: <44872EBB.2090705@hhs.nl> Michael Schwendt wrote: > On Wed, 7 Jun 2006 09:04:36 -0600, Kent E Yoder wrote: > >>> No application should ever dlopen the non-versioned .so at run-time. If >> it >>> does, it needs to be patched. An application is built for a specific >>> API/ABI and must not expect an arbitrary .so to be the right one. >> You are absolutely correct under normal circumstances, but this is a bit >> of a special case. libopencryptoki.so implements the PKCS#11 API, which >> is designed to be used in exactly this way. PKCS#11 apps routinely provide >> a way for you to specify which PKCS#11 API .so you'd like to use. This is >> because different PKCS#11 implementations *should* be interchangeable, >> since they each provide the same API, but may support different hardware >> under the covers. In fact, fedora already ships one such program with the >> opensc package, "pkcs11-tool". > > Well, then this is the kind of reply the reviewer should get, which > explains why the .so is not in the -devel package. > > However, it would be better if these plugin DSOs were located in a special > directory and not in standard library search path. > As is done with ctapi DSO's which work essentially the same, I feel like I'm beating a dead horse here, please take a look at the ctapi-cyberjack review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369 Which has this fixed exactly as you suggest by putting them in a special dir while still providing a way for apps to find them. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jun 7 19:54:42 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 21:54:42 +0200 Subject: taking over tripwire? In-Reply-To: <200606071812.k57IC3B1016385@lair.supercomputer.org> References: <200606071812.k57IC3B1016385@lair.supercomputer.org> Message-ID: <44872F02.4000105@hhs.nl> dwight at supercomputer.org wrote: > I'd like to take over the maintenance of the currently orphaned > tripwire package, unless there's some objection. > > Also, for those who are interested in getting the latest version > to actually install, I posted a patch up on tripwire's sourceforge > site last week. > AFAIK the problem with tripwire is that it doesn't check SELinux security atrributes (ar any xattr for what thats worth) making its value significantly less then it used to be. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jun 7 19:57:29 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Jun 2006 21:57:29 +0200 Subject: FE package database In-Reply-To: <44872CD7.3040707@redhat.com> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> <44872CD7.3040707@redhat.com> Message-ID: <44872FA9.2060201@hhs.nl> Warren Togami wrote: > Chris Weyl wrote: >> So here's a couple thoughts -- it would have taken more time to type >> it out than to show the table relationship in dia, so here goes: >> >> http://home.comcast.net/~ckweyl/fedora_package_db.dia >> >> And yes, it's just a sketch :) >> >> It also comes to mind, do we have actual requirements for what we want >> this database to be able to do? e.g. just track packages & owners, >> include builddeps, etc, etc? > > I'm glad that people are talking about possibilities of how to implement > this, but we should step back and first think about what are our goals, > what do we actually want out of this? I think a package database system > would eventually encompass all kinds of information, but initially we > must prioritize implementation of things that we need and dependent data > structures. > > These below are a few higher priority items that we keep discussing as > needed in FESCO meetings. > > - per-package per-branch fine grained ownership > - multiple owners possible > - package groups, subscription, notification > - views of packages, change history and associated bugs > - tracking of MIA owners, auto-nag, timeout, notification > - tracking of neglected packages, timeout, notification > - tracking of orphans > > The above would allow things like: > > - Build a package that breaks deps of other things in the distro. A > background job detects this, and automatically notifies owners and > whoever subscribed to watch affected packages. > - Security team could know at-a-glance what is being neglected and step-in. > > Later we will be able to add things like: > > - All of the other informational metadata that wasn't required by the > above but would be useful to view and search. This includes stuff like > dependencies. > - ACL access grant and revocation by owners at the package/branch level > (this will become more important as we move closer to merging Core and > Extras) > May I add to this list: - per package rpmlint exception, so that a script can be created which as part of the build on the buildserver runs rpmlint on the created rpms and fails the resulting packages if they give any warnings/errors not on the exception list. Regards, Hans From dwight at supercomputer.org Wed Jun 7 20:09:14 2006 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Wed, 07 Jun 2006 13:09:14 -0700 Subject: taking over tripwire? In-Reply-To: Message from Hans de Goede of "Wed, 07 Jun 2006 21:54:42 +0200." <44872F02.4000105@hhs.nl> Message-ID: <200606072009.k57K9E3F017029@lair.supercomputer.org> > Date: Wed, 07 Jun 2006 21:54:42 +0200 > From: Hans de Goede > > dwight at supercomputer.org wrote: > > I'd like to take over the maintenance of the currently orphaned > > tripwire package, unless there's some objection. > > > > Also, for those who are interested in getting the latest version > > to actually install, I posted a patch up on tripwire's sourceforge > > site last week. > > > > AFAIK the problem with tripwire is that it doesn't check SELinux > security atrributes (ar any xattr for what thats worth) making its value > significantly less then it used to be. > > Regards, > > Hans Thanks, Hans. Yes, I had noticed the SELinux issue. Clearly this needs to be addressed. The first thing though, IMHO, is to get the source in sync with a more recent version than the one which Fedora currently uses. Then I was planning on dealing with the SELinux issues. I've been working with Ron Forrester recently (who maintains Open Source tripwire in general). It would be nice to try and keep the different versions in sync as much as possible. Regards, -dwight- From toshio at tiki-lounge.com Wed Jun 7 21:09:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 14:09:58 -0700 Subject: FE package database In-Reply-To: <44872CD7.3040707@redhat.com> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> <44872CD7.3040707@redhat.com> Message-ID: <1149714598.2794.10.camel@localhost> On Wed, 2006-06-07 at 15:45 -0400, Warren Togami wrote: > I'm glad that people are talking about possibilities of how to implement > this, but we should step back and first think about what are our goals, > what do we actually want out of this? I think a package database system > would eventually encompass all kinds of information, but initially we > must prioritize implementation of things that we need and dependent data > structures. I copied the information from Warren and Hans into the PackageDatabase page (since it didn't exist yet). I left space for implementation notes at the bottom but didn't fill it as I agree that the "what" is still open enough that the "how" could change drastically. http://www.fedoraproject.org/wiki/Extras/Schedule/PackageDatabase -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Jun 7 21:22:06 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 7 Jun 2006 15:22:06 -0600 Subject: taking over tripwire? In-Reply-To: <200606072009.k57K9E3F017029@lair.supercomputer.org> References: <44872F02.4000105@hhs.nl> <200606072009.k57K9E3F017029@lair.supercomputer.org> Message-ID: <80d7e4090606071422n4ded2ee5q7f6f12819054ecde@mail.gmail.com> On 6/7/06, dwight at supercomputer.org wrote: > > Date: Wed, 07 Jun 2006 21:54:42 +0200 > > From: Hans de Goede > > > > dwight at supercomputer.org wrote: > > > I'd like to take over the maintenance of the currently orphaned > > > tripwire package, unless there's some objection. > > > > > > Also, for those who are interested in getting the latest version > > > to actually install, I posted a patch up on tripwire's sourceforge > > > site last week. > > > > > > > AFAIK the problem with tripwire is that it doesn't check SELinux > > security atrributes (ar any xattr for what thats worth) making its value > > significantly less then it used to be. > > There are several problems with tripwire that I have seen mentioned in the last 2 years. We quit using tripwire due to the 64 bit problem and just went with rpm -V and some sha256 scripts to do files not loaded in rpm database. 1) Selinux/xattr aware 2) 64 bit compilation/working 3) Prelink aware 4) Licensing problems with later versions? -- Stephen J Smoogen. CSIRT/Linux System Administrator From chitlesh at fedoraproject.org Wed Jun 7 21:27:39 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 7 Jun 2006 23:27:39 +0200 Subject: rpath fails rpmbuild In-Reply-To: <4483239D.5060904@amiga-hardware.com> References: <13dbfe4f0606041017m2aef356bn89be0263ab4446af@mail.gmail.com> <4483239D.5060904@amiga-hardware.com> Message-ID: <13dbfe4f0606071427i7c2817c6r3701361abc70152f@mail.gmail.com> Hello Ian, It was nice to show me my mistakes, I have updated my spec file and uploading my src.rpm as well. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 2 of 9 issues are still unsolved as I mentioned in the BZ#193929 I need to work on them, later on. Chitlesh -- http://clunixchit.blogspot.com From wtogami at redhat.com Wed Jun 7 21:37:38 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Jun 2006 17:37:38 -0400 Subject: FE package database In-Reply-To: <1149714598.2794.10.camel@localhost> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> <44872CD7.3040707@redhat.com> <1149714598.2794.10.camel@localhost> Message-ID: <44874722.1020205@redhat.com> Toshio Kuratomi wrote: > On Wed, 2006-06-07 at 15:45 -0400, Warren Togami wrote: > >> I'm glad that people are talking about possibilities of how to implement >> this, but we should step back and first think about what are our goals, >> what do we actually want out of this? I think a package database system >> would eventually encompass all kinds of information, but initially we >> must prioritize implementation of things that we need and dependent data >> structures. > > I copied the information from Warren and Hans into the PackageDatabase > page (since it didn't exist yet). I left space for implementation notes > at the bottom but didn't fill it as I agree that the "what" is still > open enough that the "how" could change drastically. > > http://www.fedoraproject.org/wiki/Extras/Schedule/PackageDatabase > > -Toshio > http://fedoraproject.org/wiki/Infrastructure/PackageDatabase Hmm... I also put it here earlier. We should merge the info and reformat it at some point. Warren From dwmw2 at infradead.org Wed Jun 7 22:54:23 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Jun 2006 23:54:23 +0100 Subject: Extras build failures... Message-ID: <1149720864.1608.36.camel@shinybook.infradead.org> Whassup? -- dwmw2 -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Build Error (Job 10650): qemu-0_8_1-2_fc6 on fedora-development-extras Date: Wed, 7 Jun 2006 18:36:50 -0400 (EDT) Size: 3242 URL: From toshio at tiki-lounge.com Wed Jun 7 23:08:13 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 07 Jun 2006 16:08:13 -0700 Subject: FE package database In-Reply-To: <44874722.1020205@redhat.com> References: <200606070805.k5785iUK011970@ludwig-alpha.unil.ch> <1149698599.2273.9.camel@localhost.localdomain> <7dd7ab490606071050j74fdca1bt4bd689fc4aef8d5b@mail.gmail.com> <44872CD7.3040707@redhat.com> <1149714598.2794.10.camel@localhost> <44874722.1020205@redhat.com> Message-ID: <1149721694.2794.12.camel@localhost> On Wed, 2006-06-07 at 17:37 -0400, Warren Togami wrote: > Toshio Kuratomi wrote: > > http://www.fedoraproject.org/wiki/Extras/Schedule/PackageDatabase > > > > -Toshio > > > > http://fedoraproject.org/wiki/Infrastructure/PackageDatabase > > Hmm... I also put it here earlier. We should merge the info and > reformat it at some point. Looks like you have all the information on the Infrastructure/PackageDatabase page so I made Schedule/PackageDatabase a redirect to it. (Schedule/PackageDatabase was mentioned in the FESCo meeting minutes.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at stefan-neufeind.de Thu Jun 8 01:09:28 2006 From: fedora at stefan-neufeind.de (Stefan Neufeind) Date: Thu, 08 Jun 2006 03:09:28 +0200 Subject: knetworkmanager In-Reply-To: <200605290857.33486.dennis@ausil.us> References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> <1148897232.4310.806.camel@sundaram.pnq.redhat.com> <200605290857.33486.dennis@ausil.us> Message-ID: <448778C8.2010201@stefan-neufeind.de> Dennis Gilmore wrote: > On Monday 29 May 2006 5:07 am, Rahul Sundaram wrote: >> On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: >>> I was wondering if there were any current plans to include >>> knetworkmanager in extras. If not, then I'd like to request that it >>> be. I'm sure I'm not the only one who's been waiting for a way to use >>> NetworkManager with KDE. >> I havent seen any submissions. Would you like to get involved in >> packaging it? >> >> http://fedoraproject.org/wiki/Extras >> >> Rahul > Ive started work on packaging it. Im using it currently. I need to finish my > review of the dbus-qt bindings and then submit for review. Hi, I've tried recompiling the NetworkManager-kde-package from http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/src/ myself. Okay, in the Fedora-world names like "dbus-devel" instead of "dbus-3-devel" are used - no problem with that. But to me it seems that kdepim3-networkstatus (or kdepim-networkstatus in Fedora) is really needed - it seems there are several references to files from that package. However those headerfiles don't exist in kdepim-devel in Fedora which is 3.5.2-0.4.fc5. I've found that there is "networkstatus" in the kdepim-sourcepackage actually - but I didn't yet figure out why the current kdepim / kdepim doesn't ship with libnetworkstatus or any headerfiles for this functionlity. Regards, Stefan From katzj at redhat.com Thu Jun 8 02:09:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Jun 2006 22:09:41 -0400 Subject: Extras build failures... In-Reply-To: <1149720864.1608.36.camel@shinybook.infradead.org> References: <1149720864.1608.36.camel@shinybook.infradead.org> Message-ID: <448786E5.90507@redhat.com> David Woodhouse wrote: > Whassup? [snip] > Job failed because it was killed. Looks like we hit a deadlock in plague -- dgilmore said he's hit a few times. I kicked everything and things seem to be building more happily now Jeremy From michael at knox.net.nz Thu Jun 8 02:16:56 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 08 Jun 2006 14:16:56 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <4469877D.8030505@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> Message-ID: <44878898.4020305@knox.net.nz> Michael J Knox wrote: [snip] check out the achive for the rest ;) >> Let's start with X, maximum packager response time for a bugzilla ticket, >> in which a serious (or normal) bug was reported. Would X=14 days be too >> short? X+Y would cover at least two weekends. I mean, if a packager is on >> a long vacation (several weeks or more) and is neglecting package >> maintenance knowingly, the package would be suitable for shared >> maintainership anyway. And in cases where a packager has had an accident >> or is facing temporary illness (and similar things), we're back at what >> I've written before -- that it should be in the packager's best interest >> that other contributors help. >> > > I feel, that if an owner is considered "active" then he/she should be > able to at the very least, acknowledge a form of contact, direct email > or BZ, within a 3 week time frame. > > However, I think it needs to be more than one attempt over that time > frame. The person attempting the NMU must provide "proof" IMHO in the > form of BZ reports etc of these attempts. > > A formal accounacment of intent on the extras list would be required, in > case someone on the list knows the current owner where abouts. Ok, So I have somemore time to focus on this. So far I have only had comments from Michael Schwendt, but I would like to hear more from other FE maitainers. What sorts of time frames do people think is reasonable? How many contact attempts should there be? Michael From tibbs at math.uh.edu Thu Jun 8 02:24:06 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 07 Jun 2006 21:24:06 -0500 Subject: MLton (SML compiler) bootstrapping In-Reply-To: <44872B53.8070900@spicenitz.org> (Adam Goode's message of "Wed, 07 Jun 2006 15:38:59 -0400") References: <44872B53.8070900@spicenitz.org> Message-ID: >>>>> "AG" == Adam Goode writes: AG> It looks like the solution was to provide a special one-time AG> source package with binaries for all 3 platforms inside. Yes, this was used for fpc and cmucl as well. This method works well and has the added benefit of not require any overworked admins to manually handle the procedure. Keep in mind that packages are immediately available to the buildsystem as soon as they're built, so you can get your packages done without the special source package ever making it out to the mirrors. - J< From adam at spicenitz.org Thu Jun 8 02:27:20 2006 From: adam at spicenitz.org (Adam Goode) Date: Wed, 07 Jun 2006 22:27:20 -0400 Subject: MLton (SML compiler) bootstrapping In-Reply-To: References: <44872B53.8070900@spicenitz.org> Message-ID: <44878B08.5040306@spicenitz.org> Jason L Tibbitts III wrote: >>>>>> "AG" == Adam Goode writes: > > AG> It looks like the solution was to provide a special one-time > AG> source package with binaries for all 3 platforms inside. > > Yes, this was used for fpc and cmucl as well. This method works well > and has the added benefit of not require any overworked admins to > manually handle the procedure. > > Keep in mind that packages are immediately available to the > buildsystem as soon as they're built, so you can get your packages > done without the special source package ever making it out to the > mirrors. > Excellent! I hadn't realized that... but it makes sense. Thanks! Adam -------------- 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 all-the-johnsons.co.uk Thu Jun 8 06:13:08 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 08 Jun 2006 07:13:08 +0100 Subject: AWOL owners and stale packages. In-Reply-To: <44878898.4020305@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> Message-ID: <1149747189.31232.29.camel@T7.Linux> Hi, > So far I have only had comments from Michael Schwendt, but I would like > to hear more from other FE maitainers. Not quite - I did start a thread in a similar vein a short while back inspired by qparted. > What sorts of time frames do people think is reasonable? How many > contact attempts should there be? I think 5 should be enough contacts and preferably a month (depending on the package size) from initial BZ to acceptance. Okay, that does mean a lot more people acting as sponsors. A month is a good amount of time, though if the package is a large one (such as Amaya), this time frame may vary. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu Jun 8 06:31:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 08 Jun 2006 08:31:11 +0200 Subject: plib changes heads up Message-ID: <4487C42F.6050005@hhs.nl> Hi all, After some discussion with Matthias we both decided that it would be better if I took over as plib maintainer. One of the first changes I've made is to modify plib so that it builds shared libs instead of static ones. As of a few days there is a new plib release in the devel branch which offers these shared libs. As such it now also consists of 2 packages plib and plib-devel (previously we only had plib-devel). This should not affect existing packages since these are staticly linked against the previous release. Could everyone with a plib using package please build it (localy) against the new plib and let me know if it works (or not). I'm planning to push this new plib for FE-5 within a couple of days (notice once more this won't break existing apps, but new builds need some extra testing even though they should be fine). Regards, Hans From dwight at supercomputer.org Thu Jun 8 06:33:37 2006 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Wed, 07 Jun 2006 23:33:37 -0700 Subject: taking over tripwire? In-Reply-To: Message from "Stephen John Smoogen" of "Wed, 07 Jun 2006 15:22:06 MDT." <80d7e4090606071422n4ded2ee5q7f6f12819054ecde@mail.gmail.com> Message-ID: <200606080633.k586XbHX020244@lair.supercomputer.org> > From: "Stephen John Smoogen" > > There are several problems with tripwire that I have seen mentioned in > the last 2 years. We quit using tripwire due to the 64 bit problem and > just went with rpm -V and some sha256 scripts to do files not loaded > in rpm database. > > 1) Selinux/xattr aware > 2) 64 bit compilation/working > 3) Prelink aware > 4) Licensing problems with later versions? Thanks for the information. The rpm and scripts approach don't meet my own needs; hence my interest in dusting off tripwire for the more recent versions of Fedora. I'm familiar with the first three issues. But I haven't heard of any recent issues with the licensing. I've also mentioned my intentions to Ron, and he hasn't mentioned such an issue. If you have specifics on licensing problems, I'd be appreciative if you could pass them along. -dwight- From gemi at bluewin.ch Thu Jun 8 07:48:31 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 08 Jun 2006 09:48:31 +0200 Subject: MLton (SML compiler) bootstrapping In-Reply-To: References: <44872B53.8070900@spicenitz.org> Message-ID: <1149752911.20191.1.camel@scriabin.tannenrauch.ch> On Wed, 2006-06-07 at 21:24 -0500, Jason L Tibbitts III wrote: > >>>>> "AG" == Adam Goode writes: > > AG> It looks like the solution was to provide a special one-time > AG> source package with binaries for all 3 platforms inside. > > Yes, this was used for fpc and cmucl as well. This method works well > and has the added benefit of not require any overworked admins to > manually handle the procedure. > > Keep in mind that packages are immediately available to the > buildsystem as soon as they're built, so you can get your packages > done without the special source package ever making it out to the > mirrors. What happens when a new branch is created? This bootstrapping has to been done again, I presume, since the required package is not yet available. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From paul at all-the-johnsons.co.uk Thu Jun 8 09:10:12 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 08 Jun 2006 10:10:12 +0100 Subject: On the subject of sponsors... Message-ID: <1149757812.22694.9.camel@mrwibble.mrwobble> Hi, I had to be a nagging toad, but I currently have 8 packages waiting for sponsorship, 2 are not assigned and the others are really just sitting there (okay, that's a shade unfair, some have had some movement). All except one package are mono based which could be the reason for a lack of movement. In case anyone is interested, the BZ numbers and package names are... 177512 - mysql-connector-net (mono) 178901 - gtksourceview-sharp (mono - required for monodevelop) 178904 - monodevelop (mono - requires gtksourceview-sharp and boo) 182320 - gnome-build (required for anjuta-2.0.x) 189092 - boo (required for monodevelop, requires nant) 189093 - mono-debugger (mono) 189150 - mod-mono (mono - I know this has issues though) 193957 - nant (required for boo) mod-mono and nant are currently not assigned to anyone. In order of which I'd like seeing included in extras, it's 2-3-5-8 together, then 1, 4, 6, 7. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Thu Jun 8 09:18:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 08 Jun 2006 10:18:22 +0100 Subject: On the subject of sponsors... In-Reply-To: <1149757812.22694.9.camel@mrwibble.mrwobble> References: <1149757812.22694.9.camel@mrwibble.mrwobble> Message-ID: <4487EB5E.8070100@city-fan.org> s/sponsors/reviewers/g PFJ wrote: > I had to be a nagging toad, but I currently have 8 packages waiting for > sponsorship, 2 are not assigned and the others are really just sitting > there (okay, that's a shade unfair, some have had some movement). > > All except one package are mono based which could be the reason for a > lack of movement. I'm still looking for mono packaging standards to be sorted out; for instance, the %{_libdir} hack is still under debate, as is a move to put mono stuff under %{_datadir}. Paul. From paul at all-the-johnsons.co.uk Thu Jun 8 09:25:06 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 08 Jun 2006 10:25:06 +0100 Subject: On the subject of sponsors... In-Reply-To: <4487EB5E.8070100@city-fan.org> References: <1149757812.22694.9.camel@mrwibble.mrwobble> <4487EB5E.8070100@city-fan.org> Message-ID: <1149758707.22694.15.camel@mrwibble.mrwobble> Hi, > > All except one package are mono based which could be the reason for a > > lack of movement. > > I'm still looking for mono packaging standards to be sorted out; for > instance, the %{_libdir} hack is still under debate, as is a move to put > mono stuff under %{_datadir}. Would it be possible then to go through the packages, accepting the caveats you've put above and just check to see that they would be allowed? All seem happy under mock (which makes a change ;-p) I can understand the point about the libdir hack, but having tried just about every permutation to get packages not to require it, I can say that the hack is about the only sure fire way of ensuring packages which build on other packages actually work. I've tried as many hacks, tricks, patches and other such things as to give the average person a nose bleed! Putting the mono stuff in %{_datadir} currently is not that good an idea - mainly as upstream there are no plans to change how things are done in that respect. Other distros packaging mono and mono apps (SuSE especially) have no plans currently. I know some testing has been done, but the results were not that brilliant (as in quite a lot of packages just failed to work!) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From thomas at apestaart.org Thu Jun 8 09:34:51 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 08 Jun 2006 11:34:51 +0200 Subject: libdir and python on x86_64 In-Reply-To: <4486C915.5060702@redhat.com> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> <4486C915.5060702@redhat.com> Message-ID: <1149759292.24971.107.camel@otto.amantes> Hi, > > It seems to me that, for a set of packages that are going to share the > > same module namespace, if any of them contains any arch-dependent code, > > *ALL* of these packages need to go into sitearch. > > > > In Extras, this would apply to both Twisted and Flumotion. > > > > Does this seem correct, or am I missing something ? > > Hrmm... but how will this work with the non-arch-dependent packages > being noarch? Python handles this correctly. If module namespace A lives in the arch-dependent path, and module namespace B lives in the arch-independent one, then they can both be imported just fine. The problem I'm describing is when A.B is put in the arch-dependent one, and A.C in the arch-independent one. Then programs can only import A.B or A.C, but not both, effectively rendering A useless. Thomas From dwmw2 at infradead.org Thu Jun 8 09:42:18 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Jun 2006 10:42:18 +0100 Subject: Extras build failures... In-Reply-To: <448786E5.90507@redhat.com> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> Message-ID: <1149759738.13596.109.camel@pmac.infradead.org> On Wed, 2006-06-07 at 22:09 -0400, Jeremy Katz wrote: > Looks like we hit a deadlock in plague -- dgilmore said he's hit a few > times. I kicked everything and things seem to be building more happily now Ta. -- dwmw2 From buildsys at fedoraproject.org Thu Jun 8 10:57:41 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 8 Jun 2006 06:57:41 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-08 Message-ID: <20060608105741.608D6152151@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 24 OpenSceneGraph-1.0-4.fc5 compat-erlang-R10B-10.2.fc5 dia-0.95-4.fc5 freenx-0.5.0-0.3.test7.fc5 gallery2-2.1-0.21.svn20060524.fc5 gnubg-20060530-5.fc5 jed-0.99.18-4.fc5 keyutils-1.1-4.fc5 lilypond-2.8.4-1.fc5 lua-5.1-6.fc5 multitail-4.0.5-1.fc5 nx-1.5.0-9.fc5 perl-Module-CoreList-2.05-1.fc5 perl-Net-SCP-0.07-3.fc5 perl-Net-SSH-0.08-3.fc5 perl-Spreadsheet-ParseExcel-0.2603-1.fc5 perl-XML-XQL-0.68-2.fc5 rrdtool-1.0.50-4.fc5 scite-1.69-3.fc5 seamonkey-1.0.2-1.fc5 spicctrl-1.9-4.fc5 vpnc-0.3.3-7.2 xaos-3.2.1-2.fc5 xfwm4-4.2.3.2-5.fc5 Packages built and released for Fedora Extras 4: 15 OpenSceneGraph-0.9.9-5.fc4 compat-erlang-R10B-10.2.fc4.1 gallery2-2.1-0.21.svn20060524.fc4 kphotoalbum-2.2-3.fc4 libsigc++20-2.0.17-1 lua-5.1-6.fc4 multitail-4.0.5-1.fc4 perl-Module-CoreList-2.05-1.fc4 perl-Net-SCP-0.07-3.fc4 perl-Net-SSH-0.08-3.fc4 perl-Spreadsheet-ParseExcel-0.2603-1.fc4 scite-1.69-3.fc4 spicctrl-1.9-4.fc4 xaos-3.2.1-2.fc4 xfwm4-4.2.3.2-2.fc4 Packages built and released for Fedora Extras 3: 2 OpenSceneGraph-0.9.9-5.fc3 perl-Module-CoreList-2.05-1.fc3 Packages built and released for Fedora Extras development: 28 OpenSceneGraph-1.0-4.fc6 balsa-2.3.12-2.fc6 blobwars-1.05-2.fc6 compat-erlang-R10B-10.2.fc6 dia-0.95-4.fc6 gallery2-2.1-0.21.svn20060524.fc6 gnubg-20060530-5.fc6 jed-0.99.18-4.fc6 keyutils-1.1-4.fc6 lilypond-2.8.4-1.fc6 lilypond-doc-2.8.4-1.fc6 lua-5.1-6.fc6 man-pages-uk-0.1-0.2.20060328.fc6 multitail-4.0.5-1.fc6 nagios-plugins-1.4.3-6.fc6 nagios-plugins-1.4.3-7.fc6 perl-Module-CoreList-2.05-1.fc6 perl-Net-SCP-0.07-3.fc6 perl-Net-SSH-0.08-3.fc6 perl-Spreadsheet-ParseExcel-0.2603-1.fc6 perl-XML-XQL-0.68-2.fc6 rrdtool-1.2.13-4.fc6 seamonkey-1.0.2-1.fc6 spicctrl-1.9-4.fc6 tuxkart-0.4.0-4.fc6 xaos-3.2.1-2.fc6 xfwm4-4.2.3.2-5.fc6 xscreensaver-5.00-6.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bugs.michael at gmx.net Thu Jun 8 10:49:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Jun 2006 12:49:07 +0200 Subject: On the subject of sponsors... In-Reply-To: <1149757812.22694.9.camel@mrwibble.mrwobble> References: <1149757812.22694.9.camel@mrwibble.mrwobble> Message-ID: <20060608124907.f7671fe7.bugs.michael@gmx.net> On Thu, 08 Jun 2006 10:10:12 +0100, PFJ wrote: > Hi, > > I had to be a nagging toad, but I currently have 8 packages waiting for > sponsorship, 2 are not assigned and the others are really just sitting > there (okay, that's a shade unfair, some have had some movement). Packages are not sponsored. New contributors are sponsored. Packages are _reviewed_ and _approved_. [just a correction to the terminology] From paul at all-the-johnsons.co.uk Thu Jun 8 11:18:50 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 08 Jun 2006 12:18:50 +0100 Subject: Amaya Message-ID: <1149765530.22694.58.camel@mrwibble.mrwobble> Hi, It seems that the full source is required for amaya to build. There are some patches to use the system versions, but they have not been accepted into the main source branch. This causes some problems. 1. The gtk version is not as well support as wx and is a broken 2. The wx version ships with wx 2.6.2 3. The full blown version includes it's own mesa and a few other packages. All three are a pain in the backside. It seems that the main problem is that the package doesn't use anything the system provides, so it relies on it's own w3c-libwww et al. As it comes with it's own wx and mesa, this does give rise to a potential for package conflicts and that is a definite no-no. For now, I suggest leaving amaya as it stands, but I'll keep an eye upstream and continue to plow on trying to get amaya fixed for inclusion. The current version on the amaya site is 9.51 TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at all-the-johnsons.co.uk Thu Jun 8 11:19:45 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 08 Jun 2006 12:19:45 +0100 Subject: On the subject of sponsors... In-Reply-To: <20060608124907.f7671fe7.bugs.michael@gmx.net> References: <1149757812.22694.9.camel@mrwibble.mrwobble> <20060608124907.f7671fe7.bugs.michael@gmx.net> Message-ID: <1149765585.22694.60.camel@mrwibble.mrwobble> Hi, > > I had to be a nagging toad, but I currently have 8 packages waiting for > > sponsorship, 2 are not assigned and the others are really just sitting > > there (okay, that's a shade unfair, some have had some movement). > > Packages are not sponsored. > New contributors are sponsored. > Packages are _reviewed_ and _approved_. > > [just a correction to the terminology] Thanks. Any chance of some reviews then? Pretty please. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From buildsys at fedoraproject.org Thu Jun 8 11:14:02 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 08 Jun 2006 11:14:02 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-08 Message-ID: <20060608111402.18823.75814@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Thu Jun 8 11:14:02 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 08 Jun 2006 11:14:02 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-08 Message-ID: <20060608111402.18814.49432@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Thu Jun 8 11:14:02 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 08 Jun 2006 11:14:02 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-08 Message-ID: <20060608111402.18828.91110@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 rpy 0.4.6-10.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc rpy 0.4.6-10.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 rpy 0.4.6-10.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors ====================================================================== package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: rpy - 0.4.6-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: R = 0:2.3.0 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: rpy - 0.4.6-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: R = 0:2.3.0 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: rpy - 0.4.6-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: R = 0:2.3.0 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Thu Jun 8 11:14:02 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 08 Jun 2006 11:14:02 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-08 Message-ID: <20060608111402.18825.77182@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc5.i386 libopensync-plugin-evolution2 0.18-6.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- kphotoalbum 2.2-2.fc5.ppc libopensync-plugin-evolution2 0.18-6.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch kphotoalbum 2.2-2.fc5.x86_64 libopensync-plugin-evolution2 0.18-6.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: zipsonic AT gmail.com package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 ====================================================================== package: kphotoalbum - 2.2-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libexiv2-0.9.1.so package: libopensync-plugin-evolution2 - 0.18-6.fc5.i386 from fedora-extras-5-i386 unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: libopensync-plugin-evolution2 - 0.18-6.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libedata-cal-1.2.so.1()(64bit) libecal-1.2.so.3()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: kphotoalbum - 2.2-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libexiv2-0.9.1.so()(64bit) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: kphotoalbum - 2.2-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libexiv2-0.9.1.so package: libopensync-plugin-evolution2 - 0.18-6.fc5.ppc from fedora-extras-5-ppc unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 From rdieter at math.unl.edu Thu Jun 8 11:38:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Jun 2006 06:38:52 -0500 Subject: knetworkmanager References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> <1148897232.4310.806.camel@sundaram.pnq.redhat.com> <200605290857.33486.dennis@ausil.us> Message-ID: Dennis Gilmore wrote: > On Monday 29 May 2006 5:07 am, Rahul Sundaram wrote: >> On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: >> > I was wondering if there were any current plans to include >> > knetworkmanager in extras. If not, then I'd like to request that it >> > be. I'm sure I'm not the only one who's been waiting for a way to use >> > NetworkManager with KDE. >> >> I havent seen any submissions. Would you like to get involved in >> packaging it? >> http://fedoraproject.org/wiki/Extras > Ive started work on packaging it. Im using it currently. I need to finish > my review of the dbus-qt bindings and then submit for review. FYI, Dennis' review is complete, so dbus-qt (and dbus-qt-devel) are now available from Extras. -- Rex From dcbw at redhat.com Thu Jun 8 12:11:33 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 08 Jun 2006 08:11:33 -0400 Subject: Extras build failures... In-Reply-To: <448786E5.90507@redhat.com> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> Message-ID: <1149768693.3768.14.camel@localhost.localdomain> On Wed, 2006-06-07 at 22:09 -0400, Jeremy Katz wrote: > David Woodhouse wrote: > > Whassup? > [snip] > > Job failed because it was killed. > > Looks like we hit a deadlock in plague -- dgilmore said he's hit a few > times. I kicked everything and things seem to be building more happily now This means that the builder waited more than 30 minutes for the server to tell the builder that the repository is now unlocked. The repo locks when the server copies new packages to the repo, or updates the repodata, or also when Extras admins are running the push scripts, regenerating the repoview stuff, etc. I think we should bump up the timeout here, actually. It's not a problem on the builders, but an issue with the server and Extras release scripts. Dan From katzj at redhat.com Thu Jun 8 12:27:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jun 2006 08:27:21 -0400 Subject: libdir and python on x86_64 In-Reply-To: <1149759292.24971.107.camel@otto.amantes> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> <4486C915.5060702@redhat.com> <1149759292.24971.107.camel@otto.amantes> Message-ID: <448817A9.3080103@redhat.com> Thomas Vander Stichele wrote: > Hi, > >>> It seems to me that, for a set of packages that are going to share the >>> same module namespace, if any of them contains any arch-dependent code, >>> *ALL* of these packages need to go into sitearch. >>> >>> In Extras, this would apply to both Twisted and Flumotion. >>> >>> Does this seem correct, or am I missing something ? >> Hrmm... but how will this work with the non-arch-dependent packages >> being noarch? > > Python handles this correctly. If module namespace A lives in the > arch-dependent path, and module namespace B lives in the > arch-independent one, then they can both be imported just fine. Right, I completely understand this... > The problem I'm describing is when A.B is put in the arch-dependent one, > and A.C in the arch-independent one. Then programs can only import A.B > or A.C, but not both, effectively rendering A useless. But what you're saying is that both A.B and A.C need to be in the arch-dependent path. Which means that A.C can no longer be built as noarch (as if it is, where it ends up randomly depends on which arch it's built on) Jeremy From bdpepple at ameritech.net Thu Jun 8 12:28:51 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 08 Jun 2006 08:28:51 -0400 Subject: On the subject of sponsors... In-Reply-To: <1149757812.22694.9.camel@mrwibble.mrwobble> References: <1149757812.22694.9.camel@mrwibble.mrwobble> Message-ID: <1149769731.2479.4.camel@shuttle.piedmont.com> On Thu, 2006-06-08 at 10:10 +0100, PFJ wrote: > I had to be a nagging toad, but I currently have 8 packages waiting for > sponsorship, 2 are not assigned and the others are really just sitting > there (okay, that's a shade unfair, some have had some movement). The best way to get someone to review your packages, is to review other packages that are also waiting. It's a lot better way than constantly sending messages to the mailing 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 paul at city-fan.org Thu Jun 8 12:31:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 08 Jun 2006 13:31:49 +0100 Subject: libdir and python on x86_64 In-Reply-To: <448817A9.3080103@redhat.com> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> <4486C915.5060702@redhat.com> <1149759292.24971.107.camel@otto.amantes> <448817A9.3080103@redhat.com> Message-ID: <448818B5.4050600@city-fan.org> Jeremy Katz wrote: > Thomas Vander Stichele wrote: >> Hi, >> >>>> It seems to me that, for a set of packages that are going to share the >>>> same module namespace, if any of them contains any arch-dependent code, >>>> *ALL* of these packages need to go into sitearch. >>>> >>>> In Extras, this would apply to both Twisted and Flumotion. >>>> >>>> Does this seem correct, or am I missing something ? >>> Hrmm... but how will this work with the non-arch-dependent packages >>> being noarch? >> >> Python handles this correctly. If module namespace A lives in the >> arch-dependent path, and module namespace B lives in the >> arch-independent one, then they can both be imported just fine. > > Right, I completely understand this... > >> The problem I'm describing is when A.B is put in the arch-dependent one, >> and A.C in the arch-independent one. Then programs can only import A.B >> or A.C, but not both, effectively rendering A useless. > > But what you're saying is that both A.B and A.C need to be in the > arch-dependent path. Which means that A.C can no longer be built as > noarch (as if it is, where it ends up randomly depends on which arch > it's built on) How does one persuade an arch-independent python package to install itself into %{python_sitearch} instead of %{python_sitelib}? Is there an option to pass to "python setup.py" that will usually work? Paul. From ndbecker2 at gmail.com Thu Jun 8 13:12:50 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 08 Jun 2006 09:12:50 -0400 Subject: nx, freenx on x86_64 Message-ID: Thanks for adding nx, freenx to extras! Can we add i386 packages to x86_64 repository, please? From tibbs at math.uh.edu Thu Jun 8 13:13:38 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 08 Jun 2006 08:13:38 -0500 Subject: MLton (SML compiler) bootstrapping In-Reply-To: <1149752911.20191.1.camel@scriabin.tannenrauch.ch> =?iso-8859-1?q?=28G=E9rard?= Milmeister's message of "Thu, 08 Jun 2006 09:48:31 +0200") References: <44872B53.8070900@spicenitz.org> <1149752911.20191.1.camel@scriabin.tannenrauch.ch> Message-ID: >>>>> "GM" == G?rard Milmeister writes: GM> What happens when a new branch is created? You have to do the bootstrap for backwards branches (i.e. the first FC-5 branch creation). You won't have to do anything special when the FC-6 branch is made. For simplicity I would simply not request a build until everything branches, but there's nothing that says you have to do it that way. - J< From fedora at leemhuis.info Thu Jun 8 13:51:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Jun 2006 15:51:17 +0200 Subject: nx, freenx on x86_64 In-Reply-To: References: Message-ID: <1149774677.27607.23.camel@thl.ct.heise.de> Am Donnerstag, den 08.06.2006, 09:12 -0400 schrieb Neal Becker: > Thanks for adding nx, freenx to extras! > > Can we add i386 packages to x86_64 repository, please? No, I don't think that we should do that ATM -- or are there any *good* reasons for it? And did somebody check if that combination even works? And in any case: Just copying the i386 version over to the x86-64 repo because the maintainer couldn't fix it for x86-64 on it's own is the wrong approach IMHO because then we might have a bunch of i386 packages in the x86-64 soon just because maintainers were to lazy to fix their stuff (or find someone interested in x86-64 to fix it). Wine is a special exception because having wine.i386 is what most people probably want because that is able to execute 32-bit software (wine.x86_64 can only execute x64-binaries iirc and those are rare). CU thl From dtimms at bigpond.net.au Thu Jun 8 14:15:29 2006 From: dtimms at bigpond.net.au (David Timms) Date: Fri, 09 Jun 2006 00:15:29 +1000 Subject: When package review is finalised - add link to viewcvs ? Message-ID: <44883101.5000305@bigpond.net.au> Could there be a standard that when a package (ie .spec) bugzilla review is completed (and imported into cvs), that the comment in the bug should reference a viewcvs link to the imported spec file ? eg: # comment Imported into cvs: This would make it a lot easier to see how a .spec changed during review , and what the final polished version is without separate searching. It's hard to learn the process (what things to improve) from personal published .spec files that the packager erases from their web space ! It could become the last step in: http://fedoraproject.org/wiki/Extras/NewPackageProcessMarkTwo#head-280417153414c7968079e1592b4e415438127679 DaveT. From ndbecker2 at gmail.com Thu Jun 8 14:21:20 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 08 Jun 2006 10:21:20 -0400 Subject: nx, freenx on x86_64 References: <1149774677.27607.23.camel@thl.ct.heise.de> Message-ID: Thorsten Leemhuis wrote: > Am Donnerstag, den 08.06.2006, 09:12 -0400 schrieb Neal Becker: >> Thanks for adding nx, freenx to extras! >> >> Can we add i386 packages to x86_64 repository, please? > > No, I don't think that we should do that ATM -- or are there any *good* > reasons for it? And did somebody check if that combination even works? > 1. So that people that have a standard yum or smart setup on x86_64 can do install easily. Otherwise, they have to add i386 repos to their setup. In core, there are quite a few i386 packages in x86_64 repos so this is consistent with existing practice. 2. Yes, works for me. Except, it's only nx - freenx is noarch (my mistake) > And in any case: Just copying the i386 version over to the x86-64 repo > because the maintainer couldn't fix it for x86-64 on it's own is the > wrong approach IMHO because then we might have a bunch of i386 packages > in the x86-64 soon just because maintainers were to lazy to fix their > stuff (or find someone interested in x86-64 to fix it). > I don't know what it takes to fix this, but there are some cases where it really is a problem to get a x86_64 version. For example, there are some (few) packages that use i386 assembly. From toshio at tiki-lounge.com Thu Jun 8 15:27:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 08 Jun 2006 08:27:18 -0700 Subject: Mono Packaging (was Re: On the subject of sponsors...) In-Reply-To: <4487EB5E.8070100@city-fan.org> References: <1149757812.22694.9.camel@mrwibble.mrwobble> <4487EB5E.8070100@city-fan.org> Message-ID: <1149780438.3152.14.camel@localhost> On Thu, 2006-06-08 at 10:18 +0100, Paul Howarth wrote: > > I'm still looking for mono packaging standards to be sorted out; for > instance, the %{_libdir} hack is still under debate, as is a move to put > mono stuff under %{_datadir}. Are we collecting the open questions about packaging mono apps anywhere? http://www.fedoraproject.org/wiki/Packaging/Mono seems to be an instruction manual for packaging mono rather than a lit of questions we need to solve (and lists the _libdir hack as a solution a bit prematurely, IMHO) Another open question would be how this affects us: http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs It's advocating using .dlls with unstable APIs the same way we normally use static libraries (including a local copy with the application). It has all the usual features of a static library scheme but fails to mention any security issues. Should packages entering Fedora be checked to make sure they *do not* follow this or are mono .dlls immune to the security concerns with normal static libraries? PS: This is moving into general packaging territory so I'm cross-posting it to fedora-packaging. Replies to fedora-packaging please. -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 rdieter at math.unl.edu Thu Jun 8 15:56:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Jun 2006 10:56:41 -0500 Subject: rpms/wmx/FC-4 wmx.spec,1.7,1.8 References: <200606081537.k58FbdJJ016850@cvs-int.fedora.redhat.com> Message-ID: Gabriel L. Somlo (somlo) wrote: > RCS file: /cvs/extras/rpms/wmx/FC-4/wmx.spec,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- wmx.spec 7 Jun 2006 21:00:51 -0000 1.7 > +++ wmx.spec 8 Jun 2006 15:37:37 -0000 1.8 > @@ -32,8 +32,7 @@ > %patch3 -p1 > > %build > -# export LDFLAGS=-L/usr/X11R6/%{_lib} > -%configure > +%configure --x-libraries=%{_libdir} --x-includes=%{_includedir}/X11 AFAICT, this is correct only for fc5+, not the FC-4 branch. -- Rex From rdieter at math.unl.edu Thu Jun 8 16:09:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Jun 2006 11:09:02 -0500 Subject: rpms/wmx/FC-4 wmx.spec,1.7,1.8 References: <200606081537.k58FbdJJ016850@cvs-int.fedora.redhat.com> Message-ID: Rex Dieter wrote: > Gabriel L. Somlo (somlo) wrote: > >> RCS file: /cvs/extras/rpms/wmx/FC-4/wmx.spec,v >> retrieving revision 1.7 >> retrieving revision 1.8 >> diff -u -r1.7 -r1.8 >> --- wmx.spec 7 Jun 2006 21:00:51 -0000 1.7 >> +++ wmx.spec 8 Jun 2006 15:37:37 -0000 1.8 >> @@ -32,8 +32,7 @@ >> %patch3 -p1 >> >> %build >> -# export LDFLAGS=-L/usr/X11R6/%{_lib} >> -%configure >> +%configure --x-libraries=%{_libdir} --x-includes=%{_includedir}/X11 > > AFAICT, this is correct only for fc5+, not the FC-4 branch. Ignore me (I'm wrong)... not enough coffee yet. move along, nothing to see here. -- Rex From bpepple at fedoraproject.org Thu Jun 8 16:21:47 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 08 Jun 2006 12:21:47 -0400 Subject: Mono Packaging (was Re: On the subject of sponsors...) In-Reply-To: <1149780438.3152.14.camel@localhost> References: <1149757812.22694.9.camel@mrwibble.mrwobble> <4487EB5E.8070100@city-fan.org> <1149780438.3152.14.camel@localhost> Message-ID: <1149783707.5995.1.camel@shuttle.piedmont.com> On Thu, 2006-06-08 at 08:27 -0700, Toshio Kuratomi wrote: > Another open question would be how this affects us: > http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs > > It's advocating using .dlls with unstable APIs the same way we normally > use static libraries (including a local copy with the application). It > has all the usual features of a static library scheme but fails to > mention any security issues. Should packages entering Fedora be checked > to make sure they *do not* follow this or are mono .dlls immune to the > security concerns with normal static libraries? I agree this is something that should be decided, before we start getting more mono apps into Extras. /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 frank-buettner at gmx.net Thu Jun 8 16:50:51 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Thu, 08 Jun 2006 18:50:51 +0200 Subject: prevent to build packae for ppc Message-ID: <4488556B.3090400@gmx.net> Hello I have an package, with I know only work on x86. So I put an ExcludeArch: ppc in the spec file. But the package was build for PowerPC:( what goes wrong??? Thanks Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Thu Jun 8 16:58:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Jun 2006 18:58:26 +0200 Subject: prevent to build packae for ppc In-Reply-To: <4488556B.3090400@gmx.net> References: <4488556B.3090400@gmx.net> Message-ID: <20060608185826.0bd9dc68.bugs.michael@gmx.net> On Thu, 08 Jun 2006 18:50:51 +0200, Frank B?ttner wrote: > Hello I have an package, with I know only work on x86. > So I put an > ExcludeArch: ppc > in the spec file. > But the package was build for PowerPC:( > what goes wrong??? Don't try to cheat. You changed the spec file, but you didn't tag it appropriately before requesting a build. You asked the buildsys to fetch the previous version of spec file which has the tag 'ctapi-cyberjack-2_0_10-3_fc6'. From thomas at apestaart.org Thu Jun 8 16:59:27 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 08 Jun 2006 18:59:27 +0200 Subject: libdir and python on x86_64 In-Reply-To: <448817A9.3080103@redhat.com> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> <4486C915.5060702@redhat.com> <1149759292.24971.107.camel@otto.amantes> <448817A9.3080103@redhat.com> Message-ID: <1149785968.24971.143.camel@otto.amantes> Hi, > > The problem I'm describing is when A.B is put in the arch-dependent one, > > and A.C in the arch-independent one. Then programs can only import A.B > > or A.C, but not both, effectively rendering A useless. > > But what you're saying is that both A.B and A.C need to be in the > arch-dependent path. Which means that A.C can no longer be built as > noarch (as if it is, where it ends up randomly depends on which arch > it's built on) Correct. Compared with not working at all on x86_64 and working by accident on i386, I think this is the lesser of two evils. Note that most of the packages in question install binaries anyway, so they're already not parallel-installable. I don't think anyone has a need for having both a 32 bit and 64 bit version of flumotion or twisted running. Thomas From thomas at apestaart.org Thu Jun 8 17:00:37 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 08 Jun 2006 19:00:37 +0200 Subject: libdir and python on x86_64 In-Reply-To: <448818B5.4050600@city-fan.org> References: <20050601002201.09A943809C8@ningauble.scrye.com> <429D01B1.8060508@shahms.com> <20050601031818.6F8B5380D08@ningauble.scrye.com> <1117608411.4633.111.camel@bobcat.mine.nu> <20050603021844.9D35638113B@ningauble.scrye.com> <1117827118.3176.48.camel@localhost> <1149674566.24971.54.camel@otto.amantes> <4486C915.5060702@redhat.com> <1149759292.24971.107.camel@otto.amantes> <448817A9.3080103@redhat.com> <448818B5.4050600@city-fan.org> Message-ID: <1149786037.24971.146.camel@otto.amantes> Hi, > How does one persuade an arch-independent python package to install > itself into %{python_sitearch} instead of %{python_sitelib}? Is there an > option to pass to "python setup.py" that will usually work? The python modules that already have arch-dependant code in them automatically install correctly. The ones that have pure python code can be persuaded by --install-purelib %{python_sitearch} Thomas From zipsonic at gmail.com Thu Jun 8 17:03:36 2006 From: zipsonic at gmail.com (Rick Stout) Date: Thu, 08 Jun 2006 10:03:36 -0700 Subject: nx, freenx on x86_64 In-Reply-To: <20060608160027.126AB736DD@hormel.redhat.com> References: <20060608160027.126AB736DD@hormel.redhat.com> Message-ID: <44885868.1050305@gmail.com> > Thorsten Leemhuis wrote: > >> No, I don't think that we should do that ATM -- or are there any *good* >> reasons for it? And did somebody check if that combination even works? It does work. >> And in any case: Just copying the i386 version over to the x86-64 repo >> because the maintainer couldn't fix it for x86-64 on it's own is the >> wrong approach IMHO because then we might have a bunch of i386 packages >> in the x86-64 soon just because maintainers were to lazy to fix their >> stuff (or find someone interested in x86-64 to fix it). >> I *have* looked into getting this fixed for x86_64. I have been part of the freenx/nx project since 2004, and no one has successfully ran this on x86_64. I'm told that nxagent is not 64-bit safe, and that fixing it would require somewhat of a rewrite. I also think that it's a little rash to determine that maintainers are lazy because they have a package that does not work on all architectures. From bugs.michael at gmx.net Thu Jun 8 17:11:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Jun 2006 19:11:44 +0200 Subject: Fedora Extras Package Build Report 2006-06-08 In-Reply-To: <20060608105741.608D6152151@buildsys.fedoraproject.org> References: <20060608105741.608D6152151@buildsys.fedoraproject.org> Message-ID: <20060608191144.3850690b.bugs.michael@gmx.net> On Thu, 8 Jun 2006 06:57:41 -0400 (EDT), buildsys at fedoraproject.org wrote: > nagios-plugins-1.4.3-6.fc6 > nagios-plugins-1.4.3-7.fc6 This is no duplicate, which should have been eliminated. It is only because the network kicked me out while pushing builds, and due to that no sync happened for several hours. With the next push attempt, the next build of this package was available already. The push script, however, remembers all published releases up to when a sync succeeds. So, this is sort of two build reports in one. ;) [If all this sounds like it doesn't make any sense, rest assured, it does, it does.] From ville.skytta at iki.fi Thu Jun 8 17:13:21 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 08 Jun 2006 20:13:21 +0300 Subject: prevent to build packae for ppc In-Reply-To: <4488556B.3090400@gmx.net> References: <4488556B.3090400@gmx.net> Message-ID: <1149786801.8267.10.camel@localhost.localdomain> On Thu, 2006-06-08 at 18:50 +0200, Frank B?ttner wrote: > Hello I have an package, with I know only work on x86. > So I put an > ExcludeArch: ppc > in the spec file. > But the package was build for PowerPC:( > what goes wrong??? You seem to have tried to do a brown paper bag update without increasing the release tag. Bump it and try again. https://www.redhat.com/archives/fedora-extras-commits/2006-June/msg00680.html http://buildsys.fedoraproject.org/build-status/job.psp?uid=10715 From frank-buettner at gmx.net Thu Jun 8 17:41:26 2006 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Thu, 08 Jun 2006 19:41:26 +0200 Subject: prevent to build packae for ppc In-Reply-To: <1149786801.8267.10.camel@localhost.localdomain> References: <4488556B.3090400@gmx.net> <1149786801.8267.10.camel@localhost.localdomain> Message-ID: <44886146.9000209@gmx.net> Yes I have found it. There was 2 version's of the spec file:) Now I have the right one. This was happened because I have used the wrong backup for this file:( Sorry for that. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From kevin-fedora-extras at scrye.com Thu Jun 8 17:51:25 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 08 Jun 2006 11:51:25 -0600 (MDT) Subject: AWOL owners and stale packages. References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> Message-ID: <20060608.115125.96779216.kevin@scrye.com> >>>>> "Michael" == Michael J Knox writes: Michael> Michael J Knox wrote: [snip] check out the achive for the Michael> rest ;) >>> Let's start with X, maximum packager response time for a bugzilla >>> ticket, in which a serious (or normal) bug was reported. Would >>> X=14 days be too short? X+Y would cover at least two weekends. I >>> mean, if a packager is on a long vacation (several weeks or more) >>> and is neglecting package maintenance knowingly, the package would >>> be suitable for shared maintainership anyway. And in cases where a >>> packager has had an accident or is facing temporary illness (and >>> similar things), we're back at what I've written before -- that it >>> should be in the packager's best interest that other contributors >>> help. >>> >> I feel, that if an owner is considered "active" then he/she should >> be able to at the very least, acknowledge a form of contact, direct >> email or BZ, within a 3 week time frame. However, I think it needs >> to be more than one attempt over that time frame. The person >> attempting the NMU must provide "proof" IMHO in the form of BZ >> reports etc of these attempts. A formal accounacment of intent on >> the extras list would be required, in case someone on the list >> knows the current owner where abouts. Michael> Ok, So I have somemore time to focus on this. Michael> So far I have only had comments from Michael Schwendt, but I Michael> would like to hear more from other FE maitainers. Michael> What sorts of time frames do people think is reasonable? How Michael> many contact attempts should there be? How about something like: - When someone sees that a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like, they file a bug against the package in bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. - After every 7 days, the reporter adds a comment to the bug asking again for response. Others can add to the bug that they also were not successfull in contacting the maintainer, or providing additional contact information for the maintainer (ie, alternative email, irc, etc). - After 2 attempts (2 weeks) of no response from the maintainer, the reporter posts to the fedora-extras list with a url to the bug report and asks if anyone knows how to contact the maintainer. - After another 7 days (now 3 weeks total), the reporter posts to the extras list with the bug link and indicates that all attempts to contact the maintainer have failed and that they wish to take over the package. Additionally we could require the former maintainers sponsor to sign off on the change. I think the bug is important to be able to track things, and the maintainer should follow email from bugzilla for their packages anyhow. Just my 2cents. :) Michael> Michael kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Jun 8 18:04:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Jun 2006 20:04:44 +0200 Subject: nx, freenx on x86_64 In-Reply-To: References: <1149774677.27607.23.camel@thl.ct.heise.de> Message-ID: <1149789884.2428.7.camel@localhost.localdomain> Am Donnerstag, den 08.06.2006, 10:21 -0400 schrieb Neal Becker: > Thorsten Leemhuis wrote: > > > Am Donnerstag, den 08.06.2006, 09:12 -0400 schrieb Neal Becker: > >> Thanks for adding nx, freenx to extras! > >> Can we add i386 packages to x86_64 repository, please? > > No, I don't think that we should do that ATM -- or are there any *good* > > reasons for it? And did somebody check if that combination even works? > 1. So that people that have a standard yum or smart setup on x86_64 can do > install easily. Otherwise, they have to add i386 repos to their setup. That is a general thing and not much special for NX. > In > core, there are quite a few i386 packages in x86_64 repos so this is > consistent with existing practice. FESCo discussed this some months back and the consensus was "only wine.i386 for now; we might have a technical solution that might make handling i386 packages in the x86-64 repo easier after FC6". But if people want to change that now and work out a interim solution -- okay, please start a discussion (or continue this one). I'm lurking. > 2. Yes, works for me. Except, it's only nx - freenx is noarch (my mistake) > > > And in any case: Just copying the i386 version over to the x86-64 repo > > because the maintainer couldn't fix it for x86-64 on it's own is the > > wrong approach IMHO because then we might have a bunch of i386 packages > > in the x86-64 soon just because maintainers were to lazy to fix their > > stuff (or find someone interested in x86-64 to fix it). > I don't know what it takes to fix this, but there are some cases where it > really is a problem to get a x86_64 version. For example, there are some > (few) packages that use i386 assembly. And they should be fixed. But yes, I know it's a problem. But a pretty small one afaics. Cu thl -- Thorsten Leemhuis From fedora at leemhuis.info Thu Jun 8 18:11:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Jun 2006 20:11:51 +0200 Subject: nx, freenx on x86_64 In-Reply-To: <44885868.1050305@gmail.com> References: <20060608160027.126AB736DD@hormel.redhat.com> <44885868.1050305@gmail.com> Message-ID: <1149790311.2428.16.camel@localhost.localdomain> Am Donnerstag, den 08.06.2006, 10:03 -0700 schrieb Rick Stout: > > Thorsten Leemhuis wrote: > >> And in any case: Just copying the i386 version over to the x86-64 repo > >> because the maintainer couldn't fix it for x86-64 on it's own is the > >> wrong approach IMHO because then we might have a bunch of i386 packages > >> in the x86-64 soon just because maintainers were to lazy to fix their > >> stuff (or find someone interested in x86-64 to fix it). First: sorry, I didn't meant to be harsch. > I *have* looked into getting this fixed for x86_64. I have been part of > the freenx/nx project since 2004, and no one has successfully ran this > on x86_64. Okay. > I'm told that nxagent is not 64-bit safe, and that fixing it > would require somewhat of a rewrite. Great :-/ -- someone should tell the upstream developers that we're living in 2006 and most modern CPUs support the x86-64 extension. (someone probably already did). Well, that's life and we have to deal with it. > I also think that it's a little rash to determine that maintainers are > lazy because they have a package that does not work on all architectures. We had some of "lazy maintainers" that simply excluded x86_64 in the past and it took me and some others quite lot of work to fix most of them in the early days of Fedora Extras. Cu thl -- Thorsten Leemhuis From wtogami at redhat.com Thu Jun 8 19:07:44 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Jun 2006 15:07:44 -0400 Subject: nagios-plugins FC-3 branch request Message-ID: <44887580.5080407@redhat.com> By the new policy of branching for Legacy distros, FESCO approval is required for new branches of FC-3. The Fedora Infrastructure team requires nagios-plugins in order to help in monitoring and maintenance of the project infrastructure. This is a very obviously needed reason for granting branch exception for FC-3. mmcgrath isn't quite ready with a FC-3 package yet anyway, so I propose branching Monday if no FESCO members object. OK? Warren Togami wtogami at redhat.com From michael at knox.net.nz Thu Jun 8 20:32:02 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 09 Jun 2006 08:32:02 +1200 Subject: tinderbox. Message-ID: <44888942.20306@knox.net.nz> Hey all, I am wondering if anyone has tinderbox srpms kicking around? I saw an email from Elliot Lee on the Extras list about the middle of last year, but can't seem to find any follow ups after that. Michael From seg at haxxed.com Thu Jun 8 21:06:27 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Jun 2006 16:06:27 -0500 Subject: taking over tripwire? In-Reply-To: <80d7e4090606071422n4ded2ee5q7f6f12819054ecde@mail.gmail.com> References: <44872F02.4000105@hhs.nl> <200606072009.k57K9E3F017029@lair.supercomputer.org> <80d7e4090606071422n4ded2ee5q7f6f12819054ecde@mail.gmail.com> Message-ID: <1149800787.6780.29.camel@localhost> On Wed, 2006-06-07 at 15:22 -0600, Stephen John Smoogen wrote: > There are several problems with tripwire that I have seen mentioned in > the last 2 years. We quit using tripwire due to the 64 bit problem and > just went with rpm -V and some sha256 scripts to do files not loaded > in rpm database. > > 1) Selinux/xattr aware > 2) 64 bit compilation/working > 3) Prelink aware > 4) Licensing problems with later versions? What about AIDE? (http://www.cs.tut.fi/~rammer/aide.html) Its already in extras. Its at least is GPL and appears to be 64bit clean. Adding selinux/xattr/prelink support can't be that hugely difficult... I started running it on my (debian) server after I heard it detected a break in.. of Debian's servers. ;P -------------- 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 Thu Jun 8 21:48:20 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 08 Jun 2006 16:48:20 -0500 Subject: Retiring: R-gnomeGUI Message-ID: <1149803300.5199.65.camel@localhost.localdomain> The R-gnomeGUI package relies on ancient gnome libs to function, and since those libs are going away in -devel, I'm retiring this package. If anyone is motivated to do the work to port this code to gtk2, then I would be happy to give them ownership of this package. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From lists at forevermore.net Thu Jun 8 21:57:41 2006 From: lists at forevermore.net (Chris Petersen) Date: Thu, 08 Jun 2006 14:57:41 -0700 Subject: Thoughts about courier-mta packaging? In-Reply-To: <446E2D76.7020004@forevermore.net> References: <446E2D76.7020004@forevermore.net> Message-ID: <44889D55.4030308@forevermore.net> Top-posting myself to resubmitting this idea... I talked to Sam on the courier list, and he has no intention of ever submitting this to fedora for packaging (and contrary to what was previously thought, he's not on the extras mailing list, only the core list, and is not a contributor). So this goes back to the original question below... How flexible are the extras maintainers when it comes to allowing packages made from a really good upstream spec. It needs a little work, which I'd be willing to do (and would hope that Sam would incorporate upstream), but it's not worth it to me to rewrite (and maintain) a new spec from scratch. -Chris Chris Petersen wrote: > I use courier as a mail server both at work and at home, and have often > wondered why it wasn't included as part of fedora extras. > > Sam (the author) has built a wonderful multi-distro spec that works fine > (except for one missing build-dep that's specific to a package split in > fc4; an easy fix). > > I'd be more than happy to submit/maintain the package in extras if it > didn't require maintaining the spec myself -- it's HUGE and complicated > and there's no need to maintain a separate one when the upstream author > does it already. > > I couldn't find any info about courier in bugzilla or the list archives, > so I figured I'd toss it out here for a quick discussion before > submitting the idea for package review. > > -Chris > From somlo at cmu.edu Thu Jun 8 22:06:40 2006 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Thu, 8 Jun 2006 18:06:40 -0400 Subject: rpms/wmx/FC-4 wmx.spec,1.7,1.8 In-Reply-To: References: <20060608214803.8477873032@hormel.redhat.com> Message-ID: <20060608220640.GB20905@hedwig.net.cmu.edu> Rex Dieter wrote: > > > Gabriel L. Somlo (somlo) wrote: > > > >> RCS file: /cvs/extras/rpms/wmx/FC-4/wmx.spec,v ... > >> +%configure --x-libraries=%{_libdir} --x-includes=%{_includedir}/X11 > > > > AFAICT, this is correct only for fc5+, not the FC-4 branch. > > Ignore me (I'm wrong)... not enough coffee yet. move along, nothing > to see here. Actually, you were right -- the build for fc4 failed, and then succeeded after I reverted to %configure w/o the --x-libraries part... Gabriel From jkeating at redhat.com Thu Jun 8 22:52:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 08 Jun 2006 18:52:20 -0400 Subject: nagios-plugins FC-3 branch request In-Reply-To: <44887580.5080407@redhat.com> References: <44887580.5080407@redhat.com> Message-ID: <1149807140.11713.28.camel@ender> On Thu, 2006-06-08 at 15:07 -0400, Warren Togami wrote: > mmcgrath isn't quite ready with a FC-3 package yet anyway, so I > propose > branching Monday if no FESCO members object. > > OK? +1 Worksforme. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Thu Jun 8 22:59:01 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 8 Jun 2006 18:59:01 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-08 Message-ID: <20060608225901.70E8615217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jun 8 23:00:57 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 8 Jun 2006 19:00:57 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-08 Message-ID: <20060608230057.9EBFF15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jun 8 23:00:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 8 Jun 2006 19:00:59 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-08 Message-ID: <20060608230059.E637515217C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 3: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From MSchwartz at mn.rr.com Fri Jun 9 00:01:39 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Thu, 08 Jun 2006 19:01:39 -0500 Subject: Retiring: R-gnomeGUI In-Reply-To: <1149803300.5199.65.camel@localhost.localdomain> References: <1149803300.5199.65.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > The R-gnomeGUI package relies on ancient gnome libs to function, and > since those libs are going away in -devel, I'm retiring this package. If > anyone is motivated to do the work to port this code to gtk2, then I > would be happy to give them ownership of this package. > > ~spot Tom, Is this situation FC specific or more general for GNOME moving forward? It would be worth your posting this to r-devel to give folks a heads up on this pending situation, since undoubtedly, somebody will try to compile the CRAN package at some future date and find that it won't. In addition, Appendix D in the R Admin manual covers the building of the GUI and will need to be updated to reflect the change. Barring somebody wanting to port to gtk2, what was a spartan proof of concept GUI for R, it may be time to finally retire the CRAN package to orphan status. Or perhaps to simply make the code available for example purposes, but not have a functional version if the libs are no longer going to be available. That's a call for R Core to make. There are certainly better evolving GUI's for R for those that might want one. Best regards, Marc Schwartz From hugo at devin.com.br Fri Jun 9 00:14:33 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Thu, 8 Jun 2006 21:14:33 -0300 Subject: Security Patch in netpanzer (question) In-Reply-To: <20060608230059.E637515217C@buildsys.fedoraproject.org> References: <20060608230059.E637515217C@buildsys.fedoraproject.org> Message-ID: <200606082114.33519.hugo@devin.com.br> Hi, I'm trying to fix this bug in the netpanzer package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192990 It seems that the SVN version is ok, but I'm not a programmer to make a patch only to fix this vulnerability. An option would be to create and apply a patch to update the entire version to SVN instead of only the vulnerability fix. What do you think? What is the current method? If applying the patch to update entirely to the svn version, I must change the entire package's version or change only the release field in the specfile? Thanks! -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From dwmw2 at infradead.org Fri Jun 9 00:53:20 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Jun 2006 01:53:20 +0100 Subject: nx, freenx on x86_64 In-Reply-To: References: <1149774677.27607.23.camel@thl.ct.heise.de> Message-ID: <1149814401.18635.71.camel@shinybook.infradead.org> On Thu, 2006-06-08 at 10:21 -0400, Neal Becker wrote: > I don't know what it takes to fix this, but there are some cases where it > really is a problem to get a x86_64 version. For example, there are some > (few) packages that use i386 assembly. Ew, really? Do Red Hat engineers still have veto powers? Which packages? -- dwmw2 From dwmw2 at infradead.org Fri Jun 9 00:57:03 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Jun 2006 01:57:03 +0100 Subject: prevent to build packae for ppc In-Reply-To: <4488556B.3090400@gmx.net> References: <4488556B.3090400@gmx.net> Message-ID: <1149814623.18635.73.camel@shinybook.infradead.org> On Thu, 2006-06-08 at 18:50 +0200, Frank B?ttner wrote: > Hello I have an package, with I know only work on x86. > So I put an > ExcludeArch: ppc You need to file a bug if you do that, and make it block the 'Extras ExcludeArch PPC' bug. -- dwmw2 From tibbs at math.uh.edu Fri Jun 9 04:30:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 08 Jun 2006 23:30:45 -0500 Subject: Security Patch in netpanzer (question) In-Reply-To: <200606082114.33519.hugo@devin.com.br> (Hugo Cisneiros's message of "Thu, 8 Jun 2006 21:14:33 -0300") References: <20060608230059.E637515217C@buildsys.fedoraproject.org> <200606082114.33519.hugo@devin.com.br> Message-ID: >>>>> "HC" == Hugo Cisneiros writes: HC> It seems that the SVN version is ok, but I'm not a programmer to HC> make a patch only to fix this vulnerability. Upstream should be pretty well qualified to help you out here; have you contacted them? (I guess you must have; they seem to have taken a patch from you.) HC> An option would be to create and apply a patch to update the HC> entire version to SVN instead of only the vulnerability fix. That's rather suboptimal, but would work if nothing else does. You have to be careful that it's not less stable and doesn't break existing configurations. Ideally you'd just get a patch that fixes the issue. One possibility if upstream won't or can't help you is to go though their SVN tree and look for a commit that indicates it fixes the security issue. You may get lucky and can find something obvious, but it assumes that upstream provides useful comments. When I reported that CVE I did spend a little time looking through their tree but nothing jumped out of me. I just looked again; try looking at revisions 928, 929 and other revisions around that time. They seem to be related, although there are a lot of patches. Many of them seem to be trivial changes; perhaps you can pick out the fix. http://svn.berlios.de/viewcvs/netpanzer?rev=928&view=rev HC> If applying the patch to update entirely to the svn version, I HC> must change the entire package's version or change only the HC> release field in the specfile? I would indicate the version change; the naming guidelines have information on how to name snapshot packages: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb6f00cec9fe3623ea619f843394837 - J< From Christian.Iseli at licr.org Fri Jun 9 06:56:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 09 Jun 2006 08:56:19 +0200 Subject: Thoughts about courier-mta packaging? In-Reply-To: Your message of "Thu, 08 Jun 2006 14:57:41 PDT." <44889D55.4030308@forevermore.net> Message-ID: <200606090656.k596uNOe027667@mx3.redhat.com> lists at forevermore.net said: > How flexible are the extras maintainers when it comes to allowing packages > made from a really good upstream spec. It needs a little work, which I'd be > willing to do (and would hope that Sam would incorporate upstream), but it's > not worth it to me to rewrite (and maintain) a new spec from scratch. I guess if you want people to actually have a look and provide feedback, you should provide a pointer to the spec file... Christian From michael at knox.net.nz Fri Jun 9 07:18:42 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 09 Jun 2006 19:18:42 +1200 Subject: change to owners.list Message-ID: <448920D2.7050309@knox.net.nz> Can we have a marker of some sort to indicate a retired package? e.g. wizbang | Ultra cool thingy |extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org|dead.package| Michael From jamatos at fc.up.pt Fri Jun 9 07:24:47 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 9 Jun 2006 08:24:47 +0100 Subject: Retiring: R-gnomeGUI In-Reply-To: References: <1149803300.5199.65.camel@localhost.localdomain> Message-ID: <200606090824.47829.jamatos@fc.up.pt> On Friday 09 June 2006 01:01, Marc Schwartz wrote: > Tom, > > Is this situation FC specific or more general for GNOME moving forward? I am not Tom (I guess you already know that ;-) but if I remember correctly this is one of the packages with LinuxThreads. That means it will not run with FC5+. My memory is very fuzzy regarding this, so I could be wrong. > It would be worth your posting this to r-devel to give folks a heads up > on this pending situation, since undoubtedly, somebody will try to > compile the CRAN package at some future date and find that it won't. You are right. Do you want to volunteer? ;-) > Best regards, > > Marc Schwartz -- Jos? Ab?lio From paul at city-fan.org Fri Jun 9 07:35:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Jun 2006 08:35:55 +0100 Subject: prevent to build packae for ppc In-Reply-To: <1149814623.18635.73.camel@shinybook.infradead.org> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> Message-ID: <1149838555.31656.23.camel@laurel.intra.city-fan.org> On Fri, 2006-06-09 at 01:57 +0100, David Woodhouse wrote: > On Thu, 2006-06-08 at 18:50 +0200, Frank B?ttner wrote: > > Hello I have an package, with I know only work on x86. > > So I put an > > ExcludeArch: ppc > > You need to file a bug if you do that, and make it block the 'Extras > ExcludeArch PPC' bug. If if it really "only works on x86", shouldn't it be "ExclusiveArch" to that and not just "ExcludeArch PPC"? Paul. From j.w.r.degoede at hhs.nl Fri Jun 9 08:11:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Jun 2006 10:11:07 +0200 Subject: Security Patch in netpanzer (question) In-Reply-To: <200606082114.33519.hugo@devin.com.br> References: <20060608230059.E637515217C@buildsys.fedoraproject.org> <200606082114.33519.hugo@devin.com.br> Message-ID: <44892D1B.8060604@hhs.nl> Hugo Cisneiros wrote: > Hi, > > I'm trying to fix this bug in the netpanzer package: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192990 > > It seems that the SVN version is ok, but I'm not a programmer to make a patch > only to fix this vulnerability. An option would be to create and apply a > patch to update the entire version to SVN instead of only the vulnerability > fix. > > What do you think? What is the current method? > > If applying the patch to update entirely to the svn version, I must change the > entire package's version or change only the release field in the specfile? > Why don't you ask upstream to make a new release with their fix for this and the fix I've attached to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192983 for CVE-2006-2575? That sounds like a good reason to make a new release to me? Otherwise I would try to find the exact patch fixing this and backporting it, upgrading to a snapshot might cause all kinda problems including network protocol incompatibilities. Regards, Hans From frank-buettner at gmx.net Fri Jun 9 07:47:17 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Fri, 09 Jun 2006 09:47:17 +0200 Subject: prevent to build packae for ppc In-Reply-To: <1149838555.31656.23.camel@laurel.intra.city-fan.org> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> <1149838555.31656.23.camel@laurel.intra.city-fan.org> Message-ID: <44892785.5040006@gmx.net> Paul Howarth schrieb: > On Fri, 2006-06-09 at 01:57 +0100, David Woodhouse wrote: >> On Thu, 2006-06-08 at 18:50 +0200, Frank B?ttner wrote: >>> Hello I have an package, with I know only work on x86. >>> So I put an >>> ExcludeArch: ppc >> You need to file a bug if you do that, and make it block the 'Extras >> ExcludeArch PPC' bug. > > If if it really "only works on x86", shouldn't it be "ExclusiveArch" to > that and not just "ExcludeArch PPC"? > > Paul. > So long Fedora only support PPC and x86 I think it doesn't matter. Are there plains to support more systems? When somebody with an PPC system an the hardware for the cyberjack package can tell me that the kernel contains the module then I can remove the entry. But until the question is resolved I think it is cleaner do "disable" the build on ppc. Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Fri Jun 9 08:58:37 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Jun 2006 09:58:37 +0100 Subject: prevent to build packae for ppc In-Reply-To: <44892785.5040006@gmx.net> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> <1149838555.31656.23.camel@laurel.intra.city-fan.org> <44892785.5040006@gmx.net> Message-ID: <4489383D.8020106@city-fan.org> Frank B?ttner wrote: > Paul Howarth schrieb: >> On Fri, 2006-06-09 at 01:57 +0100, David Woodhouse wrote: >>> On Thu, 2006-06-08 at 18:50 +0200, Frank B?ttner wrote: >>>> Hello I have an package, with I know only work on x86. >>>> So I put an >>>> ExcludeArch: ppc >>> You need to file a bug if you do that, and make it block the 'Extras >>> ExcludeArch PPC' bug. >> If if it really "only works on x86", shouldn't it be "ExclusiveArch" to >> that and not just "ExcludeArch PPC"? >> >> Paul. >> > So long Fedora only support PPC and x86 I think it doesn't matter. > Are there plains to support more systems? Some people rebuild Extras packages for other distributions/hardware. For instance, there is Aurora Linux for sparc, which is based on Fedora. There are probably people doing the same for Itanium. > When somebody with an PPC system an the hardware for the cyberjack > package can tell me that the kernel contains the module then I can > remove the entry. But until the question is resolved I think it is > cleaner do "disable" the build on ppc. Can't you just download a ppc kernel rpm and use "rpm -qlp kernel-xxx.ppc.rpm" to see if the module is included? Paul. From buildsys at fedoraproject.org Fri Jun 9 08:59:21 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 9 Jun 2006 04:59:21 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-09 Message-ID: <20060609085921.A2E8715217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 23 ctapi-cyberjack-2.0.10-4.fc6 emacs-common-muse-3.02.91-4.fc6 erlang-esdl-0.95.0630-7.fc6 gallery2-2.1-0.22.svn20060524.fc6 glitz-0.5.6-3.fc6 gobby-0.4.0-3.rc2.fc6 libsvg-0.1.4-2.fc6 nazghul-0.5.3-5.fc6 nethack-vultures-2.1.0-1.fc6 pam_keyring-0.0.7-2 perl-File-Tail-0.99.3-5.fc6 perl-HTML-Mason-1.33-2.fc6 perl-Module-Install-0.63-1.fc6 perl-Module-Pluggable-3.01-1.fc6 perl-PAR-Dist-0.10-1.fc6 qemu-0.8.1-3.fc6 qt4-4.1.3-7.fc6 stripesnoop-1.5-6.fc6 texmaker-1.3-4.fc6 wings-0.98.32b-8.fc6 wmx-6pl1-13.fc6 xffm-4.2.3-4.fc6 xfprint-4.2.3-3.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Christian.Iseli at licr.org Fri Jun 9 09:28:57 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 09 Jun 2006 11:28:57 +0200 Subject: change to owners.list In-Reply-To: Your message of "Fri, 09 Jun 2006 19:18:42 +1200." <448920D2.7050309@knox.net.nz> Message-ID: <200606090928.k599Svp2000844@ludwig-alpha.unil.ch> michael at knox.net.nz said: > Can we have a marker of some sort to indicate a retired package? IMHO, we should put our energy into getting the new package database up and running (see http://fedoraproject.org/wiki/Infrastructure/PackageDatabase) instead of changing owners.list peacemeal. ATM, that information can be found in the CVS repository. My CHF 0.02 ... Cheers, Christian From buildsys at fedoraproject.org Fri Jun 9 09:59:21 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 9 Jun 2006 05:59:21 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-09 Message-ID: <20060609095921.5462215217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 17 erlang-esdl-0.95.0630-7.fc5 gallery2-2.1-0.22.svn20060524.fc5 glitz-0.5.6-3.fc5 kphotoalbum-2.2-3.fc5 man-pages-uk-0.1-0.2.20060328.fc5 nazghul-0.5.3-5.fc5 nethack-vultures-2.1.0-1.fc5 perl-File-Tail-0.99.3-5.fc5 qemu-0.8.1-3.fc5 qt4-4.1.3-7.fc5 stripesnoop-1.5-6.fc5 sunifdef-1.0.1-4.fc5 texmaker-1.3-4.fc5 wings-0.98.32b-8.fc5 wmx-6pl1-13.fc5 xffm-4.2.3-4.fc5 xfprint-4.2.3-3.fc5 Packages built and released for Fedora Extras 4: 15 emacs-auctex-11.82-12.fc4 erlang-esdl-0.95.0630-7.fc4 gallery2-2.1-0.22.svn20060524.fc4 man-pages-uk-0.1-0.2.20060328.fc4 nazghul-0.5.3-5.fc4 nethack-vultures-2.1.0-1.fc4 qt4-4.1.3-7.fc4 seamonkey-1.0.2-1.fc4 stripesnoop-1.5-6.fc4 sunifdef-1.0.1-4.fc4 texmaker-1.3-4.fc4 wings-0.98.32b-8.fc4 wmx-6pl1-13.fc4 xffm-4.2.3-2.fc4 xfprint-4.2.3-2.fc4 Packages built and released for Fedora Extras 3: 1 nethack-vultures-2.1.0-1.fc3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From frank-buettner at gmx.net Fri Jun 9 10:17:12 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Fri, 09 Jun 2006 12:17:12 +0200 Subject: prevent to build packae for ppc In-Reply-To: <4489383D.8020106@city-fan.org> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> <1149838555.31656.23.camel@laurel.intra.city-fan.org> <44892785.5040006@gmx.net> <4489383D.8020106@city-fan.org> Message-ID: <44894AA8.5030205@gmx.net> > > Can't you just download a ppc kernel rpm and use "rpm -qlp > kernel-xxx.ppc.rpm" to see if the module is included? > > Paul. > Good idea. Yes the module exits in this kernel. When now someone can tell me that this module will work than I can remove the arch exclude. Or shut I remove it and wait until someone tell me that it will not work?. What do you think will be better? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From buildsys at fedoraproject.org Fri Jun 9 10:11:53 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 10:11:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-09 Message-ID: <20060609101153.27822.29547@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Fri Jun 9 10:11:53 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 10:11:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-09 Message-ID: <20060609101153.27826.79393@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 rpy 0.4.6-10.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc rpy 0.4.6-10.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 rpy 0.4.6-10.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: rpy - 0.4.6-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: R = 0:2.3.0 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: rpy - 0.4.6-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: R = 0:2.3.0 package: rpy - 0.4.6-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: R = 0:2.3.0 package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 From buildsys at fedoraproject.org Fri Jun 9 10:11:53 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 10:11:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-09 Message-ID: <20060609101153.27809.54533@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Fri Jun 9 10:11:53 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 10:11:53 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-09 Message-ID: <20060609101153.27824.89130@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libopensync-plugin-evolution2 0.18-6.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libopensync-plugin-evolution2 0.18-6.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch libopensync-plugin-evolution2 0.18-6.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: libopensync-plugin-evolution2 - 0.18-6.fc5.i386 from fedora-extras-5-i386 unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 package: libopensync-plugin-evolution2 - 0.18-6.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libedata-cal-1.2.so.1()(64bit) libecal-1.2.so.3()(64bit) package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 package: libopensync-plugin-evolution2 - 0.18-6.fc5.ppc from fedora-extras-5-ppc unresolved deps: libedata-cal-1.2.so.1 libecal-1.2.so.3 From paul at all-the-johnsons.co.uk Fri Jun 9 10:38:36 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Fri, 9 Jun 2006 10:38:36 +0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-09 In-Reply-To: <20060609101153.27826.79393@extras64.linux.duke.edu> References: <20060609101153.27826.79393@extras64.linux.duke.edu> Message-ID: <20060609103836.M41979@all-the-johnsons.co.uk> Hi, > Summary of broken packages in fedora-extras-development-i386: > ---------------------------------------------------------------------- > Gtk-Perl 0.7008-40.fc5.i386 > R-gnomeGUI 2.1.0-5.fc5.i386 > diradmin 1.7.1-4.fc5.i386 > gtktalog 1.0.4-7.fc5.i386 > rpy 0.4.6-10.fc6.i386 > showimg-pgsql 0.9.5-5.fc5.i386 > syck-php 0.55-7.fc5.i386 How many of these are just waiting for a rebuild? Quite a few of these have been on here for a couple of weeks now. TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From paul at city-fan.org Fri Jun 9 10:43:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Jun 2006 11:43:22 +0100 Subject: prevent to build packae for ppc In-Reply-To: <44894AA8.5030205@gmx.net> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> <1149838555.31656.23.camel@laurel.intra.city-fan.org> <44892785.5040006@gmx.net> <4489383D.8020106@city-fan.org> <44894AA8.5030205@gmx.net> Message-ID: <448950CA.2030406@city-fan.org> Frank B?ttner wrote: >> Can't you just download a ppc kernel rpm and use "rpm -qlp >> kernel-xxx.ppc.rpm" to see if the module is included? >> >> Paul. >> > Good idea. > Yes the module exits in this kernel. > When now someone can tell me that this module will work than I can > remove the arch exclude. Or shut I remove it and wait until someone tell > me that it will not work?. > What do you think will be better? I'd remove it and wait for a bug report. If the package isn't available for ppc, nobody will even try it... Paul. From frank-buettner at gmx.net Fri Jun 9 11:29:01 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Fri, 09 Jun 2006 13:29:01 +0200 Subject: prevent to build packae for ppc In-Reply-To: <448950CA.2030406@city-fan.org> References: <4488556B.3090400@gmx.net> <1149814623.18635.73.camel@shinybook.infradead.org> <1149838555.31656.23.camel@laurel.intra.city-fan.org> <44892785.5040006@gmx.net> <4489383D.8020106@city-fan.org> <44894AA8.5030205@gmx.net> <448950CA.2030406@city-fan.org> Message-ID: <44895B7D.9040206@gmx.net> Paul Howarth schrieb: > I'd remove it and wait for a bug report. > > If the package isn't available for ppc, nobody will even try it... > > Paul. > Yes this is an good choice. I will commend out the exclude. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From dwmw2 at infradead.org Fri Jun 9 11:31:36 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Jun 2006 12:31:36 +0100 Subject: Extras build failures... In-Reply-To: <1149768693.3768.14.camel@localhost.localdomain> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> <1149768693.3768.14.camel@localhost.localdomain> Message-ID: <1149852696.5213.94.camel@pmac.infradead.org> On Thu, 2006-06-08 at 08:11 -0400, Dan Williams wrote: > I think we should bump up the timeout here, actually. It's not a > problem on the builders, but an issue with the server and Extras > release scripts. Can't we just fix the locking? Surely we don't need to lock the repo for the _whole_ period of the upload. You can upload the new packages, then lock, then create metadata, then unlock. You don't need it locked for more than the few seconds it takes to update the metadata for the new packages, surely? -- dwmw2 From skvidal at linux.duke.edu Fri Jun 9 11:37:21 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 09 Jun 2006 07:37:21 -0400 Subject: Extras build failures... In-Reply-To: <1149852696.5213.94.camel@pmac.infradead.org> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> <1149768693.3768.14.camel@localhost.localdomain> <1149852696.5213.94.camel@pmac.infradead.org> Message-ID: <1149853041.8221.0.camel@cutter> On Fri, 2006-06-09 at 12:31 +0100, David Woodhouse wrote: > On Thu, 2006-06-08 at 08:11 -0400, Dan Williams wrote: > > I think we should bump up the timeout here, actually. It's not a > > problem on the builders, but an issue with the server and Extras > > release scripts. > > Can't we just fix the locking? Surely we don't need to lock the repo for > the _whole_ period of the upload. You can upload the new packages, then > lock, then create metadata, then unlock. You don't need it locked for > more than the few seconds it takes to update the metadata for the new > packages, surely? it takes longer than a few seconds to update the metadata. -sv From MSchwartz at mn.rr.com Fri Jun 9 12:18:51 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Fri, 09 Jun 2006 07:18:51 -0500 Subject: Retiring: R-gnomeGUI In-Reply-To: <200606090824.47829.jamatos@fc.up.pt> References: <1149803300.5199.65.camel@localhost.localdomain> <200606090824.47829.jamatos@fc.up.pt> Message-ID: Jose' Matos wrote: > On Friday 09 June 2006 01:01, Marc Schwartz wrote: >> Tom, >> >> Is this situation FC specific or more general for GNOME moving forward? > > I am not Tom (I guess you already know that ;-) but if I remember correctly > this is one of the packages with LinuxThreads. That means it will not run > with FC5+. > > My memory is very fuzzy regarding this, so I could be wrong. Jos?, I could not find anything easily with respect to documentation on that requirement, unless it is implicit in the libs requirements. I do note that it is available in FC5's Extras. Should I presume that this indicates that it does build and function properly on FC5? If so, it would suggest that the LinuxThreads requirement is not in place. Let me know on that if you could. >> It would be worth your posting this to r-devel to give folks a heads up >> on this pending situation, since undoubtedly, somebody will try to >> compile the CRAN package at some future date and find that it won't. > > You are right. Do you want to volunteer? ;-) I am happy to. If you can clarify the above issue, I will post the note for R Core. Best regards, Marc From dcbw at redhat.com Fri Jun 9 13:42:59 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 09 Jun 2006 09:42:59 -0400 Subject: Extras build failures... In-Reply-To: <1149852696.5213.94.camel@pmac.infradead.org> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> <1149768693.3768.14.camel@localhost.localdomain> <1149852696.5213.94.camel@pmac.infradead.org> Message-ID: <1149860579.2407.2.camel@localhost.localdomain> On Fri, 2006-06-09 at 12:31 +0100, David Woodhouse wrote: > On Thu, 2006-06-08 at 08:11 -0400, Dan Williams wrote: > > I think we should bump up the timeout here, actually. It's not a > > problem on the builders, but an issue with the server and Extras > > release scripts. > > Can't we just fix the locking? Surely we don't need to lock the repo for > the _whole_ period of the upload. You can upload the new packages, then > lock, then create metadata, then unlock. You don't need it locked for > more than the few seconds it takes to update the metadata for the new > packages, surely? The Extras push scripts have apparently been optimized to copy stuff too, unlock, then delete, or something like that, so the locked period is now shorter. But we can't get away from locking; the builders can't start building the mock chroots while the repodata is getting updated on the server. Though, I just thought of a few optimizations to take. Previously I'd been making really conservative approaches to this, but I think we only need to lock the repo on the server while the repodata is regenerated, not for the whole copy + repodata process. But that likely only saves a few seconds on a box with fast storage. Dan From thomas at apestaart.org Fri Jun 9 14:05:44 2006 From: thomas at apestaart.org (thomas at apestaart.org) Date: Fri, 9 Jun 2006 16:05:44 +0200 (CEST) Subject: RELEASE: Mach 0.9.0 'Cambria' Message-ID: <20060609140544.9A40DEFC0D@otto.amantes> This mail announces the release of Mach 0.9.0 'Cambria'. mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. Currently, this is limited to RPM-based distributions. This clean build root can be used for making clean packages, running jailed services, testing builds, or making disk images of clean roots. For more information, see [http://thomas.apestaart.org/projects/mach/] To file bugs, go to [https://apestaart.org/thomas/trac/newticket] -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.9.0 - Cambria. WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Fedora 4, 5 (core, updated, extras, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Fedora 1, 2, 3 (core, updated, www.fedora.us, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Red Hat 8.0, 9 (basic, updated, www.fedora.us, rpm.livna.org, JPackage, GStreamer, FreshRPMS) - Red Hat 7.2, 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.0, 7.1 (basic, updated, FreshRPMS) - SuSE 8.1/8.2/9 - Connectiva - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Dave/Dina 0.0/oven/fridge Read the README included in the distribution for a better overview. CHANGES ------- - Fix livna.org and rawhide URL's (Ville) - Fix "revert to build list" such that it can deal with upgraded versions of the build packages, as well as deal with packages with broken post/postun scripts (Thomas) - make sure we refresh local repository cache with yum >= 2.6.0 (Nigel) - always recreate repository config files, so that changes to "location" are effective immediately (Thomas) - Add JPackage URL's for FC3, 4, 5 (Ville) - mach clean also cleans out the local repo (Thomas) WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Fedora 4 Core system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/fedora/linux/4/i386/SRPMS.core/vorbis-tools-1.0.1-6.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! MAILING LIST ------------ A mailing list has been set up for discussion of mach use and development. Check http://lists.sourceforge.net/lists/listinfo/mach-devel for information. The list is low-volume. BUGS ---- To file bugs, go to https://apestaart.org/thomas/trac Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). CONTRIBUTORS ------------ Contributors to releases include - Thomas Vander Stichele - Ville Skytt?? - Jeff Pitman - Rudi Chiarito - Matthias Saou - Nigel Metheringham From kevin.kofler at chello.at Fri Jun 9 14:05:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 9 Jun 2006 14:05:51 +0000 (UTC) Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-09 References: <20060609101153.27824.89130@extras64.linux.duke.edu> Message-ID: > syck-php 0.55-7.fc5.i386 I filed bug #192798 for that more than 2 weeks ago, it's still not being rebuilt, what's up? > libopensync-plugin-evolution2 0.18-6.fc5.i386 This needs a rebuild for the new evolution-data-server. Can the maintainer please rebuild this? Kevin Kofler From bugs.michael at gmx.net Fri Jun 9 14:21:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 9 Jun 2006 16:21:22 +0200 Subject: Extras build failures... In-Reply-To: <1149853041.8221.0.camel@cutter> References: <1149720864.1608.36.camel@shinybook.infradead.org> <448786E5.90507@redhat.com> <1149768693.3768.14.camel@localhost.localdomain> <1149852696.5213.94.camel@pmac.infradead.org> <1149853041.8221.0.camel@cutter> Message-ID: <20060609162122.07d93397.bugs.michael@gmx.net> On Fri, 09 Jun 2006 07:37:21 -0400, seth vidal wrote: > On Fri, 2006-06-09 at 12:31 +0100, David Woodhouse wrote: > > On Thu, 2006-06-08 at 08:11 -0400, Dan Williams wrote: > > > I think we should bump up the timeout here, actually. It's not a > > > problem on the builders, but an issue with the server and Extras > > > release scripts. > > > > Can't we just fix the locking? Surely we don't need to lock the repo for > > the _whole_ period of the upload. You can upload the new packages, then > > lock, then create metadata, then unlock. Danger. It would be possible for the push script to fetch partial uploads from the needsign repo. Unless you upload to a tmp dir, then lock, move, createrepo, unlock. > > You don't need it locked for > > more than the few seconds it takes to update the metadata for the new > > packages, surely? > > it takes longer than a few seconds to update the metadata. No repo is locked when repodata and repoview are updated by the push script. The push script locks the needsign queue only for a short period. See my recent message to buildsys-list, which explains it. There is only one lock file per dist repo, which blocks plague from updating a needsign repository while the push script is accessing it and vice versa. This file is locked only for the short time it takes to enter the passphrase, sign packages and let them install into the local master repository. The time-consuming operations (repomanage, createrepo, repoview, sync to public master repo) are performed on the local master repo, where no locking is implemented. Btw, it would not be possible to protect any yum/mock clients from accessing the public (!) master repository while a sync is in progress. You could only play tricks like doing multiple syncs, first a no-delete sync of all new packages, excluding repodata, then another sync with the new repodata, trying to make the files available as quickly as possible, then another sync to delete gone files. And it still would not be bullet-proof -- adding files plus updating metadata would need to be an atomic operation. One major problem with the push script was that _it modified rpms_ in the needsign repo. It signed them, thereby invalidating the metadata. It _moved_ them away into the local master repo, leaving build servers with a temporarily broken needsign repo until the updates arrived at download.fedora.redhat.com. (The older push script even mailed the build report long before the actual sync.) However, the situation has changed last night, and I've modified the new push script even further to work on copies of rpms. Packages in the needsign repo now are not modified or moved by the push script. Pushed and unneeded builds expire after some time (48 hours currently). From hugo at devin.com.br Fri Jun 9 14:32:23 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 9 Jun 2006 11:32:23 -0300 Subject: Security Patch in netpanzer (question) In-Reply-To: <44892D1B.8060604@hhs.nl> References: <20060608230059.E637515217C@buildsys.fedoraproject.org> <200606082114.33519.hugo@devin.com.br> <44892D1B.8060604@hhs.nl> Message-ID: <200606091132.23231.hugo@devin.com.br> On Friday 09 June 2006 05:11, Hans de Goede wrote: > Hugo Cisneiros wrote: > > Hi, > > > > I'm trying to fix this bug in the netpanzer package: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192990 > > > > It seems that the SVN version is ok, but I'm not a programmer to make a > > patch only to fix this vulnerability. An option would be to create and > > apply a patch to update the entire version to SVN instead of only the > > vulnerability fix. > > > > What do you think? What is the current method? > > > > If applying the patch to update entirely to the svn version, I must > > change the entire package's version or change only the release field in > > the specfile? > > Why don't you ask upstream to make a new release with their fix for this > and the fix I've attached to: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192983 > for CVE-2006-2575? > > That sounds like a good reason to make a new release to me? I've applied your fix and it works very well, thanks! I'm trying to get the other fix first, then package both fixes as one release. The maintainer isn't doing this package anymore. He is looking for new maintainers and have said that no more versions will be released from him (I already asked him too ;-) >From the official home-page: http://netpanzer.berlios.de 12. Nov 2005 Looking for a new maintainer The last months I was very busy with university and other open source projects I'm working on. So effectively netpanzer development has halted. I'm looking for someone to take over the netpanzer development. If you're interested write a mail to matze at braunis.de. > Otherwise I would try to find the exact patch fixing this and > backporting it, upgrading to a snapshot might cause all kinda problems > including network protocol incompatibilities. I'll try to do this... It will be much difficult because I'm not a programmer, but I'll try beggining now ;-) Thanks for your reply. > Regards, > Hans -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From hugo at devin.com.br Fri Jun 9 15:20:37 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 9 Jun 2006 12:20:37 -0300 Subject: Security Patch in netpanzer (question) In-Reply-To: <200606091132.23231.hugo@devin.com.br> References: <20060608230059.E637515217C@buildsys.fedoraproject.org> <44892D1B.8060604@hhs.nl> <200606091132.23231.hugo@devin.com.br> Message-ID: <200606091220.37952.hugo@devin.com.br> On Friday 09 June 2006 11:32, Hugo Cisneiros wrote: > On Friday 09 June 2006 05:11, Hans de Goede wrote: > > Otherwise I would try to find the exact patch fixing this and > > backporting it, upgrading to a snapshot might cause all kinda problems > > including network protocol incompatibilities. > > I'll try to do this... It will be much difficult because I'm not a > programmer, but I'll try beggining now ;-) Thanks for your reply. I found a patch from Gentoo here: http://mirror.etf.bg.ac.yu/gentoorsync/games-strategy/netpanzer/files/netpanzer-0.8-min-size-check.patch I tested and it fixes the vulnerability! Now I'm gonna package the new release :-) -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From fedora at leemhuis.info Fri Jun 9 16:05:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Jun 2006 18:05:36 +0200 Subject: do we need a PackageMaintainGuide? (was "Re: Summary - Broken dependencies in Fedora Extras development - 2006-06-09) In-Reply-To: <20060609103836.M41979@all-the-johnsons.co.uk> References: <20060609101153.27826.79393@extras64.linux.duke.edu> <20060609103836.M41979@all-the-johnsons.co.uk> Message-ID: <1149869136.2304.10.camel@localhost.localdomain> Am Freitag, den 09.06.2006, 10:38 +0000 schrieb Paul F. Johnson: > > Summary of broken packages in fedora-extras-development-i386: > > ---------------------------------------------------------------------- > > Gtk-Perl 0.7008-40.fc5.i386 > > R-gnomeGUI 2.1.0-5.fc5.i386 > > diradmin 1.7.1-4.fc5.i386 > > gtktalog 1.0.4-7.fc5.i386 > > rpy 0.4.6-10.fc6.i386 > > showimg-pgsql 0.9.5-5.fc5.i386 > > syck-php 0.55-7.fc5.i386 > How many of these are just waiting for a rebuild? Quite a few of these have > been on here for a couple of weeks now. Yeah, it seems some Maintainers ignore the devel branch slightly (there was also a mail some days ago that indicated that). That reminds me on and old idea: Do we need a "Package Maintain Guide" (or even a policy? or maybe both?). We could maintain it in the Wiki and have some hints and rules on it. E.g., things like "if your package is broken for rawhide rebuild it even if you can't test it yourself" (or stuff like that). Opinions? Ideas what else could be on that page? CU thl -- Thorsten Leemhuis From jamatos at fc.up.pt Fri Jun 9 16:12:19 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 9 Jun 2006 17:12:19 +0100 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-09 In-Reply-To: <20060609103836.M41979@all-the-johnsons.co.uk> References: <20060609101153.27826.79393@extras64.linux.duke.edu> <20060609103836.M41979@all-the-johnsons.co.uk> Message-ID: <200606091712.19818.jamatos@fc.up.pt> On Friday 09 June 2006 11:38, Paul F. Johnson wrote: > Hi, > > > Summary of broken packages in fedora-extras-development-i386: > > ---------------------------------------------------------------------- > > ?????? rpy ? ?0.4.6-10.fc6.i386 > > How many of these are just waiting for a rebuild? Quite a few of these have > been on here for a couple of weeks now. rpy build needs to be re-queued again, since it failed on Sunday due to the broken buildsys in development during the weekend. I did not had a chance to do it since usually I am behind a firewall and so my ability to trigger builds is null. :-( > TTFN > > Paul -- Jos? Ab?lio From Christian.Iseli at licr.org Fri Jun 9 16:21:17 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 09 Jun 2006 18:21:17 +0200 Subject: do we need a PackageMaintainGuide? (was "Re: Summary - Broken dependencies in Fedora Extras development - 2006-06-09) In-Reply-To: Your message of "Fri, 09 Jun 2006 18:05:36 +0200." <1149869136.2304.10.camel@localhost.localdomain> Message-ID: <200606091621.k59GLHOS013474@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > Opinions? A good idea, to set out expectations about the devel branch... > Ideas what else could be on that page? Put a pointer to Extras/UsingCvsFaq on the prefered method to update a package. Once the page is clear enough, that can become a policy if needed. Cheers, Christian From fedora at stefan-neufeind.de Fri Jun 9 16:41:38 2006 From: fedora at stefan-neufeind.de (Stefan Neufeind) Date: Fri, 09 Jun 2006 18:41:38 +0200 Subject: Suggestion for package: makejail Message-ID: <4489A4C2.1040803@stefan-neufeind.de> Hi folks, I just stumbled across "makejail" today. And the idea looks quite nice. There is a Debian-package as well. http://www.floc.net/makejail/ Would it make sense to maybe bundle it up for Fedora Extras? Since I'm currently short of time: Would anybody volunteer to do that maybe? Regards, Stefan From jkeating at redhat.com Fri Jun 9 17:23:09 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 09 Jun 2006 13:23:09 -0400 Subject: Thoughts about courier-mta packaging? In-Reply-To: <44889D55.4030308@forevermore.net> References: <446E2D76.7020004@forevermore.net> <44889D55.4030308@forevermore.net> Message-ID: <1149873790.7833.43.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-06-08 at 14:57 -0700, Chris Petersen wrote: > > So this goes back to the original question below... How flexible are > the extras maintainers when it comes to allowing packages made from a > really good upstream spec. It needs a little work, which I'd be willing > to do (and would hope that Sam would incorporate upstream), but it's not > worth it to me to rewrite (and maintain) a new spec from scratch. There is nothing wrong with starting from the upstream spec. It will have to adhere to the standards though, no flexibility on that. It would be best if upstream could accept the changes you have to make so that life is easier. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonathan.underwood at gmail.com Fri Jun 9 18:28:16 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 9 Jun 2006 19:28:16 +0100 Subject: Suggestion for package: makejail In-Reply-To: <4489A4C2.1040803@stefan-neufeind.de> References: <4489A4C2.1040803@stefan-neufeind.de> Message-ID: <645d17210606091128g47d707eai1219dc7a6783cf54@mail.gmail.com> On 09/06/06, Stefan Neufeind wrote: > Hi folks, > > I just stumbled across "makejail" today. And the idea looks quite nice. > There is a Debian-package as well. > > http://www.floc.net/makejail/ > > Would it make sense to maybe bundle it up for Fedora Extras? Since I'm > currently short of time: Would anybody volunteer to do that maybe? > How does this compare to jailkit? http://olivier.sessink.nl/jailkit/ jailkit is available from rpmforge, so if you wanted to import it into FE, their spec file would be a good place to start. Dries seems to be the packager, and his spec file is here: http://dries.ulyssis.org/rpm/packages/jailkit/jailkit-spec.html Jonathan. > > Regards, > Stefan > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From wwoods at redhat.com Fri Jun 9 18:41:30 2006 From: wwoods at redhat.com (Will Woods) Date: Fri, 09 Jun 2006 14:41:30 -0400 Subject: Fedora Test Project Message-ID: <1149878490.9769.6.camel@metroid.rdu.redhat.com> Hello! So, as you may have heard, Red Hat announced (at the Summit last week in Nashville) that they are planning to submit an Open Source testing project to the Fedora Board. They also intend to release a bunch of their tests and testing tools, and they really want to work with the Fedora community to help improve the state of QA in both Fedora and Open Source Software as a whole. This proposed project is still in its early stages, but it goes a lot further than just Red Hat releasing some of their tools. We are trying to start a project to develop and maintain a wide variety of test tools, tests, and test processes - everything you'd need to test an entire operating system like Fedora Core. The first step (and, in my opinion, it's a big one) is that Red Hat will give us part of their automated test system and a big chunk of the tests that go with it. They want to work with us to establish a test lab to run those tests on Fedora Core + Extras. They'll also give us documentation on the test APIs so we can write our own tests for Fedora-specific things. We hope to get these things working during the FC6 test releases and providing useful information to developers and users alike. In the future we intend to develop and release more tools and work on test processes for other parts of Fedora. We want programs Fedora users can run to report bugs and help with testing. And we don't want this to be restricted to Fedora - We want tools and tests that will work with all Open Source software. Oh, and the project will need a name. "Fedora Test Project" just doesn't cut it. And it abbreviates to "FTP". Ugh! Boring *and* confusing! Red Hat's started the project here: http://testing.108.redhat.com/ I'm really excited about all this. My personal goal for this project is to never hear anyone say "Fedora is just Red Hat's beta test product" again. Help make this dream a reality! -w From buildsys at fedoraproject.org Fri Jun 9 18:32:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 9 Jun 2006 14:32:46 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-09 Message-ID: <20060609183246.33D3715217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 13 SIBsim4-0.12-1.fc5 libopensync-plugin-evolution2-0.18-7.fc5 libsvg-0.1.4-4.fc5 mach-0.9.0-1.fc5 mathml-fonts-1.0-21.fc5 netpanzer-0.8-4.fc5 perl-Module-Install-0.63-1.fc5 perl-Module-Pluggable-3.01-1.fc5 sylpheed-2.2.6-1.fc5 sylpheed-claws-2.2.3-1.fc5 tkdnd-1.0a2-6.fc5 wine-0.9.15-1.fc5 wine-docs-0.9.15-1.fc5 Packages built and released for Fedora Extras 4: 11 SIBsim4-0.12-1.fc4 conserver-8.1.14-3.fc4.2 iozone-3-2.fc4 mach-0.9.0-1.fc4 mathml-fonts-1.0-21.fc4 netpanzer-0.8-4.fc4 perl-Module-Install-0.63-1.fc4 perl-Module-Pluggable-3.01-1.fc4 sylpheed-claws-2.2.3-1.fc4 wine-0.9.15-1.fc4 wine-docs-0.9.15-0.1.fc4 Packages built and released for Fedora Extras 3: 5 conserver-8.1.14-3.fc3.1 iozone-3-2.fc3 mathml-fonts-1.0-21.fc3 wine-0.9.15-1.fc3 wine-docs-0.9.15-1.fc3 Packages built and released for Fedora Extras development: 11 SIBsim4-0.12-1.fc6 libsvg-0.1.4-4.fc6 libsvg-cairo-0.1.6-3.fc6 mach-0.9.0-1.fc6 mathml-fonts-1.0-21.fc6 netpanzer-0.8-4.fc6 sylpheed-2.2.6-1.fc6 sylpheed-claws-2.2.3-1.fc6 tkdnd-1.0a2-6.fc6 wine-0.9.15-1.fc6 wine-docs-0.9.15-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Jun 9 18:45:29 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 18:45:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-09 Message-ID: <20060609184529.10795.30010@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Fri Jun 9 18:45:29 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 18:45:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-09 Message-ID: <20060609184529.10787.1738@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Fri Jun 9 18:45:29 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 18:45:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-09 Message-ID: <20060609184529.10797.9981@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Fri Jun 9 18:45:29 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Jun 2006 18:45:29 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-09 Message-ID: <20060609184529.10799.65025@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 R-gnomeGUI 2.1.0-5.fc5.i386 diradmin 1.7.1-4.fc5.i386 gtktalog 1.0.4-7.fc5.i386 rpy 0.4.6-10.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc R-gnomeGUI 2.1.0-5.fc5.ppc diradmin 1.7.1-4.fc5.ppc gtktalog 1.0.4-7.fc5.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc rpy 0.4.6-10.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 R-gnomeGUI 2.1.0-5.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gtktalog 1.0.4-7.fc5.x86_64 rpy 0.4.6-10.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: rpy - 0.4.6-10.fc6.i386 from fedora-extras-development-i386 unresolved deps: R = 0:2.3.0 package: R-gnomeGUI - 2.1.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: rpy - 0.4.6-10.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: R = 0:2.3.0 package: R-gnomeGUI - 2.1.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs libglade-gnome.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libglade libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: rpy - 0.4.6-10.fc6.ppc from fedora-extras-development-ppc unresolved deps: R = 0:2.3.0 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: R-gnomeGUI - 2.1.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 gnome-libs libgnomesupport.so.0 libgnome.so.32 libglade-gnome.so.0 libglade libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From michael at knox.net.nz Fri Jun 9 20:33:04 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 10 Jun 2006 08:33:04 +1200 Subject: change to owners.list In-Reply-To: <200606090928.k599Svp2000844@ludwig-alpha.unil.ch> References: <200606090928.k599Svp2000844@ludwig-alpha.unil.ch> Message-ID: <4489DB00.6000608@knox.net.nz> Christian.Iseli at licr.org wrote: > michael at knox.net.nz said: >> Can we have a marker of some sort to indicate a retired package? > > IMHO, we should put our energy into getting the new package database up and > running (see http://fedoraproject.org/wiki/Infrastructure/PackageDatabase) > instead of changing owners.list peacemeal. OK, sounds like a good idea. How can I help? > ATM, that information can be found in the CVS repository. Right, I was hoping not to work with the whole CVS tree, just the owners.list Shall put up for now and see how this database thing goes :) Michael From lists at forevermore.net Fri Jun 9 20:36:11 2006 From: lists at forevermore.net (Chris Petersen) Date: Fri, 09 Jun 2006 13:36:11 -0700 Subject: Thoughts about courier-mta packaging? In-Reply-To: <1149873790.7833.43.camel@dhcp83-49.boston.redhat.com> References: <446E2D76.7020004@forevermore.net> <44889D55.4030308@forevermore.net> <1149873790.7833.43.camel@dhcp83-49.boston.redhat.com> Message-ID: <4489DBBB.5090303@forevermore.net> > There is nothing wrong with starting from the upstream spec. It will > have to adhere to the standards though, no flexibility on that. It > would be best if upstream could accept the changes you have to make so > that life is easier. well, since one of the standards is "no other-distro stuff in the spec," that makes courier's incompatible. My main concern is that it's designed to build an rpm -- on any rpm-based distro. I can clean up the stuff that would annoy rpmlint, possibly the group name (nonstandard), but I'm not about to maintain it in such a way that I always have to pull out Sam's non-fedora customizations. For reference, the file is available at: http://courier.cvs.sourceforge.net/courier/courier/courier/courier.spec.in?view=markup -Chris From Christian.Iseli at licr.org Fri Jun 9 21:50:42 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 09 Jun 2006 23:50:42 +0200 Subject: change to owners.list In-Reply-To: Your message of "Sat, 10 Jun 2006 08:33:04 +1200." <4489DB00.6000608@knox.net.nz> Message-ID: <200606092150.k59LohwR017628@mx3.redhat.com> michael at knox.net.nz said: > OK, sounds like a good idea. How can I help? Review the thread here: https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00258.html and try to re-organize the wiki page here: http://fedoraproject.org/wiki/Infrastructure/PackageDatabase so that some database scheme can be extracted and then implemented, I guess... > Right, I was hoping not to work with the whole CVS tree, just the > owners.list Ah, well... You'll need it when you update the PackageStatus page anyway :-) > Shall put up for now and see how this database thing goes :) The quicker someone prepares a reasonable solution, the faster we'll get there. Cheers, Christian From wart at kobold.org Fri Jun 9 23:43:14 2006 From: wart at kobold.org (Michael Thomas) Date: Fri, 09 Jun 2006 16:43:14 -0700 Subject: Sharing sources in CVS Message-ID: <448A0792.4060706@kobold.org> A number of game-related packages on FE use the same soure tarball for the game data and the game engine, with the game data taking up a large majority of the space. In the spec files, the game engine and game data are split up into separate packages, so that the game data doesn't have to be updated at the same time as the game engine, reducing the size of updates for end-users. Unfortunately, that just doesn't work when the -data subpackage is part of the same spec as the game engine, as it will get rebuilt and pushed when the game engine is rebuilt. One possible solution would be to create a completely separate -data package in its own CVS module, with its own sources file pointing to the same tarball as the game engine. This would allow the maintainer to update the game engine package independently from the game data, even though they share the same source tarball. It would also allow the -data package to be tagged as noarch, so that it won't get rebuilt for all architectures. Is it possible to share a source tarball between two separate packages in CVS? Alternately, would it be possible to have two spec files in the same CVS module, so that they could be built separately? Or will either of these solutions just confuse the build system? --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From hugo at devin.com.br Sat Jun 10 02:46:53 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 9 Jun 2006 23:46:53 -0300 Subject: Documentation packages in Package Naming Guidelines (and standards) Message-ID: <200606092346.53386.hugo@devin.com.br> Hi, While packaging, I needed to create a separate documentation package because of its many documentation files. In the PackageGuidelines, we have this: "Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent INSTALL file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. README.MSDOS. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use *-doc as the subpackage name, and Documentation as the value of the Group tag." I think this should be placed in the Package Naming Guidelines too. BTW, I noted that some packages in Extras have a *-docs sub-package instead of *-doc. Talking with Jason Tibbitts in IRC, he said that this is normal. Is there a standard for this or it's up to the packager/reviewer? Thanks for your attention, -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From jeff at ocjtech.us Sat Jun 10 03:04:34 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 09 Jun 2006 22:04:34 -0500 Subject: Sharing sources in CVS In-Reply-To: <448A0792.4060706@kobold.org> References: <448A0792.4060706@kobold.org> Message-ID: <1149908675.19028.9.camel@maple.ocjtech.us> On Fri, 2006-06-09 at 16:43 -0700, Michael Thomas wrote: > Is it possible to share a source tarball between two separate packages > in CVS? Alternately, would it be possible to have two spec files in the > same CVS module, so that they could be built separately? Or will either > of these solutions just confuse the build system? Yes, it's possible... The build system tracks source tarballs by MD5 hashes. The build system will keep only one copy of the source tarball, no matter how many packages attempt to upload it. When no more packages reference the source tarball it will be purged from the system. Jeff From rc040203 at freenet.de Sat Jun 10 04:34:34 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Jun 2006 06:34:34 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> Message-ID: <1149914075.12112.89.camel@mccallum.corsepiu.local> On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: > Author: xulchris > > Update of /cvs/extras/rpms/poker-eval/FC-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 > > Modified Files: > poker-eval.spec > %install > -rm -rf %{buildroot} > -make install DESTDIR=%{buildroot} > +%{__rm} -rf %{buildroot} > +%makeinstall > %changelog > +* Fri Jun 09 2006 Christopher Stone 131.0-2 > +- Add pkgconfig to devel Requires > +- Use macros for system commands > +- Use %%makeinstall macro Why the %makeinstall? makeinstall is an anachronism and should only be used if make DESTDIR=... install is nonfunctional. Ralf From chris.stone at gmail.com Sat Jun 10 04:41:31 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 9 Jun 2006 21:41:31 -0700 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149914075.12112.89.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> Message-ID: On 6/9/06, Ralf Corsepius wrote: > On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: > > Modified Files: > > poker-eval.spec > > -make install DESTDIR=%{buildroot} > > +%makeinstall > > Why the %makeinstall? makeinstall is an anachronism and should only be > used if make DESTDIR=... install is nonfunctional. Because it looks cleaner. What's wrong with using it? From michael at knox.net.nz Sat Jun 10 04:41:46 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 16:41:46 +1200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149914075.12112.89.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> Message-ID: <448A4D8A.8050203@knox.net.nz> Ralf Corsepius wrote: > On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: >> Author: xulchris >> >> Update of /cvs/extras/rpms/poker-eval/FC-4 >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 >> >> Modified Files: >> poker-eval.spec > >> %install >> -rm -rf %{buildroot} >> -make install DESTDIR=%{buildroot} >> +%{__rm} -rf %{buildroot} >> +%makeinstall > >> %changelog >> +* Fri Jun 09 2006 Christopher Stone 131.0-2 >> +- Add pkgconfig to devel Requires >> +- Use macros for system commands >> +- Use %%makeinstall macro > > Why the %makeinstall? makeinstall is an anachronism and should only be > used if make DESTDIR=... install is nonfunctional. I don't see the use of %makeinstall being discouraged in the packaging guidelines or even discussed for that matter. If this is something that shouldn't be used or whatever, then you should probably have FESCo add it to the packaging guidelines. A lot (most of actually) of the packages I have make use of %makeinstall and this is the first time I have seen it being mentoned. Michael From rc040203 at freenet.de Sat Jun 10 05:02:46 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Jun 2006 07:02:46 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <448A4D8A.8050203@knox.net.nz> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> Message-ID: <1149915767.12112.102.camel@mccallum.corsepiu.local> On Sat, 2006-06-10 at 16:41 +1200, Michael J. Knox wrote: > Ralf Corsepius wrote: > > On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: > >> Author: xulchris > >> > >> Update of /cvs/extras/rpms/poker-eval/FC-4 > >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 > >> > >> Modified Files: > >> poker-eval.spec > > > >> %install > >> -rm -rf %{buildroot} > >> -make install DESTDIR=%{buildroot} > >> +%{__rm} -rf %{buildroot} > >> +%makeinstall > > > >> %changelog > >> +* Fri Jun 09 2006 Christopher Stone 131.0-2 > >> +- Add pkgconfig to devel Requires > >> +- Use macros for system commands > >> +- Use %%makeinstall macro > > > > Why the %makeinstall? makeinstall is an anachronism and should only be > > used if make DESTDIR=... install is nonfunctional. > > I don't see the use of %makeinstall being discouraged in the packaging > guidelines or even discussed for that matter. A defect in the guidelines. > If this is something that shouldn't be used or whatever, then you should > probably have FESCo add it to the packaging guidelines. A lot (most of > actually) of the packages I have make use of %makeinstall and this is > the first time I have seen it being mentoned. This only means you haven't encountered the nasty side-effects of %makeinstall. The working principle %makeinstall is based on, has been necessary for automake-1.4x based configure scripts, but has been deprecated and discouraged in automake for many years. Besides some packages suffering from bugs in DESTDIR support most modern packages support DESTDIR. Ralf From Matt_Domsch at dell.com Sat Jun 10 05:04:28 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 10 Jun 2006 00:04:28 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 Message-ID: <20060610050428.GA28545@lists.us.dell.com> Note: This is using the extremely reduced chroot as documented in the Extras Exception List. http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 automake, autoconf, libtool and m4 had accidentally been included in my buildroots from previous runs; they're removed in this and subsequent runs, which will cause additional build failures. Extras tree as of Thursday afternoon; it takes quite a while to rebuild 1800 packages on 2 architectures. :-) In addition, about 5 packages (all perl modules IIRC) managed to hang in 'make test'. I manually killed those after ~16 hours, and they'll show up as failed builds below. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT 2006 Number failed to build: 206 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 205 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 198 ---------------------------------- abiword airsnort allegro amaya argus azureus bazaar bidiv bmp byzanz camstream ccrtp cernlib colorscheme compat-erlang contact-lookup-applet cowbell crossfire dbus-qt ddskk deskbar-applet dia dillo diradmin directfb drgeo driftnet dxpc ebtables epiphany-extensions epylog erlang exim exo factory fillets-ng fish flim flow-tools fontforge gazpacho gcompris gdesklets geomview gif2png gift glabels gnokii gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-password-generator gnome-schedule gnome-sudoku gobby gphpedit grace grads gramps grhino gstreamer08 gstreamer08-plugins gstreamer08-python gsynaptics gtk+ GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hackedbox Hermes hping2 ifplugd iftop intuitively jack-audio-connection-kit jam john kanatest kdissert kdocker kmymoney2 kover ladspa leafpad libassetml libfac libgalago libgda libgnomedb libnasl librx libtabe libtomoe-gtk libtranslate licq linkchecker logjam lucidlife Macaulay2 MagicPoint maxima mfstools mod_suphp multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool ncmpc nco nessus-core nessus-libraries NetworkManager-vpnc ngrep notemeister nucleo openal openalpp opencv orange p0f paps pari pcsc-lite perl-HTML-Mason perl-IPC-Shareable perl-Net-SSH-Perl perl-Spoon pessulus php-extras pipenightdreams pitivi pl plib plib16 plplot pure-ftpd pybliographer pygame python-cheetah python-goopy python-TestGears qa-assistant qalculate-kde qemu qt4 quarry ratpoison revelation R-gnomeGUI rpmDirectoryCheck rss-glx rssowl sabayon sblim-cmpi-base scanssh scmxx scponly SDL_ttf ser serpentine sloccount snort stow stratagus straw syck synce synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont ucarp ushare verbiste wesnoth WindowMaker wlassistant wv2 x3270 xaos xbindkeys xbsql xcin xfce4-mailwatch-plugin xfce4-xkb-plugin xforms xmms-crossfade xpilot-ng xplanet xprobe2 xscreensaver xsp With bugs filed: 7 ---------------------------------- alacarte ['194250 NEW'] banshee ['194505 NEW'] gtkhtml36 ['193476 ASSIGNED'] xfce4-weather-plugin ['193973 ASSIGNED'] xffm ['194145 CLOSED'] xfprint ['194147 CLOSED'] yumex ['193549 ASSIGNED'] 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 rc040203 at freenet.de Sat Jun 10 05:05:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Jun 2006 07:05:23 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> Message-ID: <1149915924.12112.107.camel@mccallum.corsepiu.local> On Fri, 2006-06-09 at 21:41 -0700, Christopher Stone wrote: > On 6/9/06, Ralf Corsepius wrote: > > On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: > > > Modified Files: > > > poker-eval.spec > > > -make install DESTDIR=%{buildroot} > > > +%makeinstall > > > > Why the %makeinstall? makeinstall is an anachronism and should only be > > used if make DESTDIR=... install is nonfunctional. > > Because it looks cleaner. Simply stylishness ;) > What's wrong with using it? %makeinstall overrides a set of environment variables during "make install". I.e. it performs make prefix="..." includedir="..." ... It is error prone, can have effects inside of (broken) Makefiles and can trigger rebuilds when executing "make install". If a package contains libtool archives, it will cause broken *.la's being installed. "make DESTDIR=... install" overrides a single environment variable and is supposed to be specially designed for re-rooting installs to a different installation root ($RPM_BUILD_ROOT) than the package has been configured for ("/"). Exactly what you do during an rpm's %install. Ralf From Matt_Domsch at dell.com Sat Jun 10 05:05:33 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 10 Jun 2006 00:05:33 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 Message-ID: <20060610050533.GB28545@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Fri Jun 9 23:04:41 CDT 2006 Number failed to build: 195 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 184 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 177 ---------------------------------- abicheck airsnort allegro amaya argus atitvout azureus bazaar bidiv bmp byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell crossfire dbus-qt ddskk deskbar-applet dia dillo diradmin directfb drgeo driftnet ebtables epiphany-extensions epylog erlang exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gcompris gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-password-generator gnome-schedule gnome-sudoku gobby gphpedit gramps grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hercules hping2 ifplugd iftop intuitively jam john kanatest kdissert kmymoney2 kover ladspa leafpad libassetml libfac libgda libgnomedb libnasl libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate licq linkchecker logjam lucidlife Macaulay2 MagicPoint maxima mhonarc monotone multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco nessus-core nessus-libraries NetworkManager-vpnc new ngrep notemeister openalpp OpenSceneGraph p0f pam_mount paps pcsc-lite perl-Convert-PEM perl-HTML-Mason perl-Image-Info perl-IPC-Shareable perl-Net-SSH-Perl perl-Spoon perl-Unicode-Map8 perl-Unicode-MapUTF8 pessulus php-extras php-pear-DB pipenightdreams pitivi pl plplot pybliographer pygame python-cheetah python-dateutil python-goopy python-reportlab python-TestGears qa-assistant qemu quarry revelation R-gnomeGUI rpmDirectoryCheck rssowl sabayon sblim-cmpi-base scanssh scmxx scponly SDL_ttf ser serpentine sloccount stow stratagus straw synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont ucarp uqm ushare verbiste wesnoth WindowMaker wlassistant xaos xbindkeys xbsql xcin xmms-crossfade xpilot-ng xplanet xprobe2 xsp z88dk With bugs filed: 7 ---------------------------------- alacarte ['194250 NEW'] banshee ['194505 NEW'] gtkhtml36 ['193476 ASSIGNED'] xfce4-weather-plugin ['193973 ASSIGNED'] xffm ['194145 CLOSED'] xfprint ['194147 CLOSED'] yumex ['193549 ASSIGNED'] 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 michael at knox.net.nz Sat Jun 10 05:05:52 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 17:05:52 +1200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149915767.12112.102.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> Message-ID: <448A5330.7000407@knox.net.nz> Ralf Corsepius wrote: > On Sat, 2006-06-10 at 16:41 +1200, Michael J. Knox wrote: >> Ralf Corsepius wrote: >>> On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: >>>> Author: xulchris >>>> >>>> Update of /cvs/extras/rpms/poker-eval/FC-4 >>>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 >>>> >>>> Modified Files: >>>> poker-eval.spec >>>> %install >>>> -rm -rf %{buildroot} >>>> -make install DESTDIR=%{buildroot} >>>> +%{__rm} -rf %{buildroot} >>>> +%makeinstall >>>> %changelog >>>> +* Fri Jun 09 2006 Christopher Stone 131.0-2 >>>> +- Add pkgconfig to devel Requires >>>> +- Use macros for system commands >>>> +- Use %%makeinstall macro >>> Why the %makeinstall? makeinstall is an anachronism and should only be >>> used if make DESTDIR=... install is nonfunctional. >> I don't see the use of %makeinstall being discouraged in the packaging >> guidelines or even discussed for that matter. > A defect in the guidelines. > >> If this is something that shouldn't be used or whatever, then you should >> probably have FESCo add it to the packaging guidelines. A lot (most of >> actually) of the packages I have make use of %makeinstall and this is >> the first time I have seen it being mentoned. > This only means you haven't encountered the nasty side-effects of > %makeinstall. > > The working principle %makeinstall is based on, has been necessary for > automake-1.4x based configure scripts, but has been deprecated and > discouraged in automake for many years. > > Besides some packages suffering from bugs in DESTDIR support most modern > packages support DESTDIR. > Then please make the suggestion to FESCo to add a change to the packaging guide. I think its unfair to put the spot light on someone for doing something that is not being discouraged in the Fedora packaging guide lines. Michael From rc040203 at freenet.de Sat Jun 10 05:12:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Jun 2006 07:12:35 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <448A5330.7000407@knox.net.nz> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> Message-ID: <1149916356.12112.111.camel@mccallum.corsepiu.local> On Sat, 2006-06-10 at 17:05 +1200, Michael J. Knox wrote: > Ralf Corsepius wrote: > > On Sat, 2006-06-10 at 16:41 +1200, Michael J. Knox wrote: > >> Ralf Corsepius wrote: > >>> On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: > >>>> Author: xulchris > >>>> > >>>> Update of /cvs/extras/rpms/poker-eval/FC-4 > >>>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 > >>>> > >>>> Modified Files: > >>>> poker-eval.spec > >>>> %install > >>>> -rm -rf %{buildroot} > >>>> -make install DESTDIR=%{buildroot} > >>>> +%{__rm} -rf %{buildroot} > >>>> +%makeinstall > >>>> %changelog > >>>> +* Fri Jun 09 2006 Christopher Stone 131.0-2 > >>>> +- Add pkgconfig to devel Requires > >>>> +- Use macros for system commands > >>>> +- Use %%makeinstall macro > >>> Why the %makeinstall? makeinstall is an anachronism and should only be > >>> used if make DESTDIR=... install is nonfunctional. > >> I don't see the use of %makeinstall being discouraged in the packaging > >> guidelines or even discussed for that matter. > > A defect in the guidelines. > > > >> If this is something that shouldn't be used or whatever, then you should > >> probably have FESCo add it to the packaging guidelines. A lot (most of > >> actually) of the packages I have make use of %makeinstall and this is > >> the first time I have seen it being mentoned. > > This only means you haven't encountered the nasty side-effects of > > %makeinstall. > > > > The working principle %makeinstall is based on, has been necessary for > > automake-1.4x based configure scripts, but has been deprecated and > > discouraged in automake for many years. > > > > Besides some packages suffering from bugs in DESTDIR support most modern > > packages support DESTDIR. > > > > Then please make the suggestion to FESCo to add a change to the > packaging guide. I think its unfair to put the spot light on someone for > doing something that is not being discouraged in the Fedora packaging > guide lines. Pardon, you find it unfair to ask people to think about what he is doing? You find it's appropriate to resort to bureaucracy? Sorry, I beg to differ. Ralf From chris.stone at gmail.com Sat Jun 10 05:21:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 9 Jun 2006 22:21:05 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <20060610050428.GA28545@lists.us.dell.com> References: <20060610050428.GA28545@lists.us.dell.com> Message-ID: On 6/9/06, Matt Domsch wrote: > Note: This is using the extremely reduced chroot as documented in the Extras > Exception List. > > Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT 2006 > Of those expected to have worked... > Without a bug filed: 198 > ---------------------------------- > nucleo This fails because your build system does not define %fedora, and the spec file uses %fedora to determine if it should install xorg-x11-devel or not. Note: this builds fine in your x86_64 report, so I'm guessing you have it defined in x86_64 but not on i386? From chris.stone at gmail.com Sat Jun 10 05:26:29 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 9 Jun 2006 22:26:29 -0700 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149916356.12112.111.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <1149916356.12112.111.camel@mccallum.corsepiu.local> Message-ID: On 6/9/06, Ralf Corsepius wrote: > Pardon, you find it unfair to ask people to think about what he is > doing? You find it's appropriate to resort to bureaucracy? I resent being told that I don't think about what I am doing. The reason I added this was because it looked cleaner than the DESTDIR thing and I saw it being used on many other packages that were packaged by people who have more experience at packaging than I do. How am I supposed to know that this is an anachronism especially if it is not mentioned anywhere in the guidelines? I definately think this should be mentioned in the guidelines even if it means resorting to "bureaucracy". I will change my spec files back to using the DESTDIR method, but please do not accuse me of being thoughless for using %makeinstall. From michael at knox.net.nz Sat Jun 10 05:44:27 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 17:44:27 +1200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149916356.12112.111.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <1149916356.12112.111.camel@mccallum.corsepiu.local> Message-ID: <448A5C3B.6000303@knox.net.nz> Ralf Corsepius wrote: > On Sat, 2006-06-10 at 17:05 +1200, Michael J. Knox wrote: >> Ralf Corsepius wrote: >>> On Sat, 2006-06-10 at 16:41 +1200, Michael J. Knox wrote: >>>> Ralf Corsepius wrote: >>>>> On Fri, 2006-06-09 at 21:29 -0700, Christopher Stone wrote: >>>>>> Author: xulchris >>>>>> >>>>>> Update of /cvs/extras/rpms/poker-eval/FC-4 >>>>>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29974/FC-4 >>>>>> >>>>>> Modified Files: >>>>>> poker-eval.spec >>>>>> %install >>>>>> -rm -rf %{buildroot} >>>>>> -make install DESTDIR=%{buildroot} >>>>>> +%{__rm} -rf %{buildroot} >>>>>> +%makeinstall >>>>>> %changelog >>>>>> +* Fri Jun 09 2006 Christopher Stone 131.0-2 >>>>>> +- Add pkgconfig to devel Requires >>>>>> +- Use macros for system commands >>>>>> +- Use %%makeinstall macro >>>>> Why the %makeinstall? makeinstall is an anachronism and should only be >>>>> used if make DESTDIR=... install is nonfunctional. >>>> I don't see the use of %makeinstall being discouraged in the packaging >>>> guidelines or even discussed for that matter. >>> A defect in the guidelines. >>> >>>> If this is something that shouldn't be used or whatever, then you should >>>> probably have FESCo add it to the packaging guidelines. A lot (most of >>>> actually) of the packages I have make use of %makeinstall and this is >>>> the first time I have seen it being mentoned. >>> This only means you haven't encountered the nasty side-effects of >>> %makeinstall. >>> >>> The working principle %makeinstall is based on, has been necessary for >>> automake-1.4x based configure scripts, but has been deprecated and >>> discouraged in automake for many years. >>> >>> Besides some packages suffering from bugs in DESTDIR support most modern >>> packages support DESTDIR. >>> >> Then please make the suggestion to FESCo to add a change to the >> packaging guide. I think its unfair to put the spot light on someone for >> doing something that is not being discouraged in the Fedora packaging >> guide lines. > > Pardon, you find it unfair to ask people to think about what he is > doing? You find it's appropriate to resort to bureaucracy? > > Sorry, I beg to differ. You stated that the packaging guide lines are defective. You stated that this macro has been deprecated. You stated that this has been discouraged in automake for years. I don't read those statements as "asking" or "bureaucracy", nor do I find the implication that someone doesn't think "asking" of "bureaucracy", If I am wrong, I apologize. However, with some 200 odd (a rough guess with grep) spec files that make use of %makeinstall your questioning of its use could probably have been more tactful and most certainly should have been directed to the wider audience that makes up FE Michael From michael at knox.net.nz Sat Jun 10 05:54:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 17:54:31 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <1149747189.31232.29.camel@T7.Linux> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <1149747189.31232.29.camel@T7.Linux> Message-ID: <448A5E97.9040303@knox.net.nz> Paul wrote: > Hi, > >> So far I have only had comments from Michael Schwendt, but I would like >> to hear more from other FE maitainers. > > Not quite - I did start a thread in a similar vein a short while back > inspired by qparted. Sorry, I must have missed it :-( >> What sorts of time frames do people think is reasonable? How many >> contact attempts should there be? > > I think 5 should be enough contacts and preferably a month (depending on > the package size) from initial BZ to acceptance. Okay, that does mean a > lot more people acting as sponsors. > > A month is a good amount of time, though if the package is a large one > (such as Amaya), this time frame may vary. > I would prefer all packages be treated the same. I think if you start having too many exceptions, if just leads to confusion. I am hoping for a nice simple policy :-) I like the one month period. A bz report should be considered the starting point of the contact period. I am not sure I understand why this would need more sponsors? A NMU would only happen by existing FE developer, so a sponsor would not be needed. The person wishing to do the NMU and eventual take over of the package would have to have posted an email indicating their intent along with the BZ report URL. Thats sort of how I would see it play out. Michael From michael at knox.net.nz Sat Jun 10 05:56:58 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 17:56:58 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <20060608.115125.96779216.kevin@scrye.com> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> Message-ID: <448A5F2A.7000303@knox.net.nz> Kevin Fenzi wrote: >>>>>> "Michael" == Michael J Knox writes: > > Michael> Michael J Knox wrote: [snip] check out the achive for the > Michael> rest ;) > >>>> Let's start with X, maximum packager response time for a bugzilla >>>> ticket, in which a serious (or normal) bug was reported. Would >>>> X=14 days be too short? X+Y would cover at least two weekends. I >>>> mean, if a packager is on a long vacation (several weeks or more) >>>> and is neglecting package maintenance knowingly, the package would >>>> be suitable for shared maintainership anyway. And in cases where a >>>> packager has had an accident or is facing temporary illness (and >>>> similar things), we're back at what I've written before -- that it >>>> should be in the packager's best interest that other contributors >>>> help. >>>> >>> I feel, that if an owner is considered "active" then he/she should >>> be able to at the very least, acknowledge a form of contact, direct >>> email or BZ, within a 3 week time frame. However, I think it needs >>> to be more than one attempt over that time frame. The person >>> attempting the NMU must provide "proof" IMHO in the form of BZ >>> reports etc of these attempts. A formal accounacment of intent on >>> the extras list would be required, in case someone on the list >>> knows the current owner where abouts. > > Michael> Ok, So I have somemore time to focus on this. > > Michael> So far I have only had comments from Michael Schwendt, but I > Michael> would like to hear more from other FE maitainers. > > Michael> What sorts of time frames do people think is reasonable? How > Michael> many contact attempts should there be? > > How about something like: > > - When someone sees that a maintainer isn't answering their bugs, not > answering rebuild requests, emails or the like, they file a bug > against the package in bugzilla asking for the maintainer to respond. > This bug should list the outstanding issues they need to address. > > - After every 7 days, the reporter adds a comment to the bug asking > again for response. Others can add to the bug that they also were not > successfull in contacting the maintainer, or providing additional > contact information for the maintainer (ie, alternative email, irc, > etc). > > - After 2 attempts (2 weeks) of no response from the maintainer, the > reporter posts to the fedora-extras list with a url to the bug report > and asks if anyone knows how to contact the maintainer. > > - After another 7 days (now 3 weeks total), the reporter posts to the > extras list with the bug link and indicates that all attempts to > contact the maintainer have failed and that they wish to take over the > package. Additionally we could require the former maintainers sponsor > to sign off on the change. > > I think the bug is important to be able to track things, and the > maintainer should follow email from bugzilla for their packages > anyhow. That's exactly how I foresee the process, but probably a 4 week wait. I am not sure the reasoning for having the previous sponsor resign off on the package when it should be required that the NMU be done onl by existing FE developers. Michael From chris.stone at gmail.com Sat Jun 10 07:02:04 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 10 Jun 2006 00:02:04 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <20060610050533.GB28545@lists.us.dell.com> References: <20060610050533.GB28545@lists.us.dell.com> Message-ID: On 6/9/06, Matt Domsch wrote: > pygame Can anyone help me figure out why this is failing? Here is the build log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/pygame-1.7.1-6.fc6.src.rpm/result/build.log AFAICT this should build correctly. I looked at the data structure for SDL-1.2.10 and it is the same as 1.2.9. It builds fine for me on FC-5 and it built fine for me the last time I tried it on devel. From jamatos at fc.up.pt Sat Jun 10 07:09:55 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 10 Jun 2006 08:09:55 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: References: <20060610050428.GA28545@lists.us.dell.com> Message-ID: <200606100809.55711.jamatos@fc.up.pt> On Saturday 10 June 2006 06:21, Christopher Stone wrote: > On 6/9/06, Matt Domsch wrote: > > Note: This is using the extremely reduced chroot as documented in the > > Extras Exception List. > > > > > Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT > > > 2006 > > > > Of those expected to have worked... > > Without a bug filed: 198 > > ---------------------------------- > > nucleo > > This fails because your build system does not define %fedora, and the > spec file uses %fedora to determine if it should install > xorg-x11-devel or not. Note: this builds fine in your x86_64 report, > so I'm guessing you have it defined in x86_64 but not on i386? The same should be valid for grace for the same reasons. :-) -- Jos? Ab?lio From dtimms at bigpond.net.au Sat Jun 10 07:21:53 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 10 Jun 2006 17:21:53 +1000 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <20060610050428.GA28545@lists.us.dell.com> References: <20060610050428.GA28545@lists.us.dell.com> Message-ID: <448A7311.8030805@bigpond.net.au> Matt Domsch wrote: > Note: This is using the extremely reduced chroot as documented in the Extras > Exception List. > http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > automake, autoconf, libtool and m4 had accidentally been included in > my buildroots from previous runs; they're removed in this and > subsequent runs, which will cause additional build failures. > > Extras tree as of Thursday afternoon; it takes quite a while to > rebuild 1800 packages on 2 architectures. :-) > > In addition, about 5 packages (all perl modules IIRC) managed to hang > in 'make test'. I manually killed those after ~16 hours, and they'll > show up as failed builds below. > > Open Bugs which now build, and can be marked CLOSED RAWHIDE: > gnupg2 194079 NEW > libgpg-error 193550 NEW > > Note: This is using a reduced set of packages in the build chroot as > compared to the standard Fedora Extras build system before FC6test1. See > http://fedoraproject.org/wiki/QA/FixBuildRequires for more > information, including the list of packages removed from the > default build chroot. > > Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT 2006 > Number failed to build: 206 > Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > Leaving: 205 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 198 > ---------------------------------- > abiword > airsnort > allegro > amaya > argus > azureus ... I am happy to spend sometime filing extras buildrequires bugs, if the consensus is that is what the community wants ? DavidT. From j.w.r.degoede at hhs.nl Sat Jun 10 07:46:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 10 Jun 2006 09:46:37 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448A7311.8030805@bigpond.net.au> References: <20060610050428.GA28545@lists.us.dell.com> <448A7311.8030805@bigpond.net.au> Message-ID: <448A78DD.20304@hhs.nl> David Timms wrote: > Matt Domsch wrote: >> Note: This is using the extremely reduced chroot as documented in the >> Extras >> Exception List. >> http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 >> >> automake, autoconf, libtool and m4 had accidentally been included in >> my buildroots from previous runs; they're removed in this and >> subsequent runs, which will cause additional build failures. >> >> Extras tree as of Thursday afternoon; it takes quite a while to >> rebuild 1800 packages on 2 architectures. :-) >> >> In addition, about 5 packages (all perl modules IIRC) managed to hang >> in 'make test'. I manually killed those after ~16 hours, and they'll >> show up as failed builds below. >> >> Open Bugs which now build, and can be marked CLOSED RAWHIDE: >> gnupg2 194079 NEW >> libgpg-error 193550 NEW >> >> Note: This is using a reduced set of packages in the build chroot as >> compared to the standard Fedora Extras build system before FC6test1. See >> http://fedoraproject.org/wiki/QA/FixBuildRequires for more >> information, including the list of packages removed from the >> default build chroot. >> >> Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT >> 2006 >> Number failed to build: 206 >> Number expected to fail due to ExclusiveArch or ExcludeArch: 1 >> Leaving: 205 >> (there may be some duplicates if rawhide has 2 versions of a package) >> >> Of those expected to have worked... >> Without a bug filed: 198 >> ---------------------------------- >> abiword >> airsnort >> allegro >> amaya >> argus >> azureus > ... > I am happy to spend sometime filing extras buildrequires bugs, if the > consensus is that is what the community wants ? > I'm not sure if that is what the comminity wants, but to spare you some work if you do, I'm aware of and planning on fixing soon the following: allegro dia gcompris libassetml libgda libgnomedb pipenightdreams plib Regards, Hans From peter at thecodergeek.com Sat Jun 10 07:56:17 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 10 Jun 2006 00:56:17 -0700 Subject: Unorphan: Openbox Message-ID: <448A7B21.6080500@thecodergeek.com> Hello, all. I wish to unorphan and resurrect Openbox in Extras. It was dropped in the FC3/FC4 timeframe at version 2.3.1. Because it was such a long time and even a new major release of this upstream, do I need to submit a review request for my new spec? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From michael at knox.net.nz Sat Jun 10 07:58:14 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 10 Jun 2006 19:58:14 +1200 Subject: Unorphan: Openbox In-Reply-To: <448A7B21.6080500@thecodergeek.com> References: <448A7B21.6080500@thecodergeek.com> Message-ID: <448A7B96.7070104@knox.net.nz> Peter Gordon wrote: > Hello, all. > > I wish to unorphan and resurrect Openbox in Extras. It was dropped in > the FC3/FC4 timeframe at version 2.3.1. > > Because it was such a long time and even a new major release of this > upstream, do I need to submit a review request for my new spec? Having it peer reviewed would probably be a good idea. Michael From zipsonic at gmail.com Sat Jun 10 08:03:09 2006 From: zipsonic at gmail.com (Rick Stout) Date: Sat, 10 Jun 2006 01:03:09 -0700 Subject: nx requires and provides Message-ID: <448A7CBD.9080402@gmail.com> Hi all, I need some help in clearing up some issues with the nx package. It seems to have two bigger problems at this point, and I really don't know what to do about either. First, nx *does not* work on x86_64, so it has an Excludearch: x86_64 in the spec. This is fine for the arch exclusion, but there is a package that depends on nx, freenx which is noarch (its just a bunch of scripts), so the build reports show that freenx has a broken dependency on x86_64. What is the best way to handle this? Can I Excludearch: x86_64 on a noarch package? How about a requires: wrapped in an ifnarch conditional? Second, nx is based on XFree86 4.3.0. The backend components come from a full X11 build, and require a number of adapted libraries from this build. The library of most concern right now is libX11.so.6.2. Nx installs this library in /usr/lib/NX/lib, then when any of the nx components are called, a wrapper puts the NX/lib path in front of the ld path for just that application, so as not to step on any of the other libraries already on the system. The problem, which was not apparent until now, is that yum thinks that nx provides a valid libX11.so.6 so certain applications requiring this file may download nx and its dependencies. How do I fix this? I feel that this could actually be considered a deficiency in yum or rpm in that the file is not in the standard library path, so it really isn't provided to the system. Any input would be greatly appreciated in this. Regards, Rick Stout From peter at thecodergeek.com Sat Jun 10 08:04:46 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 10 Jun 2006 01:04:46 -0700 Subject: [answered] Question about unorphaning Openbox [Was: "Re: Unorphan: Openbox"] In-Reply-To: <448A7B96.7070104@knox.net.nz> References: <448A7B21.6080500@thecodergeek.com> <448A7B96.7070104@knox.net.nz> Message-ID: <448A7D1E.3030007@thecodergeek.com> Michael J. Knox wrote: > Having it peer reviewed would probably be a good idea. I agree. I'll post a review request soon then. Thanks. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jun 10 08:07:01 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sat, 10 Jun 2006 17:07:01 +0900 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: References: <20060610050533.GB28545@lists.us.dell.com> Message-ID: <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> Christopher Stone wrote: > On 6/9/06, Matt Domsch wrote: >> pygame > > Can anyone help me figure out why this is failing? Here is the build log: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/pygame-1.7.1-6.fc6.src.rpm/result/build.log > > > AFAICT this should build correctly. I looked at the data structure > for SDL-1.2.10 and it is the same as 1.2.9. It builds fine for me on > FC-5 and it built fine for me the last time I tried it on devel. > Hello, Christopher: I also FAILED building, but correcting spec file like attached seems to work for me. Mamoru Tasaka -------------- next part -------------- A non-text attachment was scrubbed... Name: pygame.spec.diff Type: text/x-patch Size: 547 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jun 10 09:46:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 11:46:02 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <448A5330.7000407@knox.net.nz> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> Message-ID: <20060610114602.23111149.bugs.michael@gmx.net> On Sat, 10 Jun 2006 17:05:52 +1200, Michael J. Knox wrote: > >>> Why the %makeinstall? makeinstall is an anachronism and should only be > >>> used if make DESTDIR=... install is nonfunctional. > >> I don't see the use of %makeinstall being discouraged in the packaging > >> guidelines or even discussed for that matter. > > A defect in the guidelines. > > > >> If this is something that shouldn't be used or whatever, then you should > >> probably have FESCo add it to the packaging guidelines. A lot (most of > >> actually) of the packages I have make use of %makeinstall and this is > >> the first time I have seen it being mentoned. > > > This only means you haven't encountered the nasty side-effects of > > %makeinstall. > > > > The working principle %makeinstall is based on, has been necessary for > > automake-1.4x based configure scripts, but has been deprecated and > > discouraged in automake for many years. > > > > Besides some packages suffering from bugs in DESTDIR support most modern > > packages support DESTDIR. > > > > Then please make the suggestion to FESCo to add a change to the > packaging guide. I think its unfair to put the spot light on someone for > doing something that is not being discouraged in the Fedora packaging > guide lines. Calm down, everyone. Ralf is right. Using %makeinstall should be discouraged actually, and, for instance, I was under the impression that we agreed on that long ago. %makeinstall is different from %configure in that it overrides all relevant variables (like prefix= libdir= datadir=) with buildroot as a prefix. This is particularly nasty when during the install process any of these path variables are put into files on-the-fly either accidentally or deliberately. You end up with buildroot information in generated files, such as scripts, executables, libtool archives, doc files, etc. As a rule of thumb: Prefer "make DESTDIR=%{buildroot} install" wherever it works. When it doesn't work, try %makeinstall. From bugs.michael at gmx.net Sat Jun 10 09:59:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 11:59:35 +0200 Subject: nx requires and provides In-Reply-To: <448A7CBD.9080402@gmail.com> References: <448A7CBD.9080402@gmail.com> Message-ID: <20060610115935.824b1a42.bugs.michael@gmx.net> On Sat, 10 Jun 2006 01:03:09 -0700, Rick Stout wrote: > Hi all, > I need some help in clearing up some issues with the nx package. It > seems to have two bigger problems at this point, and I really don't know > what to do about either. > > First, nx *does not* work on x86_64, so it has an Excludearch: x86_64 in > the spec. This is fine for the arch exclusion, but there is a package > that depends on nx, freenx which is noarch (its just a bunch of > scripts), so the build reports show that freenx has a broken dependency > on x86_64. I believe this to be a packaging design bug. In my view it makes no sense to have a dependency "noarch -> arch-specific". The benefit of having freenx as noarch is negligible. Currently, it's listed as 59K only. The opposite is the "arch-specific -> noarch" dependency. You could have avoided this breakage in FE5 by building these packages for Fedora Extras Development first, using it as the testbed it's supposed to be. > What is the best way to handle this? Can I Excludearch: > x86_64 on a noarch package? No. ExcludeArch is about the set of build target architectures, but your BuildArch is "noarch". > How about a requires: wrapped in an ifnarch conditional? Think twice. Why does freenx depend on nx? Would it make sense to drop the dependency altogether? If not, freenx should become arch-specific, since it depends on an arch-specific package anyway. > Second, nx is based on XFree86 4.3.0. The backend components come from a > full X11 build, and require a number of adapted libraries from this > build. The library of most concern right now is libX11.so.6.2. Nx > installs this library in /usr/lib/NX/lib, then when any of the nx > components are called, a wrapper puts the NX/lib path in front of the ld > path for just that application, so as not to step on any of the other > libraries already on the system. The problem, which was not apparent > until now, is that yum thinks that nx provides a valid libX11.so.6 so > certain applications requiring this file may download nx and its > dependencies. How do I fix this? You need to add a filter to rpmbuild's soname dependency check script from within your spec file. > I feel that this could actually be > considered a deficiency in yum or rpm in that the file is not in the > standard library path, so it really isn't provided to the system. Any > input would be greatly appreciated in this. No. It's not Yum's or RPM's business to tell which paths are standard and which are not. Any package can install files to customise the run-time linker's search paths, and neither Yum or RPM can know about that at build-time. From bugs.michael at gmx.net Sat Jun 10 10:31:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 12:31:03 +0200 Subject: Thoughts about courier-mta packaging? In-Reply-To: <4489DBBB.5090303@forevermore.net> References: <446E2D76.7020004@forevermore.net> <44889D55.4030308@forevermore.net> <1149873790.7833.43.camel@dhcp83-49.boston.redhat.com> <4489DBBB.5090303@forevermore.net> Message-ID: <20060610123103.8d73cdaa.bugs.michael@gmx.net> On Fri, 09 Jun 2006 13:36:11 -0700, Chris Petersen wrote: > > There is nothing wrong with starting from the upstream spec. It will > > have to adhere to the standards though, no flexibility on that. It > > would be best if upstream could accept the changes you have to make so > > that life is easier. > > well, since one of the standards is "no other-distro stuff in the spec," > that makes courier's incompatible. My main concern is that it's > designed to build an rpm -- on any rpm-based distro. I can clean up the > stuff that would annoy rpmlint, possibly the group name (nonstandard), > but I'm not about to maintain it in such a way that I always have to > pull out Sam's non-fedora customizations. > > For reference, the file is available at: > > http://courier.cvs.sourceforge.net/courier/courier/courier/courier.spec.in?view=markup > This one is a funny incarnation of the infamous superfluous buildroot check in the spec: > test "$RPM_BUILD_ROOT" != "" && rm -rf $RPM_BUILD_ROOT It's even less useful than checking whether buildroot is set to '/'. :-) Note that the buildroot == '/' check still seen in spec files occasionally is from times when the "BuildRoot:" tag in spec files was not mandatory and when scripts in rpmbuild did not check it either. I think it is a myth that package builders commonly lost their root directory because of this. Personally, I don't know anybody who has been hit by "rm -rf /" going wild during rpmbuild. But I've seen the occasional report of typos causing many others scripts to do this, where "safety checks" failed to recognise root == // or root == '/ ' and in one very old case even $RPM_BUILD_ROOT/ Back to the courier spec, I find it overly big and complex. Screen-filling Perl helper functions, which generate %attr(...) values on-the-fly, redefinition of several globals, e.g. > %define _missing_doc_files_terminate_build 1 > %define _unpackaged_files_terminate_build 1 > %define __libtoolize /bin/true even a "%define configure ...", > AutoProv: no spec sections with a comment like > # Break up a single filelist into multiple packages right here. This is > # going to be ugly. > ## Ok, upgrades are going to get ugly. lots of "sed" usage, build-time generated profile.{sh,csh} scripts, inline Perl script usage, chown in %post (!), > chown --reference=%{_sysconfdir} %{_sysconfdir}/userdb triggerpostun scriptlets which mess with .rpmnew files. This package looks pretty much like a maintenance nightmare. I wonder why the install process is not simplified with more work in "make install"? From chris.stone at gmail.com Sat Jun 10 10:25:40 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 10 Jun 2006 03:25:40 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> Message-ID: On 6/10/06, TASAKA, Mamoru wrote: > Hello, Christopher: > I also FAILED building, but correcting spec file like attached seems to work for me. -CFLAGS="%{optflags}" %{__python} setup.py build +CFLAGS="%{optflags} -DSDL_VIDEO_DRIVER_X11" %{__python} setup.py build Interesting, is this something that should be done in a spec file or set in the optflags macro? From chris.stone at gmail.com Sat Jun 10 10:33:07 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 10 Jun 2006 03:33:07 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> Message-ID: On 6/10/06, Christopher Stone wrote: > On 6/10/06, TASAKA, Mamoru wrote: > > Hello, Christopher: > > I also FAILED building, but correcting spec file like attached seems to work for me. > > -CFLAGS="%{optflags}" %{__python} setup.py build > +CFLAGS="%{optflags} -DSDL_VIDEO_DRIVER_X11" %{__python} setup.py build > > Interesting, is this something that should be done in a spec file or > set in the optflags macro? > Or perhaps better to patch the python setup script and inform upstream. Looks like an upstream issue perhaps. Thanks for your help. From bugs.michael at gmx.net Sat Jun 10 10:35:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 12:35:25 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> Message-ID: <20060610123525.3e135514.bugs.michael@gmx.net> On Sat, 10 Jun 2006 17:07:01 +0900, TASAKA, Mamoru wrote: > Christopher Stone wrote: > > On 6/9/06, Matt Domsch wrote: > >> pygame > > > > Can anyone help me figure out why this is failing? Here is the build log: > > > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/pygame-1.7.1-6.fc6.src.rpm/result/build.log > > > > > > AFAICT this should build correctly. I looked at the data structure > > for SDL-1.2.10 and it is the same as 1.2.9. It builds fine for me on > > FC-5 and it built fine for me the last time I tried it on devel. > > > > Hello, Christopher: > I also FAILED building, but correcting spec file like attached seems to work for me. > > -Release: 6%{?dist} > +Release: 6.1%{?dist} Caution! '1' is larger than 'f', so this release would be seen as newer than any fc4, fc5, fc6 release. Avoid a half-hearted release bump like this. Use 7%{?dist} or 6%{dist}.1, where the latter is a bit dangerous, too, since when built locally with %dist undefined, Joe User ends up with 6.1, which is higher than 6.fc6, for instance. From chris.stone at gmail.com Sat Jun 10 10:47:40 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 10 Jun 2006 03:47:40 -0700 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <20060610114602.23111149.bugs.michael@gmx.net> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <20060610114602.23111149.bugs.michael@gmx.net> Message-ID: On 6/10/06, Michael Schwendt wrote: > Calm down, everyone. Ralf is right. Using %makeinstall should be > discouraged actually, and, for instance, I was under the impression that > we agreed on that long ago. No one is disagreeing with Ralf, we are only suggesting that this information be added to the wiki page somewhere so new people coming in can learn about these things. I think it would be nice to have some kind of documentation on the macros available to packagers somewhere. Are there any other macros that I should not be using? From bugs.michael at gmx.net Sat Jun 10 10:52:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 12:52:33 +0200 Subject: Sharing sources in CVS In-Reply-To: <1149908675.19028.9.camel@maple.ocjtech.us> References: <448A0792.4060706@kobold.org> <1149908675.19028.9.camel@maple.ocjtech.us> Message-ID: <20060610125233.d8ce060a.bugs.michael@gmx.net> On Fri, 09 Jun 2006 22:04:34 -0500, Jeffrey C. Ollie wrote: > On Fri, 2006-06-09 at 16:43 -0700, Michael Thomas wrote: > > > Is it possible to share a source tarball between two separate packages > > in CVS? Yes. > Alternately, would it be possible to have two spec files in the > > same CVS module, so that they could be built separately? Better don't try this. > > Or will either > > of these solutions just confuse the build system? Likely. > Yes, it's possible... The build system tracks source tarballs by MD5 > hashes. The build system will keep only one copy of the source tarball, > no matter how many packages attempt to upload it. When no more > packages reference the source tarball it will be purged from the system. Don't put more than one spec file into a CVS module root. One src.rpm per module, one spec file. Don't expect any magic which knows which one of multiple spec files to use during rpmbuild. WRT the source tarball, any file not stored in CVS, but uploaded into lookaside cache with "make upload FILES=..." or "make new-sources FILES=..." is identified by its filename and MD5 checksum as specified in the "sources" file in CVS. Any "sources" file in CVS can reference any file in lookaside cache. For example: cd bar/devel make upload FILES=bar-1.0.tar.gz makes available "bar-1.0.tar.gz" _globally_, i.e. any other branch of "bar" in CVS, any other module in CVS can access it. No need to try uploading the tarball from within ../bar/FC-5, ../bar/FC-4 or ../foobar/devel. You only need a proper "sources" file with the right MD5 checksum for this tarball. You can simply copy known good "sources" and ".cvsignore" files to a different branch or module and commit them. From paul at city-fan.org Sat Jun 10 11:37:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 10 Jun 2006 12:37:08 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448A7311.8030805@bigpond.net.au> References: <20060610050428.GA28545@lists.us.dell.com> <448A7311.8030805@bigpond.net.au> Message-ID: <1149939429.9317.25.camel@laurel.intra.city-fan.org> On Sat, 2006-06-10 at 17:21 +1000, David Timms wrote: > Matt Domsch wrote: > > Note: This is using the extremely reduced chroot as documented in the Extras > > Exception List. > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > > automake, autoconf, libtool and m4 had accidentally been included in > > my buildroots from previous runs; they're removed in this and > > subsequent runs, which will cause additional build failures. > > > > Extras tree as of Thursday afternoon; it takes quite a while to > > rebuild 1800 packages on 2 architectures. :-) > > > > In addition, about 5 packages (all perl modules IIRC) managed to hang > > in 'make test'. I manually killed those after ~16 hours, and they'll > > show up as failed builds below. > > > > Open Bugs which now build, and can be marked CLOSED RAWHIDE: > > gnupg2 194079 NEW > > libgpg-error 193550 NEW > > > > Note: This is using a reduced set of packages in the build chroot as > > compared to the standard Fedora Extras build system before FC6test1. See > > http://fedoraproject.org/wiki/QA/FixBuildRequires for more > > information, including the list of packages removed from the > > default build chroot. > > > > Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT 2006 > > Number failed to build: 206 > > Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > > Leaving: 205 > > (there may be some duplicates if rawhide has 2 versions of a package) > > > > Of those expected to have worked... > > Without a bug filed: 198 > > ---------------------------------- > > abiword > > airsnort > > allegro > > amaya > > argus > > azureus > ... > I am happy to spend sometime filing extras buildrequires bugs, if the > consensus is that is what the community wants ? I would very much prefer if you only filed bugs with suggested fixes, rather than simple bug reports. Matt's reports provide a list of failing packages, so I don't think simply filing bug reports adds a lot. Moreover, Matt's list is convenient place for people to find packages to look at if they're interested in getting things fixed. Paul. From pmatilai at laiskiainen.org Sat Jun 10 11:49:55 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 10 Jun 2006 04:49:55 -0700 (PDT) Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <20060610114602.23111149.bugs.michael@gmx.net> Message-ID: On Sat, 10 Jun 2006, Christopher Stone wrote: > On 6/10/06, Michael Schwendt wrote: >> Calm down, everyone. Ralf is right. Using %makeinstall should be >> discouraged actually, and, for instance, I was under the impression that >> we agreed on that long ago. > > No one is disagreeing with Ralf, we are only suggesting that this > information be added to the wiki page somewhere so new people coming > in can learn about these things. I think it would be nice to have > some kind of documentation on the macros available to packagers > somewhere. Are there any other macros that I should not be using? How about replacing the %makeinstall macro definition with something useful instead? "There's this convenient macro but you shouldn't use it" seems silly to me. - Panu - From denis at poolshark.org Sat Jun 10 12:11:59 2006 From: denis at poolshark.org (Denis Leroy) Date: Sat, 10 Jun 2006 14:11:59 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <20060610114602.23111149.bugs.michael@gmx.net> Message-ID: <448AB70F.5010006@poolshark.org> Panu Matilainen wrote: > How about replacing the %makeinstall macro definition with something > useful instead? "There's this convenient macro but you shouldn't use it" > seems silly to me. Thank you, that's exactly what I was thinking. How about updating all those nice macros with what we should be using ? If the old behavior is still useful in some cases, let's identify those cases and rename the old %makeinstall to something more excplit. We're fighting against something (the RPM macro system) that's supposed to be our friend! Same thing with the common desktop file install entries etc, we could define macros for those and update all the SPEC files in CVS. -denis From j.w.r.degoede at hhs.nl Sat Jun 10 12:23:31 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 10 Jun 2006 14:23:31 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448A78DD.20304@hhs.nl> References: <20060610050428.GA28545@lists.us.dell.com> <448A7311.8030805@bigpond.net.au> <448A78DD.20304@hhs.nl> Message-ID: <448AB9C3.8020702@hhs.nl> >> Matt Domsch wrote: >>> Note: This is using the extremely reduced chroot as documented in the >>> Extras >>> Exception List. >>> http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 >>> >>> automake, autoconf, libtool and m4 had accidentally been included in >>> my buildroots from previous runs; they're removed in this and >>> subsequent runs, which will cause additional build failures. >>> Hi Matt, gcompris is on the failed list, but it never got build because of a yum timeout in setting op the buildroot, so I've got no idea if there really is a problem or not: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/gcompris-7.4-10.fc6.src.rpm/result/root.log I'm not saying its problem free otherwise though :) Regards, Hans From pmatilai at laiskiainen.org Sat Jun 10 12:29:45 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 10 Jun 2006 05:29:45 -0700 (PDT) Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <448AB70F.5010006@poolshark.org> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <20060610114602.23111149.bugs.michael@gmx.net> <448AB70F.5010006@poolshark.org> Message-ID: On Sat, 10 Jun 2006, Denis Leroy wrote: > Panu Matilainen wrote: >> How about replacing the %makeinstall macro definition with something useful >> instead? "There's this convenient macro but you shouldn't use it" seems >> silly to me. > > Thank you, that's exactly what I was thinking. How about updating all those > nice macros with what we should be using ? If the old behavior is still > useful in some cases, let's identify those cases and rename the old > %makeinstall to something more excplit. Yeah, %makebrokeninstall comes to mind. > We're fighting against something (the RPM macro system) that's supposed to be > our friend! Same thing with the common desktop file install entries etc, we > could define macros for those and update all the SPEC files in CVS. Indeed. RPM packaging is full of crazy little details such as this you're supposed to somehow know and remember. Another example that comes to mind is the "make %{?_smp_mflags}" construct. Why is that not defined as %make, as it's supposed to be the default, right? So instead of having that conditional macro stuff in each and every spec, those broken packages could set RPM_BUILD_NRCPUS=1 or similar which would make it very clear that non-paraller build is used intentionally. - Panu - From jonathan.underwood at gmail.com Sat Jun 10 12:52:50 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 10 Jun 2006 13:52:50 +0100 Subject: Buildsys glitch? Message-ID: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> Hi, I just pushed builds for an updated emacs-auctex package for FC-4, FC-5 and devel. FC-4 and devel succeeded (specs are the same), but FC-5 fails during configure with this: checking for emacs... /usr/bin/emacs checking if /usr/bin/emacs is XEmacs... cat: ./conftest-478: No such file or directory configure: error: Unable to run /usr/bin/emacs! Aborting! error: Bad exit status from /var/tmp/rpm-tmp.55095 (%build) which seems like a build system issue - emacs is in the BuildRequires and is clearly installed? The same package builds for me locally on FC-5, but I haven't had the time to do a mock build yet as the machine I usually use for that is offline due to a power outage at work. Any ideas? Jonathan From jonathan.underwood at gmail.com Sat Jun 10 13:31:16 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 10 Jun 2006 14:31:16 +0100 Subject: Buildsys glitch? In-Reply-To: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> Message-ID: <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> On 10/06/06, Jonathan Underwood wrote: > Hi, > > I just pushed builds for an updated emacs-auctex package for FC-4, > FC-5 and devel. FC-4 and devel succeeded (specs are the same), but > FC-5 fails during configure with this: > > checking for emacs... /usr/bin/emacs > checking if /usr/bin/emacs is XEmacs... cat: ./conftest-478: No such > file or directory > configure: error: Unable to run /usr/bin/emacs! Aborting! > error: Bad exit status from /var/tmp/rpm-tmp.55095 (%build) > > which seems like a build system issue - emacs is in the BuildRequires > and is clearly installed? The same package builds for me locally on > FC-5, but I haven't had the time to do a mock build yet as the machine > I usually use for that is offline due to a power outage at work. > The relevant part of the configure script is: echo "$as_me:$LINENO: checking if ${EMACS} is XEmacs" >&5 echo $ECHO_N "checking if ${EMACS} is XEmacs... $ECHO_C" >&6 elisp="(if (featurep (quote xemacs)) \"yes\" \"no\")" OUTPUT=./conftest-$$ echo "${EMACS}" -batch -no-site-file -eval "(let* ((x ${elisp})) (write-region (if (stringp x) x (prin1-to-string x)) nil \"${OUTPUT}\"))" >& 5 2>&1 "${EMACS}" -batch -no-site-file -eval "(let* ((x ${elisp})) (write-region (if (stringp x) x (prin1-to-string x)) nil \"${OUTPUT}\"))" >& 5 2>&1 XEMACS="`cat ${OUTPUT}`" echo "=> ${XEMACS}" >& 5 2>&1 rm -f ${OUTPUT} if test "${XEMACS}" = "yes"; then EMACS_FLAVOR=xemacs EMACS_NAME="XEmacs" elif test "${XEMACS}" = "no"; then EMACS_FLAVOR=emacs EMACS_NAME="Emacs" else { { echo "$as_me:$LINENO: error: Unable to run ${EMACS}! Aborting!" >&5 echo "$as_me: error: Unable to run ${EMACS}! Aborting!" >&2;} which is failing at XEMACS="`cat ${OUTPUT}`" for reasons I can't fathom. Jonathan. From rc040203 at freenet.de Sat Jun 10 14:26:38 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Jun 2006 16:26:38 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <20060610114602.23111149.bugs.michael@gmx.net> Message-ID: <1149949599.12112.140.camel@mccallum.corsepiu.local> On Sat, 2006-06-10 at 04:49 -0700, Panu Matilainen wrote: > On Sat, 10 Jun 2006, Christopher Stone wrote: > > > On 6/10/06, Michael Schwendt wrote: > >> Calm down, everyone. Ralf is right. Using %makeinstall should be > >> discouraged actually, and, for instance, I was under the impression that > >> we agreed on that long ago. > > > > No one is disagreeing with Ralf, we are only suggesting that this > > information be added to the wiki page somewhere so new people coming > > in can learn about these things. I think it would be nice to have > > some kind of documentation on the macros available to packagers > > somewhere. Are there any other macros that I should not be using? > > How about replacing the %makeinstall macro definition with something > useful instead? This doesn't work, because it would break compatibility and will have to stay for many years, if you don't want to break compatibility. It's just that %makeinstall isn't wrong, it's simply that most Makefile nowadays support a superior mechanism, which renders using %makeinstall into an anachronism/discouraged and redenders changing a functional spec file using a functional "make DESTDIR=.. install" to using %makeinstall a very questionable step. > "There's this convenient macro but you shouldn't use it" > seems silly to me. Nope, it's just a case of "Think about what you are doing". There are no 100% bullet proof rule to use %makeinstall etc. Packagers can't avoid to check for what a package expects and should chose the way they consider the most convenient to them. In some cases this will be macros, in some cases it will be other steps. Finally, in case somebody wants to write a portable spec file, ... don't use any macros - They are all broken on some distros (comprising RH and Fedora). Ralf From jonathan.underwood at gmail.com Sat Jun 10 14:41:48 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 10 Jun 2006 15:41:48 +0100 Subject: Buildsys glitch? In-Reply-To: <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> Message-ID: <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> On 10/06/06, Jonathan Underwood wrote: > which is failing at XEMACS="`cat ${OUTPUT}`" for reasons I can't fathom. > Patching out the offending part of the configure file then leads to a failure later on of a similar ilk. Basically, it always fails when trying to cat ./conftest-$$. Is there any reason specific to FC-5 that the creation and subsequent read of ./conftest-$$ ? Jonathan. From tibbs at math.uh.edu Sat Jun 10 15:08:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 10 Jun 2006 10:08:24 -0500 Subject: nx requires and provides In-Reply-To: <20060610115935.824b1a42.bugs.michael@gmx.net> (Michael Schwendt's message of "Sat, 10 Jun 2006 11:59:35 +0200") References: <448A7CBD.9080402@gmail.com> <20060610115935.824b1a42.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> I believe this to be a packaging design bug. In my view it makes MS> no sense to have a dependency "noarch -> arch-specific". But it is impossible not to have such dependencies. Every noarch Perl and Python module is going to require Perl or Python. If I package up nothing more than a simple shell script it's going to require /bin/sh. And its quite easy to think of ways that noarch packages might depend on some arch-specific package that won't build on 64-bit or PPC or whatever. - J< From jkeating at redhat.com Sat Jun 10 15:12:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Jun 2006 11:12:26 -0400 Subject: nx requires and provides In-Reply-To: <20060610115935.824b1a42.bugs.michael@gmx.net> References: <448A7CBD.9080402@gmail.com> <20060610115935.824b1a42.bugs.michael@gmx.net> Message-ID: <1149952346.27050.0.camel@ender> On Sat, 2006-06-10 at 11:59 +0200, Michael Schwendt wrote: > > I believe this to be a packaging design bug. In my view it makes no > sense > to have a dependency "noarch -> arch-specific". This happens in a lot of cases. A python package that is by nature noarch, but needs arch specific C modules or python modules to address arch specific tasks. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Sat Jun 10 15:12:57 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 10 Jun 2006 10:12:57 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: References: <20060610050428.GA28545@lists.us.dell.com> Message-ID: <20060610151257.GA24764@lists.us.dell.com> On Fri, Jun 09, 2006 at 10:21:05PM -0700, Christopher Stone wrote: > On 6/9/06, Matt Domsch wrote: > >Note: This is using the extremely reduced chroot as documented in the > >Extras > >Exception List. > >> Extras Rawhide-in-Mock Build Results for i386 Fri Jun 9 23:06:25 CDT > >2006 > >Of those expected to have worked... > >Without a bug filed: 198 > >---------------------------------- > >nucleo > > This fails because your build system does not define %fedora, and the > spec file uses %fedora to determine if it should install > xorg-x11-devel or not. Note: this builds fine in your x86_64 report, > so I'm guessing you have it defined in x86_64 but not on i386? Oops. buildsys-build isn't listed in the FESCo-approved list of minimal build environment. But of course it's necessary, and is provided by the build system (at least when you put it in the buildroot.xml file :-). Fixed, and rebuilding everything... 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 tcallawa at redhat.com Sat Jun 10 15:14:05 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Jun 2006 10:14:05 -0500 Subject: Retiring: R-gnomeGUI In-Reply-To: References: <1149803300.5199.65.camel@localhost.localdomain> Message-ID: <1149952445.5199.178.camel@localhost.localdomain> On Thu, 2006-06-08 at 19:01 -0500, Marc Schwartz wrote: > Tom 'spot' Callaway wrote: > > The R-gnomeGUI package relies on ancient gnome libs to function, and > > since those libs are going away in -devel, I'm retiring this package. If > > anyone is motivated to do the work to port this code to gtk2, then I > > would be happy to give them ownership of this package. > > > > ~spot > > Tom, > > Is this situation FC specific or more general for GNOME moving forward? Fedora Core is dropping the ancient GNOME 1 libs in FC-6. GNOME long ago moved way past the point where R-gnomeGUI stopped. > Barring somebody wanting to port to gtk2, what was a spartan proof of > concept GUI for R, it may be time to finally retire the CRAN package to > orphan status. Or perhaps to simply make the code available for example > purposes, but not have a functional version if the libs are no longer > going to be available. That's a call for R Core to make. Yep. > There are certainly better evolving GUI's for R for those that might > want one. If there is a good gtk2 GUI console (I could not find one), I would be willing to put it in Fedora Extras. At one point, the gnomeGUI tool was described to me as having: "... not been developed in some years. It is more of a technology demonstration than a useable GUI." Based on that feedback from upstream, and the removal of GNOME 1 libs from Fedora Core, I've opted to retire this package. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Sat Jun 10 15:17:03 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Jun 2006 10:17:03 -0500 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-09 In-Reply-To: <20060609101153.27826.79393@extras64.linux.duke.edu> References: <20060609101153.27826.79393@extras64.linux.duke.edu> Message-ID: <1149952623.5199.180.camel@localhost.localdomain> On Fri, 2006-06-09 at 10:11 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-development-i386: > ---------------------------------------------------------------------- > R-gnomeGUI 2.1.0-5.fc5.i386 All of the R-gnomeGUI packages in -devel just need to be nuked from orbit. I'll put in the proper request for this to occur. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Sat Jun 10 15:27:09 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Jun 2006 18:27:09 +0300 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <20060610050428.GA28545@lists.us.dell.com> References: <20060610050428.GA28545@lists.us.dell.com> Message-ID: <1149953230.8267.25.camel@localhost.localdomain> On Sat, 2006-06-10 at 00:04 -0500, Matt Domsch wrote: [...] Would it be possible to include info about maintainers of listed packages in this report? The list is pretty long, and it's not too much fun to try to search it through based on package names if one happens to maintain lots of packages or sponsor others who in turn maintain many packages too. On a related note, libusb-devel was broken in Rawhide and has been fixed now (missing dependency on pkgconfig); I think that has caused a bunch of build failures which thus require no action. From tibbs at math.uh.edu Sat Jun 10 15:30:31 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 10 Jun 2006 10:30:31 -0500 Subject: Documentation packages in Package Naming Guidelines (and standards) In-Reply-To: <200606092346.53386.hugo@devin.com.br> (Hugo Cisneiros's message of "Fri, 9 Jun 2006 23:46:53 -0300") References: <200606092346.53386.hugo@devin.com.br> Message-ID: >>>>> "HC" == Hugo Cisneiros writes: HC> BTW, I noted that some packages in Extras have a *-docs HC> sub-package instead of *-doc. Talking with Jason Tibbitts in IRC, HC> he said that this is normal. Is there a standard for this or it's HC> up to the packager/reviewer? We have a standard; I'm just continually confused about which one actually is the standard. Both names were used in various wiki pages and I just can't keep it straight. A look through what's currently in extras shows little agreement, although more -doc than -docs. Getting this in the naming guidelines would indeed be a good idea. Write access to those pages has been restricted so we'll have to go through the packaging committee (i.e. currently just spot). - J< From MSchwartz at mn.rr.com Sat Jun 10 15:30:36 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Sat, 10 Jun 2006 10:30:36 -0500 Subject: Retiring: R-gnomeGUI In-Reply-To: <1149952445.5199.178.camel@localhost.localdomain> References: <1149803300.5199.65.camel@localhost.localdomain> <1149952445.5199.178.camel@localhost.localdomain> Message-ID: <448AE59C.5060703@mn.rr.com> Tom 'spot' Callaway wrote: > On Thu, 2006-06-08 at 19:01 -0500, Marc Schwartz wrote: >> Tom 'spot' Callaway wrote: >>> The R-gnomeGUI package relies on ancient gnome libs to function, and >>> since those libs are going away in -devel, I'm retiring this package. If >>> anyone is motivated to do the work to port this code to gtk2, then I >>> would be happy to give them ownership of this package. >>> >>> ~spot >> Tom, >> >> Is this situation FC specific or more general for GNOME moving forward? > > Fedora Core is dropping the ancient GNOME 1 libs in FC-6. GNOME long ago > moved way past the point where R-gnomeGUI stopped. Tom, Thanks for the clarification. >> Barring somebody wanting to port to gtk2, what was a spartan proof of >> concept GUI for R, it may be time to finally retire the CRAN package to >> orphan status. Or perhaps to simply make the code available for example >> purposes, but not have a functional version if the libs are no longer >> going to be available. That's a call for R Core to make. > > Yep. > >> There are certainly better evolving GUI's for R for those that might >> want one. > > If there is a good gtk2 GUI console (I could not find one), I would be > willing to put it in Fedora Extras. I don't know that there is one to be honest. With the proviso that I am not a R GUI user (I use ESS with emacs 22 from CVS with the XFT patches), the ones that I see discussed relatively frequently on the R lists (ie. RCmdr, JGR, SciViews, etc.) are not GTK based. > At one point, the gnomeGUI tool was described to me as having: > > "... not been developed in some years. It is more of a > technology demonstration than a useable GUI." That characterization is still accurate. > Based on that feedback from upstream, and the removal of GNOME 1 libs > from Fedora Core, I've opted to retire this package. No disagreement with your decision. I'll post a note to r-devel (as I noted in my reply to Jos?), so that R Core is aware of the pending change and can make whatever decisions they require based upon that information. Thanks Tom. Regards, Marc Schwartz From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jun 10 15:31:58 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 11 Jun 2006 00:31:58 +0900 Subject: Buildsys glitch? In-Reply-To: <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> Message-ID: <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> Jonathan Underwood wrote: > On 10/06/06, Jonathan Underwood wrote: >> which is failing at XEMACS="`cat ${OUTPUT}`" for reasons I can't fathom. >> > > Patching out the offending part of the configure file then leads to a > failure later on of a similar ilk. Basically, it always fails when > trying to cat ./conftest-$$. Is there any reason specific to FC-5 that > the creation and subsequent read of ./conftest-$$ ? > > Jonathan. > Seems VERY STRANGE. It seems that your srpm should be rebuilt as done on FE-devel. Maybe does this show some bugs on emacs under FC5-ppc? I cannot understand why, however, the attached patch may find a clue to this issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: auctex-11.83-debug.patch Type: text/x-patch Size: 349 bytes Desc: not available URL: From tcallawa at redhat.com Sat Jun 10 15:32:55 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Jun 2006 10:32:55 -0500 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149916356.12112.111.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <1149916356.12112.111.camel@mccallum.corsepiu.local> Message-ID: <1149953575.5199.183.camel@localhost.localdomain> On Sat, 2006-06-10 at 07:12 +0200, Ralf Corsepius wrote: > > Then please make the suggestion to FESCo to add a change to the > > packaging guide. I think its unfair to put the spot light on someone for > > doing something that is not being discouraged in the Fedora packaging > > guide lines. > > Pardon, you find it unfair to ask people to think about what he is > doing? You find it's appropriate to resort to bureaucracy? > > Sorry, I beg to differ. My psychic powers are unable to read your mind, Ralf. It would have taken you less time for you to email me (or fedora-packaging) and ask for this obvious oversight to be corrected than it took you to flame someone on this mailing list. The guidelines have been updated to reflect that %makeinstall may eat your babies, and that it should not be used in Fedora RPMS. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Sat Jun 10 15:42:38 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Jun 2006 10:42:38 -0500 Subject: Documentation packages in Package Naming Guidelines (and standards) In-Reply-To: References: <200606092346.53386.hugo@devin.com.br> Message-ID: <1149954158.5199.185.camel@localhost.localdomain> On Sat, 2006-06-10 at 10:30 -0500, Jason L Tibbitts III wrote: > >>>>> "HC" == Hugo Cisneiros writes: > > HC> BTW, I noted that some packages in Extras have a *-docs > HC> sub-package instead of *-doc. Talking with Jason Tibbitts in IRC, > HC> he said that this is normal. Is there a standard for this or it's > HC> up to the packager/reviewer? > > We have a standard; I'm just continually confused about which one > actually is the standard. Both names were used in various wiki pages > and I just can't keep it straight. A look through what's currently in > extras shows little agreement, although more -doc than -docs. > > Getting this in the naming guidelines would indeed be a good idea. > Write access to those pages has been restricted so we'll have to go > through the packaging committee (i.e. currently just spot). All of the three core guidelines documents (Naming, Packaging, Review) are now consistent on this point. You should use %{name}-doc for documentation subpackages. All of this confusion over a typo I made, sorry folks. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Sat Jun 10 15:49:44 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Jun 2006 10:49:44 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <20060610123525.3e135514.bugs.michael@gmx.net> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> Message-ID: <1149954584.5199.188.camel@localhost.localdomain> On Sat, 2006-06-10 at 12:35 +0200, Michael Schwendt wrote: > > -Release: 6%{?dist} > > +Release: 6.1%{?dist} > > Caution! '1' is larger than 'f', so this release would be seen as newer than > any fc4, fc5, fc6 release. Avoid a half-hearted release bump like this. Use > 7%{?dist} or 6%{dist}.1, where the latter is a bit dangerous, too, since when > built locally with %dist undefined, Joe User ends up with 6.1, which is higher > than 6.fc6, for instance. Indeed. Perhaps we should only allow integer release increments? I can document this in the guidelines... ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Sat Jun 10 15:55:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Jun 2006 17:55:46 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149954584.5199.188.camel@localhost.localdomain> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> Message-ID: <1149954948.3309.48.camel@rousalka.dyndns.org> Le samedi 10 juin 2006 ? 10:49 -0500, Tom 'spot' Callaway a ?crit : > On Sat, 2006-06-10 at 12:35 +0200, Michael Schwendt wrote: > > > > -Release: 6%{?dist} > > > +Release: 6.1%{?dist} > > > > Caution! '1' is larger than 'f', so this release would be seen as newer than > > any fc4, fc5, fc6 release. Avoid a half-hearted release bump like this. Use > > 7%{?dist} or 6%{dist}.1, where the latter is a bit dangerous, too, since when > > built locally with %dist undefined, Joe User ends up with 6.1, which is higher > > than 6.fc6, for instance. > > Indeed. Perhaps we should only allow integer release increments? I can > document this in the guidelines... please don't, we need 0.x to mark release candidates and others pre-real-release versions -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Sat Jun 10 16:08:35 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Jun 2006 19:08:35 +0300 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149954584.5199.188.camel@localhost.localdomain> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> Message-ID: <1149955715.8267.41.camel@localhost.localdomain> On Sat, 2006-06-10 at 10:49 -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-06-10 at 12:35 +0200, Michael Schwendt wrote: > > > Use > > 7%{?dist} or 6%{dist}.1, where the latter is a bit dangerous, too, since when > > built locally with %dist undefined, Joe User ends up with 6.1, which is higher > > than 6.fc6, for instance. Well, it can be argued too that getting the same NEVR from a local rebuild as is in the corresponding distro package is "dangerous" too as the package is not the same. > Indeed. Perhaps we should only allow integer release increments? That's very wasteful in cases where only an old distro version needs a fix as it will require rebuilds of not only the package fixed in an old distro version, but all in newer distro versions too, just for the sake of keeping the upgrade path intact. Useless downloads, potential config file annoyance etc. > I can document this in the guidelines... +1 for mandating integer-only bumps in cases where it won't cause an upgrade problem, and appending dots and digits to the very *right* of the release tag otherwise (including after the disttag). See also https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html From ville.skytta at iki.fi Sat Jun 10 16:09:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Jun 2006 19:09:50 +0300 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149955715.8267.41.camel@localhost.localdomain> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> <1149955715.8267.41.camel@localhost.localdomain> Message-ID: <1149955790.8267.43.camel@localhost.localdomain> On Sat, 2006-06-10 at 19:08 +0300, Ville Skytt? wrote: > +1 for mandating integer-only bumps in cases where it won't cause an > upgrade problem, and appending dots and digits to the very *right* of > the release tag otherwise (including after the disttag). See also > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html ...and of course allowing the 0.* special case for pre-release versions like Nicolas pointed out. From katzj at redhat.com Sat Jun 10 16:13:24 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 10 Jun 2006 12:13:24 -0400 Subject: nx requires and provides In-Reply-To: <448A7CBD.9080402@gmail.com> References: <448A7CBD.9080402@gmail.com> Message-ID: <1149956004.19002.1.camel@aglarond.local> On Sat, 2006-06-10 at 01:03 -0700, Rick Stout wrote: > First, nx *does not* work on x86_64, so it has an Excludearch: x86_64 in > the spec. This is fine for the arch exclusion, but there is a package > that depends on nx, freenx which is noarch (its just a bunch of > scripts), so the build reports show that freenx has a broken dependency > on x86_64. What is the best way to handle this? Can I Excludearch: > x86_64 on a noarch package? How about a requires: wrapped in an ifnarch > conditional? The way we handle this with Core at the moment is an ExcludeArch in the noarch package and then the tree composition scripts use that to say "no, don't pull this package into the $arch tree". Similar in the Extras scripts may well make a lot of sense. Jeremy From katzj at redhat.com Sat Jun 10 16:15:44 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 10 Jun 2006 12:15:44 -0400 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149953575.5199.183.camel@localhost.localdomain> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <448A4D8A.8050203@knox.net.nz> <1149915767.12112.102.camel@mccallum.corsepiu.local> <448A5330.7000407@knox.net.nz> <1149916356.12112.111.camel@mccallum.corsepiu.local> <1149953575.5199.183.camel@localhost.localdomain> Message-ID: <1149956144.19002.3.camel@aglarond.local> On Sat, 2006-06-10 at 10:32 -0500, Tom 'spot' Callaway wrote: > The guidelines have been updated to reflect that %makeinstall may eat > your babies, and that it should not be used in Fedora RPMS. ... except in cases where 'make DESTDIR=... install' doesn't work[1], right? :) Jeremy [1] eg, old code in most cases From jonathan.underwood at gmail.com Sat Jun 10 16:16:06 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 10 Jun 2006 17:16:06 +0100 Subject: Buildsys glitch? In-Reply-To: <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> Message-ID: <645d17210606100916p7790d7f2t1d6bc9a12c8c15c7@mail.gmail.com> On 10/06/06, TASAKA, Mamoru wrote: > Seems VERY STRANGE. It seems that your srpm should be rebuilt as done on FE-devel. > > Maybe does this show some bugs on emacs under FC5-ppc? I cannot understand why, > however, the attached patch may find a clue to this issue. OK, thanks, will give that a whirl. J. From ville.skytta at iki.fi Sat Jun 10 16:17:42 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Jun 2006 19:17:42 +0300 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149955790.8267.43.camel@localhost.localdomain> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> <1149955715.8267.41.camel@localhost.localdomain> <1149955790.8267.43.camel@localhost.localdomain> Message-ID: <1149956262.8267.46.camel@localhost.localdomain> On Sat, 2006-06-10 at 19:09 +0300, Ville Skytt? wrote: > On Sat, 2006-06-10 at 19:08 +0300, Ville Skytt? wrote: > > > +1 for mandating integer-only bumps in cases where it won't cause an > > upgrade problem, and appending dots and digits to the very *right* of > > the release tag otherwise (including after the disttag). See also > > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html > > ...and of course allowing the 0.* special case for pre-release versions > like Nicolas pointed out. ...and also allowing kmod packages to continue to have the target kernel version in the release tag. From andy at smile.org.ua Sat Jun 10 16:53:17 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 10 Jun 2006 19:53:17 +0300 Subject: %find_lang vs. several lang packs Message-ID: <448AF8FD.7010606@smile.org.ua> Hi, All! My proposition is to add the small howto usage of the %find_lang macro in specific case to the Wiki guidelines. It's came from the following discuss: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189315#c8 Opinions? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From denis at poolshark.org Sat Jun 10 17:20:50 2006 From: denis at poolshark.org (Denis Leroy) Date: Sat, 10 Jun 2006 19:20:50 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149954948.3309.48.camel@rousalka.dyndns.org> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> <1149954948.3309.48.camel@rousalka.dyndns.org> Message-ID: <448AFF72.9050404@poolshark.org> Nicolas Mailhot wrote: > please don't, we need 0.x to mark release candidates and others > pre-real-release versions I don't understand this one. The release is not the version number, and it's something that we completely control (unlike the upstream version number), so should it be anything other that a linearly increasing single number (just like a build number) ? (I can see an exception being made for things with kernel versions in them otoh). -denis From bugs.michael at gmx.net Sat Jun 10 18:16:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Jun 2006 20:16:39 +0200 Subject: nx requires and provides In-Reply-To: References: <448A7CBD.9080402@gmail.com> <20060610115935.824b1a42.bugs.michael@gmx.net> Message-ID: <20060610201639.3d1da65b.bugs.michael@gmx.net> On Sat, 10 Jun 2006 10:08:24 -0500, Jason L Tibbitts III wrote: > MS> I believe this to be a packaging design bug. In my view it makes > MS> no sense to have a dependency "noarch -> arch-specific". > > But it is impossible not to have such dependencies. Every noarch Perl > and Python module is going to require Perl or Python. If I package up > nothing more than a simple shell script it's going to require > /bin/sh. And its quite easy to think of ways that noarch packages > might depend on some arch-specific package that won't build on 64-bit > or PPC or whatever. Sorry. I didn't refer to the general case, but to the nx+freenx pair. When you know that nx is not available on one platform, you cannot (should not!) make freenx noarch and let it depend on a non-available nx. For the general case, yes, of course noarch->arch-specific deps can occur in many cases and can be beneficial (wrt heterogenous environments, mounted network filesystems etc.) From Matt_Domsch at dell.com Sat Jun 10 18:43:40 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 10 Jun 2006 13:43:40 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <1149953230.8267.25.camel@localhost.localdomain> References: <20060610050428.GA28545@lists.us.dell.com> <1149953230.8267.25.camel@localhost.localdomain> Message-ID: <20060610184340.GB10214@humbolt.us.dell.com> On Sat, Jun 10, 2006 at 06:27:09PM +0300, Ville Skytt? wrote: > On Sat, 2006-06-10 at 00:04 -0500, Matt Domsch wrote: > [...] > > Would it be possible to include info about maintainers of listed > packages in this report? The list is pretty long, and it's not too much > fun to try to search it through based on package names if one happens to > maintain lots of packages or sponsor others who in turn maintain many > packages too. I think I've got this working now, so owner names should appear in the next report. I don't have an owners.list for Core though. > On a related note, libusb-devel was broken in Rawhide and has been fixed > now (missing dependency on pkgconfig); I think that has caused a bunch > of build failures which thus require no action. I'm rerunning all of extras today, so if this morning's rawhide has the fix, so will the next report. 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 andy at smile.org.ua Sat Jun 10 19:02:00 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 10 Jun 2006 22:02:00 +0300 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448AFF72.9050404@poolshark.org> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> <1149954948.3309.48.camel@rousalka.dyndns.org> <448AFF72.9050404@poolshark.org> Message-ID: <448B1728.3090201@smile.org.ua> Denis Leroy ?????: >> please don't, we need 0.x to mark release candidates and others >> pre-real-release versions > I don't understand this one. The release is not the version number, and > it's something that we completely control (unlike the upstream version > number), so should it be anything other that a linearly increasing > single number (just like a build number) ? (I can see an exception being > made for things with kernel versions in them otoh). If you catch new version of the package from CVS or SVN directly the version of it can't be still old (like x.y.z for last release) almost in all cases. Look for example. Last release: x.y.z-1%{?dist} Preparing release: x.y.(z+n)-0.1.%{date}cvs%{?dist} New release: x.y.(z+n)-1%{?dist} (attent to version tag). And case just after release (i.e. in case when new cvs/svn version more preferable than couple of patches): x.y.(z+n)-1.1.%{date}cvs%{?dist} -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From yeti at physics.muni.cz Sat Jun 10 19:04:44 2006 From: yeti at physics.muni.cz (David =?iso-8859-2?B?TmXoYXMgKFlldGkp?=) Date: Sat, 10 Jun 2006 21:04:44 +0200 Subject: nx requires and provides In-Reply-To: <20060610201639.3d1da65b.bugs.michael@gmx.net> References: <448A7CBD.9080402@gmail.com> <20060610115935.824b1a42.bugs.michael@gmx.net> <20060610201639.3d1da65b.bugs.michael@gmx.net> Message-ID: <20060610190444.GU30886@potato.chello.upc.cz> On Sat, Jun 10, 2006 at 08:16:39PM +0200, Michael Schwendt wrote: > > > > But it is impossible not to have such dependencies. Every noarch Perl > > and Python module is going to require Perl or Python. If I package up > > nothing more than a simple shell script it's going to require > > /bin/sh. And its quite easy to think of ways that noarch packages > > might depend on some arch-specific package that won't build on 64-bit > > or PPC or whatever. > > Sorry. I didn't refer to the general case, but to the nx+freenx pair. When > you know that nx is not available on one platform, you cannot (should > not!) make freenx noarch and let it depend on a non-available nx. The right place to hardcode the architectures where package A builds isn't the spec file of an architecture independent package B. Even if the two are related (well, when a package depends on another they are usually related). Package B simply works everywhere where A is availabe and that's all. The real problem is that there is no mechanism to infer the exclusion of B from the unavailability of A and depdndency of B on A (it would be the opposite of the broken dependencies check). Yeti -- Anonyms eat their boogers. From tibbs at math.uh.edu Sat Jun 10 19:15:04 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 10 Jun 2006 14:15:04 -0500 Subject: nx requires and provides In-Reply-To: <20060610201639.3d1da65b.bugs.michael@gmx.net> (Michael Schwendt's message of "Sat, 10 Jun 2006 20:16:39 +0200") References: <448A7CBD.9080402@gmail.com> <20060610115935.824b1a42.bugs.michael@gmx.net> <20060610201639.3d1da65b.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> When you know that nx is not available on one platform, you cannot MS> (should not!) make freenx noarch and let it depend on a MS> non-available nx. I don't think it reasonable, though, to prevent a package from being noarch just because somewhere in its dependency tree is a package which is not available on every architecture. It would be better to somehow inform the buildsystem or the sign&push script that the noarch package shouldn't go out to all of the architectures. (Assuming it can't just figure that out on its own.) Even better, of course, would be to fix nx. We're nearly fifteen years into the era of common 64-bit computing! One wonders how you can expect upstream to get something important like security correct when they've ignored something fundamental like 64-bitness. - J< From nicolas.mailhot at laposte.net Sat Jun 10 19:24:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Jun 2006 21:24:40 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-08 In-Reply-To: <448AFF72.9050404@poolshark.org> References: <20060610050533.GB28545@lists.us.dell.com> <448A7DA5.80803@ioa.s.u-tokyo.ac.jp> <20060610123525.3e135514.bugs.michael@gmx.net> <1149954584.5199.188.camel@localhost.localdomain> <1149954948.3309.48.camel@rousalka.dyndns.org> <448AFF72.9050404@poolshark.org> Message-ID: <1149967480.6422.6.camel@rousalka.dyndns.org> Le samedi 10 juin 2006 ? 19:20 +0200, Denis Leroy a ?crit : > Nicolas Mailhot wrote: > > please don't, we need 0.x to mark release candidates and others > > pre-real-release versions > > I don't understand this one. The release is not the version number, and > it's something that we completely control (unlike the upstream version > number), so should it be anything other that a linearly increasing > single number (just like a build number) ? (I can see an exception being > made for things with kernel versions in them otoh). There is a convention to use 0.x release numbers when you package something which is almost, but not quite the version number the package advertises (fairly common situation nearby a FC release when all sorts of stuff is packaged early in expectation of reaching full release before the actual distro release) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jonathan.underwood at gmail.com Sat Jun 10 19:26:30 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 10 Jun 2006 20:26:30 +0100 Subject: Buildsys glitch? In-Reply-To: <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> Message-ID: <645d17210606101226s66a3e2e0obb28b8466d7e65fb@mail.gmail.com> On 10/06/06, TASAKA, Mamoru wrote: > > Seems VERY STRANGE. It seems that your srpm should be rebuilt as done on FE-devel. > > Maybe does this show some bugs on emacs under FC5-ppc? I cannot understand why, > however, the attached patch may find a clue to this issue. I am not currently at home, so haven't had chance to try the patch. But, if it does turn out to be ppc specific, is there any way to request a noarch build on one of the other build machines of a different arch? (My guess: no). Jonathan. From michael at knox.net.nz Sat Jun 10 20:48:02 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 11 Jun 2006 08:48:02 +1200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606070001.k5701ZrG029332@mx3.redhat.com> References: <200606070001.k5701ZrG029332@mx3.redhat.com> Message-ID: <448B3002.60908@knox.net.nz> Christian.Iseli at licr.org wrote: > FE-ACCEPT packages stats: > - 9 accepted, closed package reviews not in owners Should be ignored by the QA script: lineak_xosdplugin, lineak_kdeplugins, lineak_xosdplugin Are in the owners.list, however the name differs from the subject of the review request. Sub the "_" for a "-". Re-Review is actually jed, which is in the owners.list kimdaba has been replaced by kphotoalbum, which is in the owners.list libgsf113 appears to have been removed from cvs, repos and owners.list Corrected: conntrack is in the owners.list (2006/06/07) Actual missing missing: perl-Net-Jabber has had a reminder sent blam has had a reminder sent From peter at thecodergeek.com Sat Jun 10 20:59:10 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 10 Jun 2006 13:59:10 -0700 Subject: Comps Generation? [Was: Re: comps comps-fe5.xml,1.7,1.8] In-Reply-To: <200606101350.k5ADoSxO023272@cvs-int.fedora.redhat.com> References: <200606101350.k5ADoSxO023272@cvs-int.fedora.redhat.com> Message-ID: <448B329E.4010403@thecodergeek.com> Hans de Goede (jwrdegoede) wrote: > Author: jwrdegoede > > Update of /cvs/extras/comps > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23255/comps > > Modified Files: > comps-fe5.xml > Log Message: > add blobwars and tuxkart > Why are we changing the .xml files? The xml.in is what we need to add it to, and the build system automagically regenerates the true comps.xml from that, right? How often does this occur? Perhaps we should make it regenerate with every day's new Extras push if any of those added something to it? What's our policy, if any, on this? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Sat Jun 10 22:19:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 10 Jun 2006 18:19:44 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-10 Message-ID: <20060610221944.91B6215217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 16 DevIL-1.6.8-0.8.rc1.fc5 blobwars-1.05-2.fc5 gurlchecker-0.10.0-2.fc5 libsvg-cairo-0.1.6-3.fc5 nucleo-0.5-6.fc5 openalpp-20060405-6.fc5 perl-IO-Tty-1.05-1.fc5 perl-Image-Size-3.0-1.fc5 perl-List-MoreUtils-0.20-1.fc5 perl-PPI-1.115-2.fc5 plib-1.8.4-6.fc5 poker-eval-131.0-2.fc5 qt4-4.1.3-8.fc5 subversion-api-docs-1.3.2-1.fc5 tuxkart-0.4.0-4.fc5 xaos-3.2.1-3.fc5 Packages built and released for Fedora Extras 4: 11 DevIL-1.6.8-0.8.rc1.fc4 emacs-auctex-11.83-1.fc4 gurlchecker-0.10.0-2.fc4 nucleo-0.5-6.fc4 openalpp-20060405-6.fc4 perl-IO-Tty-1.05-1.fc4 perl-List-MoreUtils-0.20-1.fc4 plib-1.8.4-6.fc4 poker-eval-131.0-2.fc4 qt4-4.1.3-8.fc4 xaos-3.2.1-3.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 27 R-mAr-1.1-5.fc6 R-waveslim-1.5-3.fc6 R-wavethresh-2.2-3.fc6 abcMIDI-20060422-1.fc6 allegro-4.2.0-13.fc6 dia-0.95-5.fc6 emacs-auctex-11.83-4.fc6 gcompris-7.4-11.fc6 gtkhtml36-3.6.2-5.fc6 gurlchecker-0.10.0-2.fc6 intuitively-0.7-9.fc6 libassetml-1.2.1-3.fc6 libgda-1.9.100-7.fc6 libgnomedb-1.9.100-8.fc6 nucleo-0.5-6.fc6 openalpp-20060405-6.fc6 perl-IO-Tty-1.05-1.fc6 perl-Image-Size-3.0-1.fc6 perl-List-MoreUtils-0.20-1.fc6 pipenightdreams-0.10.0-4.fc6 plib-1.8.4-6.fc6 poker-eval-131.0-2.fc6 qt4-4.1.3-8.fc6 rpy-0.4.6-11.fc6 wormux-0.7.2-5.fc6 xaos-3.2.1-3.fc6 xscreensaver-5.00-6.1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jun 10 22:35:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 10 Jun 2006 22:35:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-10 Message-ID: <20060610223545.22045.51505@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Sat Jun 10 22:35:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 10 Jun 2006 22:35:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-10 Message-ID: <20060610223545.22037.45759@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw From buildsys at fedoraproject.org Sat Jun 10 22:35:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 10 Jun 2006 22:35:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-10 Message-ID: <20060610223545.22047.15684@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Sat Jun 10 22:35:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 10 Jun 2006 22:35:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-10 Message-ID: <20060610223545.22049.32390@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 autotrace 0.31.1-12.fc5.i386 diradmin 1.7.1-4.fc5.i386 gdl 0.9-0.pre.fc6.i386 gtktalog 1.0.4-7.fc5.i386 kipi-plugins 0.1.0-0.10.rc2.fc6.i386 kismet-extras 0.0.2006.04.R1-2.fc6.i386 koffice-devel 1.5.1-1.fc6.i386 koffice-filters 1.5.1-1.fc6.i386 koffice-karbon 1.5.1-1.fc6.i386 koffice-krita 1.5.1-1.fc6.i386 octave-forge 2006.03.17-4.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc autotrace 0.31.1-12.fc5.ppc diradmin 1.7.1-4.fc5.ppc gdl 0.9-0.pre.fc6.ppc gtktalog 1.0.4-7.fc5.ppc kipi-plugins 0.1.0-0.10.rc2.fc6.ppc kismet-extras 0.0.2006.04.R1-2.fc6.ppc koffice-devel 1.5.1-1.fc6.ppc koffice-filters 1.5.1-1.fc6.ppc koffice-karbon 1.5.1-1.fc6.ppc koffice-krita 1.5.1-1.fc6.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc octave-forge 2006.03.17-4.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 autotrace 0.31.1-12.fc5.x86_64 diradmin 1.7.1-4.fc5.x86_64 gdl 0.9-0.pre.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc6.x86_64 kismet-extras 0.0.2006.04.R1-2.fc6.x86_64 koffice-devel 1.5.1-1.fc6.x86_64 koffice-filters 1.5.1-1.fc6.x86_64 koffice-karbon 1.5.1-1.fc6.x86_64 koffice-krita 1.5.1-1.fc6.x86_64 octave-forge 2006.03.17-4.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== New report for: enrico.scholz AT informatik.tu-chemnitz.de package: kismet-extras - 0.0.2006.04.R1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: kismet-extras - 0.0.2006.04.R1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: koffice-filters - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-karbon - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-krita - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-krita - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-karbon - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-filters - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-karbon - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-filters - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-krita - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: roozbeh AT farsiweb.info package: autotrace - 0.31.1-12.fc5.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: autotrace - 0.31.1-12.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: autotrace - 0.31.1-12.fc5.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: qspencer AT ieee.org package: octave-forge - 2006.03.17-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 libMagick.so.9 package: octave-forge - 2006.03.17-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) libMagick.so.9()(64bit) package: octave-forge - 2006.03.17-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 libMagick.so.9 ====================================================================== New report for: orion AT cora.nwra.com package: gdl - 0.9-0.pre.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 package: gdl - 0.9-0.pre.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) package: gdl - 0.9-0.pre.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 ====================================================================== New report for: rdieter AT math.unl.edu package: kipi-plugins - 0.1.0-0.10.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 package: kipi-plugins - 0.1.0-0.10.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) package: kipi-plugins - 0.1.0-0.10.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 ====================================================================== package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so From jonathan.underwood at gmail.com Sun Jun 11 00:03:16 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 11 Jun 2006 01:03:16 +0100 Subject: Buildsys glitch? In-Reply-To: <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> Message-ID: <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> On 10/06/06, TASAKA, Mamoru wrote: > Seems VERY STRANGE. It seems that your srpm should be rebuilt as done on FE-devel. > > Maybe does this show some bugs on emacs under FC5-ppc? I cannot understand why, > however, the attached patch may find a clue to this issue. OK, it does seem that there's a problem with emacs in the chroot: checking if /usr/bin/emacs is XEmacs... /usr/bin/emacs -batch -no-site-file -eval (let* ((x (if (featurep (quote xemacs)) "yes" "no"))) (write-region (if (stringp x) x (prin1-to-string x)) nil "./conftest-12047")) emacs: error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory Full build logs at: http://buildsys.fedoraproject.org/logs/fedora-5-extras/10868-emacs-auctex-11.83-2.fc5.4/noarch/build.log Anyone know what's causing that? Jonathan ps. I am travelling for a week, so won't be able to attempt any more builds until next weekend. From kevin.kofler at chello.at Sun Jun 11 01:07:33 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 11 Jun 2006 01:07:33 +0000 (UTC) Subject: What's the best practice for packaging java apps on FC References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> <20060607041652.GB11376@redhat.com> Message-ID: Andrew Overholt writes: > > 2. Use aot-compile-rpm to make precompiled .so files [...] > Correct and correct. Sadly, DoctorJ doesn't do that. :-( I just filed Bug 194806 for that. Kevin Kofler From michael at knox.net.nz Sun Jun 11 01:54:26 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 11 Jun 2006 13:54:26 +1200 Subject: What's the best practice for packaging java apps on FC In-Reply-To: References: <4ccd9dcb0606040703y75c1be46y8a07108ddfa29999@mail.gmail.com> <20060607041652.GB11376@redhat.com> Message-ID: <448B77D2.4000806@knox.net.nz> Kevin Kofler wrote: > Andrew Overholt writes: >>> 2. Use aot-compile-rpm to make precompiled .so files [...] >> Correct and correct. > > Sadly, DoctorJ doesn't do that. :-( I just filed Bug 194806 for that. > Has now been addressed and building on the buildsys. Thanks for the report too! Michael From rc040203 at freenet.de Sun Jun 11 02:06:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 11 Jun 2006 04:06:18 +0200 Subject: Buildsys glitch? In-Reply-To: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> Message-ID: <1149991578.12112.183.camel@mccallum.corsepiu.local> On Sat, 2006-06-10 at 13:52 +0100, Jonathan Underwood wrote: > Hi, > > I just pushed builds for an updated emacs-auctex package for FC-4, > FC-5 and devel. FC-4 and devel succeeded (specs are the same), but > FC-5 fails during configure with this: AFAIS, the spec suffers from several bugs, but I fail to understand why it should build anywhere ;) > Any ideas? Cf. the patch below. Ralf PS.: CC:-ing you, because I am not sure this list will let attachments pass through -------------- next part -------------- A non-text attachment was scrubbed... Name: emacs-auctex.diff Type: text/x-patch Size: 1729 bytes Desc: not available URL: From kaboom at oobleck.net Sun Jun 11 02:47:11 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 10 Jun 2006 22:47:11 -0400 (EDT) Subject: Unorphan: Openbox In-Reply-To: <448A7B21.6080500@thecodergeek.com> References: <448A7B21.6080500@thecodergeek.com> Message-ID: On Sat, 10 Jun 2006, Peter Gordon wrote: > Hello, all. > > I wish to unorphan and resurrect Openbox in Extras. It was dropped in > the FC3/FC4 timeframe at version 2.3.1. > > Because it was such a long time and even a new major release of this > upstream, do I need to submit a review request for my new spec? It needs a full review. The openbox stuff that's in FC3 CVS was an autoimport from the old fedora.us days and has never gone through the full Fedora Extras process.... later, chris From peter at thecodergeek.com Sun Jun 11 03:19:01 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 10 Jun 2006 20:19:01 -0700 Subject: Unorphan: Openbox In-Reply-To: References: <448A7B21.6080500@thecodergeek.com> Message-ID: <448B8BA5.4030806@thecodergeek.com> Chris Ricker wrote: > On Sat, 10 Jun 2006, Peter Gordon wrote: > >> Hello, all. >> >> I wish to unorphan and resurrect Openbox in Extras. It was dropped in >> the FC3/FC4 timeframe at version 2.3.1. >> >> Because it was such a long time and even a new major release of this >> upstream, do I need to submit a review request for my new spec? > > It needs a full review. The openbox stuff that's in FC3 CVS was an > autoimport from the old fedora.us days and has never gone through the full > Fedora Extras process.... > > later, > chris That explains it beautifully. I'll finish up this mock test build and post the review request. Thanks! -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 11 03:54:13 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 11 Jun 2006 12:54:13 +0900 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> Message-ID: <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> Jonathan Underwood wrote: > OK, it does seem that there's a problem with emacs in the chroot: > > checking if /usr/bin/emacs is XEmacs... /usr/bin/emacs -batch > -no-site-file -eval (let* ((x (if (featurep (quote xemacs)) "yes" > "no"))) (write-region (if (stringp x) x (prin1-to-string x)) nil > "./conftest-12047")) > emacs: error while loading shared libraries: libXext.so.6: cannot open > shared object file: No such file or directory > > Full build logs at: > http://buildsys.fedoraproject.org/logs/fedora-5-extras/10868-emacs-auctex-11.83-2.fc5.4/noarch/build.log VERY VERY STRANGE!!!! As long as I saw your root.log, mock did not install libXext rpm. But truely, emacs requires libXext.so.6 (by "rpm -q --requires emacs). I downloaded primary.xml.gz of FC-5 and checked dependency, however, emacs and emacs-common do not require libXext.so.6, this is APPARANTRY WRONG!! You can work around by adding "BuildRequires: libXext", but this issue must be filed to bugzilla. From zipsonic at gmail.com Sun Jun 11 04:47:50 2006 From: zipsonic at gmail.com (Rick Stout) Date: Sat, 10 Jun 2006 21:47:50 -0700 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> Message-ID: <448BA076.3060209@gmail.com> >> emacs: error while loading shared libraries: libXext.so.6: cannot open >> shared object file: No such file or directory >> The problem is related to nx falsely providing libXext.so.6, which was installed in the buildroot. This problem has been fixed and the build has been pushed. When the mirrors update, this problem will be resolved. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 11 05:11:35 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 11 Jun 2006 14:11:35 +0900 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <448BA076.3060209@gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> Message-ID: <448BA607.7070309@ioa.s.u-tokyo.ac.jp> Rick Stout wrote: >>> emacs: error while loading shared libraries: libXext.so.6: cannot open >>> shared object file: No such file or directory >>> > > The problem is related to nx falsely providing libXext.so.6, which was > installed in the buildroot. This problem has been fixed and the build > has been pushed. When the mirrors update, this problem will be resolved. > No. The problem is that FC-5 emacs does not require libXext.so.6 (using yum), but the truth is that emacs SHOULD require libXext.so.6. Even if nx comes to not provide libXext.so.6 any longer, this problem will not resolved until emacs comes to require libXext.so.6 . Note: nx is in FC5-extras, however, the fix for primary.xml.gz in FC5-core is needed. From j.w.r.degoede at hhs.nl Sun Jun 11 05:24:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 11 Jun 2006 07:24:23 +0200 Subject: Comps Generation? [Was: Re: comps comps-fe5.xml,1.7,1.8] In-Reply-To: <448B329E.4010403@thecodergeek.com> References: <200606101350.k5ADoSxO023272@cvs-int.fedora.redhat.com> <448B329E.4010403@thecodergeek.com> Message-ID: <448BA907.9020602@hhs.nl> Peter Gordon wrote: > Hans de Goede (jwrdegoede) wrote: >> Author: jwrdegoede >> >> Update of /cvs/extras/comps >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23255/comps >> >> Modified Files: >> comps-fe5.xml >> Log Message: >> add blobwars and tuxkart >> > > Why are we changing the .xml files? The xml.in is what we need to add it > to, and the build system automagically regenerates the true comps.xml > from that, right? How often does this occur? Perhaps we should make it > regenerate with every day's new Extras push if any of those added > something to it? What's our policy, if any, on this? > You are correct, my bad. I'll add them to the .xml.in file instead. Regards, Hans > Thanks. > From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 11 05:31:41 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (TASAKA, Mamoru) Date: Sun, 11 Jun 2006 14:31:41 +0900 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <448BA607.7070309@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> <448BA607.7070309@ioa.s.u-tokyo.ac.jp> Message-ID: <448BAABD.7020505@ioa.s.u-tokyo.ac.jp> TASAKA, Mamoru wrote: > Rick Stout wrote: >>>> emacs: error while loading shared libraries: libXext.so.6: cannot open >>>> shared object file: No such file or directory >>>> >> >> The problem is related to nx falsely providing libXext.so.6, which was >> installed in the buildroot. This problem has been fixed and the build >> has been pushed. When the mirrors update, this problem will be resolved. >> > > No. The problem is that FC-5 emacs does not require libXext.so.6 (using > yum), > but the truth is that emacs SHOULD require libXext.so.6. > > Even if nx comes to not provide libXext.so.6 any longer, this problem will > not resolved until emacs comes to require libXext.so.6 . > > Note: nx is in FC5-extras, however, the fix for primary.xml.gz in > FC5-core is > needed. > Ah.. I was mistaken. Rick, you are right. Emacs truely required libXext.so.6, however, mock falsely installed nx to satisfy the dependency for libXext.so.6 (by root.log). Yes, the primary.xml.gz for FE-extras should be fixed. Sorry for my confusion. From rc040203 at freenet.de Sun Jun 11 05:41:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 11 Jun 2006 07:41:17 +0200 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <448BA607.7070309@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> <448BA607.7070309@ioa.s.u-tokyo.ac.jp> Message-ID: <1150004477.30155.3.camel@mccallum.corsepiu.local> On Sun, 2006-06-11 at 14:11 +0900, TASAKA, Mamoru wrote: > Rick Stout wrote: > >>> emacs: error while loading shared libraries: libXext.so.6: cannot open > >>> shared object file: No such file or directory > >>> > > > > The problem is related to nx falsely providing libXext.so.6, which was > > installed in the buildroot. This problem has been fixed and the build > > has been pushed. When the mirrors update, this problem will be resolved. > > > > No. The problem is that FC-5 emacs does not require libXext.so.6 (using yum), What makes you say this? # rpm -q --requires emacs | grep libXext # rpm -q emacs libXext emacs-21.4-14 libXext-1.0.0-3.2 Ralf From tibbs at math.uh.edu Sun Jun 11 05:49:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 11 Jun 2006 00:49:11 -0500 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <448BAABD.7020505@ioa.s.u-tokyo.ac.jp> (Mamoru TASAKA's message of "Sun, 11 Jun 2006 14:31:41 +0900") References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> <448BA607.7070309@ioa.s.u-tokyo.ac.jp> <448BAABD.7020505@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "MT" == Mamoru TASAKA writes: MT> Ah.. I was mistaken. Rick, you are right. Emacs truely required MT> libXext.so.6, however, mock falsely installed nx to satisfy the MT> dependency for libXext.so.6 (by root.log). Well, it didn't falsely install it. Emacs requires libXext.so.6, so yum went to install it and found two packages providing it. Having no other information to go on, it chose the one with the shorter name. The real problem here that I see is that a package containing a file named /usr/lib/NX/lib/libXext.so.6 ends up providing libXext.so.6. That's bound to bite us many, many more times in the future unless RPM's automatic dependency generation stops adding provides for libraries that are outside the regular library search path. Yes, this has a chance of breaking dependencies for packages which add directories to the search path; those are probably few enough that it would be simple to add the provides by hand. - J< From michael at knox.net.nz Sun Jun 11 08:17:32 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 11 Jun 2006 20:17:32 +1200 Subject: rpath joy Message-ID: <448BD19C.1070409@knox.net.nz> Hi all, I am sure this has been beaten to death, however, I have not been able to find much info on this. I am trying to package up ntop for FE. However, I have a rpath error on the plugins.. I get this: ERROR 0002: file '/usr/lib/ntop/plugins/rrdPlugin.so' contains an invalid rpath '/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs' in [/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs] error: Bad exit status from /home/mjk/rpmbuild/tmp/rpm-tmp.53484 (%install) I have reviewed this page: http://fedoraproject.org/wiki/Extras/Schedule/RpathCheckBuildsys and http://wiki.debian.org/RpathIssue I have tried all sorts of nasty hacks to see what needs to be done to fix this, however, I simply do not seem to make any head way. Could someone who knows enough on this topic give a clue as to what I am looking for ? Thanks Michael From nicolas.mailhot at laposte.net Sun Jun 11 09:04:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Jun 2006 11:04:40 +0200 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> <448BA607.7070309@ioa.s.u-tokyo.ac.jp> <448BAABD.7020505@ioa.s.u-tokyo.ac.jp> Message-ID: <1150016680.13829.36.camel@rousalka.dyndns.org> Le dimanche 11 juin 2006 ? 00:49 -0500, Jason L Tibbitts III a ?crit : > The real problem here that I see is that a package containing a file > named /usr/lib/NX/lib/libXext.so.6 ends up providing libXext.so.6. > That's bound to bite us many, many more times in the future unless > RPM's automatic dependency generation stops adding provides for > libraries that are outside the regular library search path. Or unless packages are audited deeper to detect library collisions before upload (and most of the time these collisions will be the result of a private fork of a common library, which we do not want anyway, so the audit is not lost effort) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Sun Jun 11 09:07:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 11 Jun 2006 11:07:21 +0200 Subject: rpath joy In-Reply-To: <448BD19C.1070409@knox.net.nz> References: <448BD19C.1070409@knox.net.nz> Message-ID: <20060611090721.GA2415@free.fr> On Sun, Jun 11, 2006 at 08:17:32PM +1200, Michael J. Knox wrote: > Hi all, > > I am sure this has been beaten to death, however, I have not been able > to find much info on this. > > I am trying to package up ntop for FE. However, I have a rpath error on > the plugins.. I get this: > > ERROR 0002: file '/usr/lib/ntop/plugins/rrdPlugin.so' contains an > invalid rpath '/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs' in > [/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs] > error: Bad exit status from /home/mjk/rpmbuild/tmp/rpm-tmp.53484 (%install) Do you have a build log or could you give an explanation on how to reproduce your build? In gnash there are rpath that appear when the plugin dll is copied with cp instead of installed by libtool with libtool --install. The make rule is: $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $(plugin_LTLIBRARIES) "$(DESTDIR)$(plugindir)/$(plugin_LTLIBRARIES)" -- Pat From joost at soeterbroek.com Sun Jun 11 09:10:53 2006 From: joost at soeterbroek.com (Joost Soeterbroek) Date: Sun, 11 Jun 2006 11:10:53 +0200 Subject: failed mock build of gnubg on fc4 Message-ID: <448BDE1D.8090304@soeterbroek.com> Hi, I am unable to mock build package gnubg on fc4. I've narrowed it down to an autoconf/automake problem in dir 'intl', where Makefile.in is incorrectly generated missing separators for SOURCES variable: SOURCES = bindtextdom.c dcgettext.c dgettext.c etc.. causing make to fail with error "Missing seperator". It does build successfully (in mock) for fc5 and devel, just not fc-4. Build logs are available: http://buildsys.fedoraproject.org/logs/fedora-4-extras/10691-gnubg-20060530-5.fc4/i386/ Any ideas? Regards, Joost Soeterbroek From dan at danny.cz Sun Jun 11 09:20:30 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 11 Jun 2006 11:20:30 +0200 Subject: how to patch configure.ac and not require autotools Message-ID: <1150017630.3481.22.camel@eagle.danny.cz> Hello, I need to patch configure.ac so it doesn't explicitely add '-s' to LDFLAGS (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a discussion started in http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. I see 3 possible ways - leave the warnings in the buildlog - patch the files without modifying their timestamp (but is it possible?) - generate a patch that will contain empty patches for the other generated files only to update their timestamp (but again how?) Dan From paul at city-fan.org Sun Jun 11 09:31:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 11 Jun 2006 10:31:51 +0100 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-10 In-Reply-To: <20060610223545.22045.51505@extras64.linux.duke.edu> References: <20060610223545.22045.51505@extras64.linux.duke.edu> Message-ID: <1150018312.9317.31.camel@laurel.intra.city-fan.org> On Sat, 2006-06-10 at 22:35 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-4-i386: > ---------------------------------------------------------------------- > plague 0.4.4.1-1.fc4.noarch I propose that plague 0.4.4.1 is removed from the FC-4 and FC-3 repos due to its broken deps that are unlikely ever to be fixed (certainly not in the case of FC-3). Anyone think of a reason why this should *not* happen? Paul. From paul at city-fan.org Sun Jun 11 09:37:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 11 Jun 2006 10:37:12 +0100 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150017630.3481.22.camel@eagle.danny.cz> References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <1150018632.9317.33.camel@laurel.intra.city-fan.org> On Sun, 2006-06-11 at 11:20 +0200, Dan Hor?k wrote: > Hello, > > I need to patch configure.ac so it doesn't explicitely add '-s' to > LDFLAGS (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > discussion started in > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. > I see 3 possible ways > - leave the warnings in the buildlog > - patch the files without modifying their timestamp (but is it > possible?) > - generate a patch that will contain empty patches for the other > generated files only to update their timestamp (but again how?) Can't you just patch configure and not configure.ac? Paul. From yeti at physics.muni.cz Sun Jun 11 09:40:08 2006 From: yeti at physics.muni.cz (David =?iso-8859-2?B?TmXoYXMgKFlldGkp?=) Date: Sun, 11 Jun 2006 11:40:08 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150017630.3481.22.camel@eagle.danny.cz> References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <20060611094008.GA30886@potato.chello.upc.cz> On Sun, Jun 11, 2006 at 11:20:30AM +0200, Dan Hor?k wrote: > Hello, > > I need to patch configure.ac so it doesn't explicitely add '-s' to > LDFLAGS (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > discussion started in > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. Since the use of autotools is forbidden, do not patch configure.ac. Yeti -- Anonyms eat their boogers. From dan at danny.cz Sun Jun 11 09:45:19 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 11 Jun 2006 11:45:19 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150018632.9317.33.camel@laurel.intra.city-fan.org> References: <1150017630.3481.22.camel@eagle.danny.cz> <1150018632.9317.33.camel@laurel.intra.city-fan.org> Message-ID: <1150019119.3481.35.camel@eagle.danny.cz> Paul Howarth p??e v Ne 11. 06. 2006 v 10:37 +0100: > > I see 3 possible ways > > - leave the warnings in the buildlog > > - patch the files without modifying their timestamp (but is it > > possible?) > > - generate a patch that will contain empty patches for the other > > generated files only to update their timestamp (but again how?) > > Can't you just patch configure and not configure.ac? > Yes, I can. Why to look for a complex solution when there is a simple one ;-) Dan From rdieter at math.unl.edu Sun Jun 11 12:43:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 11 Jun 2006 07:43:19 -0500 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150017630.3481.22.camel@eagle.danny.cz> References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: Dan Hor?k wrote: > Hello, > > I need to patch configure.ac so it doesn't explicitely add '-s' to > LDFLAGS (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > discussion started in > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. I guess I missed the conclusion that using auto* tools is absolutely forgidden. AFAIK, it's not in the PackagingGuidelines, and there are certainly valid cases where their use is warranted (this may be one of them). I'd suggest simply patching things and BuildRequires: automake autoconf and be done with it. -- Rex From katzj at redhat.com Sun Jun 11 12:50:26 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 11 Jun 2006 08:50:26 -0400 Subject: Comps Generation? [Was: Re: comps comps-fe5.xml,1.7,1.8] In-Reply-To: <448B329E.4010403@thecodergeek.com> References: <200606101350.k5ADoSxO023272@cvs-int.fedora.redhat.com> <448B329E.4010403@thecodergeek.com> Message-ID: <1150030226.2865.3.camel@aglarond.local> On Sat, 2006-06-10 at 13:59 -0700, Peter Gordon wrote: > Why are we changing the .xml files? The xml.in is what we need to add it > to, and the build system automagically regenerates the true comps.xml > from that, right? How often does this occur? Perhaps we should make it > regenerate with every day's new Extras push if any of those added > something to it? What's our policy, if any, on this? Yes, the .in files should be changed. The plan is to integrate checkout and update of the comps file in the tree with the Extras push script but I still haven't had a 'round 'tuit which means that updates happen when I think about it and notice that some have gone in. I'll try to update it later today Jeremy From nicolas.mailhot at laposte.net Sun Jun 11 13:20:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Jun 2006 15:20:41 +0200 Subject: Changing the default font in Fedora Core 6 Message-ID: <1150032041.13829.79.camel@rousalka.dyndns.org> Hi, As you may (or may not) know the current default Fedora fonts suffer from several problems : 1. their licensing may preclude them from being fixed when a glyph is bad or missing (problems like this are reported every few weeks) 2. sometimes they haven't changed for years (usually in conjonction with 1) 3. they may mack modern Opentype features and be plain ugly on a modern LCD The default distribution font is not a trivial matter, as it plays a big role in user appreciation of the Fedora GUI. Even the LSB is worrying about the font situation under Linux (http://lwn.net/Articles/186613/). Last October Rahul Sundaram opened a RFE to have this situation changed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170218 However at the time it was felt we were too close to FC5 release to make the switch. Since we're quickly approaching the point at which a FC6 switch won't be possible either, I'd like everyone interested in this problem to read the bugzilla entry, and contribute whatever they can to get this issue resolved before FC6. Or we will suck greatly another full release (at least). Since I'm the Fedora Extras maintainer of the font Rahul proposed, my own selfish interest in this issue is to get a resolution so proponents and opponents of the change stop hammering my inbox. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Sun Jun 11 16:18:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 11 Jun 2006 11:18:03 -0500 Subject: Buildsys glitch? (perhaps primary.xml.gz problem) In-Reply-To: <1150016680.13829.36.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sun, 11 Jun 2006 11:04:40 +0200") References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <645d17210606100631n505a9bd7xc1b525f90b905bc1@mail.gmail.com> <645d17210606100741h7df74827hdc22570ffe478324@mail.gmail.com> <448AE5EE.9010000@ioa.s.u-tokyo.ac.jp> <645d17210606101703m7f0a89d2w691de60ab50a2086@mail.gmail.com> <448B93E5.8070809@ioa.s.u-tokyo.ac.jp> <448BA076.3060209@gmail.com> <448BA607.7070309@ioa.s.u-tokyo.ac.jp> <448BAABD.7020505@ioa.s.u-tokyo.ac.jp> <1150016680.13829.36.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Or unless packages are audited deeper to detect library collisions NM> before upload (and most of the time these collisions will be the NM> result of a private fork of a common library, which we do not want NM> anyway, so the audit is not lost effort) This is why I include the list of provided (and required) symbols when I review a package. I don't, however, know of an easy way to search for every potential conflict for libraries that are in private directories. Does anyone know how to extract the complete list of provided *.so symbols from the repodata? - J< From peter at thecodergeek.com Sun Jun 11 16:59:22 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 11 Jun 2006 09:59:22 -0700 Subject: Comps Generation? [Was: Re: comps comps-fe5.xml,1.7,1.8] In-Reply-To: <1150030226.2865.3.camel@aglarond.local> References: <200606101350.k5ADoSxO023272@cvs-int.fedora.redhat.com> <448B329E.4010403@thecodergeek.com> <1150030226.2865.3.camel@aglarond.local> Message-ID: <448C4BEA.3060507@thecodergeek.com> Jeremy Katz wrote: > Yes, the .in files should be changed. The plan is to integrate checkout > and update of the comps file in the tree with the Extras push script but > I still haven't had a 'round 'tuit which means that updates happen when > I think about it and notice that some have gone in. > > I'll try to update it later today > > Jeremy Awesome. Thanks, Jeremy. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wart at kobold.org Sun Jun 11 17:02:00 2006 From: wart at kobold.org (Wart) Date: Sun, 11 Jun 2006 10:02:00 -0700 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150017630.3481.22.camel@eagle.danny.cz> References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <448C4C88.7020400@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Hor?k wrote: > Hello, > > I need to patch configure.ac so it doesn't explicitely add '-s' to > LDFLAGS (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > discussion started in > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. > I see 3 possible ways > - leave the warnings in the buildlog > - patch the files without modifying their timestamp (but is it > possible?) > - generate a patch that will contain empty patches for the other > generated files only to update their timestamp (but again how?) 'touch', not patch. I run into this quite a lot. In addition to patching both configure.ac and configure.in, you'll need to 'touch' all of the "Makefile.in" files in the package, since they likely have a dependency on configure.in. In some cases you'll have to touch 'config.h.in' as well. If you add "exit 1" at the end of your %prep section, then manually run "make -d 2>&1 | tee make.out" in your build directory, you'll see what dependencies are triggering the call to autoxxx. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEjEyFDeYlPfs40g8RAhYmAJwMtCD9SRWufNLSmEwTuFLxgcKUQQCdEh0t Vq4sf7OSPQVN7/LvDDnw0a0= =8+NO -----END PGP SIGNATURE----- From fedora at leemhuis.info Sun Jun 11 17:06:07 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 11 Jun 2006 19:06:07 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <1150045567.2305.7.camel@localhost.localdomain> Am Sonntag, den 11.06.2006, 07:43 -0500 schrieb Rex Dieter: > Dan Hor?k wrote: > > Hello, > > > > I need to patch configure.ac so it doesn't explicitely add '-s' to > > LDFLAGS (see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > > discussion started in > > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. > > I guess I missed the conclusion that using auto* tools is absolutely > forgidden. AFAIK, it's not in the PackagingGuidelines, and there are > certainly valid cases where their use is warranted (this may be one of > them). I'd suggest simply patching things and > BuildRequires: automake autoconf > and be done with it. Yes, it's not forbidden afaik. And there is no general agreement how to solve things like that; some people say "running auto* in spec files is okay" while others say "run auto* locally, create patches, check if it works and include those in the rpm because running auto* in spec files might break sooner or later". I tend to think the "running auto* in spec files might break sooner or later" is true, but how ofter does it break and is it worth the hassle to create patches? CU thl -- Thorsten Leemhuis From toshio at tiki-lounge.com Sun Jun 11 17:18:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 11 Jun 2006 10:18:18 -0700 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150017630.3481.22.camel@eagle.danny.cz> References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <1150046298.3147.13.camel@localhost> On Sun, 2006-06-11 at 11:20 +0200, Dan Hor?k wrote: > From a > discussion started in > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. It is not forbidden. The conclusion of the thread is that it is the packager's responsibility to create a working package. Ralf makes the case one has to review what auto* changes in the package anyway (to avoid subtle problems caused by mismatching versions) so making diffs that others can review makes sense. OTOH, auto* patches are very large and once you have reviewed the changes you may decide that calling autoconf is a better alternative. Blindly making diffs between the original and regenerated source files is as problematic as blindly running auto*. The packager has to examine the results whether they choose to call auto* from the package or include diffs. -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 wart at kobold.org Sun Jun 11 17:35:37 2006 From: wart at kobold.org (Wart) Date: Sun, 11 Jun 2006 10:35:37 -0700 Subject: how to patch configure.ac and not require autotools In-Reply-To: <448C4C88.7020400@kobold.org> References: <1150017630.3481.22.camel@eagle.danny.cz> <448C4C88.7020400@kobold.org> Message-ID: <448C5469.5000906@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wart wrote: > Dan Hor?k wrote: > >>>Hello, >>> >>>I need to patch configure.ac so it doesn't explicitely add '-s' to >>>LDFLAGS (see >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a >>>discussion started in >>>http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. >>>I see 3 possible ways >>>- leave the warnings in the buildlog >>>- patch the files without modifying their timestamp (but is it >>>possible?) >>>- generate a patch that will contain empty patches for the other >>>generated files only to update their timestamp (but again how?) > > > 'touch', not patch. > > I run into this quite a lot. In addition to patching both configure.ac > and configure.in, you'll need to 'touch' all of the "Makefile.in" files > in the package, since they likely have a dependency on configure.in. In > some cases you'll have to touch 'config.h.in' as well. > > If you add "exit 1" at the end of your %prep section, Correction: Add 'exit 1' in %build, right after running %configure. then manually run > "make -d 2>&1 | tee make.out" in your build directory, you'll see what > dependencies are triggering the call to autoxxx. > > --Mike - --Mike2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEjFRnDeYlPfs40g8RAkF2AJ93im90GZtukR33vTgxzkRUtBPMuwCeNxh3 jYFRZC82peBchE4gLywd1QE= =0ZZH -----END PGP SIGNATURE----- From enrico.scholz at informatik.tu-chemnitz.de Sun Jun 11 17:59:39 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 11 Jun 2006 19:59:39 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: <448C4C88.7020400@kobold.org> (wart@kobold.org's message of "Sun, 11 Jun 2006 10:02:00 -0700") References: <1150017630.3481.22.camel@eagle.danny.cz> <448C4C88.7020400@kobold.org> Message-ID: <878xo34lpw.fsf@kosh.bigo.ensc.de> wart at kobold.org (Wart) writes: > 'touch', not patch. > > I run into this quite a lot. In addition to patching both configure.ac > and configure.in, you'll need to 'touch' all of the "Makefile.in" files > in the package, since they likely have a dependency on configure.in. That's only needed for projects whose authors do not use AM_MAINTAINER_MODE. Instead of touching all Makefile.in's you could restore the original timestamp with: | touch -r configure configure.stamp | ... patch configure ... | touch -r configure.stamp configure Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Jun 11 18:24:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 11 Jun 2006 13:24:59 -0500 Subject: Changing the default font in Fedora Core 6 In-Reply-To: <1150032041.13829.79.camel@rousalka.dyndns.org> References: <1150032041.13829.79.camel@rousalka.dyndns.org> Message-ID: <448C5FFB.9030502@math.unl.edu> Nicolas Mailhot wrote: > As you may (or may not) know the current default Fedora fonts suffer > from several problems : > 1. their licensing may preclude them from being fixed when a glyph is > bad or missing (problems like this are reported every few weeks) Wow. Doesn't that violate item #3 on http://opensource.org/docs/definition.php "3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." Which font(s) are you referring to, bitstream-vera? -- Rex From nicolas.mailhot at laposte.net Sun Jun 11 18:42:07 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Jun 2006 20:42:07 +0200 Subject: Changing the default font in Fedora Core 6 In-Reply-To: <448C5FFB.9030502@math.unl.edu> References: <1150032041.13829.79.camel@rousalka.dyndns.org> <448C5FFB.9030502@math.unl.edu> Message-ID: <1150051327.2748.3.camel@rousalka.dyndns.org> Le dimanche 11 juin 2006 ? 13:24 -0500, Rex Dieter a ?crit : > Nicolas Mailhot wrote: > > > As you may (or may not) know the current default Fedora fonts suffer > > from several problems : > > 1. their licensing may preclude them from being fixed when a glyph is > > bad or missing (problems like this are reported every few weeks) > > Wow. Doesn't that violate item #3 on > http://opensource.org/docs/definition.php > "3. Derived Works > The license must allow modifications and derived works, and must allow > them to be distributed under the same terms as the license of the > original software." No, because so far they've been considered as static content, not code, so any font which is redistributable but can not be changed/improved has been OK for FC so far. The freest font in Core is Vera, and even this font can't be changed without changing its name (hence all de Vera derivatives like DejaVu have their own font name) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From buildsys at fedoraproject.org Sun Jun 11 20:48:11 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 11 Jun 2006 16:48:11 -0400 (EDT) Subject: Broken upgrade paths in Fedora Extras 2006-06-11 Message-ID: <20060611204811.271AE15217B@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 6: 0:2.4.0.3-0.20060328cvs_5.fc6 banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 DevIL: 5: 0:1.6.8-0.8.rc1.fc5 6: 0:1.6.8-0.7.rc1.fc6 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 kdemultimedia-extras: 5: 6:3.5.2-5.fc5 6: 6:3.5.1-8.fc6 kdesvn: 5: 0:0.8.4-1.fc5 6: 0:0.7.4-1.fc5 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 paraview: 4: 0:2.4.3-7.fc4 5: 0:2.4.3-6.fc5 6: 0:2.4.3-7.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 subversion-api-docs: 5: 0:1.3.2-1.fc5 6: 0:1.3.1-1.fc6 wine-docs: 3: 0:0.9.15-1.fc3 4: 0:0.9.15-0.1.fc4 5: 0:0.9.15-1.fc5 6: 0:0.9.15-1.fc6 From paul at all-the-johnsons.co.uk Sun Jun 11 21:57:45 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 11 Jun 2006 22:57:45 +0100 Subject: desktop-file-install problem Message-ID: <1150063066.10716.75.camel@T7.Linux> Hi, I seem to have hit a problem with the desktop file used in CastPodder (currently waiting review for FE) - there is a problem with the spec file which I'm working on... I have included a desktop-file-install section in the install which looks like this %install mkdir -p %{buildroot}/%{_bindir} mkdir -p %{buildroot}/%{_datadir}/%{name} mkdir -p %{buildroot}/opt/%{name} cp -f -R * %{buildroot}/opt/%{name} cp -f %{buildroot}/opt/%{name}/%{name}.sh %{buildroot}/%{_bindir}/%{name} chmod -R 755 %{buildroot}/opt/%{name}/*.py desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ --delete-original \ %{buildroot}%{_datadir}/applications/CastPodder.desktop install -m644 %{SOURCE1} -D %{buildroot}/%{_miconsdir}/%{name}.png install -m644 %{SOURCE2} -D %{buildroot}/%{_iconsdir}/%{name}.png install -m644 %{SOURCE3} -D %{buildroot}/%{_liconsdir}/%{name}.png When I run rpmbuild on the specfile though, the build works until it gets to the desktop-file-install which gives + desktop-file-install --vendor fedora --dir /var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications --add-category X-Fedora --delete-original /var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop Error on file "/var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop": Failed to open file '/var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop' : No such file or directory As I understand it, shouldn't the desktop-file-install copy from {BUILD} to %{buildroot}%{_datadir}/applications/ the .desktop file or is there something I'm missing (which is possible)? I have tried the spec file with and without the --delete-original and get the same results. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sun Jun 11 23:12:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 12 Jun 2006 01:12:24 +0200 Subject: desktop-file-install problem In-Reply-To: <1150063066.10716.75.camel@T7.Linux> References: <1150063066.10716.75.camel@T7.Linux> Message-ID: <20060612011224.df6a0e3f.bugs.michael@gmx.net> On Sun, 11 Jun 2006 22:57:45 +0100, Paul wrote: > Hi, > > I seem to have hit a problem with the desktop file used in CastPodder > (currently waiting review for FE) - there is a problem with the spec > file which I'm working on... > > I have included a desktop-file-install section in the install which > looks like this > > %install rm -rf %{buildroot} is missing here at beginning of %install section. > mkdir -p %{buildroot}/%{_bindir} > mkdir -p %{buildroot}/%{_datadir}/%{name} > mkdir -p %{buildroot}/opt/%{name} > cp -f -R * %{buildroot}/opt/%{name} > cp -f %{buildroot}/opt/%{name}/%{name}.sh > %{buildroot}/%{_bindir}/%{name} > chmod -R 755 %{buildroot}/opt/%{name}/*.py > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > --add-category X-Fedora \ > --delete-original \ > %{buildroot}%{_datadir}/applications/CastPodder.desktop > install -m644 %{SOURCE1} -D %{buildroot}/%{_miconsdir}/%{name}.png > install -m644 %{SOURCE2} -D %{buildroot}/%{_iconsdir}/%{name}.png > install -m644 %{SOURCE3} -D %{buildroot}/%{_liconsdir}/%{name}.png > > When I run rpmbuild on the specfile though, the build works until it > gets to the desktop-file-install which gives > > + desktop-file-install --vendor fedora > --dir /var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications > --add-category X-Fedora > --delete-original /var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop > Error on file > "/var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop": Failed to open file '/var/tmp/CastPodder-5.0-3-root-paul/usr/share/applications/CastPodder.desktop' : No such file or directory > > As I understand it, shouldn't the desktop-file-install copy from {BUILD} > to %{buildroot}%{_datadir}/applications/ the .desktop file or is there > something I'm missing (which is possible)? > > I have tried the spec file with and without the --delete-original and > get the same results. Eh? Does the file exist in the buildroot? You sound as if it does not exist. If you list %{buildroot}/%{_datadir}/applications, does the original CastPodder.desktop file exist? From michael at knox.net.nz Sun Jun 11 23:20:52 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 12 Jun 2006 11:20:52 +1200 Subject: rpath joy In-Reply-To: <20060611090721.GA2415@free.fr> References: <448BD19C.1070409@knox.net.nz> <20060611090721.GA2415@free.fr> Message-ID: <448CA554.5030300@knox.net.nz> Patrice Dumas wrote: > On Sun, Jun 11, 2006 at 08:17:32PM +1200, Michael J. Knox wrote: > >>Hi all, >> >>I am sure this has been beaten to death, however, I have not been able >>to find much info on this. >> >>I am trying to package up ntop for FE. However, I have a rpath error on >>the plugins.. I get this: >> >>ERROR 0002: file '/usr/lib/ntop/plugins/rrdPlugin.so' contains an >>invalid rpath '/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs' in >>[/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs] >>error: Bad exit status from /home/mjk/rpmbuild/tmp/rpm-tmp.53484 (%install) > > > Do you have a build log or could you give an explanation on how to > reproduce your build? > > In gnash there are rpath that appear when the plugin dll is copied with cp > instead of installed by libtool with libtool --install. > > The make rule is: > $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $(plugin_LTLIBRARIES) "$(DESTDIR)$(plugindir)/$(plugin_LTLIBRARIES)" > No, I don't have a build.log, I am just builing this in my normal rpmbuild root like so"rpmbuild -bi ntop.spec" I found a patch from PLD Linux that addresses the problem, the do: --- ntop/plugins/Makefile.am 2004-11-11 10:12:52.000000000 +0000 +++ ntop.new/plugins/Makefile.am 2005-01-01 21:09:57.376911224 +0000 @@ -42,16 +42,6 @@ # # The meat for ntop # -noinst_PROGRAMS = \ - icmpPlugin.so \ - lastSeenPlugin.so \ - netflowPlugin.so \ - pdaPlugin.so \ - rrdPlugin.so \ - snmpPlugin.so \ - sflowPlugin.so \ - xmldumpPlugin.so - lib_LTLIBRARIES = \ libicmpPlugin.la \ liblastSeenPlugin.la \ --- ntop-3.2/plugins/Makefile.am~ 2006-01-02 02:11:46.000000000 +0200 +++ ntop-3.2/plugins/Makefile.am 2006-01-02 02:47:33.000000000 +0200 @@ -42,7 +42,7 @@ # # The meat for ntop # -lib_LTLIBRARIES = \ +plugin_LTLIBRARIES = \ libicmpPlugin.la \ liblastSeenPlugin.la \ libnetflowPlugin.la \ seems the change from lib_LTLIBRARES to plugin_LIBRARIES fixes it? Michael From michael at knox.net.nz Sun Jun 11 23:24:43 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 12 Jun 2006 11:24:43 +1200 Subject: rpath joy In-Reply-To: <448CA554.5030300@knox.net.nz> References: <448BD19C.1070409@knox.net.nz> <20060611090721.GA2415@free.fr> <448CA554.5030300@knox.net.nz> Message-ID: <448CA63B.10106@knox.net.nz> Michael J. Knox wrote: > Patrice Dumas wrote: > >> On Sun, Jun 11, 2006 at 08:17:32PM +1200, Michael J. Knox wrote: >> >>> Hi all, >>> >>> I am sure this has been beaten to death, however, I have not been >>> able to find much info on this. >>> >>> I am trying to package up ntop for FE. However, I have a rpath error >>> on the plugins.. I get this: >>> >>> ERROR 0002: file '/usr/lib/ntop/plugins/rrdPlugin.so' contains an >>> invalid rpath '/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs' in >>> [/home/mjk/rpmbuild/BUILD/ntop-3.2/myrrd/.libs] >>> error: Bad exit status from /home/mjk/rpmbuild/tmp/rpm-tmp.53484 >>> (%install) >> >> >> >> Do you have a build log or could you give an explanation on how to >> reproduce your build? >> >> In gnash there are rpath that appear when the plugin dll is copied >> with cp >> instead of installed by libtool with libtool --install. >> >> The make rule is: >> $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) >> $(plugin_LTLIBRARIES) "$(DESTDIR)$(plugindir)/$(plugin_LTLIBRARIES)" >> > > No, I don't have a build.log, I am just builing this in my normal > rpmbuild root like so"rpmbuild -bi ntop.spec" > > I found a patch from PLD Linux that addresses the problem, the do: > > --- ntop/plugins/Makefile.am 2004-11-11 10:12:52.000000000 +0000 > +++ ntop.new/plugins/Makefile.am 2005-01-01 21:09:57.376911224 +0000 > @@ -42,16 +42,6 @@ > # > # The meat for ntop > # > -noinst_PROGRAMS = \ > - icmpPlugin.so \ > - lastSeenPlugin.so \ > - netflowPlugin.so \ > - pdaPlugin.so \ > - rrdPlugin.so \ > - snmpPlugin.so \ > - sflowPlugin.so \ > - xmldumpPlugin.so > - > lib_LTLIBRARIES = \ > libicmpPlugin.la \ > liblastSeenPlugin.la \ > --- ntop-3.2/plugins/Makefile.am~ 2006-01-02 02:11:46.000000000 +0200 > +++ ntop-3.2/plugins/Makefile.am 2006-01-02 02:47:33.000000000 +0200 > @@ -42,7 +42,7 @@ > # > # The meat for ntop > # > -lib_LTLIBRARIES = \ > +plugin_LTLIBRARIES = \ > libicmpPlugin.la \ > liblastSeenPlugin.la \ > libnetflowPlugin.la \ > > seems the change from lib_LTLIBRARES to plugin_LIBRARIES fixes it? or that the .so's are being installed... Michael From tibbs at math.uh.edu Sun Jun 11 23:52:04 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 11 Jun 2006 18:52:04 -0500 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150045567.2305.7.camel@localhost.localdomain> (Thorsten Leemhuis's message of "Sun, 11 Jun 2006 19:06:07 +0200") References: <1150017630.3481.22.camel@eagle.danny.cz> <1150045567.2305.7.camel@localhost.localdomain> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> I tend to think the "running auto* in spec files might break TL> sooner or later" is true, but how ofter does it break and is it TL> worth the hassle to create patches? Could someone detail just how things get broken and what things we should be looking out for? I'm reviewing a package now (aplus-fsf, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174021) that patches Makefile.am files all over the place and then calls the autotools. This is a really old piece of software but once massaged a bit it puts everything in the proper places and runs fine. I don't see any problem with what it's doing, and I don't understand why it would be any better to do a bunch of hacking just to avoid calling the autotools. - J< From michael at knox.net.nz Sun Jun 11 23:58:03 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 12 Jun 2006 11:58:03 +1200 Subject: how to patch configure.ac and not require autotools In-Reply-To: References: <1150017630.3481.22.camel@eagle.danny.cz> <1150045567.2305.7.camel@localhost.localdomain> Message-ID: <448CAE0B.2000500@knox.net.nz> Jason L Tibbitts III wrote: >>>>>>"TL" == Thorsten Leemhuis writes: > > > TL> I tend to think the "running auto* in spec files might break > TL> sooner or later" is true, but how ofter does it break and is it > TL> worth the hassle to create patches? > > Could someone detail just how things get broken and what things we > should be looking out for? I'm reviewing a package now (aplus-fsf, > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174021) that > patches Makefile.am files all over the place and then calls the > autotools. This is a really old piece of software but once massaged a > bit it puts everything in the proper places and runs fine. I don't > see any problem with what it's doing, and I don't understand why it > would be any better to do a bunch of hacking just to avoid calling the > autotools. I asked about the use of autoreconf in IRC today and was told its up to the maintainers discreation as to weather its used or not. I have to use it in the ntop spec I am working with to help fix an rpath issue. IMHO I think patching autogenrated files instead of the source files (*.am's etc) and regenrating them is a bit ass about face. If you have a real issue and refreshing the auto* files fixes it then it should be acceptable. Running the autotools because you can, should not be. Michael From rc040203 at freenet.de Mon Jun 12 01:26:42 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Jun 2006 03:26:42 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: References: <1150017630.3481.22.camel@eagle.danny.cz> Message-ID: <1150075603.30155.28.camel@mccallum.corsepiu.local> On Sun, 2006-06-11 at 07:43 -0500, Rex Dieter wrote: > Dan Hor?k wrote: > > Hello, > > > > I need to patch configure.ac so it doesn't explicitely add '-s' to > > LDFLAGS (see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194782). From a > > discussion started in > > http://www.redhat.com/archives/fedora-extras-list/2005-October/msg01545.html it is forbidden to use autotools during the build process and it suggests to patch configure and the other generated files too. But in my situation the only files that differ are configure.ac and configure. And after applying the patch their timestamps are set to the current time and because other files (Makefile.am, config.h, ...) depend on them, they want to be regenerated. The whole package seem buildable without the autotools, but with some not very nice messages about missing automake, autoconf, etc in the buildlog. > > I guess I missed the conclusion that using auto* tools is absolutely > forgidden. AFAIK, it's not in the PackagingGuidelines, and there are > certainly valid cases where their use is warranted (this may be one of > them). I'd suggest simply patching things and > BuildRequires: automake autoconf > and be done with it. .. and wait for blindly generated diff to break your package. Pedantically speaking, the opposite is true. Modern automake-based packages support and ship "missing": c.f. /usr/share/automake-1.9/missing --help I.e. the packager provides a *complete and functional* patch which breaks timestamps on generated files, and does NOT to have the autotools installed, the autotools will "touch the generated files", themselves I.e. Actually, BuildConflicts: and using missing would solve the problem. Less pedantically, if the default set of packages inside of the buildsys doesn't contain the autotools, and if packagers were required to provide complete patches, this issue becomes a non-issue. The down-side would be users rebuilding a package and having the autotools installed, would see the autotools be run, i.e. non-deterministic "user-builts". Build qgit with the patch below and the autotools uninstalled to see the effects I am talking about. Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: qgit-configure.patch Type: text/x-patch Size: 644 bytes Desc: not available URL: From wart at kobold.org Mon Jun 12 02:23:40 2006 From: wart at kobold.org (Wart) Date: Sun, 11 Jun 2006 19:23:40 -0700 Subject: how to patch configure.ac and not require autotools In-Reply-To: <878xo34lpw.fsf@kosh.bigo.ensc.de> References: <1150017630.3481.22.camel@eagle.danny.cz> <448C4C88.7020400@kobold.org> <878xo34lpw.fsf@kosh.bigo.ensc.de> Message-ID: <448CD02C.2050805@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Enrico Scholz wrote: > wart at kobold.org (Wart) writes: > > >>'touch', not patch. >> >>I run into this quite a lot. In addition to patching both configure.ac >>and configure.in, you'll need to 'touch' all of the "Makefile.in" files >>in the package, since they likely have a dependency on configure.in. > > > That's only needed for projects whose authors do not use AM_MAINTAINER_MODE. > > Instead of touching all Makefile.in's you could restore the original > timestamp with: > > | touch -r configure configure.stamp > | ... patch configure ... > | touch -r configure.stamp configure That's an even better solution. Thanks for the tip. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEjNAqDeYlPfs40g8RAhv8AJ4xpwJALRmCCz7B7LW3u6xsutxAaACdGb11 7hcXIDjzr75Muo/HGx33Yn4= =5Ghp -----END PGP SIGNATURE----- From Matt_Domsch at dell.com Mon Jun 12 03:46:30 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 11 Jun 2006 22:46:30 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-11 Message-ID: <20060612034630.GA27124@lists.us.dell.com> Now with email addresses from the owners.list for each package. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Sun Jun 11 22:41:54 CDT 2006 Number failed to build: 176 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 175 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 171 ---------------------------------- abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya gauret at free.fr argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang compat-erlang contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt dbus-qt ddskk petersen at redhat.com deskbar-applet ivazquez at ivazquez.net dietlibc enrico.scholz at informatik.tu-chemnitz.de dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gcompris j.w.r.degoede at hhs.nl gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-password-generator michael at knox.net.nz gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk gprolog Jochen at herr-schmitt.de grads pertusus at free.fr gramps bdpepple at ameritech.net grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com jed notting at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com mftrace qspencer at ieee.org multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us naim lmacken at redhat.com nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at notemeister fedora at leemhuis.info openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org OpenSceneGraph rc040203 at freenet.de orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org paps tagoh at redhat.com pcsc-lite ville.skytta at iki.fi perl-Spoon steve at silug.org pessulus splinux at fedoraproject.org php-extras dmitry at butskoy.name pitivi redhat at flyn.org pl gemi at bluewin.ch plplot orion at cora.nwra.com pure-ftpd gauret at free.fr pybliographer z.kota at gmx.net pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net qa-assistant toshio at tiki-lounge.com quarry michel.salim at gmail.com revelation fedora at leemhuis.info rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru straw byte at fedoraproject.org syck oliver at linux-kernel.at sylpheed-claws-plugins andreas.bierfert at lowlatency.de synaptic Axel.Thimm at ATrpms.net synce andreas.bierfert at lowlatency.de synce-gnomevfs andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de x3270 karsten at redhat.com xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 Mon Jun 12 03:46:59 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 11 Jun 2006 22:46:59 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-11 Message-ID: <20060612034659.GB27124@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Sun Jun 11 22:40:02 CDT 2006 Number failed to build: 226 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 215 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 209 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya gauret at free.fr apollon rdieter at math.unl.edu argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il blktool jgarzik at redhat.com blogtk stickster at gmail.com bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net crossfire wart at kobold.org ctrlproxy jwboyer at jdub.homelinux.org dbus-qt dbus-qt ddskk petersen at redhat.com deskbar-applet ivazquez at ivazquez.net dietlibc enrico.scholz at informatik.tu-chemnitz.de dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com dvdisaster dmitry at butskoy.name dxpc rdieter at math.unl.edu ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gaim-otr paul at xtdnet.nl gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gcompris j.w.r.degoede at hhs.nl gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnet2 ivazquez at ivazquez.net gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-blog bdpepple at ameritech.net gnome-password-generator michael at knox.net.nz gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grace jamatos at fc.up.pt gramps bdpepple at ameritech.net grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtk+ rdieter at math.unl.edu gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gts ed at eh3.com gwget fedora.wickert at arcor.de heartbeat fedora at soeterbroek.com hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr irssi anvil at livna.org jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu koffice andreas.bierfert at lowlatency.de konversation dennis at ausil.us kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libassetml j.w.r.degoede at hhs.nl libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libopensync andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libspectrum paul at all-the-johnsons.co.uk libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org linphone ivazquez at ivazquez.net logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org maxima rdieter at math.unl.edu meanwhile jwboyer at jdub.homelinux.org mftrace qspencer at ieee.org mhonarc gauret at free.fr mod_suphp andreas at bawue.net most adrian at lisas.de multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us naim lmacken at redhat.com nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at notemeister fedora at leemhuis.info openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org orpie lists at forevermore.net p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org paps tagoh at redhat.com pcsc-lite ville.skytta at iki.fi perl-Glib jpo at di.uminho.pt perl-Image-Info jpo at di.uminho.pt perl-IPC-Shareable jpo at di.uminho.pt perl-Spoon steve at silug.org perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr pessulus splinux at fedoraproject.org php-extras dmitry at butskoy.name php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch plplot orion at cora.nwra.com pure-ftpd gauret at free.fr pybliographer z.kota at gmx.net pygame chris.stone at gmail.com python-bibtex z.kota at gmx.net python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net qa-assistant toshio at tiki-lounge.com qof toshio at tiki-lounge.com quarry michel.salim at gmail.com revelation fedora at leemhuis.info rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rssowl green at redhat.com rxvt-unicode andreas.bierfert at lowlatency.de sabayon markmc at redhat.com sblim-cmpi-base hamzy at us.ibm.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net seamonkey kengert at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net showimg gauret at free.fr sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru straw byte at fedoraproject.org sylpheed-claws-plugins andreas.bierfert at lowlatency.de synce andreas.bierfert at lowlatency.de synce-gnomevfs andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ttywatch Matt_Domsch at dell.com ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de wv gauret at free.fr x3270 karsten at redhat.com xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xfce4-xkb-plugin fedora.wickert at arcor.de xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 6 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com libqalculate ['193481 CLOSED'] dakingun at gmail.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de xfprint ['194147 CLOSED'] kevin-redhat-bugzilla at tummy.com yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 michael at knox.net.nz Mon Jun 12 04:08:24 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 12 Jun 2006 16:08:24 +1200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-11 In-Reply-To: <20060612034630.GA27124@lists.us.dell.com> References: <20060612034630.GA27124@lists.us.dell.com> Message-ID: <448CE8B8.7020706@knox.net.nz> Matt Domsch wrote: > gnome-password-generator michael at knox.net.nz This seems to have failed becuase of this: Error Downloading Packages: pyorbit - 2.14.0-1.i386: failure: Fedora/RPMS/pyorbit-2.14.0-1.i386.rpm from core: [Errno 256] No more mirrors to try. core 27 k However, a test build in my mock, with the reduced package set, completes successfully: Requires: /usr/bin/python gnome-python2 pygtk2 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/gnome-password-generator-1.4-4-root-mockbuild warning: Could not canonicalize hostname: leroy.et.endace.com Wrote: /builddir/build/RPMS/gnome-password-generator-1.4-4.noarch.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.47586 Michael From chris.stone at gmail.com Mon Jun 12 06:02:44 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 11 Jun 2006 23:02:44 -0700 Subject: Strange Build Failures Message-ID: I am getting a build failure on one of my packages for FC-5 i386/ppc only. The root.log indicates that it installs libXxf86vm.i386 0:1.0.0-2.2 - core without installing libXext.i386 0:1.0.0-3.2 - core How can this be? http://buildsys.fedoraproject.org/logs/fedora-5-extras/10918-osgal-20060410-3.fc5/i386/root.log From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jun 12 06:11:33 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 12 Jun 2006 15:11:33 +0900 Subject: Strange Build Failures In-Reply-To: References: Message-ID: <448D0595.4090208@ioa.s.u-tokyo.ac.jp> Christopher Stone wrote: > I am getting a build failure on one of my packages for FC-5 i386/ppc only. > > The root.log indicates that it installs > > libXxf86vm.i386 0:1.0.0-2.2 - core > > without installing > > libXext.i386 0:1.0.0-3.2 - core > > How can this be? > > http://buildsys.fedoraproject.org/logs/fedora-5-extras/10918-osgal-20060410-3.fc5/i386/root.log > > This is related to nx problem as discussed before. Please see https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00456.html (titled "Buildsys glitch?") From Christian.Iseli at licr.org Mon Jun 12 07:29:12 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 12 Jun 2006 09:29:12 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: Your message of "Sun, 11 Jun 2006 08:48:02 +1200." <448B3002.60908@knox.net.nz> Message-ID: <200606120729.k5C7TCeD013872@ludwig-alpha.unil.ch> michael at knox.net.nz said: > Should be ignored by the QA script: > lineak_xosdplugin, lineak_kdeplugins, lineak_xosdplugin Are in the > owners.list, however the name differs from the subject of the review > request. Sub the "_" for a "-". At first, I had a list of BZ tickets for which the script could not determine the correct package name (file bzId_pkg.txt attached to the Extras/UsefulScripts wiki page). But I think it was a bad idea: very hard to maintain. I think the proper way to handle those is to fix the Summary line of the affected BZ tickets. Which I have done with the lineak* tickets. > Re-Review is actually jed, which is in the owners.list Yup. Fixed the script so that it groks this one too. > kimdaba has been replaced by kphotoalbum, which is in the owners.list But there still is a kimdaba package with a full devel branch... So something is wrong somewhere... > libgsf113 appears to have been removed from cvs, repos and owners.list This one has been blacklisted now. Cheers, Christian From michael at knox.net.nz Mon Jun 12 07:34:15 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 12 Jun 2006 19:34:15 +1200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606120729.k5C7TCeD013872@ludwig-alpha.unil.ch> References: <200606120729.k5C7TCeD013872@ludwig-alpha.unil.ch> Message-ID: <448D18F7.2070802@knox.net.nz> Christian.Iseli at licr.org wrote: > michael at knox.net.nz said: >> Should be ignored by the QA script: >> lineak_xosdplugin, lineak_kdeplugins, lineak_xosdplugin Are in the >> owners.list, however the name differs from the subject of the review >> request. Sub the "_" for a "-". > > At first, I had a list of BZ tickets for which the script could not determine > the correct package name (file bzId_pkg.txt attached to the > Extras/UsefulScripts wiki page). But I think it was a bad idea: very hard to > maintain. I think the proper way to handle those is to fix the Summary line > of the affected BZ tickets. Which I have done with the lineak* tickets. Ok, I will fix up those bz reports then. >> Re-Review is actually jed, which is in the owners.list > > Yup. Fixed the script so that it groks this one too. Just saw that ;) >> kimdaba has been replaced by kphotoalbum, which is in the owners.list > > But there still is a kimdaba package with a full devel branch... So > something is wrong somewhere... Rex is looking into it I believe. >> libgsf113 appears to have been removed from cvs, repos and owners.list > > This one has been blacklisted now. > Nice! Thanks Michael From chris.stone at gmail.com Mon Jun 12 07:38:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 12 Jun 2006 00:38:45 -0700 Subject: Buildsys glitch? In-Reply-To: <1149991578.12112.183.camel@mccallum.corsepiu.local> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> Message-ID: >From the root.log: http://buildsys.fedoraproject.org/logs/fedora-5-extras/10841-emacs-auctex-11.83-2.fc5/noarch/root.log Install: libXxf86vm.ppc 0:1.0.0-2.2 - core Installing libXxf86vm.ppc should require the install of libXext.ppc: http://cvs.fedora.redhat.com/viewcvs/devel/libXxf86vm/libXxf86vm.spec?rev=1.14&view=markup For some reason this dependency is not being picked up on i386 and ppc (and noarch since noarch uses ppc to build) arches under FC-5. From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jun 12 08:26:31 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 12 Jun 2006 17:26:31 +0900 Subject: Buildsys glitch? In-Reply-To: References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> Message-ID: <448D2537.7050701@ioa.s.u-tokyo.ac.jp> Christopher Stone wrote: >> From the root.log: > > http://buildsys.fedoraproject.org/logs/fedora-5-extras/10841-emacs-auctex-11.83-2.fc5/noarch/root.log > > > Install: libXxf86vm.ppc 0:1.0.0-2.2 - core > > Installing libXxf86vm.ppc should require the install of libXext.ppc: This is related to nx problem, as pointed by Rick Stout. It seems that Rick forbad nx to provide libXext.so.6 by nx-1_5_0-10_fc5, so when this nx is pushed, this problem will be resolved. From pertusus at free.fr Mon Jun 12 10:29:00 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Jun 2006 12:29:00 +0200 Subject: rpath joy In-Reply-To: <448CA554.5030300@knox.net.nz> References: <448BD19C.1070409@knox.net.nz> <20060611090721.GA2415@free.fr> <448CA554.5030300@knox.net.nz> Message-ID: <20060612102859.GB2541@free.fr> On Mon, Jun 12, 2006 at 11:20:52AM +1200, Michael J. Knox wrote: > No, I don't have a build.log, I am just builing this in my normal > rpmbuild root like so"rpmbuild -bi ntop.spec" >From which src.rpm? > I found a patch from PLD Linux that addresses the problem, the do: > > --- ntop/plugins/Makefile.am 2004-11-11 10:12:52.000000000 +0000 > +++ ntop.new/plugins/Makefile.am 2005-01-01 21:09:57.376911224 +0000 > @@ -42,16 +42,6 @@ > # > # The meat for ntop > # > -noinst_PROGRAMS = \ > - icmpPlugin.so \ > - lastSeenPlugin.so \ > - netflowPlugin.so \ > - pdaPlugin.so \ > - rrdPlugin.so \ > - snmpPlugin.so \ > - sflowPlugin.so \ > - xmldumpPlugin.so > - > lib_LTLIBRARIES = \ > libicmpPlugin.la \ > liblastSeenPlugin.la \ > --- ntop-3.2/plugins/Makefile.am~ 2006-01-02 02:11:46.000000000 +0200 > +++ ntop-3.2/plugins/Makefile.am 2006-01-02 02:47:33.000000000 +0200 > @@ -42,7 +42,7 @@ > # > # The meat for ntop > # > -lib_LTLIBRARIES = \ > +plugin_LTLIBRARIES = \ > libicmpPlugin.la \ > liblastSeenPlugin.la \ > libnetflowPlugin.la \ > > seems the change from lib_LTLIBRARES to plugin_LIBRARIES fixes it? Indeed with plugin_LTLIBRARIES libtool will do the usual install in the plugin dir, but there should be some changes elsewhere, as previously there was something installed in the plugin dir - even though not by libtool? -- Pat From buildsys at fedoraproject.org Mon Jun 12 12:17:05 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 12 Jun 2006 08:17:05 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-12 Message-ID: <20060612121705.7ED4D15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 15 abcMIDI-20060422-1.fc5 curry-0.9.10-2.fc5 doctorj-5.0.0-5.fc5 freenx-0.5.0-0.5.test7.fc5 gnome-sudoku-0.4.0-6.fc5 gossip-0.11.2-2.fc5 grace-5.1.20-1.fc5 meld-1.1.4-2.fc5 nx-1.5.0-10.fc5 openalpp-20060405-7.fc5 paps-0.6.6-3.fc5 pypoker-eval-131.0-5.fc5 qgit-1.3-2.fc5 renrot-0.21-1.fc5 wormux-0.7.2-5.fc5 Packages built and released for Fedora Extras 4: 13 abcMIDI-20060422-1.fc4 curry-0.9.10-2.fc4 doctorj-5.0.0-5.fc4 freenx-0.5.0-0.4.test7.fc4 gnome-sudoku-0.4.0-6.fc4 grace-5.1.20-1.fc4 nx-1.5.0-10.fc4 openalpp-20060405-7.fc4 osgal-20060410-3.fc4 pypoker-eval-131.0-5.fc4 qgit-1.3-2.fc4 renrot-0.21-1.fc4 wormux-0.7.2-5.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 20 DevIL-1.6.8-0.8.rc1.fc6 curry-0.9.10-2.fc6 dejavu-fonts-2.7.0-0.14.fc6 doctorj-5.0.0-5.fc6 flow-tools-0.68-8.fc6 gnome-sudoku-0.4.0-6.fc6 gossip-0.11.2-3.fc6 grace-5.1.20-1.fc6 guichan-0.4.0-2.fc6 kdesvn-0.8.4-1.fc6 kipi-plugins-0.1.0-0.10.rc2.fc6.1 meld-1.1.4-3.fc6 nagios-plugins-1.4.3-9.fc6 openalpp-20060405-7.fc6 osgal-20060410-3.fc6 paps-0.6.6-3.fc6 pypoker-eval-131.0-5.fc6 qgit-1.3-2.fc6 renrot-0.21-1.fc6 xsp-1.1.15-2.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Jun 12 12:17:18 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 12 Jun 2006 08:17:18 -0400 (EDT) Subject: Broken upgrade paths in Fedora Extras 2006-06-12 Message-ID: <20060612121718.9B4B615217B@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 6: 0:2.4.0.3-0.20060328cvs_5.fc6 banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 kdemultimedia-extras: 5: 6:3.5.2-5.fc5 6: 6:3.5.1-8.fc6 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 paraview: 4: 0:2.4.3-7.fc4 5: 0:2.4.3-6.fc5 6: 0:2.4.3-7.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 subversion-api-docs: 5: 0:1.3.2-1.fc5 6: 0:1.3.1-1.fc6 wine-docs: 3: 0:0.9.15-1.fc3 4: 0:0.9.15-0.1.fc4 5: 0:0.9.15-1.fc5 6: 0:0.9.15-1.fc6 From buildsys at fedoraproject.org Mon Jun 12 12:33:47 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 12 Jun 2006 12:33:47 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-12 Message-ID: <20060612123347.28604.79304@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 kipi-plugins 0.1.0-0.10.rc2.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 kipi-plugins 0.1.0-0.10.rc2.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 ====================================================================== package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: kipi-plugins - 0.1.0-0.10.rc2.fc3.i386 from fedora-extras-3-i386 unresolved deps: dcraw package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: kipi-plugins - 0.1.0-0.10.rc2.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: dcraw From buildsys at fedoraproject.org Mon Jun 12 12:33:47 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 12 Jun 2006 12:33:47 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-12 Message-ID: <20060612123347.28616.29917@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Mon Jun 12 12:33:47 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 12 Jun 2006 12:33:47 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-12 Message-ID: <20060612123347.28618.79499@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 autotrace 0.31.1-12.fc5.i386 dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.i386 gdl 0.9-0.pre.fc6.i386 gnokii 0.6.12-4.fc6.i386 gnokii-smsd 0.6.12-4.fc6.i386 gtktalog 1.0.4-7.fc5.i386 kismet-extras 0.0.2006.04.R1-2.fc6.i386 koffice-devel 1.5.1-1.fc6.i386 koffice-filters 1.5.1-1.fc6.i386 koffice-karbon 1.5.1-1.fc6.i386 koffice-krita 1.5.1-1.fc6.i386 libopensync-plugin-irmc 0.18-6.fc5.i386 octave-forge 2006.03.17-4.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 xgnokii 0.6.12-4.fc6.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc autotrace 0.31.1-12.fc5.ppc dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.ppc gdl 0.9-0.pre.fc6.ppc gnokii 0.6.12-4.fc6.ppc gnokii-smsd 0.6.12-4.fc6.ppc gtktalog 1.0.4-7.fc5.ppc kismet-extras 0.0.2006.04.R1-2.fc6.ppc koffice-devel 1.5.1-1.fc6.ppc koffice-filters 1.5.1-1.fc6.ppc koffice-karbon 1.5.1-1.fc6.ppc koffice-krita 1.5.1-1.fc6.ppc libopensync-plugin-irmc 0.18-6.fc5.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc octave-forge 2006.03.17-4.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc xgnokii 0.6.12-4.fc6.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 autotrace 0.31.1-12.fc5.x86_64 dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.x86_64 gdl 0.9-0.pre.fc6.x86_64 gnokii 0.6.12-4.fc6.x86_64 gnokii-smsd 0.6.12-4.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 kismet-extras 0.0.2006.04.R1-2.fc6.x86_64 koffice-devel 1.5.1-1.fc6.x86_64 koffice-filters 1.5.1-1.fc6.x86_64 koffice-karbon 1.5.1-1.fc6.x86_64 koffice-krita 1.5.1-1.fc6.x86_64 libopensync-plugin-irmc 0.18-6.fc5.x86_64 octave-forge 2006.03.17-4.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 xgnokii 0.6.12-4.fc6.x86_64 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: libopensync-plugin-irmc - 0.18-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: libbluetooth.so.1 package: libopensync-plugin-irmc - 0.18-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libbluetooth.so.1()(64bit) package: libopensync-plugin-irmc - 0.18-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: libbluetooth.so.1 ====================================================================== New report for: triad AT df.lth.se package: gnokii-smsd - 0.6.12-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libbluetooth.so.1 package: xgnokii - 0.6.12-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libbluetooth.so.1 package: gnokii - 0.6.12-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libbluetooth.so.1 package: gnokii - 0.6.12-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libbluetooth.so.1()(64bit) package: xgnokii - 0.6.12-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libbluetooth.so.1()(64bit) package: gnokii-smsd - 0.6.12-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libbluetooth.so.1()(64bit) package: gnokii - 0.6.12-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libbluetooth.so.1 package: xgnokii - 0.6.12-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libbluetooth.so.1 package: gnokii-smsd - 0.6.12-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libbluetooth.so.1 ====================================================================== New report for: nicolas.mailhot AT laposte.net package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-i386 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-ppc unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 ====================================================================== package: kismet-extras - 0.0.2006.04.R1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: gdl - 0.9-0.pre.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: koffice-filters - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: autotrace - 0.31.1-12.fc5.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: octave-forge - 2006.03.17-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 libMagick.so.9 package: koffice-krita - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-karbon - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: koffice-filters - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: koffice-devel - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: octave-forge - 2006.03.17-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) libMagick.so.9()(64bit) package: gdl - 0.9-0.pre.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) package: koffice-krita - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: autotrace - 0.31.1-12.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: koffice-karbon - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: octave-forge - 2006.03.17-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 libMagick.so.9 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: koffice-krita - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: gdl - 0.9-0.pre.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 package: autotrace - 0.31.1-12.fc5.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: kismet-extras - 0.0.2006.04.R1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: koffice-karbon - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-filters - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors nagios-plugins = 0:1.4.3-6.fc6 From buildsys at fedoraproject.org Mon Jun 12 12:33:47 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 12 Jun 2006 12:33:47 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-12 Message-ID: <20060612123347.28612.25563@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== New report for: dcbw AT redhat.com package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From dlutter at redhat.com Mon Jun 12 13:25:25 2006 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 12 Jun 2006 15:25:25 +0200 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable Message-ID: <1150118725.22268.2.camel@localhost.localdomain> I was going to make a few tweaks to above page, but it is immutable, and I seem to lack the powers to make iteditable again. Could somebody with the right powers make the page editable ? thanks, David From skvidal at linux.duke.edu Mon Jun 12 13:31:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Jun 2006 09:31:46 -0400 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <1150118725.22268.2.camel@localhost.localdomain> References: <1150118725.22268.2.camel@localhost.localdomain> Message-ID: <1150119106.8514.0.camel@cutter> On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: > I was going to make a few tweaks to above page, but it is immutable, and > I seem to lack the powers to make iteditable again. Could somebody with > the right powers make the page editable ? > Spot is the guy to ask. -sv From paul at city-fan.org Mon Jun 12 14:03:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Jun 2006 15:03:57 +0100 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <1150119106.8514.0.camel@cutter> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> Message-ID: <448D744D.2040202@city-fan.org> seth vidal wrote: > On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: >> I was going to make a few tweaks to above page, but it is immutable, and >> I seem to lack the powers to make iteditable again. Could somebody with >> the right powers make the page editable ? >> > > Spot is the guy to ask. Have the default acls changed for the wiki? Packaging/Perl is also immutable, and there is no #acl line in it. Paul. From skvidal at linux.duke.edu Mon Jun 12 14:09:18 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Jun 2006 10:09:18 -0400 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <448D744D.2040202@city-fan.org> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> Message-ID: <1150121359.8514.2.camel@cutter> On Mon, 2006-06-12 at 15:03 +0100, Paul Howarth wrote: > seth vidal wrote: > > On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: > >> I was going to make a few tweaks to above page, but it is immutable, and > >> I seem to lack the powers to make iteditable again. Could somebody with > >> the right powers make the page editable ? > >> > > > > Spot is the guy to ask. > > Have the default acls changed for the wiki? Packaging/Perl is also > immutable, and there is no #acl line in it. > acl's cascade from the page above. look at Packaging -sv From paul at city-fan.org Mon Jun 12 14:14:34 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Jun 2006 15:14:34 +0100 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <1150121359.8514.2.camel@cutter> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> Message-ID: <448D76CA.3060503@city-fan.org> seth vidal wrote: > On Mon, 2006-06-12 at 15:03 +0100, Paul Howarth wrote: >> seth vidal wrote: >>> On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: >>>> I was going to make a few tweaks to above page, but it is immutable, and >>>> I seem to lack the powers to make iteditable again. Could somebody with >>>> the right powers make the page editable ? >>>> >>> Spot is the guy to ask. >> Have the default acls changed for the wiki? Packaging/Perl is also >> immutable, and there is no #acl line in it. >> > > acl's cascade from the page above. > > look at Packaging Aha, that explains it. Didn't see anything about that on HelpOnAccessControlLists. Thanks. Paul. From skvidal at linux.duke.edu Mon Jun 12 14:19:57 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Jun 2006 10:19:57 -0400 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <448D76CA.3060503@city-fan.org> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> Message-ID: <1150121997.8514.6.camel@cutter> On Mon, 2006-06-12 at 15:14 +0100, Paul Howarth wrote: > seth vidal wrote: > > On Mon, 2006-06-12 at 15:03 +0100, Paul Howarth wrote: > >> seth vidal wrote: > >>> On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: > >>>> I was going to make a few tweaks to above page, but it is immutable, and > >>>> I seem to lack the powers to make iteditable again. Could somebody with > >>>> the right powers make the page editable ? > >>>> > >>> Spot is the guy to ask. > >> Have the default acls changed for the wiki? Packaging/Perl is also > >> immutable, and there is no #acl line in it. > >> > > > > acl's cascade from the page above. > > > > look at Packaging > > Aha, that explains it. Didn't see anything about that on > HelpOnAccessControlLists. Thanks. it's a local fedoraproject wiki patch. -sv From paul at city-fan.org Mon Jun 12 14:20:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Jun 2006 15:20:27 +0100 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <1150121997.8514.6.camel@cutter> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> Message-ID: <448D782B.3010901@city-fan.org> seth vidal wrote: > On Mon, 2006-06-12 at 15:14 +0100, Paul Howarth wrote: >> seth vidal wrote: >>> On Mon, 2006-06-12 at 15:03 +0100, Paul Howarth wrote: >>>> seth vidal wrote: >>>>> On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: >>>>>> I was going to make a few tweaks to above page, but it is immutable, and >>>>>> I seem to lack the powers to make iteditable again. Could somebody with >>>>>> the right powers make the page editable ? >>>>>> >>>>> Spot is the guy to ask. >>>> Have the default acls changed for the wiki? Packaging/Perl is also >>>> immutable, and there is no #acl line in it. >>>> >>> acl's cascade from the page above. >>> >>> look at Packaging >> Aha, that explains it. Didn't see anything about that on >> HelpOnAccessControlLists. Thanks. > > it's a local fedoraproject wiki patch. OK. Is the intention for the Packaging/Lang pages eventually to be editable by the LangSIG members, or for each person to be approved by Spot, or something else? Paul. From skvidal at linux.duke.edu Mon Jun 12 14:25:17 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Jun 2006 10:25:17 -0400 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <448D782B.3010901@city-fan.org> References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> <448D782B.3010901@city-fan.org> Message-ID: <1150122318.8514.8.camel@cutter> On Mon, 2006-06-12 at 15:20 +0100, Paul Howarth wrote: > seth vidal wrote: > > On Mon, 2006-06-12 at 15:14 +0100, Paul Howarth wrote: > >> seth vidal wrote: > >>> On Mon, 2006-06-12 at 15:03 +0100, Paul Howarth wrote: > >>>> seth vidal wrote: > >>>>> On Mon, 2006-06-12 at 15:25 +0200, David Lutterkort wrote: > >>>>>> I was going to make a few tweaks to above page, but it is immutable, and > >>>>>> I seem to lack the powers to make iteditable again. Could somebody with > >>>>>> the right powers make the page editable ? > >>>>>> > >>>>> Spot is the guy to ask. > >>>> Have the default acls changed for the wiki? Packaging/Perl is also > >>>> immutable, and there is no #acl line in it. > >>>> > >>> acl's cascade from the page above. > >>> > >>> look at Packaging > >> Aha, that explains it. Didn't see anything about that on > >> HelpOnAccessControlLists. Thanks. > > > > it's a local fedoraproject wiki patch. > > OK. > > Is the intention for the Packaging/Lang pages eventually to be editable > by the LangSIG members, or for each person to be approved by Spot, or > something else? > Ask spot. -sv From frank-buettner at gmx.net Mon Jun 12 14:48:01 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Mon, 12 Jun 2006 16:48:01 +0200 Subject: Socks Proxy Message-ID: <448D7EA1.3070108@gmx.net> Hallo, hat jemand ein Socks Proxy welcher unter FC5 l?uft zur Hand? Ein yum search socks proxy brachte leider nix zu tage:( -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Mon Jun 12 15:02:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Jun 2006 17:02:41 +0200 (CEST) Subject: Broken dependencies in Fedora Extras development - 2006-06-12 In-Reply-To: <20060612123347.28618.8719@extras64.linux.duke.edu> References: <20060612123347.28618.8719@extras64.linux.duke.edu> Message-ID: <58665.192.54.193.51.1150124561.squirrel@rousalka.dyndns.org> Le Lun 12 juin 2006 14:33, Fedora Extras repoclosure a ?crit : > This is an automated mail created by an experimental script. > Your following packages in the repository contain broken dependencies: > > package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from > fedora-extras-development-i386 > unresolved deps: > dejavu-fonts = 0:2.6.0-1.fc6 ... This is a dud - I queued several dejavu builds this week end (working on it a few hours, declaring it was time to do something else of my free type, then going back on it worrying it was still not good enough for Behdad). As a result the oldest builds deps are not satisfied since the buildsys only considers newest versions -- Nicolas Mailhot From notting at redhat.com Mon Jun 12 15:14:48 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 11:14:48 -0400 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: <200606120729.k5C7TCeD013872@ludwig-alpha.unil.ch> References: <448B3002.60908@knox.net.nz> <200606120729.k5C7TCeD013872@ludwig-alpha.unil.ch> Message-ID: <20060612151448.GB11296@nostromo.devel.redhat.com> Christian.Iseli at licr.org (Christian.Iseli at licr.org) said: > > Re-Review is actually jed, which is in the owners.list > > Yup. Fixed the script so that it groks this one too. Sorry. Didn't know I wasn't supposed to change the subject. :) Bill From paul at city-fan.org Mon Jun 12 15:30:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Jun 2006 16:30:53 +0100 Subject: failed mock build of gnubg on fc4 In-Reply-To: <448BDE1D.8090304@soeterbroek.com> References: <448BDE1D.8090304@soeterbroek.com> Message-ID: <448D88AD.4080609@city-fan.org> Joost Soeterbroek wrote: > Hi, > > I am unable to mock build package gnubg on fc4. > > I've narrowed it down to an autoconf/automake problem in dir 'intl', > where Makefile.in is incorrectly generated missing separators for > SOURCES variable: > SOURCES = > bindtextdom.c > dcgettext.c > dgettext.c > etc.. > causing make to fail with error "Missing seperator". > > It does build successfully (in mock) for fc5 and devel, just not fc-4. > Build logs are available: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/10691-gnubg-20060530-5.fc4/i386/ > > > Any ideas? It's not a mock issue. I can reproduce the issue on an up to date FC-4 system. It seems to be an automake issue; intl/Makefile.in is generated from intl/Makefile.am and includes two definitions of SOURCES, the first without the backslashes at the end of each line, and the second one being correct. Replacing aclocal and automake in the autogen.sh script with aclocal-1.7 and automake-1.7 from the automake17 package gets you past this, for reasons I can't fathom. *Insert here lecture from Ralf on the evils of using autotools in packages* I suspect it's not worth the bother of fixing this though, because the next issue you'll hit is: render.c:48:19: error: cairo.h: No such file or directory FC-4 doesn't have Cairo and the configure script doesn't offer a means of turning off Cairo, unless you also turn off GTK2. Paul. From Christian.Iseli at licr.org Mon Jun 12 15:32:09 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 12 Jun 2006 17:32:09 +0200 Subject: FE Package Status of Jun 7, 2006 In-Reply-To: Your message of "Mon, 12 Jun 2006 11:14:48 EDT." <20060612151448.GB11296@nostromo.devel.redhat.com> Message-ID: <200606121532.k5CFW9AH022154@ludwig-alpha.unil.ch> notting at redhat.com said: > Sorry. Didn't know I wasn't supposed to change the subject. :) Ah well, it's easier if the subject line keeps some consistency. Otherwise, the parsing script needs to get too smart... and we all know too smart scripts can't be trusted :) Christian From rdieter at math.unl.edu Mon Jun 12 15:50:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Jun 2006 10:50:20 -0500 Subject: kxdocker Orphaned Message-ID: I just placed kxdocker on the Orphans page. It's packaging and configuration complexities have grown considerably with recent releases, and unfortunately, I haven't the time (nor interest) to tackle this properly. -- Rex From dan at danny.cz Mon Jun 12 16:08:32 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 12 Jun 2006 18:08:32 +0200 Subject: how to patch configure.ac and not require autotools In-Reply-To: <1150075603.30155.28.camel@mccallum.corsepiu.local> References: <1150017630.3481.22.camel@eagle.danny.cz> <1150075603.30155.28.camel@mccallum.corsepiu.local> Message-ID: <1150128512.3488.27.camel@eagle.danny.cz> Ralf Corsepius p??e v Po 12. 06. 2006 v 03:26 +0200: > > them). I'd suggest simply patching things and > > BuildRequires: automake autoconf > > and be done with it. > > . and wait for blindly generated diff to break your package. > > > Pedantically speaking, the opposite is true. Modern automake-based > packages support and ship "missing": > c.f. /usr/share/automake-1.9/missing --help > > I.e. the packager provides a *complete and functional* patch which > breaks timestamps on generated files, and does NOT to have the autotools > installed, the autotools will "touch the generated files", themselves > > I.e. Actually, BuildConflicts: > and using missing would solve the problem. > > > Less pedantically, if the default set of packages inside of the buildsys > doesn't contain the autotools, and if packagers were required to provide > complete patches, this issue becomes a non-issue. > > The down-side would be users rebuilding a package and having the > autotools installed, would see the autotools be run, i.e. > non-deterministic "user-builts". > > Build qgit with the patch below and the autotools uninstalled to see the > effects I am talking about. I have tried the same patch when playing with the ways to solve this problem and know what it is doing and this is also mentioned as an option in my email that started this discussion. When I summarize it 1. use BuildRequires: - generally can break the build due incompatibilities between author's autotools and the build system's autotools 2. use BuildConflicts: - secure for the build system, but when the autotools will be in the default set, then the build will fail (the buildsystem cannot uninstall a package or can it?), dtto for users 3. use neither BuildRequires or BuildConflicts - in the build system without autotools it will use "missing" and the user is responsible for what is he doing In this case I am sure, that patching both configure.ac and configure doesn't require any changes to be propagated further, so I should use point 3 and let "missing" do its work, if I understand it correctly. Dan From zipsonic at gmail.com Mon Jun 12 16:19:23 2006 From: zipsonic at gmail.com (Rick Stout) Date: Mon, 12 Jun 2006 09:19:23 -0700 Subject: Buildsys glitch? In-Reply-To: <448D2537.7050701@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> Message-ID: <448D940B.5@gmail.com> The latest nx build has been pushed out to the repo, but we are still seeing the problem because extras caries the last two packages. What is the easiest way to have nx-1.5.0-9 removed from extras? Should I push another build, or is there an easier way? -Rick From paul at city-fan.org Mon Jun 12 16:20:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Jun 2006 17:20:30 +0100 Subject: Buildsys glitch? In-Reply-To: <448D940B.5@gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> <448D940B.5@gmail.com> Message-ID: <448D944E.7000307@city-fan.org> Rick Stout wrote: > The latest nx build has been pushed out to the repo, but we are still > seeing the problem because extras caries the last two packages. What is > the easiest way to have nx-1.5.0-9 removed from extras? Should I push > another build, or is there an easier way? You could submit repo removal requests on the status pages, such as http://fedoraproject.org/wiki/Extras/FC5Status (one per distro version) Paul. From tibbs at math.uh.edu Mon Jun 12 16:46:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 12 Jun 2006 11:46:34 -0500 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <448D782B.3010901@city-fan.org> (Paul Howarth's message of "Mon, 12 Jun 2006 15:20:27 +0100") References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> <448D782B.3010901@city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Is the intention for the Packaging/Lang pages eventually to be PH> editable by the LangSIG members, or for each person to be approved PH> by Spot, or something else? Since these documents set policy for both Core and Extras, it looks like changes need to come from the Packaging Committee. That's currently just spot. I volunteered but as far as I know nobody else has been appointed to the committee. Since as far as I know all of the issues with Ruby packaging have been solved, it would be nice to start moving forward with reviews but at this point we've been asked to wait. We've been asked to wait for PHP module and Mono guidelines as well, and I don't know what to do with Java as there isn't even a page at Packaging/Java. David, my advice would be to submit your proposed changes to spot. If they're large, clone the page somewhere under your personal page, work on it there and show spot the final version. - J< From orion at cora.nwra.com Mon Jun 12 16:49:02 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 12 Jun 2006 10:49:02 -0600 Subject: Buildsys job stuck Message-ID: <448D9AFE.6070604@cora.nwra.com> My build of gdl appears stuck on i386: http://buildsys.fedoraproject.org/build-status/job.psp?uid=10897 Started: Sun Jun 11 17:26:50 2006 i386: hammer2.fedora.redhat.com Status: running/building ppc: ppc1.fedora.redhat.com Status: done/done Build Time: 16 minutes x86_64: hammer1.fedora.redhat.com Status: done/done Build Time: 17 minutes -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From michael at knox.net.nz Mon Jun 12 18:47:26 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 06:47:26 +1200 Subject: rpath joy In-Reply-To: <20060612102859.GB2541@free.fr> References: <448BD19C.1070409@knox.net.nz> <20060611090721.GA2415@free.fr> <448CA554.5030300@knox.net.nz> <20060612102859.GB2541@free.fr> Message-ID: <448DB6BE.5070307@knox.net.nz> Patrice Dumas wrote: > On Mon, Jun 12, 2006 at 11:20:52AM +1200, Michael J. Knox wrote: >> No, I don't have a build.log, I am just builing this in my normal >> rpmbuild root like so"rpmbuild -bi ntop.spec" > >>From which src.rpm? Sorry, its from dag's srpm, used that as a starting point. >> I found a patch from PLD Linux that addresses the problem, the do: >> [snip] >> seems the change from lib_LTLIBRARES to plugin_LIBRARIES fixes it? > > Indeed with plugin_LTLIBRARIES libtool will do the usual install in > the plugin dir, but there should be some changes elsewhere, as previously > there was something installed in the plugin dir - even though not by > libtool? No, that seems to be it, I do run autoreconf after patching and all seems to be well. I will confirm if something was being install outside of libtool when I get the chance :) Thanks! Michael From kevin-fedora-extras at scrye.com Mon Jun 12 21:38:58 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 12 Jun 2006 15:38:58 -0600 (MDT) Subject: AWOL owners and stale packages. References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> Message-ID: <20060612.153858.931257500.kevin@scrye.com> >> How about something like: - When someone sees that a maintainer >> isn't answering their bugs, not answering rebuild requests, emails >> or the like, they file a bug against the package in bugzilla asking >> for the maintainer to respond. This bug should list the outstanding >> issues they need to address. - After every 7 days, the reporter >> adds a comment to the bug asking again for response. Others can add >> to the bug that they also were not successfull in contacting the >> maintainer, or providing additional contact information for the >> maintainer (ie, alternative email, irc, etc). - After 2 attempts (2 >> weeks) of no response from the maintainer, the reporter posts to >> the fedora-extras list with a url to the bug report and asks if >> anyone knows how to contact the maintainer. - After another 7 days >> (now 3 weeks total), the reporter posts to the extras list with the >> bug link and indicates that all attempts to contact the maintainer >> have failed and that they wish to take over the >> package. Additionally we could require the former maintainers >> sponsor to sign off on the change. I think the bug is important to >> be able to track things, and the maintainer should follow email >> from bugzilla for their packages anyhow. Michael> That's exactly how I foresee the process, but probably a 4 Michael> week wait. Yeah, that would be fine I would think too. Michael> I am not sure the reasoning for having the previous sponsor Michael> resign off on the package when it should be required that the Michael> NMU be done onl by existing FE developers. Well, I was thinking about the case with a non packager submitting to take over a package (ie, it's their first package). Thats probibly extra complication and we should just say for now that the person trying to take over maintainership is already an existing maintainer for at least one other package. Do you want to submit this plan to FESCo for approval? We should get something in place soon IMHO. Michael> Michael kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Mon Jun 12 23:12:50 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 12 Jun 2006 16:12:50 -0700 Subject: hammer3 stuck? Message-ID: <448DF4F2.2070208@kobold.org> manaworld (job #10906) has been stuck on hammer3 for 19 hours. Builds on x86_64 and ppc finished after 12 minutes, but the build logs for hammer3/i386 are empty. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From jonathan.underwood at gmail.com Mon Jun 12 23:50:32 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 13 Jun 2006 00:50:32 +0100 Subject: Buildsys glitch? In-Reply-To: <448D940B.5@gmail.com> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> <448D940B.5@gmail.com> Message-ID: <645d17210606121650v1731456dyb63dc883e696de56@mail.gmail.com> On 12/06/06, Rick Stout wrote: > The latest nx build has been pushed out to the repo, but we are still > seeing the problem because extras caries the last two packages. What is > the easiest way to have nx-1.5.0-9 removed from extras? Should I push > another build, or is there an easier way? > Rick, Thanks for sorting this out. In case anyone is wondering, I will push builds for auctex again at the weekend. I am currently on the road. Jonathan From buildsys at fedoraproject.org Tue Jun 13 09:48:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 13 Jun 2006 05:48:07 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-13 Message-ID: <20060613094807.0DF9315217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 11 dnsmasq-2.32-1.fc5 freealut-1.1.0-1.fc5 guichan-0.4.0-2.fc5 ipython-0.7.2-1.fc5 knemo-0.4.1-1.fc5 manaworld-0.0.19-1.fc5 poker-eval-131.0-3.fc5 qt4-qsa-1.2.1-13.fc5 scribes-0.2.5-1.fc5 snort-2.6.0-1.fc5 sylpheed-claws-2.3.0-1.fc5 Packages built and released for Fedora Extras 4: 10 dnsmasq-2.32-1.fc4 freealut-1.1.0-1.fc4 guichan-0.4.0-2.fc4 ipython-0.7.2-1.fc4 knemo-0.4.1-1.fc4 manaworld-0.0.19-1.fc4 perl-XML-Simple-2.14-2.fc4 poker-eval-131.0-3.fc4 snort-2.6.0-1.fc4 sylpheed-claws-2.3.0-1.fc4 Packages built and released for Fedora Extras 3: 5 dnsmasq-2.32-1.fc3 freealut-1.1.0-1.fc3 kipi-plugins-0.1.0-0.10.rc2.fc3.1 perl-XML-Simple-2.14-2.fc3 snort-2.6.0-1.fc3 Packages built and released for Fedora Extras development: 15 cegui-0.4.1-8.fc6 dnsmasq-2.32-1.fc6 freealut-1.1.0-1.fc6 gnokii-0.6.12-5.fc6 ipython-0.7.2-1.fc6 knemo-0.4.1-1.fc6 libopensync-plugin-irmc-0.18-7.fc6 openmpi-1.0.2-1.fc6 perl-Spoon-0.23-4.fc6 poker-eval-131.0-3.fc6 qt4-qsa-1.2.1-13.fc6 rss-glx-0.8.1.p-3.fc6 scribes-0.2.5-1.fc6 snort-2.6.0-2.fc6 sylpheed-claws-2.3.0-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Jun 13 09:48:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 13 Jun 2006 05:48:20 -0400 (EDT) Subject: Broken upgrade paths in Fedora Extras 2006-06-13 Message-ID: <20060613094820.618DB15217C@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 6: 0:2.4.0.3-0.20060328cvs_5.fc6 banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 kdemultimedia-extras: 5: 6:3.5.2-5.fc5 6: 6:3.5.1-8.fc6 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 paraview: 4: 0:2.4.3-7.fc4 5: 0:2.4.3-6.fc5 6: 0:2.4.3-7.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 subversion-api-docs: 5: 0:1.3.2-1.fc5 6: 0:1.3.1-1.fc6 wine-docs: 3: 0:0.9.15-1.fc3 4: 0:0.9.15-0.1.fc4 5: 0:0.9.15-1.fc5 6: 0:0.9.15-1.fc6 From buildsys at fedoraproject.org Tue Jun 13 10:03:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 13 Jun 2006 10:03:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-13 Message-ID: <20060613100314.32073.23967@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.i386 autotrace 0.31.1-12.fc5.i386 dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.i386 gdl 0.9-0.pre.fc6.i386 gtktalog 1.0.4-7.fc5.i386 kismet-extras 0.0.2006.04.R1-2.fc6.i386 koffice-devel 1.5.1-1.fc6.i386 koffice-filters 1.5.1-1.fc6.i386 koffice-karbon 1.5.1-1.fc6.i386 koffice-krita 1.5.1-1.fc6.i386 octave-forge 2006.03.17-4.fc6.i386 showimg-pgsql 0.9.5-5.fc5.i386 syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.ppc autotrace 0.31.1-12.fc5.ppc dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.ppc gdl 0.9-0.pre.fc6.ppc gtktalog 1.0.4-7.fc5.ppc kismet-extras 0.0.2006.04.R1-2.fc6.ppc koffice-devel 1.5.1-1.fc6.ppc koffice-filters 1.5.1-1.fc6.ppc koffice-karbon 1.5.1-1.fc6.ppc koffice-krita 1.5.1-1.fc6.ppc nagios-plugins-sensors 1.4.3-6.fc6.ppc octave-forge 2006.03.17-4.fc6.ppc showimg-pgsql 0.9.5-5.fc5.ppc syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl 0.7008-40.fc5.x86_64 autotrace 0.31.1-12.fc5.x86_64 dejavu-fonts-fontconfig 2.6.0-1.fc6.noarch diradmin 1.7.1-4.fc5.x86_64 gdl 0.9-0.pre.fc6.x86_64 gtktalog 1.0.4-7.fc5.x86_64 kismet-extras 0.0.2006.04.R1-2.fc6.x86_64 koffice-devel 1.5.1-1.fc6.x86_64 koffice-filters 1.5.1-1.fc6.x86_64 koffice-karbon 1.5.1-1.fc6.x86_64 koffice-krita 1.5.1-1.fc6.x86_64 octave-forge 2006.03.17-4.fc6.x86_64 showimg-pgsql 0.9.5-5.fc5.x86_64 syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.1.2 package: octave-forge - 2006.03.17-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 libMagick.so.9 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: koffice-karbon - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-filters - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-i386 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: koffice-devel - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: kismet-extras - 0.0.2006.04.R1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-krita - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: autotrace - 0.31.1-12.fc5.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: gdl - 0.9-0.pre.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gdl - 0.9-0.pre.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: octave-forge - 2006.03.17-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) libMagick.so.9()(64bit) package: koffice-krita - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: koffice-filters - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-karbon - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: autotrace - 0.31.1-12.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: koffice-devel - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.1.2 package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 package: kismet-extras - 0.0.2006.04.R1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: octave-forge - 2006.03.17-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 libMagick.so.9 package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors nagios-plugins = 0:1.4.3-6.fc6 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.1.2 package: gdl - 0.9-0.pre.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so package: koffice-karbon - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: koffice-krita - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch from fedora-extras-development-ppc unresolved deps: dejavu-fonts = 0:2.6.0-1.fc6 package: autotrace - 0.31.1-12.fc5.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: koffice-filters - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 From buildsys at fedoraproject.org Tue Jun 13 10:03:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 13 Jun 2006 10:03:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-13 Message-ID: <20060613100314.32071.95543@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.i386 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php 0.55-7.fc5.ppc Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx 0.5.0-0.3.test7.fc5.noarch syck-php 0.55-7.fc5.x86_64 ====================================================================== package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Tue Jun 13 10:03:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 13 Jun 2006 10:03:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-13 Message-ID: <20060613100314.32069.94116@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- plague 0.4.4.1-1.fc4.noarch ====================================================================== package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: createrepo >= 0:0.4.3 package: plague - 0.4.4.1-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: createrepo >= 0:0.4.3 From buildsys at fedoraproject.org Tue Jun 13 10:03:14 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 13 Jun 2006 10:03:14 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-13 Message-ID: <20060613100314.32060.47637@extras64.linux.duke.edu> Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.i386 plague 0.4.4.1-1.fc3.noarch Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox 0.9.15.1-1.fc3.x86_64 plague 0.4.4.1-1.fc3.noarch ====================================================================== package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-i386 unresolved deps: createrepo >= 0:0.4.3 package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg package: plague - 0.4.4.1-1.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: createrepo >= 0:0.4.3 From pertusus at free.fr Tue Jun 13 10:58:11 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jun 2006 12:58:11 +0200 Subject: rpath joy In-Reply-To: <448DB6BE.5070307@knox.net.nz> References: <448BD19C.1070409@knox.net.nz> <20060611090721.GA2415@free.fr> <448CA554.5030300@knox.net.nz> <20060612102859.GB2541@free.fr> <448DB6BE.5070307@knox.net.nz> Message-ID: <20060613105811.GD2515@free.fr> > No, that seems to be it, I do run autoreconf after patching and all > seems to be well. I have read a bit the Makefile and indeed the plugins were installed by the install-data-local: rule, but since noinst_PROGRAMS and lib_LTLIBRARIES are empty after installing the patch now libtool takes care of all the installation, that's why it is right now. Something I don't understand is whether or not the links and special linking commands in Makefile.am (with darwin specific linker flags) are used, but I'll take a look on your package once you publish it somewhere ;-). -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jun 13 11:03:25 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 13 Jun 2006 20:03:25 +0900 Subject: Buildsys glitch? In-Reply-To: <448D944E.7000307@city-fan.org> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> <448D940B.5@gmail.com> <448D944E.7000307@city-fan.org> Message-ID: <448E9B7D.7070900@ioa.s.u-tokyo.ac.jp> Paul Howarth wrote: > Rick Stout wrote: >> The latest nx build has been pushed out to the repo, but we are still >> seeing the problem because extras caries the last two packages. What is >> the easiest way to have nx-1.5.0-9 removed from extras? Should I push >> another build, or is there an easier way? > > You could submit repo removal requests on the status pages, such as > http://fedoraproject.org/wiki/Extras/FC5Status (one per distro version) > > Paul. > nx-1.5.0-9.fc5 seems to be removed from FE-5, at least on download.fedora.redhat.com according to the request by Rick, thanks. From rc040203 at freenet.de Tue Jun 13 11:07:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 13:07:55 +0200 Subject: Buildsys glitch? In-Reply-To: <448E9B7D.7070900@ioa.s.u-tokyo.ac.jp> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> <448D940B.5@gmail.com> <448D944E.7000307@city-fan.org> <448E9B7D.7070900@ioa.s.u-tokyo.ac.jp> Message-ID: <1150196875.30155.137.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 20:03 +0900, Mamoru Tasaka wrote: > Paul Howarth wrote: > > Rick Stout wrote: > >> The latest nx build has been pushed out to the repo, but we are still > >> seeing the problem because extras caries the last two packages. What is > >> the easiest way to have nx-1.5.0-9 removed from extras? Should I push > >> another build, or is there an easier way? > > > > You could submit repo removal requests on the status pages, such as > > http://fedoraproject.org/wiki/Extras/FC5Status (one per distro version) > > > > Paul. > > > nx-1.5.0-9.fc5 seems to be removed from FE-5, at least on download.fedora.redhat.com > according to the request by Rick, thanks. It still contains a Provides: # rpm -q --provides \ -p nx-1.5.0-10.fc5.i386.rpm libXcomp.so.1 libXcompext.so.1 nx = 1.5.0-10.fc5 The libXcomp*.so.1's seem to be wrong to me. These currently don't do any harm, because they don't conflict with other shared libs, nevertheless, I don't think they are correct. Ralf From pertusus at free.fr Tue Jun 13 14:25:38 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jun 2006 16:25:38 +0200 Subject: anybody wanting to have a look at fcron review? Message-ID: <20060613142537.GG2515@free.fr> Hello all, In my opinion fcron could be approved now. It is submitted here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185531 assigned to myself. For me it is in shape for inclusion in extras, but if somebody wants to have a look, I will let one week for other reviewers to have a look. It includes setuid/setgid programs, so there are potential security risks. Maybe it could replace cron/anacron in core, so it may be better if it is rightly reviewed. -- Pat From rdieter at math.unl.edu Tue Jun 13 15:10:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jun 2006 10:10:58 -0500 Subject: rpms/knemo/devel knemo.spec,1.2,1.3 References: <200606131441.k5DEfHxM014598@cvs-int.fedora.redhat.com> Message-ID: Hugo Cisneiros (eitch) wrote: > Author: eitch > > Update of /cvs/extras/rpms/knemo/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14581 > > Modified Files: > knemo.spec > Log Message: > * Tue Jun 13 2006 Hugo Cisneiros > - ifconfig and > iwconfig are now in Requires section instead > of BuildRequires. They are runtime dependencies. Thanks to > Kevin Kofler for pointing this. They should be *both* BuildRequires and Requires. knemo checks for them at build-time as well. -- Rex From mmcgrath at fedoraproject.org Tue Jun 13 15:45:34 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 13 Jun 2006 10:45:34 -0500 Subject: hammer3 stuck? In-Reply-To: <448DF4F2.2070208@kobold.org> References: <448DF4F2.2070208@kobold.org> Message-ID: <448EDD9E.6060309@fedoraproject.org> Michael Thomas wrote: > manaworld (job #10906) has been stuck on hammer3 for 19 hours. Builds > on x86_64 and ppc finished after 12 minutes, but the build logs for > hammer3/i386 are empty. > > --Mike > For some of these don't forget about the ticketing system: https://admin.fedoraproject.org/tickets/ -Mike From tibbs at math.uh.edu Tue Jun 13 16:00:48 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 13 Jun 2006 11:00:48 -0500 Subject: anybody wanting to have a look at fcron review? In-Reply-To: <20060613142537.GG2515@free.fr> (Patrice Dumas's message of "Tue, 13 Jun 2006 16:25:38 +0200") References: <20060613142537.GG2515@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> It includes setuid/setgid programs, so there are potential PD> security risks. Maybe it could replace cron/anacron in core, so it PD> may be better if it is rightly reviewed. I take it the two CVEs from February are fixed in the packaged version? http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-0575 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-0539 - J< From pertusus at free.fr Tue Jun 13 16:19:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jun 2006 18:19:21 +0200 Subject: anybody wanting to have a look at fcron review? In-Reply-To: References: <20060613142537.GG2515@free.fr> Message-ID: <20060613161920.GH2515@free.fr> > I take it the two CVEs from February are fixed in the packaged > version? > > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-0575 > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-0539 Yes, at least it is what is said upstream about those issues. Moreover the vulnerable program, convert-fcrontab isn't shipped in the package submitted to fedora extras, so it is not vulnerable. -- Pat From mclasen at redhat.com Tue Jun 13 16:48:06 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Jun 2006 12:48:06 -0400 Subject: Packages up for adoption Message-ID: <1150217286.15532.26.camel@golem.boston.redhat.com> We plan to drop the standalone gdk-pixbuf and imlib packages from Core before FC6, together with the rest of the Gnome 1 stack. There are probably some things in Extras that still require these, therefore I put slightly cleaned up spec files and srpms up here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 If anybody feels like maintaining these in Extras, please step up. Matthias From rdieter at math.unl.edu Tue Jun 13 17:33:03 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jun 2006 12:33:03 -0500 Subject: hammer3 stuck? References: <448DF4F2.2070208@kobold.org> <448EDD9E.6060309@fedoraproject.org> Message-ID: Mike McGrath wrote: > Michael Thomas wrote: >> manaworld (job #10906) has been stuck on hammer3 for 19 hours. Builds >> on x86_64 and ppc finished after 12 minutes, but the build logs for >> hammer3/i386 are empty. > For some of these don't forget about the ticketing system: > https://admin.fedoraproject.org/tickets/ submitted, ticket #2006061310000024 "i386 builders wedged a bit(?)" -- Rex From wtogami at redhat.com Tue Jun 13 17:51:04 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Jun 2006 13:51:04 -0400 Subject: Stuck Build Jobs Message-ID: <448EFB08.5020804@redhat.com> I'm attempting to dig into the cause of the stuck Extras build jobs. It appears that most of the problems are sed deadlocking during i386 FC6 builds. Trying to dig deeper into possible causes. Warren From zipsonic at gmail.com Tue Jun 13 18:07:51 2006 From: zipsonic at gmail.com (Rick Stout) Date: Tue, 13 Jun 2006 11:07:51 -0700 Subject: Buildsys glitch? In-Reply-To: <1150196875.30155.137.camel@mccallum.corsepiu.local> References: <645d17210606100552x2850ef5dy224a88bf9d76b90f@mail.gmail.com> <1149991578.12112.183.camel@mccallum.corsepiu.local> <448D2537.7050701@ioa.s.u-tokyo.ac.jp> <448D940B.5@gmail.com> <448D944E.7000307@city-fan.org> <448E9B7D.7070900@ioa.s.u-tokyo.ac.jp> <1150196875.30155.137.camel@mccallum.corsepiu.local> Message-ID: <448EFEF7.7030805@gmail.com> > It still contains a Provides: > > # rpm -q --provides \ > -p nx-1.5.0-10.fc5.i386.rpm > libXcomp.so.1 > libXcompext.so.1 > nx = 1.5.0-10.fc5 > > The libXcomp*.so.1's seem to be wrong to me. These currently don't do > any harm, because they don't conflict with other shared libs, > nevertheless, I don't think they are correct. > > Ralf This is correct, and will actually be used in the future (In progress GPL'd client). There will be *no other package* that will provide these libraries as they were designed and built specifically for this application, hence, it provides those libraries. Rick From wtogami at redhat.com Tue Jun 13 18:15:44 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Jun 2006 14:15:44 -0400 Subject: Stuck Build Jobs In-Reply-To: <448EFB08.5020804@redhat.com> References: <448EFB08.5020804@redhat.com> Message-ID: <448F00D0.8050905@redhat.com> Warren Togami wrote: > I'm attempting to dig into the cause of the stuck Extras build jobs. It > appears that most of the problems are sed deadlocking during i386 FC6 > builds. Trying to dig deeper into possible causes. > OK, it seems that stuck jobs are either sed or g++ on i386 FC6 only. sed is always stuck on a waitpaid() g++ is stuck like this: [ Process PID=5163 runs in 32 bit mode. ] futex(0x556a5c60, FUTEX_WAIT, 2, ptrace: umoven: Input/output error {...} I'm requeing builds and watching them from scratch now... Warren From wtogami at redhat.com Tue Jun 13 19:01:35 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Jun 2006 15:01:35 -0400 Subject: Stuck Build Jobs In-Reply-To: <448F00D0.8050905@redhat.com> References: <448EFB08.5020804@redhat.com> <448F00D0.8050905@redhat.com> Message-ID: <448F0B8F.3080306@redhat.com> Running 32bit strace within the chroot gives something different for g++. futex(0x556a5c60, FUTEX_WAIT, 2, NULL g++ backtrace from within buildroot... #0 0xffffe405 in __kernel_vsyscall () #1 0x5564abee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x555a0ccd in _L_lock_15 () from /lib/libc.so.6 #3 0x555a0b7f in __new_exitfn () from /lib/libc.so.6 #4 0x555a0c95 in __cxa_atexit_internal () from /lib/libc.so.6 #5 0x5558b706 in __libc_start_main () from /lib/libc.so.6 #6 0x08049591 in ?? () After I install debuginfo... (gdb) bt #0 0xffffe405 in __kernel_vsyscall () #1 0x5564abee in ?? () from /lib/libc.so.6 #2 0x555a0ccd in ?? () from /lib/libc.so.6 Previous frame identical to this frame (corrupt stack?) Um... Warren From michael at knox.net.nz Tue Jun 13 19:32:33 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 14 Jun 2006 07:32:33 +1200 (NZST) Subject: Packages up for adoption In-Reply-To: <1150217286.15532.26.camel@golem.boston.redhat.com> References: <1150217286.15532.26.camel@golem.boston.redhat.com> Message-ID: <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> Matthias Clasen wrote: > We plan to drop the standalone gdk-pixbuf and imlib packages from Core > before FC6, together with the rest of the Gnome 1 stack. > > There are probably some things in Extras that still require these, > therefore I put slightly cleaned up spec files and srpms up here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 > > If anybody feels like maintaining these in Extras, please step up. I don't know if these have been claimed yet, but I will take them on, bugzilla seems to be tossing up errors, so I can't check the reports. Michael From mclasen at redhat.com Tue Jun 13 19:45:47 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Jun 2006 15:45:47 -0400 Subject: Packages up for adoption In-Reply-To: <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> Message-ID: <1150227947.15532.29.camel@golem.boston.redhat.com> On Wed, 2006-06-14 at 07:32 +1200, Michael J. Knox wrote: > Matthias Clasen wrote: > > We plan to drop the standalone gdk-pixbuf and imlib packages from Core > > before FC6, together with the rest of the Gnome 1 stack. > > > > There are probably some things in Extras that still require these, > > therefore I put slightly cleaned up spec files and srpms up here: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 > > > > If anybody feels like maintaining these in Extras, please step up. > > I don't know if these have been claimed yet, but I will take them on, > bugzilla seems to be tossing up errors, so I can't check the reports. > > Michael > Thats great, thanks. Bugzilla is down atm. From fedora at stefan-neufeind.de Tue Jun 13 22:00:30 2006 From: fedora at stefan-neufeind.de (Stefan Neufeind) Date: Wed, 14 Jun 2006 00:00:30 +0200 Subject: knetworkmanager In-Reply-To: References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> <1148897232.4310.806.camel@sundaram.pnq.redhat.com> <200605290857.33486.dennis@ausil.us> Message-ID: <448F357E.2020006@stefan-neufeind.de> Rex Dieter wrote: > Dennis Gilmore wrote: > >> On Monday 29 May 2006 5:07 am, Rahul Sundaram wrote: >>> On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: >>>> I was wondering if there were any current plans to include >>>> knetworkmanager in extras. If not, then I'd like to request that it >>>> be. I'm sure I'm not the only one who's been waiting for a way to use >>>> NetworkManager with KDE. >>> I havent seen any submissions. Would you like to get involved in >>> packaging it? >>> http://fedoraproject.org/wiki/Extras > >> Ive started work on packaging it. Im using it currently. I need to finish >> my review of the dbus-qt bindings and then submit for review. > > FYI, Dennis' review is complete, so dbus-qt (and dbus-qt-devel) are now > available from Extras. Any news on knetworkmanager, any betas? I'm really looking forward to try something, if RPMs are available for testing :-) Regards, Stefan From buildsys at fedoraproject.org Wed Jun 14 12:29:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Jun 2006 08:29:06 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-14 Message-ID: <20060614122906.2AEE915217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 10 git-1.4.0-1.fc5 knemo-0.4.1-2.fc5 libmthca-1.0.2-1.fc5 nucleo-0.5-7.fc5 openalpp-20060405-8.fc5 osgal-20060410-3.fc5 poker-engine-1.0.15-3.fc5 python-sqlite2-2.3.0-1.fc5 qucs-0.0.9-3.fc5 serpentine-0.7-1.fc5 Packages built and released for Fedora Extras 4: 7 git-1.4.0-1.fc4 knemo-0.4.1-2.fc4 libmthca-1.0.2-1.fc4 nucleo-0.5-7.fc4 openalpp-20060405-8.fc4 poker-engine-1.0.15-3.fc4 qucs-0.0.9-3.fc4 Packages built and released for Fedora Extras 3: 2 git-1.4.0-1.fc3 qucs-0.0.9-3.fc3 Packages built and released for Fedora Extras development: 11 git-1.4.0-1.fc6 kdemultimedia-extras-3.5.2-5.fc6 knemo-0.4.1-2.fc6 libmthca-1.0.2-1.fc6 nucleo-0.5-7.fc6 openalpp-20060405-8.fc6 python-sqlite2-2.3.0-1.fc6 q-7.1-2.fc6 qucs-0.0.9-3.fc6 serpentine-0.7-1.fc6 x3270-3.3.4p7-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Jun 14 12:29:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Jun 2006 08:29:19 -0400 (EDT) Subject: Broken upgrade paths in Fedora Extras 2006-06-14 Message-ID: <20060614122919.2791A15217B@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 6: 0:2.4.0.3-0.20060328cvs_5.fc6 banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 paraview: 4: 0:2.4.3-7.fc4 5: 0:2.4.3-6.fc5 6: 0:2.4.3-7.fc6 poker-engine: 5: 0:1.0.15-3.fc5 6: 0:1.0.15-2.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 subversion-api-docs: 5: 0:1.3.2-1.fc5 6: 0:1.3.1-1.fc6 wine-docs: 3: 0:0.9.15-1.fc3 4: 0:0.9.15-0.1.fc4 5: 0:0.9.15-1.fc5 6: 0:0.9.15-1.fc6 From buildsys at fedoraproject.org Wed Jun 14 13:02:15 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 14 Jun 2006 13:02:15 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-14 Message-ID: <20060614130215.6251.12745@extras64.linux.duke.edu> ERROR: dbus-qt not in owners.list ERROR: source rpm is dbus-qt-0.61-3.fc6.src.rpm ERROR: dbus-qt not in owners.list ERROR: source rpm is dbus-qt-0.61-3.fc6.src.rpm ERROR: dbus-qt not in owners.list ERROR: source rpm is dbus-qt-0.61-3.fc6.src.rpm Summary of broken packages (by owner): ---------------------------------------------------------------------- UNKNOWN OWNER dbus-qt - 0.61-3.fc6.i386 dbus-qt - 0.61-3.fc6.ppc dbus-qt - 0.61-3.fc6.x86_64 andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 gauret AT free.fr showimg-pgsql - 0.9.5-5.fc5.i386 showimg-pgsql - 0.9.5-5.fc5.ppc showimg-pgsql - 0.9.5-5.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 nicolas.mailhot AT laposte.net dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 roozbeh AT farsiweb.info autotrace - 0.31.1-12.fc5.i386 autotrace - 0.31.1-12.fc5.ppc autotrace - 0.31.1-12.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 autotrace-0.31.1-12.fc5.i386 requires libMagick.so.9 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 dbus-qt-0.61-3.fc6.i386 requires dbus = 0:0.61 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 showimg-pgsql-0.9.5-5.fc5.i386 requires libpqxx-2.5.5.so syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 autotrace-0.31.1-12.fc5.ppc requires libMagick.so.9 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 dbus-qt-0.61-3.fc6.ppc requires dbus = 0:0.61 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 showimg-pgsql-0.9.5-5.fc5.ppc requires libpqxx-2.5.5.so syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) autotrace-0.31.1-12.fc5.x86_64 requires libMagick.so.9()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) dbus-qt-0.61-3.fc6.x86_64 requires dbus = 0:0.61 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) showimg-pgsql-0.9.5-5.fc5.x86_64 requires libpqxx-2.5.5.so()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: gauret AT free.fr package: showimg-pgsql - 0.9.5-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libpqxx-2.5.5.so package: showimg-pgsql - 0.9.5-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpqxx-2.5.5.so()(64bit) package: showimg-pgsql - 0.9.5-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libpqxx-2.5.5.so ====================================================================== New report for: caillon AT redhat.com package: banshee - 0.10.8-1.i386 from fedora-extras-development-i386 unresolved deps: libnautilus-burn.so.3 package: banshee - 0.10.8-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnautilus-burn.so.3()(64bit) package: banshee - 0.10.8-1.ppc from fedora-extras-development-ppc unresolved deps: libnautilus-burn.so.3 ====================================================================== New report for: UNKNOWN OWNER package: dbus-qt - 0.61-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: dbus = 0:0.61 package: dbus-qt - 0.61-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: dbus = 0:0.61 package: dbus-qt - 0.61-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: dbus = 0:0.61 ====================================================================== New report for: matthias AT rpmforge.net package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Wed Jun 14 14:00:08 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 14 Jun 2006 14:00:08 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-14 Message-ID: <20060614140008.7679.29018@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Wed Jun 14 14:02:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 14 Jun 2006 14:02:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-14 Message-ID: <20060614140249.7902.40682@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From paul at all-the-johnsons.co.uk Wed Jun 14 15:04:23 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 14 Jun 2006 16:04:23 +0100 Subject: Some of my BZ packages have gone walkies! Message-ID: <1150297463.2678.55.camel@mrwibble.mrwobble> Hi, I seem to have a case of the vanishing BZ package requests! I think I'm down by 4 packages (though I'll need to check my log at home). Did something happen and I've not noticed? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Wed Jun 14 15:06:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 14 Jun 2006 16:06:07 +0100 Subject: Some of my BZ packages have gone walkies! In-Reply-To: <1150297463.2678.55.camel@mrwibble.mrwobble> References: <1150297463.2678.55.camel@mrwibble.mrwobble> Message-ID: <449025DF.6070909@city-fan.org> PFJ wrote: > Hi, > > I seem to have a case of the vanishing BZ package requests! I think I'm > down by 4 packages (though I'll need to check my log at home). > > Did something happen and I've not noticed? Did you not see the announcement at the top of every page you get from bugzilla today? Paul. From dan at danny.cz Wed Jun 14 15:20:29 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 14 Jun 2006 17:20:29 +0200 Subject: Some of my BZ packages have gone walkies! In-Reply-To: <449025DF.6070909@city-fan.org> References: <1150297463.2678.55.camel@mrwibble.mrwobble> <449025DF.6070909@city-fan.org> Message-ID: <1150298429.3499.4.camel@eagle.danny.cz> Paul Howarth p??e v St 14. 06. 2006 v 16:06 +0100: > PFJ wrote: > > Hi, > > > > I seem to have a case of the vanishing BZ package requests! I think I'm > > down by 4 packages (though I'll need to check my log at home). > > > > Did something happen and I've not noticed? > > Did you not see the announcement at the top of every page you get from > bugzilla today? The letters are very small and quite easy to miss especially when you look at the latest comments ;-) Dan From pertusus at free.fr Wed Jun 14 16:48:48 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Jun 2006 18:48:48 +0200 Subject: fstab-sync for xfce replacement package Message-ID: <20060614164848.GA20053@free.fr> Hello, I use xfce in FC5, but I miss fstab-sync from FC4. Is there an xfce package (thunar?) that needs to be packaged (maybe in devel) to have a similar functionnality (gnome-mount isn't a proper replacement for fstab-sync, as may be seen in the bug reports)? -- Pat From kevin-fedora-extras at scrye.com Wed Jun 14 16:56:52 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 14 Jun 2006 10:56:52 -0600 (MDT) Subject: fstab-sync for xfce replacement package References: <20060614164848.GA20053@free.fr> Message-ID: <20060614.105652.515898614.kevin@scrye.com> >>>>> "Patrice" == Patrice Dumas writes: Patrice> Hello, I use xfce in FC5, but I miss fstab-sync from FC4. Is Patrice> there an xfce package (thunar?) that needs to be packaged Patrice> (maybe in devel) to have a similar functionnality Patrice> (gnome-mount isn't a proper replacement for fstab-sync, as Patrice> may be seen in the bug reports)? I am working on a thunar package (which will be the default graphical file manager for Xfce 4.4 when it's released), but I haven't had time to go too far on it. If you would like to package it up, feel free... ;) Note that thunar is in beta still until 4.4 comes out, so I don't think it should be shipped until 4.4 is released. Patrice> -- Pat kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From packages at amiga-hardware.com Wed Jun 14 17:16:36 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Wed, 14 Jun 2006 18:16:36 +0100 Subject: build system issue Message-ID: <44904474.6030503@amiga-hardware.com> Hi, I'm currently trying to build the package cegui, which succeeds for devel, but fails on fc4 and fc5. cegui depends on tolua++-devel, which in turn depends on lua-devel. The problem is, that mock is installing an older version of lua (5.1-5) which provides lua-devel in the main package, even though lua-devel was provided as a seperate RPM. This problem was fixed in version lua 5.1-6 which has been available for about a week. Buildlogs: http://buildsys.fedoraproject.org/logs/fedora-4-extras/10942-cegui-0.4.1-8.fc4/x86_64/ http://buildsys.fedoraproject.org/logs/fedora-5-extras/10943-cegui-0.4.1-8.fc5/i386/ Question is, what's the best way to deal with this? -- Ian Chapman. From cweyl at alumni.drew.edu Wed Jun 14 17:59:01 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 14 Jun 2006 10:59:01 -0700 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> <448D782B.3010901@city-fan.org> Message-ID: <7dd7ab490606141059p563233afo431420aca108b317@mail.gmail.com> On 6/12/06, Jason L Tibbitts III wrote: > >>>>> "PH" == Paul Howarth writes: > > PH> Is the intention for the Packaging/Lang pages eventually to be > PH> editable by the LangSIG members, or for each person to be approved > PH> by Spot, or something else? > > Since these documents set policy for both Core and Extras, it looks > like changes need to come from the Packaging Committee. That's > currently just spot. I volunteered but as far as I know nobody else > has been appointed to the committee. So does this mean that the Packaging/Lang pages are actually part of the packaging policy?! I thought only Packaging/Guidelines was actual "policy", the /Lang pages were places to put tricks/tips/etc. Was I wrong with that assessment? If so, where should we put stuff like that? -Chris -- Chris Weyl Ex astris, scientia From tibbs at math.uh.edu Wed Jun 14 18:07:44 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 14 Jun 2006 13:07:44 -0500 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: <7dd7ab490606141059p563233afo431420aca108b317@mail.gmail.com> (Chris Weyl's message of "Wed, 14 Jun 2006 10:59:01 -0700") References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> <448D782B.3010901@city-fan.org> <7dd7ab490606141059p563233afo431420aca108b317@mail.gmail.com> Message-ID: >>>>> "CW" == Chris Weyl writes: CW> So does this mean that the Packaging/Lang pages are actually part CW> of the packaging policy?! Yes. This is why, for example, we're not approving PHP, Ruby or Mono packages at the moment: the guidelines aren't finalized. CW> If so, where should we put stuff like that? I don't think that's been decided. Probably in a subpage like Packaging/Ruby/Tips which would be made mutable. The packaging committee is forming at the moment; hopefully it won't be long before a few things are finalized. - J< From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jun 14 18:08:35 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 15 Jun 2006 03:08:35 +0900 Subject: build system issue In-Reply-To: <44904474.6030503@amiga-hardware.com> References: <44904474.6030503@amiga-hardware.com> Message-ID: <449050A3.8090101@ioa.s.u-tokyo.ac.jp> Ian Chapman wrote: > Hi, > The problem is, that mock is installing an > older version of lua (5.1-5) which provides lua-devel in the main > package, even though lua-devel was provided as a seperate RPM. This > problem was fixed in version lua 5.1-6 which has been available for > about a week. > > Question is, what's the best way to deal with this? > The simplest workaround is to add the BuildRequires: lua-devel >= 5.1-6. Another way is to ask for the maintainer of lua to request buildsys to remove the version 5.1-5 of lua by using http://fedoraproject.org/wiki/Extras/FC5Status (see https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00570.html ). From tibbs at math.uh.edu Wed Jun 14 18:13:44 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 14 Jun 2006 13:13:44 -0500 Subject: build system issue In-Reply-To: <44904474.6030503@amiga-hardware.com> (Ian Chapman's message of "Wed, 14 Jun 2006 18:16:36 +0100") References: <44904474.6030503@amiga-hardware.com> Message-ID: >>>>> "IC" == Ian Chapman writes: IC> The problem is, that mock is installing an older version of lua IC> (5.1-5) which provides lua-devel in the main package, even though IC> lua-devel was provided as a seperate RPM. If two packages provide the same thing, yum will install the one with the shortest name. Since the old lua package is still in the repository and is still providing the symbol, yum will still install it. IC> Question is, what's the best way to deal with this? Get the old package removed from the repository. The maintainer should edit Extras/FC5Status and request the deletion (or find a helpful admin on IRC, I suppose). I wouldn't recommend it, but the lua maintainer could just bump the release and push a new package; only two versions are kept, so this would push out the old version. - J< From cweyl at alumni.drew.edu Wed Jun 14 18:18:10 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 14 Jun 2006 11:18:10 -0700 Subject: http://www.fedoraproject.org/wiki/Packaging/Ruby immutable In-Reply-To: References: <1150118725.22268.2.camel@localhost.localdomain> <1150119106.8514.0.camel@cutter> <448D744D.2040202@city-fan.org> <1150121359.8514.2.camel@cutter> <448D76CA.3060503@city-fan.org> <1150121997.8514.6.camel@cutter> <448D782B.3010901@city-fan.org> <7dd7ab490606141059p563233afo431420aca108b317@mail.gmail.com> Message-ID: <7dd7ab490606141118oafa9dcdo8fb219420aa05459@mail.gmail.com> On 6/14/06, Jason L Tibbitts III wrote: > >>>>> "CW" == Chris Weyl writes: > > CW> So does this mean that the Packaging/Lang pages are actually part > CW> of the packaging policy?! > > Yes. This is why, for example, we're not approving PHP, Ruby or Mono > packages at the moment: the guidelines aren't finalized. Ah, gotcha. I wasn't aware of that. > CW> If so, where should we put stuff like that? > > I don't think that's been decided. Probably in a subpage like > Packaging/Ruby/Tips which would be made mutable. My $0.02: how about in a PackagingTips/ namespace? It wouldn't require the tips pages to be de-acl'ed then. > The packaging committee is forming at the moment; hopefully it won't > be long before a few things are finalized. Excellent. -Chris -- Chris Weyl Ex astris, scientia From bugs.michael at gmx.net Wed Jun 14 18:25:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 14 Jun 2006 20:25:55 +0200 Subject: build system issue In-Reply-To: <44904474.6030503@amiga-hardware.com> References: <44904474.6030503@amiga-hardware.com> Message-ID: <20060614202555.3cd82dda.bugs.michael@gmx.net> On Wed, 14 Jun 2006 18:16:36 +0100, Ian Chapman wrote: > Hi, > > I'm currently trying to build the package cegui, which succeeds for > devel, but fails on fc4 and fc5. cegui depends on tolua++-devel, which > in turn depends on lua-devel. The problem is, that mock is installing an > older version of lua (5.1-5) which provides lua-devel in the main > package, even though lua-devel was provided as a seperate RPM. This > problem was fixed in version lua 5.1-6 which has been available for > about a week. > > Buildlogs: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/10942-cegui-0.4.1-8.fc4/x86_64/ > http://buildsys.fedoraproject.org/logs/fedora-5-extras/10943-cegui-0.4.1-8.fc5/i386/ > > Question is, what's the best way to deal with this? [...] --> Running transaction check --> Processing Dependency: libtolua++-5.1.so for package: tolua++-devel --> Processing Dependency: lua-devel >= 5.1 for package: tolua++-devel --> Processing Dependency: tolua++ = 1.0.92-3.fc5 for package: tolua++-devel --> Processing Dependency: liblua-5.1.so for package: tolua++-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. It's Yum's very own way of picking a package which satisfies these requirements "lua-devel >= 5.1 and liblua-5.1.so", $ repoquery --whatprovides liblua-5.1.so lua-0:5.1-6.fc5.i386 lua-0:5.1-5.fc5.i386 (!) $ repoquery --whatprovides lua-devel lua-devel-0:5.1-6.fc5.i386 lua-0:5.1-5.fc5.i386 (!) lua-devel-0:5.1-5.fc5.i386 instead of picking the really latest packages, which you would get after another "yum update". There are other (related) cases like this, e.g. failure to notice obsolete sub-packages: http://bugzilla.redhat.com/190116 Most convenient work-around is to get rid of the old lua in the repository. You would submit such a request via the Wiki. See the Repository Status pages in the middle of: http://fedoraproject.org/wiki/Extras From mclasen at redhat.com Wed Jun 14 18:36:51 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Jun 2006 14:36:51 -0400 Subject: Packages up for adoption In-Reply-To: <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> Message-ID: <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> On Wed, 2006-06-14 at 07:32 +1200, Michael J. Knox wrote: > Matthias Clasen wrote: > > We plan to drop the standalone gdk-pixbuf and imlib packages from Core > > before FC6, together with the rest of the Gnome 1 stack. > > > > There are probably some things in Extras that still require these, > > therefore I put slightly cleaned up spec files and srpms up here: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 > > > > If anybody feels like maintaining these in Extras, please step up. > > I don't know if these have been claimed yet, but I will take them on, > bugzilla seems to be tossing up errors, so I can't check the reports. > Bugzilla is back up; oh, and imlib and gdk-pixbuf are being whacked from Core for test1, so feel free to get them into Extras. Matthias From michael at knox.net.nz Wed Jun 14 19:10:58 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 15 Jun 2006 07:10:58 +1200 Subject: Packages up for adoption In-Reply-To: <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> Message-ID: <44905F42.9040704@knox.net.nz> Matthias Clasen wrote: > On Wed, 2006-06-14 at 07:32 +1200, Michael J. Knox wrote: > >>Matthias Clasen wrote: >> >>>We plan to drop the standalone gdk-pixbuf and imlib packages from Core >>>before FC6, together with the rest of the Gnome 1 stack. >>> >>>There are probably some things in Extras that still require these, >>>therefore I put slightly cleaned up spec files and srpms up here: >>> >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 >>> >>>If anybody feels like maintaining these in Extras, please step up. >> >>I don't know if these have been claimed yet, but I will take them on, >>bugzilla seems to be tossing up errors, so I can't check the reports. >> > > > Bugzilla is back up; oh, and imlib and gdk-pixbuf are being whacked from > Core for test1, so feel free to get them into Extras. Cool, thanks. My next question is, do these need a full review for inclusion in extras? Michael From mclasen at redhat.com Wed Jun 14 19:17:19 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Jun 2006 15:17:19 -0400 Subject: Packages up for adoption In-Reply-To: <44905F42.9040704@knox.net.nz> References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> <44905F42.9040704@knox.net.nz> Message-ID: <1150312640.3304.6.camel@dhcp83-98.boston.redhat.com> On Thu, 2006-06-15 at 07:10 +1200, Michael J. Knox wrote: > Matthias Clasen wrote: > > On Wed, 2006-06-14 at 07:32 +1200, Michael J. Knox wrote: > > > >>Matthias Clasen wrote: > >> > >>>We plan to drop the standalone gdk-pixbuf and imlib packages from Core > >>>before FC6, together with the rest of the Gnome 1 stack. > >>> > >>>There are probably some things in Extras that still require these, > >>>therefore I put slightly cleaned up spec files and srpms up here: > >>> > >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 > >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 > >>> > >>>If anybody feels like maintaining these in Extras, please step up. > >> > >>I don't know if these have been claimed yet, but I will take them on, > >>bugzilla seems to be tossing up errors, so I can't check the reports. > >> > > > > > > Bugzilla is back up; oh, and imlib and gdk-pixbuf are being whacked from > > Core for test1, so feel free to get them into Extras. > > Cool, thanks. > > My next question is, do these need a full review for inclusion in extras? Jesse already gave it a look, and the spec files in the bugs include his feedback. Don't know if thats formal enough... From tibbs at math.uh.edu Wed Jun 14 19:32:56 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 14 Jun 2006 14:32:56 -0500 Subject: Packages up for adoption In-Reply-To: <44905F42.9040704@knox.net.nz> (Michael J. Knox's message of "Thu, 15 Jun 2006 07:10:58 +1200") References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> <44905F42.9040704@knox.net.nz> Message-ID: >>>>> "MJK" == Michael J Knox writes: MJK> My next question is, do these need a full review for inclusion in MJK> extras? They need the same review that any other package coming into extras (or core, for that matter) would get. - J< From michael at knox.net.nz Wed Jun 14 19:36:59 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 15 Jun 2006 07:36:59 +1200 Subject: Packages up for adoption In-Reply-To: References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> <44905F42.9040704@knox.net.nz> Message-ID: <4490655B.9020908@knox.net.nz> Jason L Tibbitts III wrote: >>>>>>"MJK" == Michael J Knox writes: > > > MJK> My next question is, do these need a full review for inclusion in > MJK> extras? > > They need the same review that any other package coming into extras > (or core, for that matter) would get. Ok, cool... Could someone be kind enough to do a review? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194353 Michael From michael at knox.net.nz Wed Jun 14 20:01:58 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 15 Jun 2006 08:01:58 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <20060612.153858.931257500.kevin@scrye.com> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> Message-ID: <44906B36.7030207@knox.net.nz> Kevin Fenzi wrote: >>>How about something like: - When someone sees that a maintainer >>>isn't answering their bugs, not answering rebuild requests, emails >>>or the like, they file a bug against the package in bugzilla asking >>>for the maintainer to respond. This bug should list the outstanding >>>issues they need to address. - After every 7 days, the reporter >>>adds a comment to the bug asking again for response. Others can add >>>to the bug that they also were not successfull in contacting the >>>maintainer, or providing additional contact information for the >>>maintainer (ie, alternative email, irc, etc). - After 2 attempts (2 >>>weeks) of no response from the maintainer, the reporter posts to >>>the fedora-extras list with a url to the bug report and asks if >>>anyone knows how to contact the maintainer. - After another 7 days >>>(now 3 weeks total), the reporter posts to the extras list with the >>>bug link and indicates that all attempts to contact the maintainer >>>have failed and that they wish to take over the >>>package. Additionally we could require the former maintainers >>>sponsor to sign off on the change. I think the bug is important to >>>be able to track things, and the maintainer should follow email >>>from bugzilla for their packages anyhow. > > > Michael> That's exactly how I foresee the process, but probably a 4 > Michael> week wait. > > Yeah, that would be fine I would think too. > > Michael> I am not sure the reasoning for having the previous sponsor > Michael> resign off on the package when it should be required that the > Michael> NMU be done onl by existing FE developers. > > Well, I was thinking about the case with a non packager submitting to > take over a package (ie, it's their first package). Thats probibly > extra complication and we should just say for now that the person > trying to take over maintainership is already an existing maintainer > for at least one other package. > > Do you want to submit this plan to FESCo for approval? > We should get something in place soon IMHO. Hello Kevin, Yeah, I will draft it and send it too the FESCo guys too mull over. Michael From Matt_Domsch at dell.com Wed Jun 14 20:10:37 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 14 Jun 2006 15:10:37 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-14 Message-ID: <20060614201037.GD23704@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Wed Jun 14 15:06:16 CDT 2006 Number failed to build: 173 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 162 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 158 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya gauret at free.fr argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtk+ rdieter at math.unl.edu gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org mftrace qspencer at ieee.org mhonarc gauret at free.fr mod_suphp andreas at bawue.net multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org paps tagoh at redhat.com perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-extras dmitry at butskoy.name php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd gauret at free.fr pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed Jun 14 20:11:11 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 14 Jun 2006 15:11:11 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-14 Message-ID: <20060614201111.GE23704@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Wed Jun 14 15:06:45 CDT 2006 Number failed to build: 155 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 154 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 150 ---------------------------------- abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya gauret at free.fr argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libmthca rolandd at cisco.com libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com mftrace qspencer at ieee.org multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org paps tagoh at redhat.com php-extras dmitry at butskoy.name pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd gauret at free.fr pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 jeff at ocjtech.us Wed Jun 14 20:26:42 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 14 Jun 2006 15:26:42 -0500 Subject: Chicken & Egg Problem with FC4 "Minimal" Buildroot Message-ID: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> This afternoon I was packaging a new Python module for potential inclusion in Extras. The package builds correctly in a "standard" mock FC4 buildroot. When I tried to build the package in a "minimal" FC4 buildroot it fails in the setup stage. This is because the Fedora Python specfile template uses Python dynamically to determine a number of parameters. For example, the Python specfile template contains the following: Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") When built using a "minimal" FC4 buildroot, you get the following error during the setup phase: Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-4-i386-core-minimal/root /sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild -bs --target i386 --nodeps /builddir/build/SPECS/python-gnupg.spec' mockbuild" sh: /usr/bin/python: No such file or directory error: line 18: Version required: Requires: python-abi = This is because the "minimal" buildroot does not install Python directly, nor is Python a dependency of anything installed with a minimal buildroot on FC4. This is not a problem on FC5 because Python gets pulled into the mininmal buildroot as a dependency. 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 wtogami at redhat.com Wed Jun 14 20:37:49 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 14 Jun 2006 16:37:49 -0400 Subject: Chicken & Egg Problem with FC4 "Minimal" Buildroot In-Reply-To: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> References: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> Message-ID: <4490739D.2090906@redhat.com> Jeffrey C. Ollie wrote: > This afternoon I was packaging a new Python module for potential > inclusion in Extras. The package builds correctly in a "standard" mock > FC4 buildroot. When I tried to build the package in a "minimal" FC4 > buildroot it fails in the setup stage. This is because the Fedora > Python specfile template uses Python dynamically to determine a number > of parameters. > > For example, the Python specfile template contains the following: > > Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") > > When built using a "minimal" FC4 buildroot, you get the following error > during the setup phase: > > Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-4-i386-core-minimal/root /sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild -bs --target i386 --nodeps /builddir/build/SPECS/python-gnupg.spec' mockbuild" > sh: /usr/bin/python: No such file or directory > error: line 18: Version required: Requires: python-abi = > > This is because the "minimal" buildroot does not install Python > directly, nor is Python a dependency of anything installed with a > minimal buildroot on FC4. This is not a problem on FC5 because Python > gets pulled into the mininmal buildroot as a dependency. > the mock "minimal" is not a functional minimal buildroot. The Fedora defined minimal buildroot includes python as one of the expected things that should be there. Warren Togami wtogami at redhat.com From peter at thecodergeek.com Wed Jun 14 20:51:34 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 14 Jun 2006 13:51:34 -0700 (PDT) Subject: Chicken & Egg Problem with FC4 "Minimal" Buildroot In-Reply-To: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> References: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> Message-ID: <42677.127.0.0.1.1150318294.squirrel@www.thecodergeek.com> Jeffrey C. Ollie wrote: > [..] This is because the Fedora > Python specfile template uses Python dynamically to determine a number > of parameters. > > For example, the Python specfile template contains the following: > > Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") You can easily remove that in FC4+. RPM now figures out the python(abi) deps automagically. :) Reference: http://fedoraproject.org/wiki/Packaging/Python -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From paul at all-the-johnsons.co.uk Wed Jun 14 20:55:10 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 21:55:10 +0100 Subject: noarch when building packages Message-ID: <1150318510.10582.18.camel@T7.Linux> Hi, Any clue on this would help. I'm adjusting a spec file so that BuildArch: noarch is used. Unfortunately, when I run %configure, the build fails as noarch-redhat is not recognised by targetarch. Help! TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed Jun 14 22:34:56 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 14 Jun 2006 15:34:56 -0700 Subject: noarch when building packages In-Reply-To: <1150318510.10582.18.camel@T7.Linux> References: <1150318510.10582.18.camel@T7.Linux> Message-ID: On 6/14/06, Paul wrote: > Hi, > > Any clue on this would help. I had a simillar problem which was fixed by removing AC_CANONICAL_TARGET from configure.ac and then running autoreconf --force --install From michael at knox.net.nz Wed Jun 14 23:07:53 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 15 Jun 2006 11:07:53 +1200 Subject: build system issue In-Reply-To: <20060614202555.3cd82dda.bugs.michael@gmx.net> References: <44904474.6030503@amiga-hardware.com> <20060614202555.3cd82dda.bugs.michael@gmx.net> Message-ID: <449096C9.7000206@knox.net.nz> Michael Schwendt wrote: > On Wed, 14 Jun 2006 18:16:36 +0100, Ian Chapman wrote: > > >>Hi, >> >>I'm currently trying to build the package cegui, which succeeds for >>devel, but fails on fc4 and fc5. cegui depends on tolua++-devel, which >>in turn depends on lua-devel. The problem is, that mock is installing an >>older version of lua (5.1-5) which provides lua-devel in the main >>package, even though lua-devel was provided as a seperate RPM. This >>problem was fixed in version lua 5.1-6 which has been available for >>about a week. >> >>Buildlogs: >>http://buildsys.fedoraproject.org/logs/fedora-4-extras/10942-cegui-0.4.1-8.fc4/x86_64/ >>http://buildsys.fedoraproject.org/logs/fedora-5-extras/10943-cegui-0.4.1-8.fc5/i386/ >> >>Question is, what's the best way to deal with this? > > > [...] > --> Running transaction check > --> Processing Dependency: libtolua++-5.1.so for package: tolua++-devel > --> Processing Dependency: lua-devel >= 5.1 for package: tolua++-devel > --> Processing Dependency: tolua++ = 1.0.92-3.fc5 for package: tolua++-devel > --> Processing Dependency: liblua-5.1.so for package: tolua++-devel > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > > It's Yum's very own way of picking a package which satisfies these > requirements "lua-devel >= 5.1 and liblua-5.1.so", > > $ repoquery --whatprovides liblua-5.1.so > lua-0:5.1-6.fc5.i386 > lua-0:5.1-5.fc5.i386 (!) > > $ repoquery --whatprovides lua-devel > lua-devel-0:5.1-6.fc5.i386 > lua-0:5.1-5.fc5.i386 (!) > lua-devel-0:5.1-5.fc5.i386 > > instead of picking the really latest packages, which you would get > after another "yum update". > > There are other (related) cases like this, e.g. failure to notice > obsolete sub-packages: http://bugzilla.redhat.com/190116 > > Most convenient work-around is to get rid of the old lua in the > repository. You would submit such a request via the Wiki. See > the Repository Status pages in the middle of: > http://fedoraproject.org/wiki/Extras > The request to have the older offending package removed has been requested. Michael From wart at kobold.org Thu Jun 15 00:41:19 2006 From: wart at kobold.org (Wart) Date: Wed, 14 Jun 2006 17:41:19 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-06-14 In-Reply-To: <20060614201111.GE23704@lists.us.dell.com> References: <20060614201111.GE23704@lists.us.dell.com> Message-ID: <4490ACAF.8010707@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for i386 Wed Jun 14 15:06:45 CDT 2006 > Number failed to build: 155 > Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > Leaving: 154 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 150 > ---------------------------------- [...] > xpilot-ng wart at kobold.org xpilot-ng fails due to a bug in SDL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195398 Other packages that require SDL-devel may be failing due to the same bug. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkKytDeYlPfs40g8RAuK4AJ4gYHZHpRa486CNIeCqN6ZhxNbUywCeP8H3 +gVWK3Wonq0lrQi3AGfsWx0= =xkL6 -----END PGP SIGNATURE----- From chris.stone at gmail.com Thu Jun 15 00:57:52 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 14 Jun 2006 17:57:52 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-06-14 In-Reply-To: <4490ACAF.8010707@kobold.org> References: <20060614201111.GE23704@lists.us.dell.com> <4490ACAF.8010707@kobold.org> Message-ID: On 6/14/06, Wart wrote: > xpilot-ng fails due to a bug in SDL: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195398 > > Other packages that require SDL-devel may be failing due to the same bug. Include pygame on that list From Matt_Domsch at dell.com Thu Jun 15 02:01:17 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 14 Jun 2006 21:01:17 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-14 In-Reply-To: References: <20060614201111.GE23704@lists.us.dell.com> <4490ACAF.8010707@kobold.org> Message-ID: <20060615020117.GA28517@lists.us.dell.com> On Wed, Jun 14, 2006 at 05:57:52PM -0700, Christopher Stone wrote: > On 6/14/06, Wart wrote: > >xpilot-ng fails due to a bug in SDL: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195398 > > > >Other packages that require SDL-devel may be failing due to the same bug. > > Include pygame on that list I rebuild all previously failed packages with each run, so when SDL is fixed, yours will be too. -- 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 bugzilla at redhat.com Thu Jun 15 03:33:18 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Jun 2006 23:33:18 -0400 Subject: [Bug 166924] Review Request: scim-skk In-Reply-To: Message-ID: <200606150333.k5F3XImi006036@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: scim-skk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166924 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From cranium2003 at yahoo.com Thu Jun 15 04:10:29 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Wed, 14 Jun 2006 21:10:29 -0700 (PDT) Subject: Mock build problem Message-ID: <20060615041029.14972.qmail@web38012.mail.mud.yahoo.com> Hi, I used fedora-mirror.py and downloaded all repository of FC5 core. Then i created repository on downloaded rpms by createrepo Fedora Then i modified fedora-5-i386-core.cfg to have my localpath of repository to be used to build package in mock. But still facing issue e.g. when i did su- build and tried to rebuild kdenetwork application i got ==================================================== [build at localhost SRPMS]$ mock -r fedora-5-i386-core.cfg kdenetwork-3.5.3-2.src.rpm init clean prep This may take a while Error peforming yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build ending done ======================================================== I am attaching my mock, log files here. wht now i need to use mock command on local system to build package __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 1793 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: root.log Type: text/x-log Size: 8800 bytes Desc: 2536305070-root.log URL: From paul at city-fan.org Thu Jun 15 06:57:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 07:57:30 +0100 Subject: Mock build problem In-Reply-To: <20060615041029.14972.qmail@web38012.mail.mud.yahoo.com> References: <20060615041029.14972.qmail@web38012.mail.mud.yahoo.com> Message-ID: <1150354651.30431.13.camel@laurel.intra.city-fan.org> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 wrote: > Hi, > I used fedora-mirror.py and downloaded all > repository of FC5 core. Then i created repository on > downloaded rpms by > createrepo Fedora > Then i modified fedora-5-i386-core.cfg to have my > localpath of repository to be used to build package in > mock. But still facing issue > > e.g. when i did su- build and tried to rebuild > kdenetwork application i got > ==================================================== > [build at localhost SRPMS]$ mock -r > fedora-5-i386-core.cfg kdenetwork-3.5.3-2.src.rpm > init > clean > prep > This may take a while > Error peforming yum command: /usr/sbin/mock-helper yum > --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > ending > done > ======================================================== > > I am attaching my mock, log files here. > wht now i need to use mock command on local system > to build package ... > Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build-minimal build-base build > Cannot find a valid baseurl for repo: extras > Error: Cannot find a valid baseurl for repo: extras yum has failed to access the Extras repo. If you want to run mock without downloading things from the Internet, you'll will need local mirrors of *all* the repos specified in your mock configuration file. Paul. From paul at city-fan.org Thu Jun 15 07:30:34 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 08:30:34 +0100 Subject: Chicken & Egg Problem with FC4 "Minimal" Buildroot In-Reply-To: <4490739D.2090906@redhat.com> References: <1150316802.15161.44.camel@pc04331.campus.dmacc.edu> <4490739D.2090906@redhat.com> Message-ID: <1150356635.30431.24.camel@laurel.intra.city-fan.org> On Wed, 2006-06-14 at 16:37 -0400, Warren Togami wrote: > Jeffrey C. Ollie wrote: > > This afternoon I was packaging a new Python module for potential > > inclusion in Extras. The package builds correctly in a "standard" mock > > FC4 buildroot. When I tried to build the package in a "minimal" FC4 > > buildroot it fails in the setup stage. This is because the Fedora > > Python specfile template uses Python dynamically to determine a number > > of parameters. > > > > For example, the Python specfile template contains the following: > > > > Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") > > > > When built using a "minimal" FC4 buildroot, you get the following error > > during the setup phase: > > > > Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-4-i386-core-minimal/root /sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild -bs --target i386 --nodeps /builddir/build/SPECS/python-gnupg.spec' mockbuild" > > sh: /usr/bin/python: No such file or directory > > error: line 18: Version required: Requires: python-abi = > > > > This is because the "minimal" buildroot does not install Python > > directly, nor is Python a dependency of anything installed with a > > minimal buildroot on FC4. This is not a problem on FC5 because Python > > gets pulled into the mininmal buildroot as a dependency. > > > > the mock "minimal" is not a functional minimal buildroot. The Fedora > defined minimal buildroot includes python as one of the expected things > that should be there. Not for FC4. None of the packages in the BuildRequires "Exceptions" section of the packaging guidelines has a dependency on python in FC4. The spec file template could either have a workaround for this, such as the hack that was discussed for the same issue for ruby packages, or, probably better, the "Requires: python-abi" line could simply be removed from the template since rpmbuild will add a "python(abi)" dependency automatically for FC4 and later, and new FC3 packages are no longer being accepted into Extras without a *really* good reason. Paul. From cranium2003 at yahoo.com Thu Jun 15 08:48:23 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 01:48:23 -0700 (PDT) Subject: Mock build problem In-Reply-To: <1150354651.30431.13.camel@laurel.intra.city-fan.org> Message-ID: <20060615084823.47036.qmail@web38005.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > On Wed, 2006-06-14 at 21:10 -0700, cranium2003 > wrote: > > Hi, > > I used fedora-mirror.py and downloaded all > > repository of FC5 core. Then i created repository > on > > downloaded rpms by > > createrepo Fedora > > Then i modified fedora-5-i386-core.cfg to have my > > localpath of repository to be used to build > package in > > mock. But still facing issue > > > > e.g. when i did su- build and tried to rebuild > > kdenetwork application i got > > > ==================================================== > > [build at localhost SRPMS]$ mock -r > > fedora-5-i386-core.cfg kdenetwork-3.5.3-2.src.rpm > > init > > clean > > prep > > This may take a while > > Error peforming yum command: /usr/sbin/mock-helper > yum > > --installroot > > /var/lib/mock/fedora-development-i386-core/root > > groupinstall build-minimal build-base build > > ending > > done > > > ======================================================== > > > > I am attaching my mock, log files here. > > wht now i need to use mock command on local > system > > to build package > > ... > > > Executing /usr/sbin/mock-helper yum > --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build-minimal build-base build > > Cannot find a valid baseurl for repo: extras > > Error: Cannot find a valid baseurl for repo: > extras > > yum has failed to access the Extras repo. If you > want to run mock > without downloading things from the Internet, you'll > will need local > mirrors of *all* the repos specified in your mock > configuration file. > Do i need extras repo also to use mock?? I did what u said from fedora-mirror.py. That script downloaded all core repo successfully but said no repo found for extras so unable to download as i gave to download only core in mirror script. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-mirror.py Type: application/octet-stream Size: 4734 bytes Desc: 2058674682-fedora-mirror.py URL: From thomas at apestaart.org Thu Jun 15 09:46:46 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 15 Jun 2006 11:46:46 +0200 Subject: orphan pre-announcement: Hermes Message-ID: <1150364807.23862.128.camel@otto.amantes> Hi, due to bugs I can't fix (like https://bugzilla.redhat.com/bugzilla//show_bug.cgi?id=184109 ) I would like to offer up Hermes for adoption. If nobody steps forward, I'll add it to the Orphan page next week. Thanks Thomas From paul at city-fan.org Thu Jun 15 10:38:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 11:38:28 +0100 Subject: Mock build problem In-Reply-To: <20060615084823.47036.qmail@web38005.mail.mud.yahoo.com> References: <20060615084823.47036.qmail@web38005.mail.mud.yahoo.com> Message-ID: <449138A4.1040509@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 >> wrote: >>> Hi, >>> I used fedora-mirror.py and downloaded all >>> repository of FC5 core. Then i created repository >> on >>> downloaded rpms by >>> createrepo Fedora >>> Then i modified fedora-5-i386-core.cfg to have my >>> localpath of repository to be used to build >> package in >>> mock. But still facing issue >>> >>> e.g. when i did su- build and tried to rebuild >>> kdenetwork application i got >>> >> ==================================================== >>> [build at localhost SRPMS]$ mock -r >>> fedora-5-i386-core.cfg kdenetwork-3.5.3-2.src.rpm >>> init >>> clean >>> prep >>> This may take a while >>> Error peforming yum command: /usr/sbin/mock-helper >> yum >>> --installroot >>> /var/lib/mock/fedora-development-i386-core/root >>> groupinstall build-minimal build-base build >>> ending >>> done >>> > ======================================================== >>> I am attaching my mock, log files here. >>> wht now i need to use mock command on local >> system >>> to build package >> ... >> >>> Executing /usr/sbin/mock-helper yum >> --installroot >> /var/lib/mock/fedora-development-i386-core/root >> groupinstall build-minimal build-base build >>> Cannot find a valid baseurl for repo: extras >>> Error: Cannot find a valid baseurl for repo: >> extras >> >> yum has failed to access the Extras repo. If you >> want to run mock >> without downloading things from the Internet, you'll >> will need local >> mirrors of *all* the repos specified in your mock >> configuration file. >> > > Do i need extras repo also to use mock?? I did what > u said from fedora-mirror.py. That script downloaded > all core repo successfully but said no repo found for > extras so unable to download as i gave to download > only core in mirror script. fedora-mirror needs an appropriate repo file for each repo you intend to mirror. So you need to create one for Extras just like you did for Core. e.g. # cat mirror-extras-development.repo [mirror-extras-development] name=Fedora Extras - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras gpgcheck=1 [mirror-extras-development-debuginfo] name=Fedora Extras - Development - Debug baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/debug/ enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras gpgcheck=1 [mirror-extras-development-source] name=Fedora Extras - Development - Source baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras gpgcheck=1 (that's for development, you'd need a different one for FC5) Paul. From cranium2003 at yahoo.com Thu Jun 15 11:01:16 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 04:01:16 -0700 (PDT) Subject: Mock build problem In-Reply-To: <449138A4.1040509@city-fan.org> Message-ID: <20060615110116.59579.qmail@web38012.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > hi, > > --- Paul Howarth wrote: > > > >> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 > >> wrote: > >>> Hi, > >>> I used fedora-mirror.py and downloaded all > >>> repository of FC5 core. Then i created > repository > >> on > >>> downloaded rpms by > >>> createrepo Fedora > >>> Then i modified fedora-5-i386-core.cfg to have > my > >>> localpath of repository to be used to build > >> package in > >>> mock. But still facing issue > >>> > >>> e.g. when i did su- build and tried to rebuild > >>> kdenetwork application i got > >>> > >> > ==================================================== > >>> [build at localhost SRPMS]$ mock -r > >>> fedora-5-i386-core.cfg > kdenetwork-3.5.3-2.src.rpm > >>> init > >>> clean > >>> prep > >>> This may take a while > >>> Error peforming yum command: > /usr/sbin/mock-helper > >> yum > >>> --installroot > >>> /var/lib/mock/fedora-development-i386-core/root > >>> groupinstall build-minimal build-base build > >>> ending > >>> done > >>> > > > ======================================================== > >>> I am attaching my mock, log files here. > >>> wht now i need to use mock command on local > >> system > >>> to build package > >> ... > >> > >>> Executing /usr/sbin/mock-helper yum > >> --installroot > >> /var/lib/mock/fedora-development-i386-core/root > >> groupinstall build-minimal build-base build > >>> Cannot find a valid baseurl for repo: extras > >>> Error: Cannot find a valid baseurl for repo: > >> extras > >> > >> yum has failed to access the Extras repo. If you > >> want to run mock > >> without downloading things from the Internet, > you'll > >> will need local > >> mirrors of *all* the repos specified in your mock > >> configuration file. > >> > > > > Do i need extras repo also to use mock?? I did > what > > u said from fedora-mirror.py. That script > downloaded > > all core repo successfully but said no repo found > for > > extras so unable to download as i gave to download > > only core in mirror script. > > fedora-mirror needs an appropriate repo file for > each repo you intend to > mirror. So you need to create one for Extras just > like you did for Core. > > e.g. > # cat mirror-extras-development.repo > [mirror-extras-development] > name=Fedora Extras - Development Tree > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel > enabled=0 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > gpgcheck=1 > > [mirror-extras-development-debuginfo] > name=Fedora Extras - Development - Debug > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/debug/ > enabled=0 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > gpgcheck=1 > > [mirror-extras-development-source] > name=Fedora Extras - Development - Source > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ > enabled=0 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > gpgcheck=1 > > (that's for development, you'd need a different one > for FC5) sorry i didnt get this?? Ok so i need to download usinf above repo conf file extras RPMs. once i have core as well as extras repo i can do mock build locally on my system right?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Thu Jun 15 11:07:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 12:07:43 +0100 Subject: Mock build problem In-Reply-To: <20060615110116.59579.qmail@web38012.mail.mud.yahoo.com> References: <20060615110116.59579.qmail@web38012.mail.mud.yahoo.com> Message-ID: <44913F7F.9050600@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> hi, >>> --- Paul Howarth wrote: >>> >>>> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 >>>> wrote: >>>>> Hi, >>>>> I used fedora-mirror.py and downloaded all >>>>> repository of FC5 core. Then i created >> repository >>>> on >>>>> downloaded rpms by >>>>> createrepo Fedora >>>>> Then i modified fedora-5-i386-core.cfg to have >> my >>>>> localpath of repository to be used to build >>>> package in >>>>> mock. But still facing issue >>>>> >>>>> e.g. when i did su- build and tried to rebuild >>>>> kdenetwork application i got >>>>> >> ==================================================== >>>>> [build at localhost SRPMS]$ mock -r >>>>> fedora-5-i386-core.cfg >> kdenetwork-3.5.3-2.src.rpm >>>>> init >>>>> clean >>>>> prep >>>>> This may take a while >>>>> Error peforming yum command: >> /usr/sbin/mock-helper >>>> yum >>>>> --installroot >>>>> /var/lib/mock/fedora-development-i386-core/root >>>>> groupinstall build-minimal build-base build >>>>> ending >>>>> done >>>>> > ======================================================== >>>>> I am attaching my mock, log files here. >>>>> wht now i need to use mock command on local >>>> system >>>>> to build package >>>> ... >>>> >>>>> Executing /usr/sbin/mock-helper yum >>>> --installroot >>>> /var/lib/mock/fedora-development-i386-core/root >>>> groupinstall build-minimal build-base build >>>>> Cannot find a valid baseurl for repo: extras >>>>> Error: Cannot find a valid baseurl for repo: >>>> extras >>>> >>>> yum has failed to access the Extras repo. If you >>>> want to run mock >>>> without downloading things from the Internet, >> you'll >>>> will need local >>>> mirrors of *all* the repos specified in your mock >>>> configuration file. >>>> >>> Do i need extras repo also to use mock?? I did >> what >>> u said from fedora-mirror.py. That script >> downloaded >>> all core repo successfully but said no repo found >> for >>> extras so unable to download as i gave to download >>> only core in mirror script. >> fedora-mirror needs an appropriate repo file for >> each repo you intend to >> mirror. So you need to create one for Extras just >> like you did for Core. >> >> e.g. >> # cat mirror-extras-development.repo >> [mirror-extras-development] >> name=Fedora Extras - Development Tree >> > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel >> enabled=0 >> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >> gpgcheck=1 >> >> [mirror-extras-development-debuginfo] >> name=Fedora Extras - Development - Debug >> > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/debug/ >> enabled=0 >> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >> gpgcheck=1 >> >> [mirror-extras-development-source] >> name=Fedora Extras - Development - Source >> > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ >> enabled=0 >> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >> gpgcheck=1 >> >> (that's for development, you'd need a different one >> for FC5) > sorry i didnt get this?? > Ok so i need to download usinf above repo conf file > extras RPMs. > once i have core as well as extras repo i can do > mock build locally on my system right?? You can use mock build already if you have a working Internet connection. If you don't, you need a local mirror of *all* repos you are using. The default fedora-5-i386-core mock config has the following repos: [core] [groups] [extras] [local] So you'll need a local groups repo too. It's small, and easy to make one yourself - see http://www.redhat.com/archives/fedora-devel-list/2006-May/msg00904.html You can probably get by without the [local] repo - just comment it out of the config file, or add "enabled=0" to it. Paul. From cranium2003 at yahoo.com Thu Jun 15 11:39:21 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 04:39:21 -0700 (PDT) Subject: Mock build problem In-Reply-To: <44913F7F.9050600@city-fan.org> Message-ID: <20060615113921.72923.qmail@web38012.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > hi, > > --- Paul Howarth wrote: > > > >> cranium2003 wrote: > >>> hi, > >>> --- Paul Howarth wrote: > >>> > >>>> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 > >>>> wrote: > >>>>> Hi, > >>>>> I used fedora-mirror.py and downloaded > all > >>>>> repository of FC5 core. Then i created > >> repository > >>>> on > >>>>> downloaded rpms by > >>>>> createrepo Fedora > >>>>> Then i modified fedora-5-i386-core.cfg to have > >> my > >>>>> localpath of repository to be used to build > >>>> package in > >>>>> mock. But still facing issue > >>>>> > >>>>> e.g. when i did su- build and tried to rebuild > >>>>> kdenetwork application i got > >>>>> > >> > ==================================================== > >>>>> [build at localhost SRPMS]$ mock -r > >>>>> fedora-5-i386-core.cfg > >> kdenetwork-3.5.3-2.src.rpm > >>>>> init > >>>>> clean > >>>>> prep > >>>>> This may take a while > >>>>> Error peforming yum command: > >> /usr/sbin/mock-helper > >>>> yum > >>>>> --installroot > >>>>> > /var/lib/mock/fedora-development-i386-core/root > >>>>> groupinstall build-minimal build-base build > >>>>> ending > >>>>> done > >>>>> > > > ======================================================== > >>>>> I am attaching my mock, log files here. > >>>>> wht now i need to use mock command on > local > >>>> system > >>>>> to build package > >>>> ... > >>>> > >>>>> Executing /usr/sbin/mock-helper yum > >>>> --installroot > >>>> /var/lib/mock/fedora-development-i386-core/root > >>>> groupinstall build-minimal build-base build > >>>>> Cannot find a valid baseurl for repo: extras > >>>>> Error: Cannot find a valid baseurl for repo: > >>>> extras > >>>> > >>>> yum has failed to access the Extras repo. If > you > >>>> want to run mock > >>>> without downloading things from the Internet, > >> you'll > >>>> will need local > >>>> mirrors of *all* the repos specified in your > mock > >>>> configuration file. > >>>> > >>> Do i need extras repo also to use mock?? I did > >> what > >>> u said from fedora-mirror.py. That script > >> downloaded > >>> all core repo successfully but said no repo > found > >> for > >>> extras so unable to download as i gave to > download > >>> only core in mirror script. > >> fedora-mirror needs an appropriate repo file for > >> each repo you intend to > >> mirror. So you need to create one for Extras just > >> like you did for Core. > >> > >> e.g. > >> # cat mirror-extras-development.repo > >> [mirror-extras-development] > >> name=Fedora Extras - Development Tree > >> > > > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ > > > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel > >> enabled=0 > >> > > > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > >> gpgcheck=1 > >> > >> [mirror-extras-development-debuginfo] > >> name=Fedora Extras - Development - Debug > >> > > > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/debug/ > >> enabled=0 > >> > > > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > >> gpgcheck=1 > >> > >> [mirror-extras-development-source] > >> name=Fedora Extras - Development - Source > >> > > > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ > >> enabled=0 > >> > > > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > >> gpgcheck=1 > >> > >> (that's for development, you'd need a different > one > >> for FC5) > > sorry i didnt get this?? > > Ok so i need to download usinf above repo conf > file > > extras RPMs. > > once i have core as well as extras repo i can do > > mock build locally on my system right?? > > You can use mock build already if you have a working > Internet connection. yes i have how can i use it now?? what extras url i need to specify?? > > If you don't, you need a local mirror of *all* repos > you are using. The > default fedora-5-i386-core mock config has the > following repos: > > [core] > [groups] > [extras] > [local] > > So you'll need a local groups repo too. It's small, > and easy to make one > yourself - see > http://www.redhat.com/archives/fedora-devel-list/2006-May/msg00904.html > > You can probably get by without the [local] repo - > just comment it out > of the config file, or add "enabled=0" to it. ok i installed buildsys package and then copy minimal.xml from above mailing thread and created repo from that that file. Then i added path under groups section and my current mock file is attahced here. is that require any chnages ?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 1882 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: From paul at city-fan.org Thu Jun 15 11:46:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 12:46:22 +0100 Subject: Mock build problem In-Reply-To: <20060615113921.72923.qmail@web38012.mail.mud.yahoo.com> References: <20060615113921.72923.qmail@web38012.mail.mud.yahoo.com> Message-ID: <4491488E.1030008@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> hi, >>> --- Paul Howarth wrote: >>> >>>> cranium2003 wrote: >>>>> hi, >>>>> --- Paul Howarth wrote: >>>>> >>>>>> On Wed, 2006-06-14 at 21:10 -0700, cranium2003 >>>>>> wrote: >>>>>>> Hi, >>>>>>> I used fedora-mirror.py and downloaded >> all >>>>>>> repository of FC5 core. Then i created >>>> repository >>>>>> on >>>>>>> downloaded rpms by >>>>>>> createrepo Fedora >>>>>>> Then i modified fedora-5-i386-core.cfg to have >>>> my >>>>>>> localpath of repository to be used to build >>>>>> package in >>>>>>> mock. But still facing issue >>>>>>> >>>>>>> e.g. when i did su- build and tried to rebuild >>>>>>> kdenetwork application i got >>>>>>> >> ==================================================== >>>>>>> [build at localhost SRPMS]$ mock -r >>>>>>> fedora-5-i386-core.cfg >>>> kdenetwork-3.5.3-2.src.rpm >>>>>>> init >>>>>>> clean >>>>>>> prep >>>>>>> This may take a while >>>>>>> Error peforming yum command: >>>> /usr/sbin/mock-helper >>>>>> yum >>>>>>> --installroot >>>>>>> >> /var/lib/mock/fedora-development-i386-core/root >>>>>>> groupinstall build-minimal build-base build >>>>>>> ending >>>>>>> done >>>>>>> > ======================================================== >>>>>>> I am attaching my mock, log files here. >>>>>>> wht now i need to use mock command on >> local >>>>>> system >>>>>>> to build package >>>>>> ... >>>>>> >>>>>>> Executing /usr/sbin/mock-helper yum >>>>>> --installroot >>>>>> /var/lib/mock/fedora-development-i386-core/root >>>>>> groupinstall build-minimal build-base build >>>>>>> Cannot find a valid baseurl for repo: extras >>>>>>> Error: Cannot find a valid baseurl for repo: >>>>>> extras >>>>>> >>>>>> yum has failed to access the Extras repo. If >> you >>>>>> want to run mock >>>>>> without downloading things from the Internet, >>>> you'll >>>>>> will need local >>>>>> mirrors of *all* the repos specified in your >> mock >>>>>> configuration file. >>>>>> >>>>> Do i need extras repo also to use mock?? I did >>>> what >>>>> u said from fedora-mirror.py. That script >>>> downloaded >>>>> all core repo successfully but said no repo >> found >>>> for >>>>> extras so unable to download as i gave to >> download >>>>> only core in mirror script. >>>> fedora-mirror needs an appropriate repo file for >>>> each repo you intend to >>>> mirror. So you need to create one for Extras just >>>> like you did for Core. >>>> >>>> e.g. >>>> # cat mirror-extras-development.repo >>>> [mirror-extras-development] >>>> name=Fedora Extras - Development Tree >>>> > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel >>>> enabled=0 >>>> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >>>> gpgcheck=1 >>>> >>>> [mirror-extras-development-debuginfo] >>>> name=Fedora Extras - Development - Debug >>>> > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/debug/ >>>> enabled=0 >>>> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >>>> gpgcheck=1 >>>> >>>> [mirror-extras-development-source] >>>> name=Fedora Extras - Development - Source >>>> > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ >>>> enabled=0 >>>> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras >>>> gpgcheck=1 >>>> >>>> (that's for development, you'd need a different >> one >>>> for FC5) >>> sorry i didnt get this?? >>> Ok so i need to download usinf above repo conf >> file >>> extras RPMs. >>> once i have core as well as extras repo i can do >>> mock build locally on my system right?? >> You can use mock build already if you have a working >> Internet connection. > yes i have how can i use it now?? what extras > url i need to specify?? >> If you don't, you need a local mirror of *all* repos >> you are using. The >> default fedora-5-i386-core mock config has the >> following repos: >> >> [core] >> [groups] >> [extras] >> [local] >> >> So you'll need a local groups repo too. It's small, >> and easy to make one >> yourself - see >> > http://www.redhat.com/archives/fedora-devel-list/2006-May/msg00904.html >> You can probably get by without the [local] repo - >> just comment it out >> of the config file, or add "enabled=0" to it. > > ok i installed buildsys package and then copy > minimal.xml from above mailing thread and created repo > from that that file. You don't need to install the buildsys-macros package on your build system, it just needs to be in your local [groups] repo. > Then i added path under groups > section and my current mock file is attahced here. is > that require any chnages ?? Your [groups] points to the same URL as the [core] repo; it should point to the directory you ran createrepo in for the local groups repo. Once you've made the local groups repo from the minimal.xml file, you need to change: config_opts['buildgroup'] = 'build-minimal build-base build' back to: config_opts['buildgroup'] = 'build' You need to disable the [local] repo. You need to add baseurl lines for the [updates-released] and [extras] repos that point to your local mirrors of these repos. Paul. From cranium2003 at yahoo.com Thu Jun 15 12:01:11 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 05:01:11 -0700 (PDT) Subject: Mock build problem In-Reply-To: <4491488E.1030008@city-fan.org> Message-ID: <20060615120111.7783.qmail@web38008.mail.mud.yahoo.com> hi, It seems i am following wrong tree to build repo. i have attached my /home/source tree in text file can u check it and then check fedora mock conf file?? Disabling local means what i need to do in mock conf file?? I hope u can understand attached tree file. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 1857 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mytree Type: application/octet-stream Size: 1026 bytes Desc: 491199642-mytree URL: From paul at city-fan.org Thu Jun 15 12:44:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 13:44:00 +0100 Subject: Mock build problem In-Reply-To: <20060615120111.7783.qmail@web38008.mail.mud.yahoo.com> References: <20060615120111.7783.qmail@web38008.mail.mud.yahoo.com> Message-ID: <44915610.6000106@city-fan.org> cranium2003 wrote: > hi, > It seems i am following wrong tree to build repo. > i have attached my /home/source tree in text file can > u check it and then check fedora mock conf file?? > Disabling local means what i need to do in mock conf > file?? > I hope u can understand attached tree file. So far you have made a local mirror of fedora-core-development (i386). You can use this for building packages targeted at FC6 (i386), You will probably need a local mirror of Extras (development) too. To build packages targeted at FC5, you will need local mirrors of FC5 core, FC5 updates and probably FC5 Extras too. You will need to keep your mirrors up to date, particularly for development. What is the platform you actually want to build for? Paul. From cranium2003 at yahoo.com Thu Jun 15 12:52:34 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 05:52:34 -0700 (PDT) Subject: Mock build problem In-Reply-To: <44915610.6000106@city-fan.org> Message-ID: <20060615125234.71131.qmail@web38007.mail.mud.yahoo.com> Hi, --- Paul Howarth wrote: > cranium2003 wrote: > > hi, > > It seems i am following wrong tree to build > repo. > > i have attached my /home/source tree in text file > can > > u check it and then check fedora mock conf file?? > > Disabling local means what i need to do in mock > conf > > file?? > > I hope u can understand attached tree file. > > So far you have made a local mirror of > fedora-core-development (i386). > You can use this for building packages targeted at > FC6 (i386), You will > probably need a local mirror of Extras (development) > too. > > To build packages targeted at FC5, you will need > local mirrors of FC5 > core, FC5 updates and probably FC5 Extras too. > > You will need to keep your mirrors up to date, > particularly for development. > > What is the platform you actually want to build for? can u help to modify fedora-mirror.py script because last night i completed all downloading of fedora-core development repo. but then it said no repo found for extras. Now how to made attached fedora-mirror script to continuosly go on downloading from core to extras to updates automatically once i start that script?? Also i modified fedora-core-mock as its attached here and under error log i got Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/repodata/repomd.xml: [Errno 4] IOError: 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... What i did made mock to have local core repo and extras online repo but it failed. Can u give me fedora-5-i386-core.cfg that will use local development core repo but all others from internet?? or how to modify mirror script?? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-mirror.py Type: text/x-python Size: 4734 bytes Desc: 2058674682-fedora-mirror.py URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-5-i386-core.cfg Type: application/octet-stream Size: 1686 bytes Desc: 3045534007-fedora-5-i386-core.cfg URL: From paul at city-fan.org Thu Jun 15 12:59:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 13:59:27 +0100 Subject: Mock build problem In-Reply-To: <20060615125234.71131.qmail@web38007.mail.mud.yahoo.com> References: <20060615125234.71131.qmail@web38007.mail.mud.yahoo.com> Message-ID: <449159AF.2090002@city-fan.org> cranium2003 wrote: > Hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> hi, >>> It seems i am following wrong tree to build >> repo. >>> i have attached my /home/source tree in text file >> can >>> u check it and then check fedora mock conf file?? >>> Disabling local means what i need to do in mock >> conf >>> file?? >>> I hope u can understand attached tree file. >> So far you have made a local mirror of >> fedora-core-development (i386). >> You can use this for building packages targeted at >> FC6 (i386), You will >> probably need a local mirror of Extras (development) >> too. >> >> To build packages targeted at FC5, you will need >> local mirrors of FC5 >> core, FC5 updates and probably FC5 Extras too. >> >> You will need to keep your mirrors up to date, >> particularly for development. >> >> What is the platform you actually want to build for? Please answer the above question before asking any others. Do you want to build packages in mock for FC5, FC6 (development), or both? You will need to mirror different things for these. Paul. From cranium2003 at yahoo.com Thu Jun 15 13:08:56 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Thu, 15 Jun 2006 06:08:56 -0700 (PDT) Subject: Mock build problem In-Reply-To: <449159AF.2090002@city-fan.org> Message-ID: <20060615130856.65113.qmail@web38001.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > cranium2003 wrote: > > Hi, > > --- Paul Howarth wrote: > > > >> cranium2003 wrote: > >>> hi, > >>> It seems i am following wrong tree to build > >> repo. > >>> i have attached my /home/source tree in text > file > >> can > >>> u check it and then check fedora mock conf > file?? > >>> Disabling local means what i need to do in mock > >> conf > >>> file?? > >>> I hope u can understand attached tree file. > >> So far you have made a local mirror of > >> fedora-core-development (i386). > >> You can use this for building packages targeted > at > >> FC6 (i386), You will > >> probably need a local mirror of Extras > (development) > >> too. > >> > >> To build packages targeted at FC5, you will need > >> local mirrors of FC5 > >> core, FC5 updates and probably FC5 Extras too. > >> > >> You will need to keep your mirrors up to date, > >> particularly for development. > >> > >> What is the platform you actually want to build > for? FC5. I am extermely sorry as i got confused with those URLs in fedora-5-i386-core.cfg > > Please answer the above question before asking any > others. > > Do you want to build packages in mock for FC5, FC6 > (development), or > both? You will need to mirror different things for > these. > > Paul. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rdieter at math.unl.edu Thu Jun 15 13:34:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Jun 2006 08:34:51 -0500 Subject: Packages up for adoption References: <1150217286.15532.26.camel@golem.boston.redhat.com> <1123.219.89.41.91.1150227153.squirrel@www.knox.net.nz> <1150310211.3304.4.camel@dhcp83-98.boston.redhat.com> Message-ID: Matthias Clasen wrote: > Bugzilla is back up; oh, and imlib and gdk-pixbuf are being whacked from > Core for test1, so feel free to get them into Extras. Another kde dependancy bites the dust... so kdegraphics goes to Extras too? (: -- rex From paul at city-fan.org Thu Jun 15 14:09:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 15:09:05 +0100 Subject: Mock build problem In-Reply-To: <20060615130856.65113.qmail@web38001.mail.mud.yahoo.com> References: <20060615130856.65113.qmail@web38001.mail.mud.yahoo.com> Message-ID: <44916A01.8080002@city-fan.org> cranium2003 wrote: > hi, > --- Paul Howarth wrote: > >> cranium2003 wrote: >>> Hi, >>> --- Paul Howarth wrote: >>> >>>> cranium2003 wrote: >>>>> hi, >>>>> It seems i am following wrong tree to build >>>> repo. >>>>> i have attached my /home/source tree in text >> file >>>> can >>>>> u check it and then check fedora mock conf >> file?? >>>>> Disabling local means what i need to do in mock >>>> conf >>>>> file?? >>>>> I hope u can understand attached tree file. >>>> So far you have made a local mirror of >>>> fedora-core-development (i386). >>>> You can use this for building packages targeted >> at >>>> FC6 (i386), You will >>>> probably need a local mirror of Extras >> (development) >>>> too. >>>> >>>> To build packages targeted at FC5, you will need >>>> local mirrors of FC5 >>>> core, FC5 updates and probably FC5 Extras too. >>>> >>>> You will need to keep your mirrors up to date, >>>> particularly for development. >>>> >>>> What is the platform you actually want to build >> for? > FC5. > I am extermely sorry as i got confused with those > URLs in fedora-5-i386-core.cfg Right. The bad news then is that your mirror of fedora-development is useless to you. You will need local mirrors/repos for FC5 i386 [core], FC5 i386 [updates-released], FC5 i386 [extras], and FC5 i386 [groups]. You can use your FC5 ISO image(s) as a local [core] repo: http://www.city-fan.org/tips/YumRepoFromImages To make the FC5 updates and extras mirrors, you'll need in your fedora-mirror script: flavourlist=["extras", "updates"] versionlist=["5"] archlist=["i386"] subflavourlist=["binary"] You will need to create mirror repo files too. Copy fedora-updates.repo to mirror-fedora-updates.repo and copy fedora-extras.repo to mirror-fedora-extras.repo. In the mirror-*.repo files, edit the repo IDs (the names in square brackets) by putting "mirror-" in front of them (like you did with the mirror-fedora-development repo file), so for instance [updates] gets changed to [mirror-updates]. You should then be able to run fedora-mirror to create and keep up to date your local FC5 mirrors. As for the local [groups] mirror, create it as follows: # cd /home/source/fedora # mkdir -p 5/core/i386/groups # mv development/core/i386/*/minimal.xml 5/core/i386/groups # cd 5/core/i386/groups # wget http://fedoraproject.org/buildgroups/5/i386/buildsys-macros-5-2.fc5.noarch.rpm # wget http://fedoraproject.org/buildgroups/5/i386/buildsys-macros-5-2.fc5.src.rpm # createrepo -g minimal.xml . The mock config file (fedora-5-i386-core.cfg) should look like: #!/usr/bin/python -tt import os config_opts['root'] = 'fedora-development-i386-core' config_opts['basedir'] = '/var/lib/mock/' config_opts['chroot'] = '/usr/sbin/mock-helper chroot' config_opts['mount'] = '/usr/sbin/mock-helper mount' config_opts['umount'] = '/usr/sbin/mock-helper umount' config_opts['rm'] = '/usr/sbin/mock-helper rm' config_opts['mknod'] = '/usr/sbin/mock-helper mknod' config_opts['yum'] = '/usr/sbin/mock-helper yum' config_opts['runuser'] = '/sbin/runuser' config_opts['buildgroup'] = 'build' config_opts['chrootuser'] = 'mockbuild' config_opts['chrootgroup'] = 'mockbuild' config_opts['chrootuid'] = os.geteuid() config_opts['chrootgid'] = os.getegid() config_opts['chroothome'] = '/builddir' config_opts['clean'] = True config_opts['target_arch'] = 'i386' config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos [core] name=core #baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 #mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-5 baseurl=file:///home/source/fedora/5/core/i386/mirror-core [updates-released] name=updates #mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc5 baseurl=file:///home/source/fedora/5/updates/i386/mirror-updates [groups] name=groups #baseurl=http://buildsys.fedoraproject.org/buildgroups/5/i386/ baseurl=file:///home/source/fedora/5/core/i386/groups [extras] name=extras #mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-5 baseurl=file:///home/source/fedora/5/extras/i386/mirror-extras [local] name=local baseurl=http://extras64.linux.duke.edu/plague-results/fedora-5-extras enabled=0 """ That assumes that you created your local FC5 core repo at /home/source/fedora/5/core/i386/mirror-core. Paul. From rdieter at math.unl.edu Thu Jun 15 14:04:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Jun 2006 09:04:54 -0500 Subject: rpms/texmaker/FC-5 texmaker.spec,1.7,1.8 References: <200606142203.k5EM3OrG006542@cvs-int.fedora.redhat.com> Message-ID: Deji Akingunola (deji) wrote: > Author: deji > > Update of /cvs/extras/rpms/texmaker/FC-5 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6522 > > Modified Files: > texmaker.spec > Log Message: > * Thu Jun 08 2006 Deji Akingunola > - 1.3-5 - Fix bug > #194587 It would be nice to at least briefly mention what it is you're fixing in the changelog, instead of simply referring to the bugzilla #. Also, it appears this # is wrong, since 194587 is a scim bug. -- Rex From paul at city-fan.org Thu Jun 15 14:18:25 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jun 2006 15:18:25 +0100 Subject: rpms/texmaker/FC-5 texmaker.spec,1.7,1.8 In-Reply-To: References: <200606142203.k5EM3OrG006542@cvs-int.fedora.redhat.com> Message-ID: <44916C31.9060307@city-fan.org> Rex Dieter wrote: > Deji Akingunola (deji) wrote: > >> Author: deji >> >> Update of /cvs/extras/rpms/texmaker/FC-5 >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6522 >> >> Modified Files: >> texmaker.spec >> Log Message: >> * Thu Jun 08 2006 Deji Akingunola >> - 1.3-5 - Fix bug >> #194587 > > It would be nice to at least briefly mention what it is you're fixing in the > changelog, instead of simply referring to the bugzilla #. Also, it appears > this # is wrong, since 194587 is a scim bug. The number was probably right when the bug was originally entered, but became a different bug due to the bugzilla crash. I suspect that the bug that this fixes has not been re-entered into bugzilla. Paul. From paul at all-the-johnsons.co.uk Thu Jun 15 15:31:49 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 15 Jun 2006 16:31:49 +0100 Subject: Gnu Classpath Message-ID: <1150385509.17856.22.camel@mrwibble.mrwobble> Hi, Anyone know what the current state of play is for having gnu classpath in either core or extras? ikvm needs it to build (0.19 for v0.22 and 0.91 for v0.28) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Thu Jun 15 15:46:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Jun 2006 10:46:52 -0500 Subject: Gnu Classpath References: <1150385509.17856.22.camel@mrwibble.mrwobble> Message-ID: PFJ wrote: > Anyone know what the current state of play is for having gnu classpath > in either core or extras? Just did a quick bugzilla search... It's not (yet) been submitted for any formal Fedora (Core or Extras) review. So, atm, there's no relief in sight. -- Rex From paul at all-the-johnsons.co.uk Thu Jun 15 15:59:17 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 15 Jun 2006 16:59:17 +0100 Subject: Gnu Classpath In-Reply-To: References: <1150385509.17856.22.camel@mrwibble.mrwobble> Message-ID: <1150387157.17856.26.camel@mrwibble.mrwobble> Hi, > > Anyone know what the current state of play is for having gnu classpath > > in either core or extras? > > Just did a quick bugzilla search... It's not (yet) been submitted for any > formal Fedora (Core or Extras) review. So, atm, there's no relief in > sight. Oh well - as ikvm needs it, I suppose I'll have a go at packaging it... Another one to add to my portfolio ;-) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From nicolas.mailhot at laposte.net Thu Jun 15 16:05:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jun 2006 18:05:31 +0200 (CEST) Subject: Gnu Classpath In-Reply-To: References: <1150385509.17856.22.camel@mrwibble.mrwobble> Message-ID: <26850.192.54.193.52.1150387531.squirrel@rousalka.dyndns.org> Le Jeu 15 juin 2006 17:46, Rex Dieter a ?crit : > PFJ wrote: > >> Anyone know what the current state of play is for having gnu classpath >> in either core or extras? > > Just did a quick bugzilla search... It's not (yet) been submitted for any > formal Fedora (Core or Extras) review. So, atm, there's no relief in > sight. I think large parts of classpath are already available in Fedora or JPackage (or both). They're just split in different packages -- Nicolas Mailhot From pertusus at free.fr Thu Jun 15 16:44:52 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Jun 2006 18:44:52 +0200 Subject: fstab-sync for xfce replacement package In-Reply-To: <20060614.105652.515898614.kevin@scrye.com> References: <20060614164848.GA20053@free.fr> <20060614.105652.515898614.kevin@scrye.com> Message-ID: <20060615164452.GB2646@free.fr> > I am working on a thunar package (which will be the default graphical > file manager for Xfce 4.4 when it's released), but I haven't had time > to go too far on it. If you would like to package it up, feel > free... ;) > > Note that thunar is in beta still until 4.4 comes out, so I don't > think it should be shipped until 4.4 is released. I have completed a thunar package which may be found on http://www.environnement.ens.fr/perso/dumas/fc-srpms/Thunar-0.3.0-0.beta1.src.rpm It requires a newer version of the exo library, which I requested, together with a diff for the spec file here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195435 It handles right my usb key, but there seems to be icons missing for the different files. Or maybe they are not in thunar directly or I missed something while packaging. Otherwise it looks like a nice and fast filemanager. I tested on FC5. -- Pat From kevin-fedora-extras at scrye.com Thu Jun 15 18:36:42 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Thu, 15 Jun 2006 12:36:42 -0600 (MDT) Subject: fstab-sync for xfce replacement package References: <20060614164848.GA20053@free.fr> <20060614.105652.515898614.kevin@scrye.com> <20060615164452.GB2646@free.fr> Message-ID: <20060615.123642.360390868.kevin@scrye.com> >>>>> "Patrice" == Patrice Dumas writes: >> I am working on a thunar package (which will be the default >> graphical file manager for Xfce 4.4 when it's released), but I >> haven't had time to go too far on it. If you would like to package >> it up, feel free... ;) >> >> Note that thunar is in beta still until 4.4 comes out, so I don't >> think it should be shipped until 4.4 is released. Patrice> I have completed a thunar package which may be found on Patrice> http://www.environnement.ens.fr/perso/dumas/fc-srpms/Thunar-0.3.0-0.beta1.src.rpm Patrice> It requires a newer version of the exo library, which I Patrice> requested, together with a diff for the spec file here: Patrice> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195435 I am a bit learly of updaing exo to a beta1 version, shipping things that the developers aren't even called a RC yet is kinda scary. Take a look at all the xubuntu problem reports that pop up on the Xfce lists (xubuntu shipped Xfce 4.4beta1 + their patches). On the plus side, exo only has one thing that depends on it (Terminal), and also the current exo doesn't build right under devel, so updating exo and Terminal might be ok. I will do some testing and see how stable new exo/Terminal seem. Patrice> It handles right my usb key, but there seems to be icons Patrice> missing for the different files. Or maybe they are not in Patrice> thunar directly or I missed something while Patrice> packaging. Otherwise it looks like a nice and fast Patrice> filemanager. Yeah, it is a beta tho, so expect some issues. Patrice> I tested on FC5. Patrice> -- Pat kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rmuller at sandia.gov Thu Jun 15 20:49:11 2006 From: rmuller at sandia.gov (Rick Muller) Date: Thu, 15 Jun 2006 14:49:11 -0600 Subject: Who maintains python-numeric Message-ID: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> Who maintains python-numeric in extras? There has been a bug in the eigenvector routines for some time. I submitted a bug report some time ago about this. It's something I could fix in all of 30 seconds, so if there's any way that I could help, I'd be glad to. Rick From michael at knox.net.nz Thu Jun 15 20:51:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 16 Jun 2006 08:51:21 +1200 Subject: Who maintains python-numeric In-Reply-To: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> Message-ID: <4491C849.4070502@knox.net.nz> Rick Muller wrote: > Who maintains python-numeric in extras? There has been a bug in the > eigenvector routines for some time. I submitted a bug report some time > ago about this. It's something I could fix in all of 30 seconds, so if > there's any way that I could help, I'd be glad to. No one by the looks of it: [michael at leroy owners]$ cat owners.list | grep python-numeric Fedora Extras|python-numeric|Fast multidimensional array functions for Python|extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| [michael at leroy owners]$ I can unorphan it if no one else wants it. Michael From Matt_Domsch at dell.com Thu Jun 15 20:57:16 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 15 Jun 2006 15:57:16 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-15 Message-ID: <20060615205716.GC31124@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Thu Jun 15 15:33:36 CDT 2006 Number failed to build: 155 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 154 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 150 ---------------------------------- abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libmthca rolandd at cisco.com libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com mftrace qspencer at ieee.org multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org paps tagoh at redhat.com php-extras dmitry at butskoy.name pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd gauret at free.fr pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 Thu Jun 15 20:57:46 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 15 Jun 2006 15:57:46 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-15 Message-ID: <20060615205746.GD31124@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Thu Jun 15 15:32:02 CDT 2006 Number failed to build: 172 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 161 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 157 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz jeff at ollie.clive.ia.us camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop gauret at free.fr jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org mftrace qspencer at ieee.org mhonarc gauret at free.fr mod_suphp andreas at bawue.net multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp chris.stone at gmail.com opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org paps tagoh at redhat.com perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-extras dmitry at butskoy.name php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd gauret at free.fr pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 paul at all-the-johnsons.co.uk Thu Jun 15 21:12:43 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 15 Jun 2006 22:12:43 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-15 In-Reply-To: <20060615205746.GD31124@lists.us.dell.com> References: <20060615205746.GD31124@lists.us.dell.com> Message-ID: <1150405963.26381.1.camel@T7.Linux> Hi, > z88dk paul at all-the-johnsons.co.uk https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185511 TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Thu Jun 15 21:45:13 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 15 Jun 2006 14:45:13 -0700 (PDT) Subject: Who maintains python-numeric In-Reply-To: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> Message-ID: <33343.127.0.0.1.1150407913.squirrel@www.thecodergeek.com> Rick Muller wrote: > Who maintains python-numeric in extras? There has been a bug in the > eigenvector routines for some time. I submitted a bug report some > time ago about this. It's something I could fix in all of 30 seconds, > so if there's any way that I could help, I'd be glad to. It's orphaned, according to owners/owners.list in CVS. Feel free to take ownership of it and fix this if you want. :) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From rmuller at sandia.gov Thu Jun 15 21:47:12 2006 From: rmuller at sandia.gov (Rick Muller) Date: Thu, 15 Jun 2006 15:47:12 -0600 Subject: Who maintains python-numeric In-Reply-To: <33343.127.0.0.1.1150407913.squirrel@www.thecodergeek.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <33343.127.0.0.1.1150407913.squirrel@www.thecodergeek.com> Message-ID: <38FE9AD0-B57C-4073-9A17-0ADADBA53310@sandia.gov> I'll be glad to take ownership. However, I've never done this before, so it might take me a little longer. I'm in the process of reading through the appropriate pages on the Fedora Extras Wiki to find out what I have to do. Rick On Jun 15, 2006, at 3:45 PM, Peter Gordon wrote: > Rick Muller wrote: >> Who maintains python-numeric in extras? There has been a bug in the >> eigenvector routines for some time. I submitted a bug report some >> time ago about this. It's something I could fix in all of 30 seconds, >> so if there's any way that I could help, I'd be glad to. > > It's orphaned, according to owners/owners.list in CVS. Feel free to > take > ownership of it and fix this if you want. :) > -- > Peter Gordon (codergeek42) > This message was sent through a webmail > interface, and thus not signed. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > Rick Muller rmuller at sandia.gov From pertusus at free.fr Thu Jun 15 21:59:42 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Jun 2006 23:59:42 +0200 Subject: fstab-sync for xfce replacement package In-Reply-To: <20060615.123642.360390868.kevin@scrye.com> References: <20060614164848.GA20053@free.fr> <20060614.105652.515898614.kevin@scrye.com> <20060615164452.GB2646@free.fr> <20060615.123642.360390868.kevin@scrye.com> Message-ID: <20060615215920.GA2493@free.fr> > On the plus side, exo only has one thing that depends on it > (Terminal), and also the current exo doesn't build right under devel, > so updating exo and Terminal might be ok. And unlike Xfce in general exo is a lib, and seems not to have anything depending on it currently. -- Pat From Axel.Thimm at ATrpms.net Thu Jun 15 22:01:16 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 00:01:16 +0200 Subject: Who maintains python-numeric In-Reply-To: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> Message-ID: <20060615220116.GC15009@neu.nirvana> On Thu, Jun 15, 2006 at 02:49:11PM -0600, Rick Muller wrote: > Who maintains python-numeric in extras? There has been a bug in the > eigenvector routines for some time. I submitted a bug report some > time ago about this. It's something I could fix in all of 30 seconds, > so if there's any way that I could help, I'd be glad to. Isn't this superseeded (by the authors) by numpy? -- 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 rmuller at sandia.gov Thu Jun 15 22:08:35 2006 From: rmuller at sandia.gov (Rick Muller) Date: Thu, 15 Jun 2006 16:08:35 -0600 Subject: Who maintains python-numeric In-Reply-To: <20060615220116.GC15009@neu.nirvana> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> Message-ID: <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> Yes, python-numeric has been superceded by numpy, but python-numeric is still used as a dependency in many fedora packages, and thus it would be good to have a version where the eigensolver doesn't hang. But maybe I'm the only person who cares about it, and, since I already have an easy workaround, it isn't that important. Rick On Jun 15, 2006, at 4:01 PM, Axel Thimm wrote: > On Thu, Jun 15, 2006 at 02:49:11PM -0600, Rick Muller wrote: >> Who maintains python-numeric in extras? There has been a bug in the >> eigenvector routines for some time. I submitted a bug report some >> time ago about this. It's something I could fix in all of 30 seconds, >> so if there's any way that I could help, I'd be glad to. > > Isn't this superseeded (by the authors) by numpy? > -- > Axel.Thimm at ATrpms.net > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list Rick Muller rmuller at sandia.gov From jwilson at redhat.com Thu Jun 15 22:16:36 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 15 Jun 2006 18:16:36 -0400 Subject: Who maintains python-numeric In-Reply-To: <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> Message-ID: <1150409796.4381.7.camel@xavier.boston.redhat.com> On Thu, 2006-06-15 at 16:08 -0600, Rick Muller wrote: > Yes, python-numeric has been superceded by numpy, but python-numeric > is still used as a dependency in many fedora packages, and thus it > would be good to have a version where the eigensolver doesn't hang. > But maybe I'm the only person who cares about it, and, since I > already have an easy workaround, it isn't that important. Would it not be better to package numpy and put in Provides: and Obsoletes: python-numeric? > On Jun 15, 2006, at 4:01 PM, Axel Thimm wrote: > > > On Thu, Jun 15, 2006 at 02:49:11PM -0600, Rick Muller wrote: > >> Who maintains python-numeric in extras? There has been a bug in the > >> eigenvector routines for some time. I submitted a bug report some > >> time ago about this. It's something I could fix in all of 30 seconds, > >> so if there's any way that I could help, I'd be glad to. > > > > Isn't this superseeded (by the authors) by numpy? -- 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 Axel.Thimm at ATrpms.net Thu Jun 15 22:28:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 00:28:11 +0200 Subject: Who maintains python-numeric In-Reply-To: <1150409796.4381.7.camel@xavier.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> Message-ID: <20060615222811.GE15009@neu.nirvana> On Thu, Jun 15, 2006 at 06:16:36PM -0400, Jarod Wilson wrote: > On Thu, 2006-06-15 at 16:08 -0600, Rick Muller wrote: > > On Jun 15, 2006, at 4:01 PM, Axel Thimm wrote: > > > > > On Thu, Jun 15, 2006 at 02:49:11PM -0600, Rick Muller wrote: > > >> Who maintains python-numeric in extras? There has been a bug in the > > >> eigenvector routines for some time. I submitted a bug report some > > >> time ago about this. It's something I could fix in all of 30 seconds, > > >> so if there's any way that I could help, I'd be glad to. > > > > > > Isn't this superseeded (by the authors) by numpy? > > > Yes, python-numeric has been superceded by numpy, but python-numeric > > is still used as a dependency in many fedora packages, and thus it > > would be good to have a version where the eigensolver doesn't hang. Do you have a list of these packages? > > But maybe I'm the only person who cares about it, and, since I > > already have an easy workaround, it isn't that important. If there are bits offcially shipped that hang then it needs to be fixed. But I'd rather see python-numeric be removed altogether and the dependent packages be rebased on numpy. > Would it not be better to package numpy and put in Provides: and > Obsoletes: python-numeric? numpy superseeds numeric, but applications based on numeric need to be touched. For example instead of "import Numeric" you'll use "import numpy.oldnumeric". The numpy folks argue that if a dependent python package hasn't been converted to use numpy then it's effectively (upstream-)unmaintained. -- 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 Jun 15 22:42:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 16 Jun 2006 00:42:53 +0200 Subject: Who maintains python-numeric In-Reply-To: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> Message-ID: <20060616004253.a7f66092.bugs.michael@gmx.net> On Thu, 15 Jun 2006 14:49:11 -0600, Rick Muller wrote: > Who maintains python-numeric in extras? There has been a bug in the > eigenvector routines for some time. I submitted a bug report some > time ago about this. It's something I could fix in all of 30 seconds, > so if there's any way that I could help, I'd be glad to. > > Rick Looks like a Core package to me: $ rpm -q python-numeric python-numeric-23.7-2.2.1 $ rpm -qi python-numeric | grep Build Release : 2.2.1 Build Date: Sun 12 Feb 2006 09:59:37 AM CET Install Date: Thu 16 Feb 2006 03:23:29 PM CET Build Host: ls20-bc1-14.build.redhat.com $ rpm -q --changelog python-numeric|head * Fri Feb 10 2006 Jesse Keating - 23.7-2.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 23.7-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Feb 23 2005 Jonathan Blandford 23.7-2 From peter at thecodergeek.com Thu Jun 15 22:50:47 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 15 Jun 2006 15:50:47 -0700 (PDT) Subject: Who maintains python-numeric In-Reply-To: <20060616004253.a7f66092.bugs.michael@gmx.net> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060616004253.a7f66092.bugs.michael@gmx.net> Message-ID: <34151.127.0.0.1.1150411847.squirrel@www.thecodergeek.com> Michael Schwendt wrote: > Looks like a Core package to me: No. It's in Extras; not Core. See: http://cvs.fedora.redhat.com/cgi-bin/viewcvs.cgi/rpms/python-numeric/?root=extras Hope that helps. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From chris.stone at gmail.com Thu Jun 15 22:56:58 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 15 Jun 2006 15:56:58 -0700 Subject: Who maintains python-numeric In-Reply-To: <20060616004253.a7f66092.bugs.michael@gmx.net> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060616004253.a7f66092.bugs.michael@gmx.net> Message-ID: python-numeric is needed by pygame, it includes /usr/include/python2.4/Numeric/arrayobject.h does numpy also have these header files? From Axel.Thimm at ATrpms.net Thu Jun 15 23:19:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 01:19:43 +0200 Subject: Who maintains python-numeric In-Reply-To: <34151.127.0.0.1.1150411847.squirrel@www.thecodergeek.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060616004253.a7f66092.bugs.michael@gmx.net> <34151.127.0.0.1.1150411847.squirrel@www.thecodergeek.com> Message-ID: <20060615231943.GF15009@neu.nirvana> On Thu, Jun 15, 2006 at 03:50:47PM -0700, Peter Gordon wrote: > Michael Schwendt wrote: > > Looks like a Core package to me: > No. It's in Extras; not Core. > > See: > http://cvs.fedora.redhat.com/cgi-bin/viewcvs.cgi/rpms/python-numeric/?root=extras > > Hope that helps. No, it's in core, indeed: http://download.fedora.redhat.com/pub/fedora/linux/core/5/source/SRPMS/python-numeric-23.7-2.2.1.src.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/python-numeric-23.7-2.2.1.src.rpm -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Jun 15 23:38:34 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 15 Jun 2006 16:38:34 -0700 Subject: FESCo Voting Application Message-ID: <1150414714.20112.24.camel@localhost> Good day fellow citizens! The FESCo 2006 elections have been promised as soon as the Voting Application is complete. That time is rapidly approaching and FESCo would like to hold the election from July 22 until June 2. Before beginning, we'd like to exorcise any remaining bugs or issues with the code that we can. There are two ways that you can help do this: 1) The Voting Application is up on: https://admin.fedoraproject.org/voting/vote.cgi Feel free to try it out. Make sure it allows you to vote. Make sure it doesn't allow you to vote twice! 2) The Voting Application code is in fedora's cvs. If you want to look at the code and check for bugs, poor code, or security issues, you can view it on the web at: http://cvs.fedora.redhat.com/viewcvs/fedora-vote/?root=fedora or check out a copy: $ CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/fedora $ cvs login Logging in to :pserver:anonymous at cvs.fedora.redhat.com:2401/cvs/fedora CVS password: [No password. Just hit enter] $ cvs co fedora-vote Feel free to contact me with any issues you encounter: a.badger at gmail.com IRC: abadger1999 -Toshio From michael at knox.net.nz Thu Jun 15 23:42:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 16 Jun 2006 11:42:21 +1200 Subject: FESCo Voting Application In-Reply-To: <1150414714.20112.24.camel@localhost> References: <1150414714.20112.24.camel@localhost> Message-ID: <4491F05D.1000106@knox.net.nz> Toshio Kuratomi wrote: > Good day fellow citizens! > > The FESCo 2006 elections have been promised as soon as the Voting > Application is complete. That time is rapidly approaching and FESCo > would like to hold the election from July 22 until June 2. June 22 until July 2 maybe? :) Michael From michael at knox.net.nz Thu Jun 15 23:46:10 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 16 Jun 2006 11:46:10 +1200 Subject: FESCo Voting Application In-Reply-To: <1150414714.20112.24.camel@localhost> References: <1150414714.20112.24.camel@localhost> Message-ID: <4491F142.5070403@knox.net.nz> Toshio Kuratomi wrote: > 1) The Voting Application is up on: > https://admin.fedoraproject.org/voting/vote.cgi Nice work. > Feel free to try it out. Make sure it allows you to vote. Make sure > it doesn't allow you to vote twice! Certain didn't allow me to vote twice. > 2) The Voting Application code is in fedora's cvs. If you want to look > at the code and check for bugs, poor code, or security issues, you can > view it on the web at: > http://cvs.fedora.redhat.com/viewcvs/fedora-vote/?root=fedora > > or check out a copy: > $ CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/fedora > $ cvs login > Logging in to :pserver:anonymous at cvs.fedora.redhat.com:2401/cvs/fedora > CVS password: [No password. Just hit enter] > $ cvs co fedora-vote don't know enough about python to comment :) Thanks! Michael From a.badger at gmail.com Thu Jun 15 23:50:54 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 15 Jun 2006 16:50:54 -0700 Subject: FESCo Voting Application In-Reply-To: <4491F05D.1000106@knox.net.nz> References: <1150414714.20112.24.camel@localhost> <4491F05D.1000106@knox.net.nz> Message-ID: <1150415455.20112.27.camel@localhost> On Fri, 2006-06-16 at 11:42 +1200, Michael J. Knox wrote: > Toshio Kuratomi wrote: > > The FESCo 2006 elections have been promised as soon as the Voting > > Application is complete. That time is rapidly approaching and FESCo > > would like to hold the election from July 22 until June 2. > > June 22 until July 2 maybe? :) > Err. Yep. Good correction :-) From wwoods at redhat.com Fri Jun 16 00:44:49 2006 From: wwoods at redhat.com (Will Woods) Date: Thu, 15 Jun 2006 20:44:49 -0400 Subject: Help name the test project! Message-ID: <1150418689.26419.59.camel@metroid.rdu.redhat.com> Hello Fedorans! I need your help. I've started putting info about the Fedora testing project on the wiki - http://fedoraproject.org/wiki/FedoraTesting - but I've got a problem. "Fedora Testing" just isn't a very inspiring project name. It's supposed to encompass a lot more than just testing Fedora - it wants to be a project (under the auspices of the Fedora community) to create and promote testing tools and methods for Open Source Software in general. We want to test everything! We want to make "Fedora" and "Open Source" synonymous with "rock-solid". So "Fedora Testing" just doesn't feel like enough to me. Even more problematic is the Open Sourcing of Red Hat's automated test system, which they have named RHTS - Red Hat Test Suite. Surely we can come up with a more inspiring name for a massive automated software test suite/harness/system. Good names would be short, fairly unique, not trademarked, and it would be nice to avoid unpronounceable acronyms (like RHTS, XML-RPC, HTTP, USB, etc). Dogtail and Mugshot are a couple of good recent examples from Red Hat. Here are some possible project names: Proof Cassandra Witness FTL (Fedora Test League / Faster Than Light) And some names for an automated test suite: Turnstile (keeps the RHTS abbreviation for easy rebranding) Giant Testing Robot (GTR or testbot for short?) So - does anyone have a good name for these things? We need your help! We can't start mailing lists and websites without a good name! -w From rrelyea at redhat.com Fri Jun 16 00:45:44 2006 From: rrelyea at redhat.com (Bob Relyea) Date: Thu, 15 Jun 2006 17:45:44 -0700 Subject: Help name the test project! In-Reply-To: <1150418689.26419.59.camel@metroid.rdu.redhat.com> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> Message-ID: <4491FF38.1020609@redhat.com> Will Woods wrote: > So - does anyone have a good name for these things? We need your help! > We can't start mailing lists and websites without a good name! > 109 ;). bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3477 bytes Desc: S/MIME Cryptographic Signature URL: From packages at amiga-hardware.com Fri Jun 16 01:33:26 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Fri, 16 Jun 2006 02:33:26 +0100 Subject: Help name the test project! In-Reply-To: <1150418689.26419.59.camel@metroid.rdu.redhat.com> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> Message-ID: <44920A66.8060509@amiga-hardware.com> Will Woods wrote: > Here are some possible project names: > Proof > Cassandra > Witness > FTL (Fedora Test League / Faster Than Light) Project Rampart The Stalwart Project Titanium Granite > And some names for an automated test suite: > Turnstile (keeps the RHTS abbreviation for easy rebranding) > Giant Testing Robot (GTR or testbot for short?) Acid Barrage Litmus Mad Hatter Paventia -- Ian Chapman. From skvidal at linux.duke.edu Fri Jun 16 02:14:01 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Jun 2006 22:14:01 -0400 Subject: Help name the test project! In-Reply-To: <1150418689.26419.59.camel@metroid.rdu.redhat.com> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> Message-ID: <1150424041.29060.2.camel@cutter> On Thu, 2006-06-15 at 20:44 -0400, Will Woods wrote: > Hello Fedorans! I need your help. > Here are some possible project names: > Proof > Cassandra > Witness > FTL (Fedora Test League / Faster Than Light) > > And some names for an automated test suite: > Turnstile (keeps the RHTS abbreviation for easy rebranding) > Giant Testing Robot (GTR or testbot for short?) Canary as in - canary in a coal mine. Canaries in coal mines were used to detect natural gas leaks. They'd pass out first and the miners would be able to get out in time and/or look for the gas leak. -sv From chris.stone at gmail.com Fri Jun 16 02:33:29 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 15 Jun 2006 19:33:29 -0700 Subject: FESCo Voting Application In-Reply-To: <1150415455.20112.27.camel@localhost> References: <1150414714.20112.24.camel@localhost> <4491F05D.1000106@knox.net.nz> <1150415455.20112.27.camel@localhost> Message-ID: Links to Wiki homepages for these people would be helpful so I can know who I'm voting for. From tibbs at math.uh.edu Fri Jun 16 04:03:48 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 15 Jun 2006 23:03:48 -0500 Subject: FESCo Voting Application In-Reply-To: (Christopher Stone's message of "Thu, 15 Jun 2006 19:33:29 -0700") References: <1150414714.20112.24.camel@localhost> <4491F05D.1000106@knox.net.nz> <1150415455.20112.27.camel@localhost> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> Links to Wiki homepages for these people would be helpful so I can CS> know who I'm voting for. Some brief statements and links to personal pages are at: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations - J< From rc040203 at freenet.de Fri Jun 16 04:50:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 06:50:39 +0200 Subject: Help name the test project! In-Reply-To: <1150424041.29060.2.camel@cutter> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> <1150424041.29060.2.camel@cutter> Message-ID: <1150433440.12910.33.camel@mccallum.corsepiu.local> On Thu, 2006-06-15 at 22:14 -0400, seth vidal wrote: > Canary "Yum"(!) said the cat, when she tore that tiny noisy yellow bird into pieces ;) Ralf From gauret at free.fr Fri Jun 16 05:47:04 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 16 Jun 2006 07:47:04 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-15 References: <20060615205716.GC31124@lists.us.dell.com> Message-ID: > stow gauret at free.fr > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ It looks like this one built fine, the srpm and noarch.rpm are there. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programming From gauret at free.fr Fri Jun 16 05:52:35 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 16 Jun 2006 07:52:35 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-15 References: <20060615205746.GD31124@lists.us.dell.com> Message-ID: > amaya paul at all-the-johnsons.co.uk > mhonarc gauret at free.fr > perl-Unicode-Map8 gauret at free.fr > perl-Unicode-MapUTF8 gauret at free.fr Those are ExcludeArch'ed x86_64. Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Unix IS user-friendly. It is just very picky about who his friends are. From j.w.r.degoede at hhs.nl Fri Jun 16 08:01:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 16 Jun 2006 10:01:35 +0200 Subject: FESCo Voting Application In-Reply-To: <1150414714.20112.24.camel@localhost> References: <1150414714.20112.24.camel@localhost> Message-ID: <4492655F.4010806@hhs.nl> Toshio Kuratomi wrote: > Good day fellow citizens! > > The FESCo 2006 elections have been promised as soon as the Voting > Application is complete. That time is rapidly approaching and FESCo > would like to hold the election from July 22 until June 2. Before > beginning, we'd like to exorcise any remaining bugs or issues with the > code that we can. There are two ways that you can help do this: > > 1) The Voting Application is up on: > https://admin.fedoraproject.org/voting/vote.cgi > > Feel free to try it out. Make sure it allows you to vote. Make sure > it doesn't allow you to vote twice! > Works for me. Regards, Hans From andreas.bierfert at lowlatency.de Fri Jun 16 08:21:49 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 16 Jun 2006 10:21:49 +0200 Subject: Need help with upgrade path Message-ID: <20060616102149.754628be@alkaid.a.lan> Hi folks, I need some help with an rpm upgrade path. Till Now: wine and its (many) subpackages Future: wine meta package (with requires what is needed for normal desktop users) wine changed to wine-core Plan: Don't make people install all requires of the meta package during the transition. Idea was to maybe add an Obsoletes wine <= 0.9.15-1 to wine-core... but before I go and mess stuff up I'd rather ask some gurus on that topic ;) Thanks for your help. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dhowells at redhat.com Fri Jun 16 08:53:00 2006 From: dhowells at redhat.com (David Howells) Date: Fri, 16 Jun 2006 09:53:00 +0100 Subject: Help name the test project! In-Reply-To: <1150418689.26419.59.camel@metroid.rdu.redhat.com> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> Message-ID: <5728.1150447980@warthog.cambridge.redhat.com> Will Woods wrote: > Good names would be short, fairly unique, not trademarked, and it would > be nice to avoid unpronounceable acronyms (like RHTS, XML-RPC, HTTP, > USB, etc). Dogtail and Mugshot are a couple of good recent examples from > Red Hat. How about "Inquisition"... after all, no-one ever expects it, right? David From andreas.bierfert at lowlatency.de Fri Jun 16 08:59:08 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 16 Jun 2006 10:59:08 +0200 Subject: Need help with upgrade path In-Reply-To: <20060616102149.754628be@alkaid.a.lan> References: <20060616102149.754628be@alkaid.a.lan> Message-ID: <20060616105908.5356d851@alkaid.a.lan> On Fri, 16 Jun 2006 10:21:49 +0200 Andreas Bierfert wrote: > Future: > wine meta package (with requires what is needed for normal desktop users) ^ which -Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Fri Jun 16 10:06:49 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 16 Jun 2006 12:06:49 +0200 Subject: Vacation 2006-06-17 - 2006-07-01 Message-ID: <1150452410.27466.77.camel@gibraltar.stuttgart.redhat.com> Hi all, I'll be on vacation for the coming two weeks and would appreciate if someone could spy on me Bugzilla-wise. Thanks in advance, 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 cranium2003 at yahoo.com Fri Jun 16 10:10:15 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Fri, 16 Jun 2006 03:10:15 -0700 (PDT) Subject: Mock build problem In-Reply-To: <44916A01.8080002@city-fan.org> Message-ID: <20060616101015.56503.qmail@web38007.mail.mud.yahoo.com> hi, --- Paul Howarth wrote: > > Right. The bad news then is that your mirror of > fedora-development is > useless to you. > > You will need local mirrors/repos for FC5 i386 > [core], FC5 i386 > [updates-released], FC5 i386 [extras], and FC5 i386 > [groups]. > > You can use your FC5 ISO image(s) as a local [core] > repo: > http://www.city-fan.org/tips/YumRepoFromImages > > To make the FC5 updates and extras mirrors, you'll > need in your > fedora-mirror script: > > flavourlist=["extras", "updates"] > versionlist=["5"] > archlist=["i386"] > subflavourlist=["binary"] > > You will need to create mirror repo files too. > Copy fedora-updates.repo to > mirror-fedora-updates.repo and copy > fedora-extras.repo to mirror-fedora-extras.repo. In > the mirror-*.repo > files, edit the repo IDs (the names in square > brackets) by putting > "mirror-" in front of them (like you did with the > mirror-fedora-development repo file), so for > instance > [updates] gets changed to [mirror-updates]. > > You should then be able to run fedora-mirror to > create and keep up to > date your local FC5 mirrors. > > As for the local [groups] mirror, create it as > follows: > > # cd /home/source/fedora > # mkdir -p 5/core/i386/groups > # mv development/core/i386/*/minimal.xml > 5/core/i386/groups > # cd 5/core/i386/groups > # wget > http://fedoraproject.org/buildgroups/5/i386/buildsys-macros-5-2.fc5.noarch.rpm > # wget > http://fedoraproject.org/buildgroups/5/i386/buildsys-macros-5-2.fc5.src.rpm > # createrepo -g minimal.xml . > > > The mock config file (fedora-5-i386-core.cfg) should > look like: > > #!/usr/bin/python -tt > > import os > config_opts['root'] = 'fedora-development-i386-core' > config_opts['basedir'] = '/var/lib/mock/' > config_opts['chroot'] = '/usr/sbin/mock-helper > chroot' > config_opts['mount'] = '/usr/sbin/mock-helper mount' > config_opts['umount'] = '/usr/sbin/mock-helper > umount' > config_opts['rm'] = '/usr/sbin/mock-helper rm' > config_opts['mknod'] = '/usr/sbin/mock-helper mknod' > config_opts['yum'] = '/usr/sbin/mock-helper yum' > config_opts['runuser'] = '/sbin/runuser' > config_opts['buildgroup'] = 'build' > config_opts['chrootuser'] = 'mockbuild' > config_opts['chrootgroup'] = 'mockbuild' > config_opts['chrootuid'] = os.geteuid() > config_opts['chrootgid'] = os.getegid() > config_opts['chroothome'] = '/builddir' > config_opts['clean'] = True > config_opts['target_arch'] = 'i386' > > > config_opts['yum.conf'] = """ > [main] > cachedir=/var/cache/yum > debuglevel=1 > reposdir=/dev/null > logfile=/var/log/yum.log > retries=20 > obsoletes=1 > gpgcheck=0 > assumeyes=1 > > # repos > > [core] > name=core > #baseurl=http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/i386 > #mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-5 > baseurl=file:///home/source/fedora/5/core/i386/mirror-core > > [updates-released] > name=updates > #mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc5 > baseurl=file:///home/source/fedora/5/updates/i386/mirror-updates > > [groups] > name=groups > #baseurl=http://buildsys.fedoraproject.org/buildgroups/5/i386/ > baseurl=file:///home/source/fedora/5/core/i386/groups > > [extras] > name=extras > #mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-5 > baseurl=file:///home/source/fedora/5/extras/i386/mirror-extras > > [local] > name=local > baseurl=http://extras64.linux.duke.edu/plague-results/fedora-5-extras > enabled=0 > > """ > > > That assumes that you created your local FC5 core > repo at > /home/source/fedora/5/core/i386/mirror-core. Can you also tell me what will be final fedora-development-i386-core.cfg file, if i decide to use development version instead of FC5?? Can it be ok to replace 5 with development and install development repositories at those locations like core extras group but what will be url for updates and local for development repository? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dtimms at bigpond.net.au Fri Jun 16 11:00:29 2006 From: dtimms at bigpond.net.au (David Timms) Date: Fri, 16 Jun 2006 21:00:29 +1000 Subject: FESCo Voting Application In-Reply-To: <1150414714.20112.24.camel@localhost> References: <1150414714.20112.24.camel@localhost> Message-ID: <44928F4D.5000205@bigpond.net.au> Toshio Kuratomi wrote: > 1) The Voting Application is up on: > https://admin.fedoraproject.org/voting/vote.cgi > > Feel free to try it out. Make sure it allows you to vote. Make sure > it doesn't allow you to vote twice! 1. unknown user is rejected with a username or password not valid. OK. 2. if username is always name at somewhere.wherever, could be good as a reminder of what your username is likely to be in this system. Perhaps email address ? 3. if account OK, but not allowed to vote, "not a member of one of the groups eligible to vote". OK. 4. site is secure https. OK. DaveT. From paul at city-fan.org Fri Jun 16 11:01:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 16 Jun 2006 12:01:19 +0100 Subject: Mock build problem In-Reply-To: <20060616101015.56503.qmail@web38007.mail.mud.yahoo.com> References: <20060616101015.56503.qmail@web38007.mail.mud.yahoo.com> Message-ID: <44928F7F.4050702@city-fan.org> cranium2003 wrote: > Can you also tell me what will be final > fedora-development-i386-core.cfg file, if i decide to > use development version instead of FC5?? Can it be ok > to replace 5 with development and install development > repositories at those locations like > core > extras > group > but what will be url for updates and local for > development repository? Just follow the same procedure as for FC5, except that there is no updates repo for development (updates go straight into "core") and you have the "local" repo disabled so it doesn't matter what the URL for that is. Paul. From jima at beer.tclug.org Fri Jun 16 11:13:13 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 16 Jun 2006 06:13:13 -0500 (CDT) Subject: FESCo Voting Application In-Reply-To: <44928F4D.5000205@bigpond.net.au> References: <1150414714.20112.24.camel@localhost> <44928F4D.5000205@bigpond.net.au> Message-ID: On Fri, 16 Jun 2006, David Timms wrote: > 2. if username is always name at somewhere.wherever, could be good as a reminder > of what your username is likely to be in this system. Perhaps email address ? If you don't know your Accounts system login, I'm not sure we want you voting. ;) Seriously, though, if you need it, I think you could probably ask anyone, because it should be in the cvsextras group list (which I think may be one of the qualifiers for voting). Jima From jima at beer.tclug.org Fri Jun 16 11:23:33 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 16 Jun 2006 06:23:33 -0500 (CDT) Subject: FESCo Voting Application In-Reply-To: References: <1150414714.20112.24.camel@localhost> <44928F4D.5000205@bigpond.net.au> Message-ID: On Fri, 16 Jun 2006, Jima wrote: > On Fri, 16 Jun 2006, David Timms wrote: >> 2. if username is always name at somewhere.wherever, could be good as a >> reminder of what your username is likely to be in this system. Perhaps >> email address ? > > Seriously, though, if you need it, I think you could probably ask anyone, > because it should be in the cvsextras group list (which I think may be one of > the qualifiers for voting). Or rather, look at: https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html Which you don't appear on? Huh. Jima From Christian.Iseli at licr.org Fri Jun 16 11:49:50 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 16 Jun 2006 13:49:50 +0200 Subject: FESCo Voting Application In-Reply-To: Your message of "Thu, 15 Jun 2006 16:38:34 PDT." <1150414714.20112.24.camel@localhost> Message-ID: <200606161149.k5GBnog7010502@ludwig-alpha.unil.ch> a.badger at gmail.com said: > Feel free to try it out. Make sure it allows you to vote. Make sure it > doesn't allow you to vote twice! WORKSFORME :) Thanks for taking care of this! Christian From bugs.michael at gmx.net Fri Jun 16 14:44:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 16 Jun 2006 16:44:18 +0200 Subject: IMPORTANT: FE - ExcludeArch for noarch packages Message-ID: <20060616164418.59b3c698.bugs.michael@gmx.net> Concerning Fedora Extras As of today, the Fedora Extras "push script", which GPG signs and publishes packages found in the "needsign" repository, respects ExcludeArch also in .noarch (!) packages. It has not done this before and has published noarch packages for all platforms. I've done the last couple of pushs with this feature enabled to see whether any package would trigger the new feature. Today, I got this warning: EXCLUDEARCH: Not releasing mhonarc-2.6.16-1.fc6.noarch.rpm for x86_64. Conclusively, it seems we have published packages like this in the repository unknowingly. You may need to submit removal requests in the Wiki for any old noarch packages, which have been published before for an architecture that should have been excluded. (Note, I've removed mhonarc for x86_64 already.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Jun 16 15:23:19 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 16 Jun 2006 11:23:19 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-16 Message-ID: <20060616152319.A4B3615217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 21 abcMIDI-20060608-1.fc5 abcm2ps-5.0.0-1.fc5 byzanz-0.1.1-2.fc5 cal3d-0.10.0-4.fc5 gstreamer-python-0.10.4-1.fc5 ikvm-0.22-8.fc5 lyx-1.4.1-8.fc5 mhonarc-2.6.16-1.fc5 mod_annodex-0.2.2-4.fc5 nagios-plugins-1.4.3-9.fc5 nfswatch-4.99.6-1.fc5 openalpp-20060405-9.fc5 perl-Event-1.06-1.fc5 perl-POE-0.3501-2.fc5 perltidy-20060614-1.fc5 pstoedit-3.44-2.fc5 q-7.1-2.fc5 qucs-0.0.9-4.fc5 sylpheed-claws-plugins-2.3.0-1.fc5 texmaker-1.3-5.fc5 vnc-reflector-1.2.4-1.fc5 Packages built and released for Fedora Extras 4: 16 abcMIDI-20060608-1.fc4 abcm2ps-5.0.0-1.fc4 cal3d-0.10.0-4.fc4 lyx-1.4.1-8.fc4 mod_annodex-0.2.2-4.fc4 nagios-plugins-1.4.3-9.fc4 nfswatch-4.99.6-1.fc4 openalpp-20060405-9.fc4 perl-Event-1.06-1.fc4 perl-POE-0.3501-2.fc4 pstoedit-3.44-2.fc4 q-7.1-2.fc4 qucs-0.0.9-4.fc4 sylpheed-claws-plugins-2.3.0-1.fc4 texmaker-1.3-5.fc4 vnc-reflector-1.2.4-1.fc4 Packages built and released for Fedora Extras 3: 2 abcm2ps-5.0.0-1.fc3 qucs-0.0.9-4.fc3 Packages built and released for Fedora Extras development: 39 PyQt-qscintilla-3.16-3.fc6 abcMIDI-20060608-1.fc6 abcm2ps-5.0.0-1.fc6 byzanz-0.1.1-2.fc6 cal3d-0.10.0-4.fc6 dbus-qt-0.62-1.fc6 dejavu-fonts-2.7.0-0.15.fc6 ganglia-3.0.3-7.fc6 gstreamer-python-0.10.4-1.fc6 gtk+-1.2.10-53.fc6 iftop-0.17-2.fc6 ikvm-0.22-8.fc6 libgda-1.9.100-8.fc6 libtranslate-0.99-7.fc6 licq-1.3.2-8 logjam-4.5.3-4.fc6 loudmouth-1.0.3-5.fc6 lyx-1.4.1-8.fc6 mail-notification-3.0-1.fc6 mhonarc-2.6.16-1.fc6 mod_annodex-0.2.2-4.fc6 monodoc-1.1.13-10.fc6 nfswatch-4.99.6-1.fc6 openalpp-20060405-9.fc6 paps-0.6.6-4.fc6 perl-Event-1.06-1.fc6 perl-POE-0.3501-2.fc6 perltidy-20060614-1.fc6 pessulus-0.10.1-2.fc6 poker-engine-1.0.15-3.fc6.1 pstoedit-3.44-2.fc6 pure-ftpd-1.0.21-6.fc6 python-chm-0.8.3-1.fc6 qucs-0.0.9-4.fc6 sylpheed-claws-plugins-2.3.0-1.fc6 texmaker-1.3-5.fc6 vnc-reflector-1.2.4-1.fc6 xscreensaver-5.00-7.1.fc6 xsp-1.1.15-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Jun 16 15:23:33 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 16 Jun 2006 11:23:33 -0400 (EDT) Subject: Broken upgrade paths in Fedora Extras 2006-06-16 Message-ID: <20060616152333.2B79315217C@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 6: 0:2.4.0.3-0.20060328cvs_5.fc6 banshee: 5: 0:0.10.9-1..fc5 6: 0:0.10.8-1 fish: 4: 0:1.14.0-1.fc4 5: 0:1.12.0-1.fc5 6: 0:1.12.0-1.fc5 fuse-encfs: 5: 0:1.3.1-1.fc5 6: 0:1.3.0-1.fc6 istanbul: 5: 0:0.1.1-9.fc5 6: 0:0.1.1-9 libxml++: 5: 0:2.14.0-1.fc5 6: 0:2.12.0-2.1.fc5 nail: 5: 0:12.0-2.fc5 6: 0:12.0-1.fc6 nsd: 3: 0:2.3.4-5.fc3 4: 0:2.3.4-4.fc4 5: 0:2.3.4-4.fc5 6: 0:2.3.4-3.fc6 otrs: 5: 0:2.0.4-3.fc5 6: 0:2.0.4-3 paraview: 4: 0:2.4.3-7.fc4 5: 0:2.4.3-6.fc5 6: 0:2.4.3-7.fc6 pygame: 5: 0:1.7.1-7.fc5 6: 0:1.7.1-6.fc6 pylint: 5: 0:0.11.0-1.fc5 6: 0:0.10.0-1.fc5 python-astng: 5: 0:0.16.0-0.fc5 6: 0:0.15.1-1.fc5 python-myghty: 5: 0:1.0.1-2.fc5 6: 0:1.0.1-1.fc5 rssowl: 5: 0:1.2.1-2.fc5 6: 0:1.2-12.fc6 scponly: 5: 0:4.6-3.fc5 6: 0:4.6-1.fc5 stratagus: 5: 0:2.1-6.fc5 6: 0:2.1-5.fc6 subversion-api-docs: 5: 0:1.3.2-1.fc5 6: 0:1.3.1-1.fc6 wine-docs: 3: 0:0.9.15-1.fc3 4: 0:0.9.15-0.1.fc4 5: 0:0.9.15-1.fc5 6: 0:0.9.15-1.fc6 From paul at city-fan.org Fri Jun 16 15:49:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 16 Jun 2006 16:49:52 +0100 Subject: Broken upgrade paths in Fedora Extras 2006-06-16 In-Reply-To: <20060616152333.2B79315217C@buildsys.fedoraproject.org> References: <20060616152333.2B79315217C@buildsys.fedoraproject.org> Message-ID: <4492D320.7080206@city-fan.org> buildsys at fedoraproject.org wrote: > azureus: > 5: 0:2.4.0.3-0.20060529cvs_1.fc5 > 6: 0:2.4.0.3-0.20060328cvs_5.fc6 ... Perhaps the script could be enhanced to take into account packages that have migrated from Core to Extras and vice versa? I know that one of my packages has a broken upgrade path like this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191686 Paul. From buildsys at fedoraproject.org Fri Jun 16 15:40:50 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 16 Jun 2006 15:40:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-16 Message-ID: <20060616154050.19295.80592@extras64.linux.duke.edu> ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc6.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc6.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc6.src.rpm Summary of broken packages (by owner): ---------------------------------------------------------------------- UNKNOWN OWNER perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 scribus - 1.3.3.2-1.fc6.i386 scribus - 1.3.3.2-1.fc6.ppc scribus - 1.3.3.2-1.fc6.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 chabotc AT xs4all.nl buoh - 0.8.1-7.i386 buoh - 0.8.1-7.ppc buoh - 0.8.1-7.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 fedora.wickert AT arcor.de xfce4-mailwatch-plugin - 1.0.0-2.fc6.i386 xfce4-mailwatch-plugin - 1.0.0-2.fc6.ppc xfce4-mailwatch-plugin - 1.0.0-2.fc6.x86_64 fedora AT soeterbroek.com heartbeat - 2.0.5-1.fc6.i386 heartbeat - 2.0.5-1.fc6.ppc heartbeat - 2.0.5-1.fc6.x86_64 stonith - 2.0.5-1.fc6.i386 stonith - 2.0.5-1.fc6.ppc stonith - 2.0.5-1.fc6.x86_64 gauret AT free.fr showimg-pgsql - 0.9.5-5.fc5.i386 showimg-pgsql - 0.9.5-5.fc5.ppc showimg-pgsql - 0.9.5-5.fc5.x86_64 gemi AT bluewin.ch gtklp - 1.2.2-1.fc6.i386 gtklp - 1.2.2-1.fc6.ppc gtklp - 1.2.2-1.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc kevin-redhat-bugzilla AT tummy.com bmp-xosd - 2.2.14-6.fc6.i386 bmp-xosd - 2.2.14-6.fc6.ppc bmp-xosd - 2.2.14-6.fc6.x86_64 xfprint - 4.2.3-3.fc6.i386 xfprint - 4.2.3-3.fc6.ppc xfprint - 4.2.3-3.fc6.x86_64 xmms-xosd - 2.2.14-6.fc6.i386 xmms-xosd - 2.2.14-6.fc6.ppc xmms-xosd - 2.2.14-6.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 net6 - 1.3.0-2.rc2.fc6.i386 net6 - 1.3.0-2.rc2.fc6.ppc net6 - 1.3.0-2.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 michael AT knox.net.nz gurlchecker - 0.10.0-2.fc6.i386 gurlchecker - 0.10.0-2.fc6.ppc gurlchecker - 0.10.0-2.fc6.x86_64 nicolas.mailhot AT laposte.net dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch nos AT utelsystems.com soundtracker - 0.6.7-3.x86_64 soundtracker - 0.6.7-4.i386 soundtracker - 0.6.7-4.ppc oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 roozbeh AT farsiweb.info autotrace - 0.31.1-12.fc5.i386 autotrace - 0.31.1-12.fc5.ppc autotrace - 0.31.1-12.fc5.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 autotrace-0.31.1-12.fc5.i386 requires libMagick.so.9 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 buoh-0.8.1-7.i386 requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtklp-1.2.2-1.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 gurlchecker-0.10.0-2.fc6.i386 requires libgnutls.so.12 gurlchecker-0.10.0-2.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) heartbeat-2.0.5-1.fc6.i386 requires libgnutls.so.12 heartbeat-2.0.5-1.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 net6-1.3.0-2.rc2.fc6.i386 requires libgnutls.so.12 net6-1.3.0-2.rc2.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.i386 requires libgdk_imlib.so.1 scribus-1.3.3.2-1.fc6.i386 requires libgnutls.so.12 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.i386 requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 soundtracker-0.6.7-4.i386 requires libgdk_pixbuf.so.2 stonith-2.0.5-1.fc6.i386 requires libgnutls.so.12 stonith-2.0.5-1.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xfce4-mailwatch-plugin-1.0.0-2.fc6.i386 requires libgnutls.so.12 xfce4-mailwatch-plugin-1.0.0-2.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) xfprint-4.2.3-3.fc6.i386 requires libgnutls.so.12 xmms-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 autotrace-0.31.1-12.fc5.ppc requires libMagick.so.9 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 buoh-0.8.1-7.ppc requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtklp-1.2.2-1.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 gurlchecker-0.10.0-2.fc6.ppc requires libgnutls.so.12 gurlchecker-0.10.0-2.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) heartbeat-2.0.5-1.fc6.ppc requires libgnutls.so.12 heartbeat-2.0.5-1.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 net6-1.3.0-2.rc2.fc6.ppc requires libgnutls.so.12 net6-1.3.0-2.rc2.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.ppc requires libgdk_imlib.so.1 scribus-1.3.3.2-1.fc6.ppc requires libgnutls.so.12 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.ppc requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 soundtracker-0.6.7-4.ppc requires libgdk_pixbuf.so.2 stonith-2.0.5-1.fc6.ppc requires libgnutls.so.12 stonith-2.0.5-1.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xfce4-mailwatch-plugin-1.0.0-2.fc6.ppc requires libgnutls.so.12 xfce4-mailwatch-plugin-1.0.0-2.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) xfprint-4.2.3-3.fc6.ppc requires libgnutls.so.12 xmms-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_pixbuf.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) autotrace-0.31.1-12.fc5.x86_64 requires libMagick.so.9()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bmp-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) buoh-0.8.1-7.x86_64 requires libgnutls.so.12()(64bit) dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtklp-1.2.2-1.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) gurlchecker-0.10.0-2.fc6.x86_64 requires libgnutls.so.12()(64bit) gurlchecker-0.10.0-2.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) heartbeat-2.0.5-1.fc6.x86_64 requires libgnutls.so.12()(64bit) heartbeat-2.0.5-1.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) net6-1.3.0-2.rc2.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) net6-1.3.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) scribus-1.3.3.2-1.fc6.x86_64 requires libgnutls.so.12()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) showimg-pgsql-0.9.5-5.fc5.x86_64 requires libpqxx-2.5.5.so()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) soundtracker-0.6.7-3.x86_64 requires libgdk_pixbuf.so.2()(64bit) stonith-2.0.5-1.fc6.x86_64 requires libgnutls.so.12()(64bit) stonith-2.0.5-1.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xfce4-mailwatch-plugin-1.0.0-2.fc6.x86_64 requires libgnutls.so.12()(64bit) xfce4-mailwatch-plugin-1.0.0-2.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) xfprint-4.2.3-3.fc6.x86_64 requires libgnutls.so.12()(64bit) xmms-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) ====================================================================== New report for: nos AT utelsystems.com package: soundtracker - 0.6.7-4.i386 from fedora-extras-development-i386 unresolved deps: libgdk_pixbuf.so.2 package: soundtracker - 0.6.7-3.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_pixbuf.so.2()(64bit) package: soundtracker - 0.6.7-4.ppc from fedora-extras-development-ppc unresolved deps: libgdk_pixbuf.so.2 ====================================================================== New report for: michael AT knox.net.nz package: gurlchecker - 0.10.0-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: gurlchecker - 0.10.0-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) libgnutls.so.12(GNUTLS_1_2)(64bit) package: gurlchecker - 0.10.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: scribus - 1.3.3.2-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: qiv - 2.0-4.i386 from fedora-extras-development-i386 unresolved deps: libgdk_imlib.so.1 package: qiv - 2.0-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) package: scribus - 1.3.3.2-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: scribus - 1.3.3.2-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: qiv - 2.0-4.ppc from fedora-extras-development-ppc unresolved deps: libgdk_imlib.so.1 ====================================================================== New report for: byte AT fedoraproject.org package: MagicPoint - 1.11b-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: imlib libImlib.so.11 package: MagicPoint - 1.11b-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libImlib.so.11()(64bit) imlib package: MagicPoint - 1.11b-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: imlib libImlib.so.11 ====================================================================== New report for: fedora AT soeterbroek.com package: heartbeat - 2.0.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: stonith - 2.0.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: heartbeat - 2.0.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) libgnutls.so.12(GNUTLS_1_2)(64bit) package: stonith - 2.0.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) libgnutls.so.12(GNUTLS_1_2)(64bit) package: stonith - 2.0.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: heartbeat - 2.0.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) ====================================================================== New report for: skvidal AT phy.duke.edu package: seahorse - 0.8-3.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: seahorse - 0.8-3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: seahorse - 0.8-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 ====================================================================== New report for: paul AT all-the-johnsons.co.uk package: amaya - 9.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgdk_imlib.so.1 package: amaya - 8.5-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) package: amaya - 9.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgdk_imlib.so.1 ====================================================================== New report for: kevin-redhat-bugzilla AT tummy.com package: bmp-xosd - 2.2.14-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgdk_pixbuf.so.2 package: xfprint - 4.2.3-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: xmms-xosd - 2.2.14-6.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgdk_pixbuf.so.2 package: bmp-xosd - 2.2.14-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_pixbuf.so.2()(64bit) package: xfprint - 4.2.3-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: xmms-xosd - 2.2.14-6.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_pixbuf.so.2()(64bit) package: bmp-xosd - 2.2.14-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgdk_pixbuf.so.2 package: xfprint - 4.2.3-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: xmms-xosd - 2.2.14-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgdk_pixbuf.so.2 ====================================================================== New report for: UNKNOWN OWNER package: perl-POE - 0.3501-2.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(POE::Resource::Controls) ====================================================================== New report for: lmacken AT redhat.com package: gobby - 0.4.0-3.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: sobby - 0.4.0-2.rc1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: net6 - 1.3.0-2.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: obby - 0.4.0-2.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: gobby - 0.4.0-3.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: net6 - 1.3.0-2.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12(GNUTLS_1_2)(64bit) libgnutls.so.12()(64bit) package: obby - 0.4.0-2.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: sobby - 0.4.0-2.rc1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: gobby - 0.4.0-3.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: sobby - 0.4.0-2.rc1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: net6 - 1.3.0-2.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: obby - 0.4.0-2.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 ====================================================================== New report for: fedora.wickert AT arcor.de package: xfce4-mailwatch-plugin - 1.0.0-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) package: xfce4-mailwatch-plugin - 1.0.0-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) libgnutls.so.12(GNUTLS_1_2)(64bit) package: xfce4-mailwatch-plugin - 1.0.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 libgnutls.so.12(GNUTLS_1_2) ====================================================================== New report for: gemi AT bluewin.ch package: gtklp - 1.2.2-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: gtklp - 1.2.2-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: gtklp - 1.2.2-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 ====================================================================== New report for: chabotc AT xs4all.nl package: buoh - 0.8.1-7.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: buoh - 0.8.1-7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: buoh - 0.8.1-7.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 From buildsys at fedoraproject.org Fri Jun 16 15:40:50 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 16 Jun 2006 15:40:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-16 Message-ID: <20060616154050.19286.73285@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Fri Jun 16 15:40:50 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 16 Jun 2006 15:40:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-16 Message-ID: <20060616154050.19292.57284@extras64.linux.duke.edu> ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc5.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc5.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc5.src.rpm Summary of broken packages (by owner): ---------------------------------------------------------------------- UNKNOWN OWNER perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 ====================================================================== New report for: UNKNOWN OWNER package: perl-POE - 0.3501-2.fc5.noarch from fedora-extras-5-i386 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc5.noarch from fedora-extras-5-ppc unresolved deps: perl(POE::Resource::Controls) From buildsys at fedoraproject.org Fri Jun 16 15:40:50 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 16 Jun 2006 15:40:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-16 Message-ID: <20060616154050.19290.16452@extras64.linux.duke.edu> ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc4.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc4.src.rpm ERROR: perl-POE not in owners.list ERROR: source rpm is perl-POE-0.3501-2.fc4.src.rpm Summary of broken packages (by owner): ---------------------------------------------------------------------- UNKNOWN OWNER perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) ====================================================================== New report for: UNKNOWN OWNER package: perl-POE - 0.3501-2.fc4.noarch from fedora-extras-4-i386 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: perl(POE::Resource::Controls) package: perl-POE - 0.3501-2.fc4.noarch from fedora-extras-4-ppc unresolved deps: perl(POE::Resource::Controls) From notting at redhat.com Fri Jun 16 16:13:28 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Jun 2006 12:13:28 -0400 Subject: Broken upgrade paths in Fedora Extras 2006-06-16 In-Reply-To: <4492D320.7080206@city-fan.org> References: <20060616152333.2B79315217C@buildsys.fedoraproject.org> <4492D320.7080206@city-fan.org> Message-ID: <20060616161328.GA11240@nostromo.devel.redhat.com> Paul Howarth (paul at city-fan.org) said: > buildsys at fedoraproject.org wrote: > >azureus: > > 5: 0:2.4.0.3-0.20060529cvs_1.fc5 > > 6: 0:2.4.0.3-0.20060328cvs_5.fc6 > > ... > > Perhaps the script could be enhanced to take into account packages that > have migrated from Core to Extras and vice versa? I know that one of my > packages has a broken upgrade path like this. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191686 Heck, I wouldn't mind if you ran it for Core too. :) Bill From rmuller at sandia.gov Fri Jun 16 17:13:17 2006 From: rmuller at sandia.gov (Rick Muller) Date: Fri, 16 Jun 2006 11:13:17 -0600 Subject: Who maintains python-numeric In-Reply-To: <20060615222811.GE15009@neu.nirvana> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> Message-ID: <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> On Jun 15, 2006, at 4:28 PM, Axel Thimm wrote: >>> Yes, python-numeric has been superceded by numpy, but python-numeric >>> is still used as a dependency in many fedora packages, and thus it >>> would be good to have a version where the eigensolver doesn't hang. > > Do you have a list of these packages? Here's a list of the dependencies when I try to remove python- numeric. People more adept at the intricacies of yum may be able to generate a more complete list: authconfig-gtk firstboot gedit gnome-python2-canvas hwbrowser pirut pygtk2 pygtk2-devel pygtk2-libglade rhn-applet system-config-date system-config-display system-config-httpd system-config-language system-config-lvm system-config-network system-config-nfs system-config-printer-gui system-config-rootpassword system-config-samba system-config-securitylevel system-config-services system-config-soundcard system-config-users up2date-gnome > >>> But maybe I'm the only person who cares about it, and, since I >>> already have an easy workaround, it isn't that important. > > If there are bits offcially shipped that hang then it needs to be > fixed. But I'd rather see python-numeric be removed altogether and the > dependent packages be rebased on numpy. > Okay. It sounds like you're pretty much on top of this. Let me know if I can help. >> Would it not be better to package numpy and put in Provides: and >> Obsoletes: python-numeric? > > numpy superseeds numeric, but applications based on numeric need to be > touched. For example instead of "import Numeric" you'll use "import > numpy.oldnumeric". > > The numpy folks argue that if a dependent python package hasn't been > converted to use numpy then it's effectively (upstream-)unmaintained. From jkeating at redhat.com Fri Jun 16 17:38:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Jun 2006 13:38:36 -0400 Subject: Who maintains python-numeric In-Reply-To: <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> Message-ID: <1150479516.9157.7.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-06-16 at 11:13 -0600, Rick Muller wrote: > > Here's a list of the dependencies when I try to remove python- > numeric. People more adept at the intricacies of yum may be able to > generate a more complete list: These are a lot of core packages... there is a python-numeric in Core. /me is confused... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Fri Jun 16 17:45:19 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 16 Jun 2006 13:45:19 -0400 Subject: [Bug 171039] Review Request: geos In-Reply-To: Message-ID: <200606161745.k5GHjJCF027392@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: geos https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171039 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From Axel.Thimm at ATrpms.net Fri Jun 16 18:15:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 20:15:39 +0200 Subject: Who maintains python-numeric In-Reply-To: <1150479516.9157.7.camel@dhcp83-49.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150479516.9157.7.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060616181539.GB25495@neu.nirvana> On Fri, Jun 16, 2006 at 01:38:36PM -0400, Jesse Keating wrote: > On Fri, 2006-06-16 at 11:13 -0600, Rick Muller wrote: > > > > Here's a list of the dependencies when I try to remove python- > > numeric. People more adept at the intricacies of yum may be able to > > generate a more complete list: > > These are a lot of core packages... there is a python-numeric in Core. > > /me is confused... > For quite some time Numeric's web page says: *Development has ceased* for Numeric, and users should transisition to NumPy as quickly as possible. So numeric needs to be replaced by numby. The end result should be numpy in core (to support pygtk) and perhaps a compat numeric package in extras for applications that did not make the conversion (and which the numeric/numarray/numpy developers therefore define as "unmaintained"). -- 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 Matt_Domsch at dell.com Fri Jun 16 18:23:07 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 16 Jun 2006 13:23:07 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-16 Message-ID: <20060616182307.GC12968@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Fri Jun 16 13:14:25 CDT 2006 Number failed to build: 172 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 161 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 157 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz-0.1.1-1.fc6.src.rpm camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt-0.61-3.fc6.src.rpm ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop-0.17-1.fc5.src.rpm jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda-1.9.100-7.fc6.src.rpm libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate-0.99-6.fc6.src.rpm licq-1.3.2-7.src.rpm lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam-4.5.3-3.fc6.src.rpm lucidlife peter at thecodergeek.com mftrace qspencer at ieee.org mhonarc-2.6.15-4.fc5.src.rpm mod_suphp andreas at bawue.net multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp-20060405-8.fc6.src.rpm opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org paps-0.6.6-3.fc6.src.rpm perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-extras dmitry at butskoy.name php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd-1.0.21-5.fc6.src.rpm pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp-1.1.15-2.fc6.src.rpm z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 Fri Jun 16 18:23:30 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 16 Jun 2006 13:23:30 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-16 Message-ID: <20060616182330.GD12968@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Fri Jun 16 13:16:08 CDT 2006 Number failed to build: 154 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 153 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 149 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Hermes thomas at apestaart.org MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de byzanz-0.1.1-1.fc6.src.rpm camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt-0.61-3.fc6.src.rpm ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu iftop-0.17-1.fc5.src.rpm jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda-1.9.100-7.fc6.src.rpm libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate-0.99-6.fc6.src.rpm licq-1.3.2-7.src.rpm lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam-4.5.3-3.fc6.src.rpm lucidlife peter at thecodergeek.com mfstools tcallawa at redhat.com mftrace qspencer at ieee.org multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-open-terminal stickster at gmail.com nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de openalpp-20060405-8.fc6.src.rpm opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org paps-0.6.6-3.fc6.src.rpm php-extras dmitry at butskoy.name pitivi redhat at flyn.org pl gemi at bluewin.ch pure-ftpd-1.0.21-5.fc6.src.rpm pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp-1.1.15-2.fc6.src.rpm With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 jkeating at redhat.com Fri Jun 16 18:32:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Jun 2006 14:32:58 -0400 Subject: Who maintains python-numeric In-Reply-To: <20060616181539.GB25495@neu.nirvana> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150479516.9157.7.camel@dhcp83-49.boston.redhat.com> <20060616181539.GB25495@neu.nirvana> Message-ID: <1150482778.9157.9.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-06-16 at 20:15 +0200, Axel Thimm wrote: > For quite some time Numeric's web page says: > > *Development has ceased* for Numeric, and users should transisition to > NumPy as quickly as possible. > > So numeric needs to be replaced by numby. The end result should be > numpy in core (to support pygtk) and perhaps a compat numeric package > in extras for applications that did not make the conversion (and which > the numeric/numarray/numpy developers therefore define as > "unmaintained"). Is there an ABI change in numby? Could not a current package that uses python-numeric just recompile against numby w/out needing any changes? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Jun 16 18:35:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 20:35:25 +0200 Subject: Who maintains python-numeric In-Reply-To: <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> Message-ID: <20060616183525.GC25495@neu.nirvana> On Fri, Jun 16, 2006 at 11:13:17AM -0600, Rick Muller wrote: > On Jun 15, 2006, at 4:28 PM, Axel Thimm wrote: > >>>Yes, python-numeric has been superceded by numpy, but python-numeric > >>>is still used as a dependency in many fedora packages, and thus it > >>>would be good to have a version where the eigensolver doesn't hang. > > > >Do you have a list of these packages? > > Here's a list of the dependencies when I try to remove python- > numeric. People more adept at the intricacies of yum may be able to > generate a more complete list: > > [... long list ...] This is all due to one package: pygtk2. Maybe I should try building pygtk2 locally against numpy and see whether it breaks anything. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 16 18:36:55 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 20:36:55 +0200 Subject: Who maintains python-numeric In-Reply-To: <1150482778.9157.9.camel@dhcp83-49.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150479516.9157.7.camel@dhcp83-49.boston.redhat.com> <20060616181539.GB25495@neu.nirvana> <1150482778.9157.9.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060616183655.GD25495@neu.nirvana> On Fri, Jun 16, 2006 at 02:32:58PM -0400, Jesse Keating wrote: > On Fri, 2006-06-16 at 20:15 +0200, Axel Thimm wrote: > > For quite some time Numeric's web page says: > > > > *Development has ceased* for Numeric, and users should transisition to > > NumPy as quickly as possible. > > > > So numeric needs to be replaced by numby. The end result should be > > numpy in core (to support pygtk) and perhaps a compat numeric package > > in extras for applications that did not make the conversion (and which > > the numeric/numarray/numpy developers therefore define as > > "unmaintained"). > > Is there an ABI change in numby? Could not a current package that uses > python-numeric just recompile against numby w/out needing any changes? > Yes and No. The old ABI still exists, but you need to transform a couple of imports. There's a script in numpy doing that for you. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri Jun 16 18:39:12 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 16 Jun 2006 14:39:12 -0400 Subject: Who maintains python-numeric In-Reply-To: <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> Message-ID: <1150483152.20058.27.camel@xavier.boston.redhat.com> On Fri, 2006-06-16 at 11:13 -0600, Rick Muller wrote: > On Jun 15, 2006, at 4:28 PM, Axel Thimm wrote: > > >>> Yes, python-numeric has been superceded by numpy, but python-numeric > >>> is still used as a dependency in many fedora packages, and thus it > >>> would be good to have a version where the eigensolver doesn't hang. > > > > Do you have a list of these packages? > > Here's a list of the dependencies when I try to remove python- > numeric. People more adept at the intricacies of yum may be able to > generate a more complete list: > > authconfig-gtk > firstboot > gedit > gnome-python2-canvas > hwbrowser > pirut > pygtk2 > pygtk2-devel > pygtk2-libglade > rhn-applet > system-config-date > system-config-display > system-config-httpd > system-config-language > system-config-lvm > system-config-network > system-config-nfs > system-config-printer-gui > system-config-rootpassword > system-config-samba > system-config-securitylevel > system-config-services > system-config-soundcard > system-config-users > up2date-gnome I take it that's the packages yum wants to remove if you issue a 'yum remove python-numeric', because many of those packages don't depend directly on python-numeric, they depend on pygtk2, which depends on python-numeric. I believe a more accurate representation of the direct deps comes from repoquery. For core, that amounts to only: $ repoquery --repoid=development --whatrequires python-numeric pygtk2-0:2.9.1-3.x86_64 For extras: $ repoquery --repoid=extras-development --whatrequires python-numeric pygsl-0:0.3.2-5.fc5.x86_64 fonttools-0:2.0-0.6.20050624cvs.fc6.x86_64 gnome-sudoku-0:0.4.0-6.fc6.noarch python-matplotlib-0:0.87.2-2.fc6.x86_64 rpy-0:0.4.6-11.fc6.x86_64 pygame-0:1.7.1-6.fc6.x86_64 So bumping to numpy in core doesn't look like it'd really be all that difficult, and there really isn't even that much fallout in 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 chris.stone at gmail.com Fri Jun 16 19:34:34 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 16 Jun 2006 12:34:34 -0700 Subject: Who maintains python-numeric In-Reply-To: <1150483152.20058.27.camel@xavier.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> Message-ID: On 6/16/06, Jarod Wilson wrote: > pygame-0:1.7.1-6.fc6.x86_64 pygame requires /usr/include/python2.4/Numeric/arrayobject.h which is not provided by numpy, how is pygame supposed to convert to numpy without the header files? From jwilson at redhat.com Fri Jun 16 20:26:43 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 16 Jun 2006 16:26:43 -0400 Subject: Who maintains python-numeric In-Reply-To: References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> Message-ID: <1150489603.20058.35.camel@xavier.boston.redhat.com> On Fri, 2006-06-16 at 12:34 -0700, Christopher Stone wrote: > On 6/16/06, Jarod Wilson wrote: > > pygame-0:1.7.1-6.fc6.x86_64 > > pygame requires /usr/include/python2.4/Numeric/arrayobject.h which is > not provided by numpy, how is pygame supposed to convert to numpy > without the header files? According to the python-numeric/numpy people, pygame is SOL until the pygame people update it to use numpy... :) But work-arounds include a -compat package as Axel suggested or possibly including a local copy of arrayobject.h in pygame (which might make more sense than building a compat package if pygame is the only package that needs it). -- 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 Axel.Thimm at ATrpms.net Fri Jun 16 20:34:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jun 2006 22:34:20 +0200 Subject: Who maintains python-numeric In-Reply-To: <1150489603.20058.35.camel@xavier.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> Message-ID: <20060616203420.GA8822@neu.nirvana> On Fri, Jun 16, 2006 at 04:26:43PM -0400, Jarod Wilson wrote: > On Fri, 2006-06-16 at 12:34 -0700, Christopher Stone wrote: > > On 6/16/06, Jarod Wilson wrote: > > > pygame-0:1.7.1-6.fc6.x86_64 > > > > pygame requires /usr/include/python2.4/Numeric/arrayobject.h which is > > not provided by numpy, how is pygame supposed to convert to numpy > > without the header files? Who says numpy doesn't provide it: /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h > According to the python-numeric/numpy people, pygame is SOL until the > pygame people update it to use numpy... :) > > But work-arounds include a -compat package as Axel suggested or possibly > including a local copy of arrayobject.h in pygame (which might make more > sense than building a compat package if pygame is the only package that > needs it). Yes, the tweaks are minimal, just adjusting paths in extensions and import statements. Since the transition is that minimal/trivial numpy/numeric/numarray folks argue that if it hasn't been done by now, then the projects are rather sleepy (or not really caring about using numeric/numpy at all). I haven't looked into pygame, but chances are that pygame can be built against numpy, too, or if not that the pygame developers would gladly accept any patches the autoconvert tool may spill out. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Fri Jun 16 20:43:10 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 16 Jun 2006 21:43:10 +0100 Subject: Who maintains python-numeric In-Reply-To: <1150483152.20058.27.camel@xavier.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> Message-ID: <200606162143.10687.jamatos@fc.up.pt> On Friday 16 June 2006 19:39, Jarod Wilson wrote: > pygsl-0:0.3.2-5.fc5.x86_64 > rpy-0:0.4.6-11.fc6.x86_64 Those projects are migrating to numpy and have testing versions that already work with numpy. I am expecting for the stable versions to release them > python-matplotlib-0:0.87.2-2.fc6.x86_64 matplotlib is an exception since it supports all three versions: python-numeric python-numarray numpy -- Jos? Ab?lio From chris.stone at gmail.com Fri Jun 16 21:09:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 16 Jun 2006 14:09:18 -0700 Subject: Who maintains python-numeric In-Reply-To: <20060616203420.GA8822@neu.nirvana> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> Message-ID: On 6/16/06, Axel Thimm wrote: > On Fri, Jun 16, 2006 at 04:26:43PM -0400, Jarod Wilson wrote: > > On Fri, 2006-06-16 at 12:34 -0700, Christopher Stone wrote: > > > On 6/16/06, Jarod Wilson wrote: > > > > pygame-0:1.7.1-6.fc6.x86_64 > > > > > > pygame requires /usr/include/python2.4/Numeric/arrayobject.h which is > > > not provided by numpy, how is pygame supposed to convert to numpy > > > without the header files? > > Who says numpy doesn't provide it: > > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h What the bleep is it doing in %{_libdir}??? How the bleep am I supposed to patch the Setup.in file when it could be located in either /usr/lib or /usr/lib64? Shouldn't these header files be located in %{_includedir}? From nicolas.mailhot at laposte.net Fri Jun 16 21:17:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 23:17:06 +0200 Subject: Who maintains python-numeric In-Reply-To: References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> Message-ID: <1150492626.2710.20.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 14:09 -0700, Christopher Stone a ?crit : > On 6/16/06, Axel Thimm wrote: > > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h > > What the bleep is it doing in %{_libdir}??? How the bleep am I > supposed to patch the Setup.in file when it could be located in either > /usr/lib or /usr/lib64? > > Shouldn't these header files be located in %{_includedir}? That depends if you want a precedent for mono packaging or not (runs) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at all-the-johnsons.co.uk Fri Jun 16 21:12:07 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 16 Jun 2006 22:12:07 +0100 Subject: Who maintains python-numeric In-Reply-To: <1150492626.2710.20.camel@rousalka.dyndns.org> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> <1150492626.2710.20.camel@rousalka.dyndns.org> Message-ID: <1150492327.29435.11.camel@T7.Linux> Hi, > > Shouldn't these header files be located in %{_includedir}? > > That depends if you want a precedent for mono packaging or not Um, why would that set precedent? Mono isn't python. It's sane! TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 jwilson at redhat.com Fri Jun 16 21:44:54 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 16 Jun 2006 17:44:54 -0400 Subject: Who maintains python-numeric In-Reply-To: References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> Message-ID: <1150494294.20058.44.camel@xavier.boston.redhat.com> On Fri, 2006-06-16 at 14:09 -0700, Christopher Stone wrote: > On 6/16/06, Axel Thimm wrote: > > Who says numpy doesn't provide it: > > > > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h [...] > How the bleep am I > supposed to patch the Setup.in file when it could be located in either > /usr/lib or /usr/lib64? Er, that's rather easy, actually. Essentially, just a global search and replace of /usr/lib with %{_libdir} in %prep. Or am I missing something? -- 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 chris.stone at gmail.com Fri Jun 16 21:49:50 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 16 Jun 2006 14:49:50 -0700 Subject: Who maintains python-numeric In-Reply-To: <1150494294.20058.44.camel@xavier.boston.redhat.com> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> <1150494294.20058.44.camel@xavier.boston.redhat.com> Message-ID: On 6/16/06, Jarod Wilson wrote: > On Fri, 2006-06-16 at 14:09 -0700, Christopher Stone wrote: > > On 6/16/06, Axel Thimm wrote: > > > Who says numpy doesn't provide it: > > > > > > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h > [...] > > How the bleep am I > > supposed to patch the Setup.in file when it could be located in either > > /usr/lib or /usr/lib64? > > Er, that's rather easy, actually. Essentially, just a global search and > replace of /usr/lib with %{_libdir} in %prep. Or am I missing something? Okay fine, but isn't this a hack? What ever happened to standards? Why are header files no longer included in /usr/include? Should I start converting all my packages to put header files in the new /usr/lib directory? From jwilson at redhat.com Fri Jun 16 22:39:39 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 16 Jun 2006 18:39:39 -0400 Subject: Who maintains python-numeric In-Reply-To: References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> <1150494294.20058.44.camel@xavier.boston.redhat.com> Message-ID: <1150497579.20058.52.camel@xavier.boston.redhat.com> On Fri, 2006-06-16 at 14:49 -0700, Christopher Stone wrote: > On 6/16/06, Jarod Wilson wrote: > > On Fri, 2006-06-16 at 14:09 -0700, Christopher Stone wrote: > > > On 6/16/06, Axel Thimm wrote: > > > > Who says numpy doesn't provide it: > > > > > > > > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h > > [...] > > > How the bleep am I > > > supposed to patch the Setup.in file when it could be located in either > > > /usr/lib or /usr/lib64? > > > > Er, that's rather easy, actually. Essentially, just a global search and > > replace of /usr/lib with %{_libdir} in %prep. Or am I missing something? > > Okay fine, but isn't this a hack? Yes, and sadly, one that's required for quite a few packages still. Not all upstream sources are lib/lib64-friendly yet. > What ever happened to standards? Which ones? :) > Why are header files no longer included in /usr/include? Don't get ahead of yourself. We're only talking about a single project that decided to put their header files in libdir here, not some universal thing. > Should I > start converting all my packages to put header files in the new > /usr/lib directory? No. If you ask me, headers should go in /usr/include. But I didn't write numpy. Someone should educate them to the error in their ways. Or package around it. Sounds like we're going to look at replacing python-numeric w/numpy sometime after the test1 release, so I'm sure someone will be talking with the numpy developers soon... -- 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 Axel.Thimm at ATrpms.net Fri Jun 16 23:39:33 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Jun 2006 01:39:33 +0200 Subject: Who maintains python-numeric In-Reply-To: References: <20060615220116.GC15009@neu.nirvana> <2A48B4C6-9E0D-46E9-B71A-93CB12E02858@sandia.gov> <1150409796.4381.7.camel@xavier.boston.redhat.com> <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> Message-ID: <20060616233933.GC8822@neu.nirvana> On Fri, Jun 16, 2006 at 02:09:18PM -0700, Christopher Stone wrote: > On 6/16/06, Axel Thimm wrote: > >On Fri, Jun 16, 2006 at 04:26:43PM -0400, Jarod Wilson wrote: > >> On Fri, 2006-06-16 at 12:34 -0700, Christopher Stone wrote: > >> > On 6/16/06, Jarod Wilson wrote: > >> > > pygame-0:1.7.1-6.fc6.x86_64 > >> > > >> > pygame requires /usr/include/python2.4/Numeric/arrayobject.h which is > >> > not provided by numpy, how is pygame supposed to convert to numpy > >> > without the header files? > > > >Who says numpy doesn't provide it: > > > >/usr/lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h > > What the bleep is it doing in %{_libdir}??? How the bleep am I > supposed to patch the Setup.in file when it could be located in either > /usr/lib or /usr/lib64? > > Shouldn't these header files be located in %{_includedir}? Some rpms for other distros do indeed package it that way, so it looks like something not carved in stone. But I think it doesn't really have to do with numeric vs numpy, it was just the packagers' (different) choices, I guess. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 16 23:41:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Jun 2006 01:41:13 +0200 Subject: Who maintains python-numeric In-Reply-To: <1150497579.20058.52.camel@xavier.boston.redhat.com> References: <20060615222811.GE15009@neu.nirvana> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <1150489603.20058.35.camel@xavier.boston.redhat.com> <20060616203420.GA8822@neu.nirvana> <1150494294.20058.44.camel@xavier.boston.redhat.com> <1150497579.20058.52.camel@xavier.boston.redhat.com> Message-ID: <20060616234113.GD8822@neu.nirvana> On Fri, Jun 16, 2006 at 06:39:39PM -0400, Jarod Wilson wrote: > Sounds like we're going to look at replacing python-numeric w/numpy > sometime after the test1 release, so I'm sure someone will be talking > with the numpy developers soon... Maybe test2 should still contain both, but have pygtk2 built against numpy. test3 could then push numeric to extras if something in extras still needs it by then. -- 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 Fri Jun 16 23:44:47 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 17 Jun 2006 00:44:47 +0100 Subject: mock build problem Message-ID: <1150501487.29435.39.camel@T7.Linux> Hi, I'm testing my builds of gtksourceview-sharp, boo, nant, monodoc and monodevelop under mock. gtksourceview-sharp and nant both are happy and installed fine (yum localinstall). When I build boo (which requires nant to build), everything goes to plan (same applies to monodevelop). However, in mock, it boo cannot find nant, despite it being in /usr/bin and monodevelop can't find gtksourceview-sharp, despite the .pc file being in /usr/lib/pkgconfig Can anyone shed some advice on these build failures? The spec files and src rpms can be found at http://www.knox.net.nz/~nodoid TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 stickster at gmail.com Sat Jun 17 02:15:41 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Jun 2006 22:15:41 -0400 Subject: Help name the test project! In-Reply-To: <1150424041.29060.2.camel@cutter> References: <1150418689.26419.59.camel@metroid.rdu.redhat.com> <1150424041.29060.2.camel@cutter> Message-ID: <1150510541.32517.3.camel@localhost.localdomain> On Thu, 2006-06-15 at 22:14 -0400, seth vidal wrote: > On Thu, 2006-06-15 at 20:44 -0400, Will Woods wrote: > > Hello Fedorans! I need your help. > > > Here are some possible project names: > > Proof > > Cassandra > > Witness > > FTL (Fedora Test League / Faster Than Light) > > > > And some names for an automated test suite: > > Turnstile (keeps the RHTS abbreviation for easy rebranding) > > Giant Testing Robot (GTR or testbot for short?) > > Canary > > as in - canary in a coal mine. > > Canaries in coal mines were used to detect natural gas leaks. They'd > pass out first and the miners would be able to get out in time and/or > look for the gas leak. Plus it's such a great Police song. "First to fall over when the atmosphere is less than perfect Your sensibilities are shaken by the slightest defect You live your life like a canary in a coalmine You get so dizzy even walking in a straight line" -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://www.fedoraproject.org/wiki/Board Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cranium2003 at yahoo.com Sat Jun 17 04:58:35 2006 From: cranium2003 at yahoo.com (cranium2003) Date: Fri, 16 Jun 2006 21:58:35 -0700 (PDT) Subject: Mock build problem In-Reply-To: <44928F7F.4050702@city-fan.org> Message-ID: <20060617045835.42888.qmail@web38001.mail.mud.yahoo.com> Paul, Got some problems. As per your suggestions i successfully created development tree(As i already downloaded development repo so instead to give time and badwidth for FC5 repo i decides to use development repo). Attached is my fedora-development-i386-core.cfg. when i gave su - build mock -r fedora-development-i386-core.cfg foo.src.rpm i got following results init clean prep This may take a while Error peforming yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build ending done __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-development-i386-core.cfg Type: application/octet-stream Size: 1786 bytes Desc: 363861165-fedora-development-i386-core.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: root.log Type: text/x-log Size: 9758 bytes Desc: 2536305070-root.log URL: From rc040203 at freenet.de Sat Jun 17 07:19:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 09:19:18 +0200 Subject: tar issue: header keyword `SCHILY.fflags' Message-ID: <1150528758.16123.13.camel@mccallum.corsepiu.local> Hi, I am facing the error below during untar'ring tarball on FC5: # tar xzvf xxxx.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' tar: Ignoring unknown extended header keyword `SCHILY.fflags' ... This error doesn't occur on FC4 and breaks building an rpm that has built flawlessly on FC < 5. Any ideas what is causing this? Googling seems to indicate the SCHILY.* errors to be related to "TAR-SCHILY extensions". How to work around it? Why is FC < 5 not affected? Ralf From rc040203 at freenet.de Sat Jun 17 08:11:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 10:11:29 +0200 Subject: tar issue: header keyword `SCHILY.fflags' In-Reply-To: <1150528758.16123.13.camel@mccallum.corsepiu.local> References: <1150528758.16123.13.camel@mccallum.corsepiu.local> Message-ID: <1150531890.16123.28.camel@mccallum.corsepiu.local> Replying to myself ... On Sat, 2006-06-17 at 09:19 +0200, Ralf Corsepius wrote: > Hi, > > I am facing the error below during untar'ring tarball on FC5: > > # tar xzvf xxxx.tar.gz > tar: Ignoring unknown extended header keyword `SCHILY.fflags' > tar: Ignoring unknown extended header keyword `SCHILY.dev' > tar: Ignoring unknown extended header keyword `SCHILY.ino' > tar: Ignoring unknown extended header keyword `SCHILY.nlink' > tar: Ignoring unknown extended header keyword `SCHILY.fflags' > ... > > This error doesn't occur on FC4 and breaks building an rpm that has > built flawlessly on FC < 5. > > Any ideas what is causing this? Seems as if gtar has changed it's behavior. Seemingly they abandoned the "SCHILY extensions", which seems to break untar'ing tarballs others pack using other tars. > Googling seems to indicate the SCHILY.* > errors to be related to "TAR-SCHILY extensions". > > How to work around it? Using star instead gtar seems to help. > Why is FC < 5 not affected? Ralf From pertusus at free.fr Sat Jun 17 08:14:40 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Jun 2006 10:14:40 +0200 Subject: fstab-sync for xfce replacement package In-Reply-To: <20060615164452.GB2646@free.fr> References: <20060614164848.GA20053@free.fr> <20060614.105652.515898614.kevin@scrye.com> <20060615164452.GB2646@free.fr> Message-ID: <20060617081440.GA2418@free.fr> > It handles right my usb key, but there seems to be icons missing for > the different files. Or maybe they are not in thunar directly or I missed > something while packaging. Otherwise it looks like a nice and fast > filemanager. It is in the thunar FAQ, and it comes from a theme lacking some icons. So I think that basically my thunar package is ok. -- Pat From paul at city-fan.org Sat Jun 17 08:31:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 17 Jun 2006 09:31:43 +0100 Subject: Mock build problem In-Reply-To: <20060617045835.42888.qmail@web38001.mail.mud.yahoo.com> References: <20060617045835.42888.qmail@web38001.mail.mud.yahoo.com> Message-ID: <1150533104.13102.0.camel@laurel.intra.city-fan.org> On Fri, 2006-06-16 at 21:58 -0700, cranium2003 wrote: > Paul, > Got some problems. As per your suggestions i > successfully created development tree(As i already > downloaded development repo so instead to give time > and badwidth for FC5 repo i decides to use development > repo). > Attached is my > fedora-development-i386-core.cfg. when i gave > su - build > mock -r fedora-development-i386-core.cfg foo.src.rpm > i got following results > init > clean > prep > This may take a while > Error peforming yum command: /usr/sbin/mock-helper yum > --installroot > /var/lib/mock/fedora-development-i386-core/root > groupinstall build > ending > done ... Traceback (most recent call last): File "/usr/libexec/mock-yum", line 12, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 97, in main result, resultmsgs = do() File "/usr/share/yum-cli/cli.py", line 565, in doCommands self.doGroupSetup() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 367, in doGroupSetup self.comps.add(groupfile) File "/usr/lib/python2.4/site-packages/yum/comps.py", line 337, in add for event, elem in parser: File "", line 56, in __iter__ SyntaxError: not well-formed (invalid token): line 1, column 0 Looks like a problem with the buildgroups file/repo. Check that your groups repo is OK: cd /home/source/fedora/development/core/i386/groups look at minimal.xml to make sure it's OK make sure you have buildsys-macros-6-2.fc6.noarch.rpm and buildsys-macros-6-2.fc6.src.rpm in this directory (you can get them from http://buildsys.fedoraproject.org/buildgroups/development/i386/) createrepo -g minimal.xml . Then try again. Paul. From thomas at apestaart.org Sat Jun 17 09:21:36 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 17 Jun 2006 11:21:36 +0200 Subject: check-rpaths In-Reply-To: References: <1148423359.24238.18.camel@T7.Linux> <1148490107.3167.11.camel@localhost> Message-ID: <1150536097.2597.57.camel@otto.amantes> Hi, > On 5/24/06, Toshio Kuratomi wrote: > > > http://fedoraproject.org/wiki/ToshioKuratomi > > I have this rpath problem in one of my packages and I've modified the > %build like so: > > %build > %configure --enable-gifplugin --disable-static > %{__make} LIBTOOL=/usr/bin/libtool %{?_smp_mflags} > > This does fix the rpath error, however with this modification, the > static library is built even though I specify --disable-static on the > %configure line. Any idea why this happens? Whether static libs get built is decided by libtool. It has a variable build_old_libs. Normally, configure writes the libtool script, and depending on the arguments passed to configure it sets this variable to no. If you bypass this mechanism and use the system-installed libtool, you use its default options, not the ones configure wants. Overriding LIBTOOL is a dirty hack. I think it would be good to mention that this hack will cause .a files to get installed as well. Also, the instructions on the wiki on how to make the system-installed LIBTOOL be used don't look correct to me. They mention you should first try setting an environment variable. I don't see any case where this would be better than setting the make variable as they're supposed to - setting them on the make command line, after make. None of these hacks are particularly appealing. Has anyone recently discussed the issue with libtool maintainers ? Thomas From chitlesh at fedoraproject.org Sat Jun 17 10:01:28 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 17 Jun 2006 12:01:28 +0200 Subject: Request BUILDS: Job failed on arch i386 Message-ID: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> Hello, I am requesting Builds on cd devel/ make build for knetstats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 Afterwards I received the following mail. What is wrong with my make build ? Job failed on arch i386 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/11137-knetstats-1.5-7.fc6/ ------------------------------------------------- Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux Executing /usr/sbin/mock-helper mount -t none -o bind /selinux /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts -o gid=5,mode=620 pts /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper mount -t tmpfs shm /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/null -m 666 c 1 3 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/urandom -m 644 c 1 9 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/random -m 644 c 1 9 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/full -m 666 c 1 7 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/ptmx -m 666 c 5 2 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/tty -m 666 c 5 0 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/zero -m 666 c 1 5 Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root groupinstall build Failed to add groups file for repository: core file:///pub/fedora/linux/core/development/i386/os/Fedora/RPMS/initscripts-8.35-1.i386.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: Fedora/RPMS/initscripts-8.35-1.i386.rpm from core: [Errno 256] No more mirrors to try. unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts Done. -- http://clunixchit.blogspot.com From ville.skytta at iki.fi Sat Jun 17 11:32:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 17 Jun 2006 14:32:33 +0300 Subject: Need help with upgrade path In-Reply-To: <20060616102149.754628be@alkaid.a.lan> References: <20060616102149.754628be@alkaid.a.lan> Message-ID: <1150543953.10344.22.camel@localhost.localdomain> On Fri, 2006-06-16 at 10:21 +0200, Andreas Bierfert wrote: > Idea was to maybe add an Obsoletes wine <= 0.9.15-1 to wine-core That should be <= 0.9.15-1%{?dist} From ville.skytta at iki.fi Sat Jun 17 13:06:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 17 Jun 2006 16:06:36 +0300 Subject: Broken upgrade paths in Fedora Extras 2006-06-16 In-Reply-To: <20060616161328.GA11240@nostromo.devel.redhat.com> References: <20060616152333.2B79315217C@buildsys.fedoraproject.org> <4492D320.7080206@city-fan.org> <20060616161328.GA11240@nostromo.devel.redhat.com> Message-ID: <1150549597.10344.24.camel@localhost.localdomain> On Fri, 2006-06-16 at 12:13 -0400, Bill Nottingham wrote: > Paul Howarth (paul at city-fan.org) said: > > buildsys at fedoraproject.org wrote: > > >azureus: > > > 5: 0:2.4.0.3-0.20060529cvs_1.fc5 > > > 6: 0:2.4.0.3-0.20060328cvs_5.fc6 > > > > ... > > > > Perhaps the script could be enhanced to take into account packages that > > have migrated from Core to Extras and vice versa? I know that one of my > > packages has a broken upgrade path like this. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191686 > > Heck, I wouldn't mind if you ran it for Core too. :) Done, the next report will be based on data from FC[456]+updates and FE[3456]. FC3 is not included because there's no SRPM repodata available for its updates. From paul at city-fan.org Sat Jun 17 13:41:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 17 Jun 2006 14:41:28 +0100 Subject: mock build problem In-Reply-To: <1150501487.29435.39.camel@T7.Linux> References: <1150501487.29435.39.camel@T7.Linux> Message-ID: <1150551689.13102.7.camel@laurel.intra.city-fan.org> On Sat, 2006-06-17 at 00:44 +0100, Paul wrote: > Hi, > > I'm testing my builds of gtksourceview-sharp, boo, nant, monodoc and > monodevelop under mock. gtksourceview-sharp and nant both are happy and > installed fine (yum localinstall). > > When I build boo (which requires nant to build), everything goes to plan > (same applies to monodevelop). However, in mock, it boo cannot find > nant, despite it being in /usr/bin and monodevelop can't find > gtksourceview-sharp, despite the .pc file being in /usr/lib/pkgconfig > > Can anyone shed some advice on these build failures? > > The spec files and src rpms can be found at > http://www.knox.net.nz/~nodoid In boo.spec you have: Requires: pkgconfig, nant It should be: BuildRequires: pkgconfig, nant If nant is a runtime dep of boo, you'll need to add that back: Requires: nant The -devel subpackage of boo should have a dep on pkgconfig since it consists only of a .pc file and is useless without pkgconfig. Paul. From Axel.Thimm at ATrpms.net Sat Jun 17 13:51:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Jun 2006 15:51:17 +0200 Subject: Broken upgrade paths in Fedora Extras 2006-06-16 In-Reply-To: <1150549597.10344.24.camel@localhost.localdomain> References: <20060616152333.2B79315217C@buildsys.fedoraproject.org> <4492D320.7080206@city-fan.org> <20060616161328.GA11240@nostromo.devel.redhat.com> <1150549597.10344.24.camel@localhost.localdomain> Message-ID: <20060617135117.GI8822@neu.nirvana> On Sat, Jun 17, 2006 at 04:06:36PM +0300, Ville Skytt? wrote: > On Fri, 2006-06-16 at 12:13 -0400, Bill Nottingham wrote: > > Paul Howarth (paul at city-fan.org) said: > > > buildsys at fedoraproject.org wrote: > > > >azureus: > > > > 5: 0:2.4.0.3-0.20060529cvs_1.fc5 > > > > 6: 0:2.4.0.3-0.20060328cvs_5.fc6 > > > > > > ... > > > > > > Perhaps the script could be enhanced to take into account packages that > > > have migrated from Core to Extras and vice versa? I know that one of my > > > packages has a broken upgrade path like this. > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191686 > > > > Heck, I wouldn't mind if you ran it for Core too. :) > > Done, the next report will be based on data from FC[456]+updates and > FE[3456]. Could you add legacy bits, too, e.g. for FC3? > FC3 is not included because there's no SRPM repodata available for > its updates. Maybe the Legacy project has srpm repodata available and if not would probably be easy to set it up there. -- 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 rpmuller at gmail.com Sat Jun 17 14:04:37 2006 From: rpmuller at gmail.com (Rick Muller) Date: Sat, 17 Jun 2006 08:04:37 -0600 Subject: Who maintains python-numeric In-Reply-To: <200606162143.10687.jamatos@fc.up.pt> References: <82C22F98-FE80-4C01-8AC2-73A22DB740AB@sandia.gov> <47E8391A-7565-420F-B620-55CBAA51E8F2@sandia.gov> <1150483152.20058.27.camel@xavier.boston.redhat.com> <200606162143.10687.jamatos@fc.up.pt> Message-ID: As does my program, PyQuante, which is a quantum chemistry package in Python. Actually, it just supports Numeric and Numpy. Which is why I was concerned about the problems with the Numeric eigensolver in the first place: since I support both versions, I'd like to make sure it can run with the versions that are distributed with Fedora. On 6/16/06, Jose' Matos wrote: > > On Friday 16 June 2006 19:39, Jarod Wilson wrote: > > pygsl-0:0.3.2-5.fc5.x86_64 > > rpy-0:0.4.6-11.fc6.x86_64 > > Those projects are migrating to numpy and have testing versions that > already > work with numpy. I am expecting for the stable versions to release them > > > > python-matplotlib-0:0.87.2-2.fc6.x86_64 > > matplotlib is an exception since it supports all three versions: > python-numeric > python-numarray > numpy > > -- > Jos? Ab?lio > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Sat Jun 17 14:39:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 16:39:36 +0200 Subject: Request BUILDS: Job failed on arch i386 In-Reply-To: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> References: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> Message-ID: <20060617163936.cda05daf.bugs.michael@gmx.net> On Sat, 17 Jun 2006 12:01:28 +0200, Chitlesh GOORAH wrote: > Hello, > > I am requesting Builds on cd devel/ > > make build > > for knetstats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 > > Afterwards I received the following mail. What is wrong with my make build ? > > Job failed on arch i386 > > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/11137-knetstats-1.5-7.fc6/ > > Failed to add groups file for repository: core > file:///pub/fedora/linux/core/development/i386/os/Fedora/RPMS/initscripts-8.35-1.i386.rpm: > [Errno -1] Header is not complete. > Trying other mirror. > Error: failure: Fedora/RPMS/initscripts-8.35-1.i386.rpm from core: > [Errno 256] No more mirrors to try. This is Rawhide. Most likely the repository was mirroring new packages. Wait some time, then run plague-client requeue 11137 to re-try your build job. From chitlesh at fedoraproject.org Sat Jun 17 15:02:29 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 17 Jun 2006 17:02:29 +0200 Subject: Request BUILDS: Job failed on arch i386 In-Reply-To: <20060617163936.cda05daf.bugs.michael@gmx.net> References: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> <20060617163936.cda05daf.bugs.michael@gmx.net> Message-ID: <13dbfe4f0606170802i3d6a8abbs25c7f75307c1969b@mail.gmail.com> On 6/17/06, Michael Schwendt wrote: > This is Rawhide. Most likely the repository was mirroring new > packages. Wait some time, then run > > plague-client requeue 11137 > > to re-try your build job. Thanks, I have successfully built my package -- http://clunixchit.blogspot.com From ville.skytta at iki.fi Sat Jun 17 17:59:43 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 17 Jun 2006 20:59:43 +0300 Subject: Broken upgrade paths in Fedora Extras 2006-06-16 In-Reply-To: <20060617135117.GI8822@neu.nirvana> References: <20060616152333.2B79315217C@buildsys.fedoraproject.org> <4492D320.7080206@city-fan.org> <20060616161328.GA11240@nostromo.devel.redhat.com> <1150549597.10344.24.camel@localhost.localdomain> <20060617135117.GI8822@neu.nirvana> Message-ID: <1150567183.2757.4.camel@localhost.localdomain> On Sat, 2006-06-17 at 15:51 +0200, Axel Thimm wrote: > On Sat, Jun 17, 2006 at 04:06:36PM +0300, Ville Skytt? wrote: > > > FC3 is not included because there's no SRPM repodata available for > > its updates. > > Maybe the Legacy project has srpm repodata available and if not would > probably be easy to set it up there. Indeed it has, so FC3 and legacy updates are in the config now as well. That revealed some interesting things. By the way, the script is available in the "upgradecheck" module in the "fedora" CVS root, and is easily adaptable in case someone wants to use it for other projects. http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora From buildsys at fedoraproject.org Sat Jun 17 18:36:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 17 Jun 2006 14:36:46 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-17 Message-ID: <20060617183646.61A7C15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 10 apachetop-0.12.6-1.fc5 cegui-0.4.1-8.fc5 emacs-auctex-11.83-2.fc5.5 gnochm-0.9.8-1.fc5 nail-12.1-1.fc5 perl-DBD-XBase-0.241-5.fc5 php-extras-5.1.4-1.fc5 python-chm-0.8.3-1.fc5 rrdtool-1.2.13-2.fc5 xfce4-mailwatch-plugin-1.0.1-1.fc5 Packages built and released for Fedora Extras 4: 7 cegui-0.4.1-8.fc4 gnochm-0.9.8-1.fc4 nail-12.1-1.fc4 perl-DBD-XBase-0.241-5.fc4 python-chm-0.8.3-1.fc4 rrdtool-1.2.13-2.fc4 xfce4-mailwatch-plugin-1.0.1-1.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 14 apachetop-0.12.6-1.fc6 dejavu-fonts-2.7.0-0.17.20060614svn943.fc6 gnome-sudoku-0.4.0-7.fc6 gtklp-1.2.2-2.fc6 heartbeat-2.0.5-2.fc6 knetstats-1.5-7.fc6 lat-1.0.5-5.fc6 nail-12.1-1.fc6 nautilus-open-terminal-0.6-4.fc6 net6-1.3.0-4.rc2.fc6 perl-DBD-XBase-0.241-5.fc6 php-extras-5.1.4-1.fc6 xfce4-mailwatch-plugin-1.0.1-1.fc6 xfprint-4.2.3-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jun 17 18:37:51 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 17 Jun 2006 14:37:51 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-17 Message-ID: <20060617183751.CA96F15217B@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) koffice: 3: 4:1.4.2-0.FC3.2 (FL3-updates) 4: 0:1.5.1-1.fc4 (FE4) 5: 0:1.5.1-1.fc5 (FE5) 6: 0:1.5.1-1.fc6 (FE6) libvirt: 5: 0:0.1.0-1.FC5 (FC5-updates) 6: 0:0.1.0-1 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.4-3.fc6 (FE6) otrs: 5: 0:2.0.4-3.fc5 (FE5) 6: 0:2.0.4-3 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) wine-docs: 3: 0:0.9.15-1.fc3 (FE3) 4: 0:0.9.15-0.1.fc4 (FE4) 5: 0:0.9.15-1.fc5 (FE5) 6: 0:0.9.15-1.fc6 (FE6) From hugo at devin.com.br Sat Jun 17 21:20:43 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 17 Jun 2006 18:20:43 -0300 Subject: KDE Sub-Packaging Approach on Fedora Message-ID: <200606171820.44076.hugo@devin.com.br> Hi list, I have just submitted a blog post on this: http://www.devin.com.br/eitch/blog/2006/06/17/kde-sub-packaging-approach-on-fedora/ And I'm bringing this discussion into the list too. I'll paste the post here too: KDE Sub-Packaging Approach on Fedora ======= First of all, I would like to bring some attention to this post, mostly for Fedora developers, Fedora Extras packagers and people that are in the KDE SIG on Extras. If you are one of these, please read this post :-) If you already don?t know, with the Fedora installer (anaconda) being integrated into yum and Fedora Extras, and Red Hat getting all the attention to GNOME, there is a proposal to get KDE into Extras, putting a community effort on it. This is detailed into the Unleash KDE Wiki Page. This proposal explained here is based on these ideas. The Current Approach ======= As most of us know, KDE is packaged on a few main ?official? packages like: kdebase, kdelibs, kdenetwork, kdeutils, kdegames, and so on. Each one of these packages contains many applications considered ?base? on the upstream. With this approach, things get easier when packaging and installing KDE on systems. For example, on Fedora, installing the kdegames package brings these games for the system: atlantik, kasteroids, katomic, kbackgammon, kblackbox, kbounce, kenolaba, kfouleggs, kgoldrunner, kjumpingcube, klickety, klines, kmahjongg, kmines, knetwalk, kolf, konquest, kpat, kpoker, kreversi, ksame, kshisen, ksirtet, ksmiletris, ksnake, ksokoban, kspaceduel, ktron, ktuberling, kwin4, lskat. Now if I want only kbounce, or konquest? What do I do? I must install all other games. I talked with many people (20+) and all of them said the same thing: this is really annoying. ?There?s got to be a way to install only kopete or kmail, instead of the whole collection of programs?. Everyone says that this will be a lot better to the user. But we know that for us packagers and maintainers, this brings more difficulty into our hands. The Solution: A Sub-Packaging Approach ======= This is already used in some distributions, and users appear to like it. The solution would be to use a sub-packaging approach, and that means we have many sub-packages independent one from the others (with a common package containing common files used by all) and a main meta-package that requires and installs all these sub-packages. For example: a single kdenetwork.src.rpm would create the packages: kdenetwork (meta), kdenetwork-common, kdenetwork-kdict, kdenetwork-kget, kdenetwork-kopete, kdenetwork-krdc, kdenetwork-ksirc, kdenetwork-kwifimanager, and so on. A single kdegames.src.rpm would create the packages: kdegames (meta), kdegames-common, kdegames-kpat, kdegames-kbounce, kdegames-konquest, kdegames-kasteroids, kdegames-kmines, kdegames-kolf, and so on. ChitleshGoorah suggested: instead of kdenetwork-kopete, the package should be named only kopete. This is because when someone tells the user to install kopete, the first thing that the user will try to do is: yum install kopete, and not yum install kdenetwork-kopete. This could be resolved adding a Provides: kopete into the specfile for the subpackage: this way user can reach the package both ways (kdenetwork-kopete will exist for organization purposes). Now if someone (or the installer for example) wants to install the whole package, just yum install kdenetwork. The package requires all sub-packages but the sub-packages does not require this meta main package. So if I want to uninstall something, removing only the packages kdenetwork and kdenetwork-kopete will work, leaving all other packages alone. Some other people from other distributions have talked to me, telling that separating applications into sub-packages gives a boost at customization. I know a distribution that has packages divided into many ones (compared to Fedora) and people always says that this is perfect for creating customizations and derived distributions. Most of the customized distributions I know are based on this distribution. We have to agree on this: this is a great way to get marketshare. More work, sure, but quality and advantages for everyone ;) Downside: Maintainership ======= While having these advantages above, we gain a more complicated specfile, meaning more difficulty to the maintainers. The specfile grows bigger with sub-packages, and the maintainers should do a initial work on describing all the applications, separating all specific files for each sub-package, manage dependencies well, and so on. Now this is my question: Is it worthy to get this new approach and get these extra difficulties? I want to know what Fedora People think :-) Some of them already likes it, some don?t because of the concern about taking responsability. As I?m determined to do this (and I don?t want to try to step on anyone), I began doing the initial work on the packages. If we agree on this, we could form a KDE maintainers group based on the KDE SIG, pretty much like we have today with Perl, Security, and so on. This will easier the maintainership for those packages. Come on everybody, please comment on this and say what you think about it ;) An Example is already made: kdegames ======= Yeah, I know, talk is cheap, show me the code. Thinking on this, I created an example of this approach, working and compiling within Fedora Core 5 or rawhide. It?s based on Rex Dieter?s Package Review on kdegames. The specs and SRPMs are linked on bugzilla too. The current specfile for kdegames: http://www.devin.com.br/eitch/fextras/SPECS/kdegames.spec Please read the comments in Bugzilla too for more explanations. Thanks and sorry for the long posting ;-) Updates: ======= - Using -n in the subpackages %package could give us the "simple package name" instead of using "Provides:". Is it better? It will not polute the specfile? Opinion: Some think it's better. If it really is, task for Eitch: make changes into the kdegames example. - Bring this into FESCo attention? -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From j.w.r.degoede at hhs.nl Sat Jun 17 21:46:29 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 17 Jun 2006 23:46:29 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp Message-ID: <44947835.1020504@hhs.nl> Hi all, I just found about about this xmms fork which is actually still alive unlike xmms and uses gtk2 called bmp, and its already in extras, then why do we still ship xmms? I tried bmp and its just like xmms only gtk2 and maintained! Well actually it was maintained, now the bmp people are working on bmpx, but there is a bmp fork called Audacious, which picked up when the bmp people stopped maintaining bmp and started working on bmpx. (Notice I didn't test Audacious. So there is a maintained and gtk2 using xmms out there, why do we thrn still ship xmms itself? Regards, Hans From buildsys at fedoraproject.org Sat Jun 17 22:27:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 17 Jun 2006 22:27:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-17 Message-ID: <20060617222745.31052.56501@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sat Jun 17 22:27:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 17 Jun 2006 22:27:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-17 Message-ID: <20060617222745.31065.19340@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 scribus - 1.3.3.2-1.fc6.i386 scribus - 1.3.3.2-1.fc6.ppc scribus - 1.3.3.2-1.fc6.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 chabotc AT xs4all.nl buoh - 0.8.1-7.i386 buoh - 0.8.1-7.ppc buoh - 0.8.1-7.x86_64 cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 gauret AT free.fr showimg-pgsql - 0.9.5-5.fc5.i386 showimg-pgsql - 0.9.5-5.fc5.ppc showimg-pgsql - 0.9.5-5.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc kevin-redhat-bugzilla AT tummy.com bmp-xosd - 2.2.14-6.fc6.i386 bmp-xosd - 2.2.14-6.fc6.ppc bmp-xosd - 2.2.14-6.fc6.x86_64 xmms-xosd - 2.2.14-6.fc6.i386 xmms-xosd - 2.2.14-6.fc6.ppc xmms-xosd - 2.2.14-6.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 michael AT knox.net.nz gurlchecker - 0.10.0-2.fc6.i386 gurlchecker - 0.10.0-2.fc6.ppc gurlchecker - 0.10.0-2.fc6.x86_64 nicolas.mailhot AT laposte.net dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch nos AT utelsystems.com soundtracker - 0.6.7-3.x86_64 soundtracker - 0.6.7-4.i386 soundtracker - 0.6.7-4.ppc oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 roozbeh AT farsiweb.info autotrace - 0.31.1-12.fc5.i386 autotrace - 0.31.1-12.fc5.ppc autotrace - 0.31.1-12.fc5.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 autotrace-0.31.1-12.fc5.i386 requires libMagick.so.9 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 buoh-0.8.1-7.i386 requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 gurlchecker-0.10.0-2.fc6.i386 requires libgnutls.so.12 gurlchecker-0.10.0-2.fc6.i386 requires libgnutls.so.12(GNUTLS_1_2) kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.i386 requires libgdk_imlib.so.1 scribus-1.3.3.2-1.fc6.i386 requires libgnutls.so.12 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.i386 requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 soundtracker-0.6.7-4.i386 requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 autotrace-0.31.1-12.fc5.ppc requires libMagick.so.9 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 buoh-0.8.1-7.ppc requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 gurlchecker-0.10.0-2.fc6.ppc requires libgnutls.so.12 gurlchecker-0.10.0-2.fc6.ppc requires libgnutls.so.12(GNUTLS_1_2) kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.ppc requires libgdk_imlib.so.1 scribus-1.3.3.2-1.fc6.ppc requires libgnutls.so.12 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.ppc requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 soundtracker-0.6.7-4.ppc requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_pixbuf.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) autotrace-0.31.1-12.fc5.x86_64 requires libMagick.so.9()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bmp-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) buoh-0.8.1-7.x86_64 requires libgnutls.so.12()(64bit) dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) gurlchecker-0.10.0-2.fc6.x86_64 requires libgnutls.so.12()(64bit) gurlchecker-0.10.0-2.fc6.x86_64 requires libgnutls.so.12(GNUTLS_1_2)(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) scribus-1.3.3.2-1.fc6.x86_64 requires libgnutls.so.12()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) showimg-pgsql-0.9.5-5.fc5.x86_64 requires libpqxx-2.5.5.so()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) soundtracker-0.6.7-3.x86_64 requires libgdk_pixbuf.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) From buildsys at fedoraproject.org Sat Jun 17 22:27:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 17 Jun 2006 22:27:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-17 Message-ID: <20060617222745.31063.86397@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Sat Jun 17 22:27:45 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 17 Jun 2006 22:27:45 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-17 Message-ID: <20060617222745.31061.89902@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) From michael at knox.net.nz Sun Jun 18 01:29:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 18 Jun 2006 13:29:31 +1200 Subject: FE Package Status of Jun 18, 2006 Message-ID: <4494AC7B.2090202@knox.net.nz> Hi all, This was meant to go out a few days ago, sorry. As noted in the last report, the CSV files are becoming large and in some cases the resulting URI is too long for bugzilla. We are now using a script to pull this information out of bugzilla (thanks to those that made that suggestion!!). So, this is the first report using this method. I have done a quick check and things look to be OK, however, if you spot something that is incorrect, please let me know! Anyways... Enjoy and keep up the good work! Michael ----- FE Package Status of Jun 18, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1867 packages - 38 orphans - 43 packages not available in extras devel or release andreas at bawue dot net dd_rescue bugs dot michael at gmx dot net libgcrypt1 cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode denis at poolshark dot org gtkmm20 denis at poolshark dot org libgnomemm20 denis at poolshark dot org libglademm20 denis at poolshark dot org libgnomecanvasmm20 denis at poolshark dot org libgnomeuimm20 denis at poolshark dot org gconfmm20 dennis at ausil dot us cryptplug fedora at leemhuis dot info alsa-firmware fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gnome-theme-clearlooks ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin mattdm at mattdm dot org wxPythonGTK2 matthias at rpmforge dot net php-pecl-pdo matthias at rpmforge dot net php-pecl-sqlite matthias at rpmforge dot net php-pecl-pdo-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache nomis80 at nomis80 dot org juk notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard rdieter at math dot unl dot edu PyQt-qsintilla redhat-bugzilla at linuxnetz dot de php-magickwand redhat-bugzilla at linuxnetz dot de php-idn tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul zing at fastmail dot fm gtypist - 9 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep dakingun at gmail dot com baobab hugo at devin dot com dot br kerry noa at resare dot com vorbisgain tcallawa at redhat dot com R-gnomeGUI wart at kobold dot org manaworld zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 5 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=189375,193342,195292 Maelstrom Bill Nottingham cegui Ian Chapman Openbox Peter Gordon https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 SquidGuard Oliver Falk webmin Jason Vas Dias - 3 packages present in the development repo which have no owners entry PyQt-qscintilla compat-erlang perl-Event - 1 orphaned packages, yet available in extras devel gtkglarea2 - 38 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for FC5: tcallawa at redhat dot com check - 2 packages duplicated for devel: petersen at redhat dot com scim-bridge tcallawa at redhat dot com check FE-ACCEPT packages stats: - 928 accepted, closed package reviews - 8 accepted, closed package reviews not in repo - 4 accepted, closed package reviews not in owners - 9 accepted, open package reviews older than 4 weeks; - 6 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 102 open tickets - 26 tickets with no activity in eight weeks - 16 tickets with no activity in four weeks - 4 closed tickets FE-NEW packages stats: - 182 open tickets - 18 tickets with no activity in eight weeks - 44 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 31 open tickets - 1 tickets with no activity in eight weeks - 9 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 216 open tickets - 135 tickets with no activity in eight weeks - 29 tickets with no activity in four weeks CVS stats: - 1716 packages with a devel directory - 27 packages with no owners entry gpasman grandr_applet gsview initng k3b-ape kernel-module-thinkpad kile-i18n kimdaba libexif muse nethack-falconseye pcb perl-Convert-ASN1 perl-DateManip perl-GD-SVG perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX perl-XML-Writer perl-bioperl python-ldap - 2 packages in CVS devel *and* Core check libevent - 39 packages were dropped from extras Maintainers stats: - 202 maintainers - 18 inactive maintainers with open bugs - 45 inactive maintainers Dropped FC packages: - 258 packages were dropped from core since FC 1 From wart at kobold.org Sun Jun 18 01:52:31 2006 From: wart at kobold.org (Wart) Date: Sat, 17 Jun 2006 18:52:31 -0700 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <4494AC7B.2090202@knox.net.nz> References: <4494AC7B.2090202@knox.net.nz> Message-ID: <4494B1DF.7000603@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael J. Knox wrote: > > FE Package Status of Jun 18, 2006 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus > > > Owners file stats: > - 1867 packages > - 38 orphans > - 43 packages not available in extras devel or release ... > wart at kobold dot org manaworld This one keeps deadlocking when building in rawhide. FC4 and FC5 builds went through ok. Warren started to look into the problem, but I don't think he found the solution yet. > - 5 packages which have not yet been FE-APPROVE'd... > > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=189375,193342,195292 > > Maelstrom Bill Nottingham This one moved from Core to Extras quite a while ago, but the owner requested a formal re-review. Changes from the review are being made directly in CVS. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFElLHdDeYlPfs40g8RAm3QAJ9BnEcQvHtaKhzZ593H5TmVH18gRACcCIad Wxd1esnV/Gbmy1DrlWSVNAM= =YBEs -----END PGP SIGNATURE----- From ville.skytta at iki.fi Sun Jun 18 06:51:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 18 Jun 2006 09:51:46 +0300 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <44947835.1020504@hhs.nl> References: <44947835.1020504@hhs.nl> Message-ID: <1150613506.2757.18.camel@localhost.localdomain> On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: > So there is a maintained and gtk2 using xmms out there, why do we thrn > still ship xmms itself? AFAIK a lot of plugins are available only for xmms, other media players can use libxmms and the plugins, gtk1 dependency chain is a lot smaller than gtk2 which may matter eg. in "pure" KDE setups, it works, has a package maintainer and is not quite dead upstream either based on CVS commits. From seg at haxxed.com Sun Jun 18 07:00:28 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 18 Jun 2006 02:00:28 -0500 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <44947835.1020504@hhs.nl> References: <44947835.1020504@hhs.nl> Message-ID: <1150614028.3602.4.camel@localhost> On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: > So there is a maintained and gtk2 using xmms out there, why do we thrn > still ship xmms itself? For one, I see no bmp-crossfade package. Even though xmms-crossfade apparently can be built for bmp. bmp-acme would be nice 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 j.w.r.degoede at hhs.nl Sun Jun 18 07:39:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Jun 2006 09:39:30 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <1150613506.2757.18.camel@localhost.localdomain> References: <44947835.1020504@hhs.nl> <1150613506.2757.18.camel@localhost.localdomain> Message-ID: <44950332.5020401@hhs.nl> Ville Skytt? wrote: > On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: > >> So there is a maintained and gtk2 using xmms out there, why do we thrn >> still ship xmms itself? > > AFAIK a lot of plugins are available only for xmms, other media players > can use libxmms and the plugins, bmp has libbmp which is api compatible with libxmms and I beleave (but I am in no way sure) even abi), the plugin interface is not ABI but is API compatible, so doing a recompile is all that it should take. One note though I tried audacious yesterday which is a fork of bmp (after bmp was declared dead by its maintainers) and we really should having this discussion about audacious as bmp is kinda dead. Audacious works fine and comes with quite a lot of plugins out of the box. (Not all though). > gtk1 dependency chain is a lot smaller > than gtk2 which may matter eg. in "pure" KDE setups. They will need this anyway for system-config-xxxx, or openoffice or firefox. AFAIK xmms is one of the few aps left using gtk1, the whole point of my post is that there are xmms replacememts out there with the same functionality (the same codebase even) that use gtk2. I was hoping that having a good replacement for xmms could sooner or later lead do really dropping gtk+. > it works, has a > package maintainer and is not quite dead upstream either based on CVS > commits. True, and I guess that as long as there is a maintainer willing to keep it in good shape, we should ship it since that is how extras works. I guess its just that people don't know about these replacements and that these replacements are really an improvement (gtk+ is kinda ugly to name one). Anyways I'll contact the bmp maintainer and ask him if he is willing to replace bmp with audacious, we really don't need 3 xmms versions. Then I'll start helping him getting as many as possible (all) the xmms plugins also available for audacious. I do feel that there is a waste of effort here and that audacious is the way to go. It has a really active upstream which IMHO is important. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 18 07:47:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Jun 2006 09:47:55 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <1150614028.3602.4.camel@localhost> References: <44947835.1020504@hhs.nl> <1150614028.3602.4.camel@localhost> Message-ID: <4495052B.7030108@hhs.nl> Callum Lerwick wrote: > On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: >> So there is a maintained and gtk2 using xmms out there, why do we thrn >> still ship xmms itself? > > For one, I see no bmp-crossfade package. Even though xmms-crossfade > apparently can be built for bmp. > > bmp-acme would be nice too... > Yes but thats all fixable AFAIK. Regards, Hans From ville.skytta at iki.fi Sun Jun 18 08:34:28 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 18 Jun 2006 11:34:28 +0300 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <44950332.5020401@hhs.nl> References: <44947835.1020504@hhs.nl> <1150613506.2757.18.camel@localhost.localdomain> <44950332.5020401@hhs.nl> Message-ID: <1150619668.2757.45.camel@localhost.localdomain> On Sun, 2006-06-18 at 09:39 +0200, Hans de Goede wrote: > Ville Skytt? wrote: > > bmp has libbmp which is api compatible with libxmms and I beleave > (but I am in no way sure) even abi) libbmp <-> libxmms needs to be taken into account when linking or dlopening in dependent apps, and those apps need to be prepared for that. > the plugin interface > is not ABI but is API compatible, so doing a recompile is all that it > should take. Hardly. #include is very commonly found in xmms plugins (all of them?) and bmp-devel doesn't provide that. Also the vast majority of xmms plugins have direct gtk1 dependencies of their own which needs to change or it makes the whole effort kind of pointless. The plugin install dirs are different too, as are xmms-config vs pkg-config bmp invocations. It may be that these issues would be easy to fix/port for gtk2/bmp, but a rebuild alone after changing build dependencies doesn't magically accomplish that. > > gtk1 dependency chain is a lot smaller > > than gtk2 which may matter eg. in "pure" KDE setups. > They will need this anyway for system-config-xxxx, or openoffice or > firefox. Note "pure" KDE setups. system-config-xxx (not necessarily needed), openoffice (-> koffice) or firefox (-> konqueror) don't qualify there. Anyway, this issue is mostly of academic interest and IMO would not qualify as a blocker against dropping xmms if all other issues would be resolved. > I was hoping > that having a good replacement for xmms could sooner or later lead do > really dropping gtk+. I share that hope, but I don't think the replacements are ready yet. From lars at homer.se Sun Jun 18 08:21:40 2006 From: lars at homer.se (Lars E. Pettersson) Date: Sun, 18 Jun 2006 10:21:40 +0200 Subject: rrdtool query Message-ID: <44950D14.9000708@homer.se> Noticed this morning, that my perl based rrdtool-scripts had stopped working during the night, due to rrdtool being updated. I found out that the rrdtool package had been split into sub packages, and that I needed perl-rrdtool. Installed it and now it works as before. I have a question. Why do these subpackages have the following names: perl-rrdtool php-rrdtool python-rrdtool Why not rrdtool-perl rrdtool-php rrdtool-python For me those names feel more logical. Lars -- Lars E. Pettersson http://www.sm6rpz.se/ From andreas.bierfert at lowlatency.de Sun Jun 18 09:12:04 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 18 Jun 2006 11:12:04 +0200 Subject: Need help with upgrade path In-Reply-To: <1150543953.10344.22.camel@localhost.localdomain> References: <20060616102149.754628be@alkaid.a.lan> <1150543953.10344.22.camel@localhost.localdomain> Message-ID: <20060618111204.6d873d5b@alkaid.a.lan> On Sat, 17 Jun 2006 14:32:33 +0300 "Ville Skytt?" wrote: > On Fri, 2006-06-16 at 10:21 +0200, Andreas Bierfert wrote: > > > Idea was to maybe add an Obsoletes wine <= 0.9.15-1 to wine-core > > That should be <= 0.9.15-1%{?dist} Yes indeed... but would that be enough? - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sun Jun 18 09:18:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Jun 2006 11:18:44 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <4494AC7B.2090202@knox.net.nz> References: <4494AC7B.2090202@knox.net.nz> Message-ID: <20060618111844.ffde77e9.bugs.michael@gmx.net> On Sun, 18 Jun 2006 13:29:31 +1200, Michael J. Knox wrote: > Owners file stats: > - 43 packages not available in extras devel or release What is this based on? The list contains many packages which are NOT included anymore on purpose. Either obsoleted or not needed anymore (and mind you, we don't have any meta package where to put global obsoletes forever). At least these need not be put into this report: > andreas at bawue dot net dd_rescue > bugs dot michael at gmx dot net libgcrypt1 > denis at poolshark dot org gtkmm20 > denis at poolshark dot org libgnomemm20 > denis at poolshark dot org libglademm20 > denis at poolshark dot org libgnomecanvasmm20 > denis at poolshark dot org libgnomeuimm20 > denis at poolshark dot org gconfmm20 > dennis at ausil dot us cryptplug > fedora at leemhuis dot info alsa-firmware > mattdm at mattdm dot org wxPythonGTK2 > matthias at rpmforge dot net php-pecl-pdo > matthias at rpmforge dot net php-pecl-sqlite > matthias at rpmforge dot net php-pecl-pdo-sqlite > matthias at rpmforge dot net php-mmcache > nomis80 at nomis80 dot org juk > wtogami at redhat dot com openoffice-extras Files merged into Core package long ago. > davidhart at tqmcube dot com leafnode Smells like a AWOL maintainer. > - 5 packages which have not yet been FE-APPROVE'd... > > Openbox Peter Gordon > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 A false positive? This is a resurrection attempt. owners.list only contains the very old entry from fedora.us era. From chitlesh at fedoraproject.org Sun Jun 18 09:20:10 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Jun 2006 11:20:10 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <4494AC7B.2090202@knox.net.nz> References: <4494AC7B.2090202@knox.net.nz> Message-ID: <13dbfe4f0606180220g5653c327qde981f1d0b7a879@mail.gmail.com> On 6/18/06, Michael J. Knox wrote: > FE Package Status of Jun 18, 2006 > Owners file stats: > - 1867 packages > - 38 orphans > - 43 packages not available in extras devel or release > cgoorah at yahoo dot com dot au kadischi As for Kadischi, we are working on it internally on cvs, but yet we can't call it stable enough to package it for release. I was thinking why not make it available on extras-development. Perhaps that could bring more testers (since we need testers who have 64 bit machines) and more contributors to push things forward quickly. Does it break any FE policies if we (from kadischi) start packaging kadischi for only and only extras-development ? Chitlesh Goorah -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Sun Jun 18 09:25:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Jun 2006 11:25:39 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <44950332.5020401@hhs.nl> References: <44947835.1020504@hhs.nl> <1150613506.2757.18.camel@localhost.localdomain> <44950332.5020401@hhs.nl> Message-ID: <20060618112539.c2439a6f.bugs.michael@gmx.net> On Sun, 18 Jun 2006 09:39:30 +0200, Hans de Goede wrote: > > > Ville Skytt? wrote: > > On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: > > > >> So there is a maintained and gtk2 using xmms out there, why do we thrn > >> still ship xmms itself? > > > > AFAIK a lot of plugins are available only for xmms, other media players > > can use libxmms and the plugins, > > bmp has libbmp which is api compatible with libxmms and I beleave (but I > am in no way sure) even abi), the plugin interface is not ABI but is API > compatible, so doing a recompile is all that it should take. Are you sure? I remember that bmp uses gnome vfs style file paths, and this is not understood by many xmms plugins if simply built for bmp. They would even fail to load files with a "file://" prefix. > One note though I tried audacious yesterday which is a fork of bmp > (after bmp was declared dead by its maintainers) and we really should > having this discussion about audacious as bmp is kinda dead. This "discussion" should be about actual packages and in the bugzilla review queue, though. We should not make a sudden jump to just another fork only to discover its deficiences. That's why XMMS is still around and why bmpx has not made it yet. From michael at knox.net.nz Sun Jun 18 09:27:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 18 Jun 2006 21:27:31 +1200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <20060618111844.ffde77e9.bugs.michael@gmx.net> References: <4494AC7B.2090202@knox.net.nz> <20060618111844.ffde77e9.bugs.michael@gmx.net> Message-ID: <44951C83.6000909@knox.net.nz> Michael Schwendt wrote: > On Sun, 18 Jun 2006 13:29:31 +1200, Michael J. Knox wrote: > >> Owners file stats: > >> - 43 packages not available in extras devel or release > > What is this based on? The same script that was run last time. In fact, last run it was 51, so we might need to check a bit closer whats happening here and ensure that that number is indeed correct. This script is not perfect and with packages moving to core from extras and from extras to core, we will see some oddities. > The list contains many packages which are NOT included anymore on > purpose. Either obsoleted or not needed anymore (and mind you, we don't > have any meta package where to put global obsoletes forever). At least > these need not be put into this report: > [snip] I can have these black listed. >> wtogami at redhat dot com openoffice-extras > > Files merged into Core package long ago. will add to an exclude list. >> davidhart at tqmcube dot com leafnode > > Smells like a AWOL maintainer. Shall it be orphaned then? >> - 5 packages which have not yet been FE-APPROVE'd... >> >> Openbox Peter Gordon >> https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 > > A false positive? This is a resurrection attempt. owners.list only > contains the very old entry from fedora.us era. Peter recently claimed ownership of this and it is going for a full review. Thanks! Michael From thomas at apestaart.org Sun Jun 18 10:42:27 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 18 Jun 2006 12:42:27 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <4494AC7B.2090202@knox.net.nz> References: <4494AC7B.2090202@knox.net.nz> Message-ID: <1150627348.2597.137.camel@otto.amantes> Hi, Nice work ! > Packages appearing both in Core and Extras: > - 1 packages duplicated for FC5: > tcallawa at redhat dot com check > - 2 packages duplicated for devel: > petersen at redhat dot com scim-bridge > tcallawa at redhat dot com check How does one get "check" out of FC5 and devel ? Who should do this ? Thomas From thomas at apestaart.org Sun Jun 18 10:44:19 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 18 Jun 2006 12:44:19 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <44947835.1020504@hhs.nl> References: <44947835.1020504@hhs.nl> Message-ID: <1150627459.2597.140.camel@otto.amantes> On Sat, 2006-06-17 at 23:46 +0200, Hans de Goede wrote: > Hi all, > > I just found about about this xmms fork which is actually still alive > unlike xmms and uses gtk2 called bmp, and its already in extras, then > why do we still ship xmms? > > I tried bmp and its just like xmms only gtk2 and maintained! > > Well actually it was maintained, now the bmp people are working on bmpx, > but there is a bmp fork called Audacious, which picked up when the bmp > people stopped maintaining bmp and started working on bmpx. (Notice I > didn't test Audacious. Well, you kind of put the finger on the problem right there. You start by saying "bmp is maintained". Then you say "not actually". And then you name two other forks/developments of the original fork of xmms. In other words, until the dust settles and there is an actual obvious replacement, I don't think people are going to be helped much if we drop xmms. Thomas From rmo at sunnmore.net Sun Jun 18 11:11:03 2006 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Sun, 18 Jun 2006 13:11:03 +0200 Subject: rrdtool query In-Reply-To: <44950D14.9000708@homer.se> References: <44950D14.9000708@homer.se> Message-ID: <449534C7.4030608@sunnmore.net> Lars E. Pettersson wrote: > Noticed this morning, that my perl based rrdtool-scripts had stopped > working during the night, due to rrdtool being updated. I found out that > the rrdtool package had been split into sub packages, and that I needed > perl-rrdtool. Installed it and now it works as before. > > I have a question. Why do these subpackages have the following names: > > perl-rrdtool > php-rrdtool > python-rrdtool It's all explained in the packaging guidelines: http://fedoraproject.org/wiki/Packaging/NamingGuidelines -- Roy-Magne Mo From dwmw2 at infradead.org Sun Jun 18 14:42:05 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Jun 2006 15:42:05 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-15 In-Reply-To: References: <20060615205746.GD31124@lists.us.dell.com> Message-ID: <1150641725.3176.381.camel@pmac.infradead.org> On Fri, 2006-06-16 at 07:52 +0200, Aurelien Bompard wrote: > > amaya paul at all-the-johnsons.co.uk > > mhonarc gauret at free.fr > > perl-Unicode-Map8 gauret at free.fr > > perl-Unicode-MapUTF8 gauret at free.fr > > Those are ExcludeArch'ed x86_64. Why? What bug number(s)? -- dwmw2 From lars at homer.se Sun Jun 18 15:18:00 2006 From: lars at homer.se (Lars E. Pettersson) Date: Sun, 18 Jun 2006 17:18:00 +0200 Subject: rrdtool query In-Reply-To: <449534C7.4030608@sunnmore.net> References: <44950D14.9000708@homer.se> <449534C7.4030608@sunnmore.net> Message-ID: <44956EA8.5030802@homer.se> On 06/18/2006 01:11 PM, Roy-Magne Mo wrote: > Lars E. Pettersson wrote: >> I have a question. Why do these subpackages have the following names: >> >> perl-rrdtool >> php-rrdtool >> python-rrdtool > > It's all explained in the packaging guidelines: > http://fedoraproject.org/wiki/Packaging/NamingGuidelines But is not the parent in this case rrdtool, and therefore rrdtool-* the correct name? The perl-rrdtool package, as one example, adds a new functionality to the rrdtool package, and can not be used on its own, you need rrdtool (and perl also, I have to admit.) As the package also is very tightly coupled to the rrdtool package (comes from the same tar file, except php that uses a patch), rrdtool-perl seems much more logical than the reverse, IMHO. I can see a chicken or egg problem here, though... Lars -- Lars E. Pettersson http://www.sm6rpz.se/ From Matt_Domsch at dell.com Sun Jun 18 18:05:32 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Jun 2006 13:05:32 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-18 Message-ID: <20060618180532.GC1390@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Sun Jun 18 12:28:53 CDT 2006 Number failed to build: 167 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 156 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 152 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk+ rdieter at math.unl.edu gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de heartbeat fedora at soeterbroek.com hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mftrace qspencer at ieee.org mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 Jun 18 18:05:59 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Jun 2006 13:05:59 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-18 Message-ID: <20060618180559.GD1390@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Sun Jun 18 12:30:27 CDT 2006 Number failed to build: 147 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 146 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 142 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Hermes thomas at apestaart.org MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dejavu-fonts nicolas.mailhot at laposte.net dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gnome-sudoku stickster at gmail.com gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com lilypond qspencer at ieee.org linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mfstools tcallawa at redhat.com mftrace qspencer at ieee.org multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 ASSIGNED'] tla at rasmil.dk 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 hugo at devin.com.br Sun Jun 18 19:06:31 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sun, 18 Jun 2006 16:06:31 -0300 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <4494AC7B.2090202@knox.net.nz> References: <4494AC7B.2090202@knox.net.nz> Message-ID: <200606181606.31351.hugo@devin.com.br> On Saturday 17 June 2006 22:29, Michael J. Knox wrote: > - 9 packages not available in extras devel but present in release > hugo at devin dot com dot br kerry The building process was stuck in a loop on devel-i386 at buildsys (a known problem). It got resolved some days ago and now I did a requeue on the job and it was sucessfully built now. -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From fedora at leemhuis.info Sun Jun 18 19:04:07 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jun 2006 21:04:07 +0200 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday Message-ID: <1150657448.2210.26.camel@localhost.localdomain> Hi! I'm proud to announce that the Fedora Extras Steering Committee (created on the first FUDCon back in February 2005) plans an election to let all Extras packagers vote the new members for the next FESCo working period. 17 people nominated themselves for the job: 1. Andreas Bierfert (awjb) 2. Tom "spot" Callaway (spot) 3. Rex Dieter (rdieter) 4. Kevin Fenzi (nirik) 5. Dennis Gilmore (ausil) irc (dgilmore) 6. Christian Iseli (c4chris) 7. Jeremy Katz (jeremy) 8. Michael J. Knox (mjk) 9. Toshio Kuratomi (abadger1999) 10. Thorsten Leemhuis (thl) 11. Jose-Pedro Oliviera (jpo) 12. Brian Pepple (bpepple) 13. Michael Schwendt (mschwendt) 14. Ville Skytt? (scop) 15. Jason Tibbitts (tibbs) 16. Warren Togami (wtogami) 17. Seth Vidal (skvidal) For details and some future plans of these fine people see: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations You are a Fedora Extras Packager and want to be in the next FESCo? Well, then hurry up and nominate yourself until Tuesday, 20 June 23:59 UTC by adding yourself to above wiki page. For some details on the nominations and the background of the decision to actually make it one see: https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html The actual election will start on Thursday, 22 June 0:01 UTC and will last until Sunday, 02 July 23:59 UTC. The results will be posted to this list. The first meeting of the "new" FESCo will be on Thursday, June 06 2006 on #fedora-extras at 17:00 UTC. A new chair will be elected there by the new members. The actual voting will happen in the accounts system. Toshio Kuratomi was so helpful and created a framework for it, see https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00676.html for details. Thanks for your great work Toshio! I hope I didn't miss any important information. If I did: Just ask. CU thl P.S.: Sorry for cross-posting, but I think that okay for this kind of mail. Follow-up-to fedora-extras-list at redhat.com only please. tia! -- Thorsten Leemhuis From fedora at leemhuis.info Sun Jun 18 19:12:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jun 2006 21:12:48 +0200 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150657968.2210.36.camel@localhost.localdomain> Hi All! There is one thing still unclear: Am Sonntag, den 18.06.2006, 21:04 +0200 schrieb Thorsten Leemhuis: > The actual voting will happen in the accounts system. Toshio Kuratomi > was so helpful and created a framework for it, see > https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00676.html > for details. Thanks for your great work Toshio! We need to restrict access to the voting app and the database and someone trustworthy that actually checks if the election worked fine and was not faked who also queries the results from the database when the election is finished. Toshio is nominated for the new FESCo so he's probably not the best one for that job. I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this mail) for that job -- he was in the old FESCo, is not nominated for the new one, is admin of the accounts system and seems to be the right one for the job. That okay for everybody? Sopwith, can you do that? CU thl -- Thorsten Leemhuis From michael at knox.net.nz Sun Jun 18 19:16:26 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 19 Jun 2006 07:16:26 +1200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <1150627348.2597.137.camel@otto.amantes> References: <4494AC7B.2090202@knox.net.nz> <1150627348.2597.137.camel@otto.amantes> Message-ID: <4495A68A.6020103@knox.net.nz> Thomas Vander Stichele wrote: > Hi, > > Nice work ! > > > >>Packages appearing both in Core and Extras: >> - 1 packages duplicated for FC5: >> tcallawa at redhat dot com check >> - 2 packages duplicated for devel: >> petersen at redhat dot com scim-bridge >> tcallawa at redhat dot com check > > > How does one get "check" out of FC5 and devel ? Who should do this ? If you mean core, I don't know, you might have to poke a RedHat ype person. Extras, there is a wiki page you can add the app too to have it manually removed. Michael From bugs.michael at gmx.net Sun Jun 18 19:32:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Jun 2006 21:32:38 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <1150627348.2597.137.camel@otto.amantes> References: <4494AC7B.2090202@knox.net.nz> <1150627348.2597.137.camel@otto.amantes> Message-ID: <20060618213238.a78ce25f.bugs.michael@gmx.net> On Sun, 18 Jun 2006 12:42:27 +0200, Thomas Vander Stichele wrote: > Hi, > > Nice work ! > > > > Packages appearing both in Core and Extras: > > - 1 packages duplicated for FC5: > > tcallawa at redhat dot com check > > - 2 packages duplicated for devel: > > petersen at redhat dot com scim-bridge > > tcallawa at redhat dot com check > > How does one get "check" out of FC5 and devel ? Who should do this ? check*.rpm will be gone with next push of FE 5 and FE development There are pages in the Wiki for requests about removing packages from the repository. From j.w.r.degoede at hhs.nl Sun Jun 18 19:58:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Jun 2006 21:58:57 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <1150619668.2757.45.camel@localhost.localdomain> References: <44947835.1020504@hhs.nl> <1150613506.2757.18.camel@localhost.localdomain> <44950332.5020401@hhs.nl> <1150619668.2757.45.camel@localhost.localdomain> Message-ID: <4495B081.5000000@hhs.nl> Ville Skytt? wrote: > On Sun, 2006-06-18 at 09:39 +0200, Hans de Goede wrote: >> Ville Skytt? wrote: >> >> bmp has libbmp which is api compatible with libxmms and I beleave >> (but I am in no way sure) even abi) > > libbmp <-> libxmms needs to be taken into account when linking or > dlopening in dependent apps, and those apps need to be prepared for > that. > If we actually drop libxmms then we can easily patch the (few) apps using libxmms to compile and link against libbmp. >> the plugin interface >> is not ABI but is API compatible, so doing a recompile is all that it >> should take. > > Hardly. #include is very commonly found in xmms plugins (all > of them?) and bmp-devel doesn't provide that. Also the vast majority of > xmms plugins have direct gtk1 dependencies of their own which needs to > change or it makes the whole effort kind of pointless. The plugin > install dirs are different too, as are xmms-config vs pkg-config bmp > invocations. It may be that these issues would be easy to fix/port for > gtk2/bmp, but a rebuild alone after changing build dependencies doesn't > magically accomplish that. > True, I forgot about that, but AFAIK (from reading docs only) GUI-less plugings will work almost out of the box, and the others "only" need a gtk1->2 port. >>> gtk1 dependency chain is a lot smaller >>> than gtk2 which may matter eg. in "pure" KDE setups. >> They will need this anyway for system-config-xxxx, or openoffice or >> firefox. > > Note "pure" KDE setups. system-config-xxx (not necessarily needed), > openoffice (-> koffice) or firefox (-> konqueror) don't qualify there. > Anyway, this issue is mostly of academic interest and IMO would not > qualify as a blocker against dropping xmms if all other issues would be > resolved. > I'm glad you say that I was thinking about investing (some) time in getting audacious into Extras (preferably as a replacement for bmp initially we really don't need xmms + 2 forks) and then working on getting the other issues resolved. It would also be nice to have a list of the other issues, so far we have that I'm aware of: -all the xmms plugins must be ported too / be available for audacious. -xmmslib using apps should be able to use audaciouslib instead. >> I was hoping >> that having a good replacement for xmms could sooner or later lead do >> really dropping gtk+. > > I share that hope, but I don't think the replacements are ready yet. > Well I'm willing to work on getting them ready and I have some time to invest this summer (I work as a teacher). For starters I'll contact the bmp package maintainer and try to work with him to get audacious in to FE (preferably as a BMP replacement). Then I'll start porting all the plugins in FE and that other repo, and the apps using libxmms. Once thats done we need some people todo a descent amount of testing and then we will hopefully be ready to drop xmms. So unless someone seems some big holes in my plan I would like to this discussion to stop and to invest my time in actually making this happen. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 18 20:11:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Jun 2006 22:11:57 +0200 Subject: kadischi kadischi.spec,1.10,1.11 In-Reply-To: <200606180904.k5I94uwM018118@cvs-int.fedora.redhat.com> References: <200606180904.k5I94uwM018118@cvs-int.fedora.redhat.com> Message-ID: <4495B38D.9030904@hhs.nl> Chitlesh GOORAH (chitlesh) wrote: > Author: chitlesh > > Update of /cvs/devel/kadischi > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18101 > > Modified Files: > kadischi.spec > Log Message: > > > > Index: kadischi.spec > =================================================================== > RCS file: /cvs/devel/kadischi/kadischi.spec,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- kadischi.spec 17 Jun 2006 19:55:36 -0000 1.10 > +++ kadischi.spec 18 Jun 2006 09:04:54 -0000 1.11 > @@ -78,8 +78,8 @@ > %ghost %{_datadir}/%{name}/post_install_scripts/*.pyo > > %changelog > -* Fri Jun 16 2006 Chitlesh Goorah - 2.1-2.20060617cvs > -- dropped empty NEWS from %%doc > +* Sat Jun 17 2006 Chitlesh Goorah - 2.1-2.20060617cvs > +- dropped empty NEWS from %doc > - don't glib-gettextize (breaks locale creation) > - fix script-without-shellbang rpmlint errors > > Erm removing the double % (%%) in the Changelog is a bad idea, take a look at the rpm -qip of a package after build with this new SPEc, I'm not sure what it will look like but I doubt it will give the desired result. Regards, Hans From chitlesh at fedoraproject.org Sun Jun 18 20:22:36 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Jun 2006 22:22:36 +0200 Subject: kadischi kadischi.spec,1.10,1.11 In-Reply-To: <4495B38D.9030904@hhs.nl> References: <200606180904.k5I94uwM018118@cvs-int.fedora.redhat.com> <4495B38D.9030904@hhs.nl> Message-ID: <13dbfe4f0606181322l61e816famd3384b8d2a92161@mail.gmail.com> On 6/18/06, Hans de Goede wrote: > Erm removing the double % (%%) in the Changelog is a bad idea, take a > look at the rpm -qip of a package after build with this new > SPEc, I'm not sure what it will look like but I doubt it will give the > desired result. Thanks. in which mailing list should I subscribe to have such cvs updates ? -- http://clunixchit.blogspot.com From nicolas.mailhot at laposte.net Sun Jun 18 20:51:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Jun 2006 22:51:00 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-18 In-Reply-To: <20060618180559.GD1390@lists.us.dell.com> References: <20060618180559.GD1390@lists.us.dell.com> Message-ID: <1150663863.7475.12.camel@rousalka.dyndns.org> Le dimanche 18 juin 2006 ? 13:05 -0500, Matt Domsch a ?crit : > dejavu-fonts nicolas.mailhot at laposte.net Can I have a build log ? It seems very strange that building a font package failed (moreover a font package wish has been rebuilt intensively this week without any failures so far) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From michael at knox.net.nz Sun Jun 18 20:56:00 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 19 Jun 2006 08:56:00 +1200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-18 In-Reply-To: <1150663863.7475.12.camel@rousalka.dyndns.org> References: <20060618180559.GD1390@lists.us.dell.com> <1150663863.7475.12.camel@rousalka.dyndns.org> Message-ID: <4495BDE0.1000906@knox.net.nz> Nicolas Mailhot wrote: > Le dimanche 18 juin 2006 ? 13:05 -0500, Matt Domsch a ?crit : > > >>dejavu-fonts nicolas.mailhot at laposte.net > > > Can I have a build log ? It seems very strange that building a font > package failed (moreover a font package wish has been rebuilt > intensively this week without any failures so far) Logs can be found here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/dejavu-fonts-2.7.0-0.17.20060614svn943.fc6.src.rpm/result/ You need to look at the root.log, seems it was not able to install some packages. The current buildsys is not using the soon to be default minimal build root (IIRC), hence why it may build on the buildsys and not with Matt's rebuild. Michael From nicolas.mailhot at laposte.net Sun Jun 18 21:04:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Jun 2006 23:04:05 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-06-18 In-Reply-To: <4495BDE0.1000906@knox.net.nz> References: <20060618180559.GD1390@lists.us.dell.com> <1150663863.7475.12.camel@rousalka.dyndns.org> <4495BDE0.1000906@knox.net.nz> Message-ID: <1150664646.7475.18.camel@rousalka.dyndns.org> Le lundi 19 juin 2006 ? 08:56 +1200, Michael J. Knox a ?crit : > Nicolas Mailhot wrote: > > Le dimanche 18 juin 2006 ? 13:05 -0500, Matt Domsch a ?crit : > > > > > >>dejavu-fonts nicolas.mailhot at laposte.net > > > > Can I have a build log ? It seems very strange that building a font > > package failed (moreover a font package wish has been rebuilt > > intensively this week without any failures so far) > > Logs can be found here: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/dejavu-fonts-2.7.0-0.17.20060614svn943.fc6.src.rpm/result/ > > You need to look at the root.log, seems it was not able to install some > packages. No Package Found for /usr/lib/perl5/5.8.8/unicore/Blocks.txt No Package Found for /usr/lib/perl5/5.8.8/unicore/UnicodeData.txt Looks like a problem in perl or yum, the builddeps are valid and do exist in the repo Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at city-fan.org Sun Jun 18 21:27:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 18 Jun 2006 22:27:00 +0100 Subject: kadischi kadischi.spec,1.10,1.11 In-Reply-To: <13dbfe4f0606181322l61e816famd3384b8d2a92161@mail.gmail.com> References: <200606180904.k5I94uwM018118@cvs-int.fedora.redhat.com> <4495B38D.9030904@hhs.nl> <13dbfe4f0606181322l61e816famd3384b8d2a92161@mail.gmail.com> Message-ID: <1150666021.13102.21.camel@laurel.intra.city-fan.org> On Sun, 2006-06-18 at 22:22 +0200, Chitlesh GOORAH wrote: > On 6/18/06, Hans de Goede wrote: > > Erm removing the double % (%%) in the Changelog is a bad idea, take a > > look at the rpm -qip of a package after build with this new > > SPEc, I'm not sure what it will look like but I doubt it will give the > > desired result. > > Thanks. > > in which mailing list should I subscribe to have such cvs updates ? fedora-extras-commits. Everyone with cvs commit access is supposed to be on that list: See: http://www.fedoraproject.org/wiki/Extras/Contributors (Join the Mailing List) Paul. From paul at all-the-johnsons.co.uk Sun Jun 18 21:28:07 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 18 Jun 2006 22:28:07 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-18 In-Reply-To: <20060618180532.GC1390@lists.us.dell.com> References: <20060618180532.GC1390@lists.us.dell.com> Message-ID: <1150666087.29435.80.camel@T7.Linux> Hi, > amaya paul at all-the-johnsons.co.uk This has an x86_64 blocker on it (BZ 182512 IIRC). Newer versions fail to build due to a missing symbol in libpng-1.2.10 (png_read_destroy). This bug has been reported. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 wart at kobold.org Sun Jun 18 22:20:58 2006 From: wart at kobold.org (Wart) Date: Sun, 18 Jun 2006 15:20:58 -0700 Subject: locales Message-ID: <4495D1CA.2080600@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A package that I'm reviewing[1] keeps its language translation files in %{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules about using %find_lang when an application doesn't use %{_datadir}/locale for the translation files? - --Mike [1] (amsn: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185951 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEldHJDeYlPfs40g8RAhseAJ41NxwJGQVw6DE4CKysPhDDbvi9EwCeJd9C 6ja6/py3IFJkEKh5s2F5NoY= =oE4N -----END PGP SIGNATURE----- From paul at all-the-johnsons.co.uk Sun Jun 18 22:23:44 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 18 Jun 2006 23:23:44 +0100 Subject: locales In-Reply-To: <4495D1CA.2080600@kobold.org> References: <4495D1CA.2080600@kobold.org> Message-ID: <1150669424.29435.86.camel@T7.Linux> Hi, > A package that I'm reviewing[1] keeps its language translation files in > %{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules > about using %find_lang when an application doesn't use > %{_datadir}/locale for the translation files? I thought languages had to be in the locale directory for them to be picked up automatically. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 wart at kobold.org Sun Jun 18 22:49:25 2006 From: wart at kobold.org (Wart) Date: Sun, 18 Jun 2006 15:49:25 -0700 Subject: locales In-Reply-To: <1150669424.29435.86.camel@T7.Linux> References: <4495D1CA.2080600@kobold.org> <1150669424.29435.86.camel@T7.Linux> Message-ID: <4495D875.1020802@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul wrote: > Hi, > > >>A package that I'm reviewing[1] keeps its language translation files in >>%{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules >>about using %find_lang when an application doesn't use >>%{_datadir}/locale for the translation files? > > > I thought languages had to be in the locale directory for them to be > picked up automatically. I interpret this to mean that an application is free to store language translation files in its own data directory, and in such a case the spec file must include the language files in %files, and use of %find_lang is not needed. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEldh0DeYlPfs40g8RAqB8AJ9kwXZG0Jmnaw0gw9rc2xHUWQynowCfeB3T Mk8F5PbiucLQgL+/9Dz22ms= =eS/s -----END PGP SIGNATURE----- From Christian.Iseli at licr.org Sun Jun 18 23:07:36 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 19 Jun 2006 01:07:36 +0200 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: Your message of "Sun, 18 Jun 2006 21:12:48 +0200." <1150657968.2210.36.camel@localhost.localdomain> Message-ID: <200606182353.k5INrBlr008670@mx1.redhat.com> fedora at leemhuis.info said: > I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this mail) for > that job -- he was in the old FESCo, is not nominated for the new one, is > admin of the accounts system and seems to be the right one for the job. > That okay for everybody? Sure. Christian From buildsys at fedoraproject.org Sun Jun 18 23:48:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 18 Jun 2006 19:48:00 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-18 Message-ID: <20060618234800.6463315217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 17 aterm-1.0.0-5.fc5 dejavu-fonts-2.7.0-1.fc5 dillo-0.8.6-1.fc5 emacs-auctex-11.83-5.fc5 flow-tools-0.68-8.fc5 flumotion-0.2.1-2.fc5 gtypist-2.7-3.fc5 knetstats-1.5-7.fc5 lat-1.0.5-5.fc5 libnasl-2.2.8-1.fc5 libtorrent-0.9.3-1.fc5 liferea-1.0.15-2.fc5 nessus-libraries-2.2.8-1.fc5 perl-Log-Log4perl-1.05-1.fc5 php-idn-1.1-6.fc5 rtorrent-0.5.3-1.fc5 wv2-0.2.3-1.fc5 Packages built and released for Fedora Extras 4: 10 aterm-1.0.0-3.fc4 dejavu-fonts-2.7.0-1.fc4 emacs-auctex-11.83-3.fc4 flow-tools-0.68-8.fc4 libnasl-2.2.8-1.fc4 libtorrent-0.9.3-1.fc4 nessus-libraries-2.2.8-1.fc4 perl-Log-Log4perl-1.05-1.fc4 rtorrent-0.5.3-1.fc4 wv2-0.2.3-1.fc4 Packages built and released for Fedora Extras 3: 3 aterm-1.0.0-3.fc3 dillo-0.8.6-1.fc3 flow-tools-0.68-8.fc3 Packages built and released for Fedora Extras development: 20 aterm-1.0.0-5.fc6 autotrace-0.31.1-12.fc6 dap-server-3.6.1-2.fc6 dejavu-fonts-2.7.0-1.fc6 dillo-0.8.6-1.fc6 emacs-auctex-11.83-6.fc6 gnome-sudoku-0.4.0-8.fc6 gtypist-2.7-3.fc6 gurlchecker-0.10.0-3.fc6 kerry-0.1.1-2.fc6 libtorrent-0.9.3-1.fc6 liferea-1.0.15-3.fc6 monodoc-1.1.13-11.fc6 perl-Log-Log4perl-1.05-1.fc6 php-idn-1.1-6.fc6 php-magickwand-0.1.8-2.fc6 rtorrent-0.5.3-1.fc6 scribus-1.3.3.2-2.fc6 wv2-0.2.3-1.fc6 xsp-1.1.15-5.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Jun 18 23:48:35 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 18 Jun 2006 19:48:35 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-18 Message-ID: <20060618234835.24CD015217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firefox: 5: 0:1.5.0.4-1.2.fc5 (FC5-updates) 6: 0:1.5.0.3-2 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvirt: 5: 0:0.1.0-1.FC5 (FC5-updates) 6: 0:0.1.0-1 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mlmmj: 5: 0:1.2.11-4.fc5 (FE5) 6: 0:1.2.11-3.fc5 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.4-3.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) otrs: 5: 0:2.0.4-3.fc5 (FE5) 6: 0:2.0.4-3 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) perl-X11-Protocol: 5: 0:0.55-4.fc5 (FE5) 6: 0:0.55-3.fc6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-GeoIP: 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-3.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-hangul: 4: 0:0.2.2-2.fc4 (FE4) 5: 0:0.2.2-1.fc5.1 (FC5-updates) 6: 0:0.2.2-4.fc6 (FC6) scim-skk: 5: 0:0.5.2-5.fc5 (FE5) 6: 0:0.5.2-4.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) showimg: 5: 0:0.9.5-7.fc5 (FE5) 6: 0:0.9.5-5.fc5 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.15-1.fc3 (FE3) 4: 0:0.9.15-0.1.fc4 (FE4) 5: 0:0.9.15-1.fc5 (FE5) 6: 0:0.9.15-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) xmms: 5: 1:1.2.10-25.fc5 (FE5) 6: 1:1.2.10-24.fc6 (FE6) From buildsys at fedoraproject.org Mon Jun 19 00:01:25 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 19 Jun 2006 00:01:25 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-18 Message-ID: <20060619000125.23787.297@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Mon Jun 19 00:01:25 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 19 Jun 2006 00:01:25 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-18 Message-ID: <20060619000125.23805.60224@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 chabotc AT xs4all.nl buoh - 0.8.1-7.i386 buoh - 0.8.1-7.ppc buoh - 0.8.1-7.x86_64 cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch perl-POE - 0.3501-2.fc6.noarch enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 gauret AT free.fr showimg-pgsql - 0.9.5-5.fc5.i386 showimg-pgsql - 0.9.5-5.fc5.ppc showimg-pgsql - 0.9.5-5.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc kevin-redhat-bugzilla AT tummy.com bmp-xosd - 2.2.14-6.fc6.i386 bmp-xosd - 2.2.14-6.fc6.ppc bmp-xosd - 2.2.14-6.fc6.x86_64 xmms-xosd - 2.2.14-6.fc6.i386 xmms-xosd - 2.2.14-6.fc6.ppc xmms-xosd - 2.2.14-6.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 nicolas.mailhot AT laposte.net dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc6.noarch nos AT utelsystems.com soundtracker - 0.6.7-3.x86_64 soundtracker - 0.6.7-4.i386 soundtracker - 0.6.7-4.ppc oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 buoh-0.8.1-7.i386 requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.i386 requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.i386 requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 soundtracker-0.6.7-4.i386 requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 buoh-0.8.1-7.ppc requires libgnutls.so.12 dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.ppc requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.ppc requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 soundtracker-0.6.7-4.ppc requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_pixbuf.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bmp-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) buoh-0.8.1-7.x86_64 requires libgnutls.so.12()(64bit) dejavu-fonts-fontconfig-2.6.0-1.fc6.noarch requires dejavu-fonts = 0:2.6.0-1.fc6 diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-POE-0.3501-2.fc6.noarch requires perl(POE::Resource::Controls) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) showimg-pgsql-0.9.5-5.fc5.x86_64 requires libpqxx-2.5.5.so()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) soundtracker-0.6.7-3.x86_64 requires libgdk_pixbuf.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) From buildsys at fedoraproject.org Mon Jun 19 00:01:25 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 19 Jun 2006 00:01:25 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-18 Message-ID: <20060619000125.23800.54118@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch perl-POE - 0.3501-2.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- perl-POE-0.3501-2.fc4.noarch requires perl(POE::Resource::Controls) From buildsys at fedoraproject.org Mon Jun 19 00:01:25 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 19 Jun 2006 00:01:25 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-18 Message-ID: <20060619000125.23802.76344@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- cweyl AT alumni.drew.edu perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch perl-POE - 0.3501-2.fc5.noarch nicolas.mailhot AT laposte.net dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- dejavu-fonts-fontconfig-2.6.0-1.fc5.noarch requires dejavu-fonts = 0:2.6.0-1.fc5 perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- dejavu-fonts-fontconfig-2.6.0-1.fc5.noarch requires dejavu-fonts = 0:2.6.0-1.fc5 perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- dejavu-fonts-fontconfig-2.6.0-1.fc5.noarch requires dejavu-fonts = 0:2.6.0-1.fc5 freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 perl-POE-0.3501-2.fc5.noarch requires perl(POE::Resource::Controls) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: nicolas.mailhot AT laposte.net package: dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch from fedora-extras-5-i386 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc5 package: dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: dejavu-fonts = 0:2.6.0-1.fc5 package: dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch from fedora-extras-5-ppc unresolved deps: dejavu-fonts = 0:2.6.0-1.fc5 From nicolas.mailhot at laposte.net Mon Jun 19 06:59:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Jun 2006 08:59:24 +0200 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-18 In-Reply-To: <20060619000125.23802.76344@extras64.linux.duke.edu> References: <20060619000125.23802.76344@extras64.linux.duke.edu> Message-ID: <1150700364.31371.3.camel@rousalka.dyndns.org> Le lundi 19 juin 2006 ? 00:01 +0000, Fedora Extras repoclosure a ?crit : > Summary of broken packages (by owner): > nicolas.mailhot AT laposte.net > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch This is a bug in the buildsys - it does not removes subpackages obsoleted by another subpackage (in this particular case dejavu-fonts-fontconfig was renamed in dejavu-fonts-makedefault) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From thomas at apestaart.org Mon Jun 19 07:35:03 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 19 Jun 2006 09:35:03 +0200 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1149915924.12112.107.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <1149915924.12112.107.camel@mccallum.corsepiu.local> Message-ID: <1150702503.2597.201.camel@otto.amantes> Hi, > > > Why the %makeinstall? makeinstall is an anachronism and should only be > > > used if make DESTDIR=... install is nonfunctional. I was asked to drop this as well from a .spec and just like Christopher I was unaware that %makeinstall was so strongly discouraged. The explanation in the Packaging Guidelines is, IMO, a little poor in providing any reasoning for this, and could be expanded. As it's explained right now it's not making the case it should be making. I'll detail below, since most of the text from the wiki seems to come from this mail. > > What's wrong with using it? > %makeinstall overrides a set of environment variables during > "make install". I.e. it performs > make prefix="..." includedir="..." ... They're make variables, not environment variables. While the difference is subtle, there is a difference. In any case, this is a statement of fact (albeit wrong), not a description of what is wrong with % makeinstall, afaict ? > It is error prone, This is too vague to mean anything. make DESTDIR=... install is also error-prone. > can have effects inside of (broken) Makefiles So can make DESTDIR=... install. Consider a Makefile that *does not have* DESTDIR :) > and can > trigger rebuilds when executing "make install". This could be true; in all these years, I've never noticed it happening though that I can remember, so it must be that the 5 seconds of additional install time did not really worry me on 5 minute package builds. > If a package contains > libtool archives, it will cause broken *.la's being installed. We don't install .la files anyway, so this is a red herring. > "make DESTDIR=... install" overrides a single environment variable If "single" vs. "many" is the reason, then this is just as much an "aesthetic" reason, and I prefer Christopher's in that case. > and > is supposed to be specially designed for re-rooting installs to a > different installation root ($RPM_BUILD_ROOT) than the package has been > configured for ("/"). True, and I like DESTDIR as well when I need it. This seems to me the only really valid reason to discourage %makeinstall, but as such it seems better to me to remove the "fake reasons" from above, and just explain this one better, with an example or something. As it stands, the packaging guidelines on this topic sound more like unfounded dogma and thus are not very believable. Thanks Thomas From paul at city-fan.org Mon Jun 19 07:35:33 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Jun 2006 08:35:33 +0100 Subject: locales In-Reply-To: <4495D875.1020802@kobold.org> References: <4495D1CA.2080600@kobold.org> <1150669424.29435.86.camel@T7.Linux> <4495D875.1020802@kobold.org> Message-ID: <1150702534.13102.36.camel@laurel.intra.city-fan.org> On Sun, 2006-06-18 at 15:49 -0700, Wart wrote: > Paul wrote: > > Hi, > > > > > >>A package that I'm reviewing[1] keeps its language translation files in > >>%{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules > >>about using %find_lang when an application doesn't use > >>%{_datadir}/locale for the translation files? > > > > > > I thought languages had to be in the locale directory for them to be > > picked up automatically. > > I interpret this to mean that an application is free to store language > translation files in its own data directory, and in such a case the spec > file must include the language files in %files, and use of %find_lang is > not needed. If the language files are listed in %files, be sure to use the %lang tag to identify the language of each file; this would happen automatically with %find_lang. Paul. From paul at city-fan.org Mon Jun 19 07:59:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Jun 2006 08:59:27 +0100 Subject: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9 In-Reply-To: <1150702503.2597.201.camel@otto.amantes> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <1149915924.12112.107.camel@mccallum.corsepiu.local> <1150702503.2597.201.camel@otto.amantes> Message-ID: <1150703967.13102.46.camel@laurel.intra.city-fan.org> On Mon, 2006-06-19 at 09:35 +0200, Thomas Vander Stichele wrote: > Hi, > > > > > Why the %makeinstall? makeinstall is an anachronism and should only be > > > > used if make DESTDIR=... install is nonfunctional. > > I was asked to drop this as well from a .spec and just like Christopher > I was unaware that %makeinstall was so strongly discouraged. > > The explanation in the Packaging Guidelines is, IMO, a little poor in > providing any reasoning for this, and could be expanded. As it's > explained right now it's not making the case it should be making. I'll > detail below, since most of the text from the wiki seems to come from > this mail. > > > > What's wrong with using it? > > %makeinstall overrides a set of environment variables during > > "make install". I.e. it performs > > make prefix="..." includedir="..." ... > > They're make variables, not environment variables. While the difference > is subtle, there is a difference. In any case, this is a statement of > fact (albeit wrong), not a description of what is wrong with % > makeinstall, afaict ? > > > It is error prone, > > This is too vague to mean anything. make DESTDIR=... install is also > error-prone. > > > can have effects inside of (broken) Makefiles > > So can make DESTDIR=... install. Consider a Makefile that *does not > have* DESTDIR :) > > > and can > > trigger rebuilds when executing "make install". > > This could be true; in all these years, I've never noticed it happening > though that I can remember, so it must be that the 5 seconds of > additional install time did not really worry me on 5 minute package > builds. > > > If a package contains > > libtool archives, it will cause broken *.la's being installed. > > We don't install .la files anyway, so this is a red herring. > > > "make DESTDIR=... install" overrides a single environment variable > > If "single" vs. "many" is the reason, then this is just as much an > "aesthetic" reason, and I prefer Christopher's in that case. > > > and > > is supposed to be specially designed for re-rooting installs to a > > different installation root ($RPM_BUILD_ROOT) than the package has been > > configured for ("/"). > > True, and I like DESTDIR as well when I need it. This seems to me the > only really valid reason to discourage %makeinstall, but as such it > seems better to me to remove the "fake reasons" from above, and just > explain this one better, with an example or something. Actually the single best reason hasn't been included here. The variables overridden by %makeinstall are sometimes used for things other than locations to install files to. For instance, some libraries might use a construct like: echo $(libdir)/libraryname > $(DESTDIR)$(sysconfdir)/ld.so.conf.d/libraryname.conf to add their own library directory to the linker's search path. Using % makeinstall in this case would result in the buildroot directory being prepended to the directory name in libraryname.conf. This is actually the same issue as for libtool, but libtool breakage is only one of the possible problems. > As it stands, the packaging guidelines on this topic sound more like > unfounded dogma and thus are not very believable. And they also should not say "MUST NOT" use %makeinstall; some Makefiles don't support DESTDIR, and %makeinstall is indeed the right approach to use for those packages (subject to them not breaking as described above). Paul. From bugs.michael at gmx.net Mon Jun 19 09:15:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 19 Jun 2006 11:15:22 +0200 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-18 In-Reply-To: <1150700364.31371.3.camel@rousalka.dyndns.org> References: <20060619000125.23802.76344@extras64.linux.duke.edu> <1150700364.31371.3.camel@rousalka.dyndns.org> Message-ID: <20060619111522.60c3dec4.bugs.michael@gmx.net> On Mon, 19 Jun 2006 08:59:24 +0200, Nicolas Mailhot wrote: > Le lundi 19 juin 2006 ? 00:01 +0000, Fedora Extras repoclosure a ?crit : > > Summary of broken packages (by owner): > > > nicolas.mailhot AT laposte.net > > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch > > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch > > dejavu-fonts-fontconfig - 2.6.0-1.fc5.noarch > > This is a bug in the buildsys - it does not removes subpackages > obsoleted by another subpackage > > (in this particular case dejavu-fonts-fontconfig was renamed in > dejavu-fonts-makedefault) It is a bug in Yum (and equally in repoclosure): http://bugzilla.redhat.com/190116 Until that will be fixed, old subpackages are available to "yum install" and break. You need to request removal of such packages via the Wiki, especially if only you, the packager, know what should be removed. From sankarshan.mukhopadhyay at gmail.com Mon Jun 19 09:25:26 2006 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 19 Jun 2006 14:55:26 +0530 Subject: [Fedora-livecd-list] Re: FE Package Status of Jun 18, 2006 In-Reply-To: <13dbfe4f0606180220g5653c327qde981f1d0b7a879@mail.gmail.com> References: <4494AC7B.2090202@knox.net.nz> <13dbfe4f0606180220g5653c327qde981f1d0b7a879@mail.gmail.com> Message-ID: <44966D86.9070902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chitlesh GOORAH wrote: > I was thinking why not make it available on extras-development. > Perhaps that could bring more testers (since we need testers who have > 64 bit machines) and more contributors to push things forward quickly. Yup. would be a good way to go. Currently it borks sometimes on EM64Ts :SM - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFElm2GXQZpNTcrCzMRAmdWAJ9XcqNrWOur/d3X0J6Bwo1w0GABYgCfRps5 mREm2Nx+11TNXz4ZS4bIt5k= =ymLx -----END PGP SIGNATURE----- From chitlesh at fedoraproject.org Mon Jun 19 09:39:15 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 19 Jun 2006 11:39:15 +0200 Subject: [Fedora-livecd-list] Re: FE Package Status of Jun 18, 2006 In-Reply-To: <44966D86.9070902@gmail.com> References: <4494AC7B.2090202@knox.net.nz> <13dbfe4f0606180220g5653c327qde981f1d0b7a879@mail.gmail.com> <44966D86.9070902@gmail.com> Message-ID: <13dbfe4f0606190239l54a3dff3o818e246b46256b61@mail.gmail.com> On 6/19/06, Sankarshan Mukhopadhyay wrote: > Yup. would be a good way to go. Currently it borks sometimes on EM64Ts Do post your difficulties and more precision about it either in the list or on bugzilla so that we can work on them :p -- http://clunixchit.blogspot.com From fedora at camperquake.de Mon Jun 19 10:10:03 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Jun 2006 12:10:03 +0200 Subject: why do we still ship (gtk1) xmms, when we have bmp In-Reply-To: <4495B081.5000000@hhs.nl> References: <44947835.1020504@hhs.nl> <1150613506.2757.18.camel@localhost.localdomain> <44950332.5020401@hhs.nl> <1150619668.2757.45.camel@localhost.localdomain> <4495B081.5000000@hhs.nl> Message-ID: <20060619121003.5117e3e2@voip.int.addix.net> Hi. On Sun, 18 Jun 2006 21:58:57 +0200, Hans de Goede wrote: > True, I forgot about that, but AFAIK (from reading docs only) GUI-less > plugings will work almost out of the box, and the others "only" need a > gtk1->2 port. Unfortunately they won't, if bmp is built with gnome-vfs support, which the FE version is. The BMP plugin interface is similar to xmms but different enough to spoil a simple recompile of xmms plugins. From kaboom at oobleck.net Mon Jun 19 13:50:33 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 19 Jun 2006 09:50:33 -0400 (EDT) Subject: permissions on gdm session files Message-ID: Something that came up while reviewing openbox for extras: What are the correct permissions for gdm session files (/usr/share/xsession/*.desktop)? Most of the existing packages which create them (fluxbox in extras, kdebase in core for two examples) make them 755 There doesn't seem to be any functional need for them to be executable, however, that I've found in limited testing and doing so causes rpmlint to parse them as shell scripts with resulting errors (since their syntax isn't shell) Anyone know of a need for them to be set executable, or should they always be 644? later, chris From wart at kobold.org Mon Jun 19 15:07:52 2006 From: wart at kobold.org (Wart) Date: Mon, 19 Jun 2006 08:07:52 -0700 Subject: locales In-Reply-To: <1150702534.13102.36.camel@laurel.intra.city-fan.org> References: <4495D1CA.2080600@kobold.org> <1150669424.29435.86.camel@T7.Linux> <4495D875.1020802@kobold.org> <1150702534.13102.36.camel@laurel.intra.city-fan.org> Message-ID: <4496BDC8.8060701@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > On Sun, 2006-06-18 at 15:49 -0700, Wart wrote: > >>Paul wrote: >> >>>Hi, >>> >>> >>> >>>>A package that I'm reviewing[1] keeps its language translation files in >>>>%{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules >>>>about using %find_lang when an application doesn't use >>>>%{_datadir}/locale for the translation files? >>> >>> >>>I thought languages had to be in the locale directory for them to be >>>picked up automatically. >> >>I interpret this to mean that an application is free to store language >>translation files in its own data directory, and in such a case the spec >>file must include the language files in %files, and use of %find_lang is >>not needed. > > > If the language files are listed in %files, be sure to use the %lang tag > to identify the language of each file; this would happen automatically > with %find_lang. I've never seen %lang() used before. I assume that this lets users select which language files they want installed for the application, no? If so, how does %lang() interface with the rpm command line? - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFElr3GDeYlPfs40g8RAlxuAJ9r5CDqWpGk3O/heVYMHlCGt3r0cwCcCOdd qeKU3nOkA9D6ZGsp5RLQlVU= =jMyr -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jun 19 15:43:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Jun 2006 16:43:48 +0100 Subject: locales In-Reply-To: <4496BDC8.8060701@kobold.org> References: <4495D1CA.2080600@kobold.org> <1150669424.29435.86.camel@T7.Linux> <4495D875.1020802@kobold.org> <1150702534.13102.36.camel@laurel.intra.city-fan.org> <4496BDC8.8060701@kobold.org> Message-ID: <1150731829.23418.16.camel@laurel.intra.city-fan.org> On Mon, 2006-06-19 at 08:07 -0700, Wart wrote: > Paul Howarth wrote: > > On Sun, 2006-06-18 at 15:49 -0700, Wart wrote: > > > >>Paul wrote: > >> > >>>>A package that I'm reviewing[1] keeps its language translation files in > >>>>%{_datadir}/%{name} instead of %{_datadir}/locale. Are there any rules > >>>>about using %find_lang when an application doesn't use > >>>>%{_datadir}/locale for the translation files? > >>> > >>> > >>>I thought languages had to be in the locale directory for them to be > >>>picked up automatically. > >> > >>I interpret this to mean that an application is free to store language > >>translation files in its own data directory, and in such a case the spec > >>file must include the language files in %files, and use of %find_lang is > >>not needed. > > > > > > If the language files are listed in %files, be sure to use the %lang tag > > to identify the language of each file; this would happen automatically > > with %find_lang. > > I've never seen %lang() used before. I assume that this lets users > select which language files they want installed for the application, no? > If so, how does %lang() interface with the rpm command line? I don't think there is a command-line interface, but rpm can be configured (don't know how offhand) to have a list of languages you want, and then not install files for other languages, which can save a lot of disk space. Paul. From toshio at tiki-lounge.com Mon Jun 19 15:45:41 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Jun 2006 08:45:41 -0700 Subject: locales In-Reply-To: <4496BDC8.8060701@kobold.org> References: <4495D1CA.2080600@kobold.org> <1150669424.29435.86.camel@T7.Linux> <4495D875.1020802@kobold.org> <1150702534.13102.36.camel@laurel.intra.city-fan.org> <4496BDC8.8060701@kobold.org> Message-ID: <1150731941.10353.19.camel@localhost> On Mon, 2006-06-19 at 08:07 -0700, Wart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: > > > > If the language files are listed in %files, be sure to use the %lang tag > > to identify the language of each file; this would happen automatically > > with %find_lang. > > I've never seen %lang() used before. I assume that this lets users > select which language files they want installed for the application, no? > If so, how does %lang() interface with the rpm command line? > I don't know if it is accessible via the command line. You can set the macro %_install_langs to the languages you want to install: %_install_langs C:en_US -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Jun 19 16:26:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 19 Jun 2006 19:26:50 +0300 Subject: %makeinstall vs DESTDIR (was: Re: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9) In-Reply-To: <1150703967.13102.46.camel@laurel.intra.city-fan.org> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <1149915924.12112.107.camel@mccallum.corsepiu.local> <1150702503.2597.201.camel@otto.amantes> <1150703967.13102.46.camel@laurel.intra.city-fan.org> Message-ID: <1150734410.17415.17.camel@localhost.localdomain> On Mon, 2006-06-19 at 08:59 +0100, Paul Howarth wrote: > Actually the single best reason hasn't been included here. [...] Additionally, note that the DESTDIR approach is the documented way of doing staged installs with automake and the Makefile Conventions section of the GNU Coding Standards. That in addition to personal experience makes me think many upstreams are much more likely to pay attention to having a working DESTDIR setup compared to the one %makeinstall currently expands to, and will graciously accept patches to fix the former in cases it doesn't work. These docs are of course non-binding per se wrt. the Fedora packaging guidelines, but good to know anyhow. http://www.gnu.org/software/automake/manual/html_node/Install.html#Install http://www.gnu.org/prep/standards/html_node/DESTDIR.html#DESTDIR Buildroot remainders may enter installed files in both approaches, but is significantly more often encountered with %makeinstall in my experience. When properly installed, check-buildroot from fedora-rpmdevtools catches those pretty well with practically no false positives. Hopefully we can get that (and check-rpaths) into the production buildsys soon. From mmcgrath at fedoraproject.org Mon Jun 19 16:50:58 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 19 Jun 2006 11:50:58 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657968.2210.36.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> Message-ID: <4496D5F2.4020202@fedoraproject.org> Thorsten Leemhuis wrote: > > I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this mail) > for that job -- he was in the old FESCo, is not nominated for the new > one, is admin of the accounts system and seems to be the right one for > the job. > > That okay for everybody? > > Sopwith, can you do that? > > CU > thl > Sounds good to me, if he can't or isn't available I'll volunteer. -Mike From ville.skytta at iki.fi Mon Jun 19 16:53:14 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 19 Jun 2006 19:53:14 +0300 Subject: permissions on gdm session files In-Reply-To: References: Message-ID: <1150735994.17415.24.camel@localhost.localdomain> On Mon, 2006-06-19 at 09:50 -0400, Chris Ricker wrote: > Something that came up while reviewing openbox for extras: > > What are the correct permissions for gdm session files > (/usr/share/xsession/*.desktop)? > > Most of the existing packages which create them (fluxbox in extras, > kdebase in core for two examples) make them 755 I'm pretty sure those are plain packaging bugs. > There doesn't seem to be any functional need for them to be executable, Based on a quick look into gdm sources, as expected, it doesn't care about the x bits but will just try to open those files for reading. > however, that I've found in limited testing and doing so causes rpmlint to > parse them as shell scripts No it doesn't, the message id is just a bit misleading. Use the -i or -I switches to rpmlint (see the man page) to get the explanation what it really thinks. From paul at city-fan.org Mon Jun 19 17:05:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Jun 2006 18:05:07 +0100 Subject: owners owners.list,1.1146,1.1147 In-Reply-To: <200606191647.k5JGlwbk014362@cvs-int.fedora.redhat.com> References: <200606191647.k5JGlwbk014362@cvs-int.fedora.redhat.com> Message-ID: <1150736708.23418.24.camel@laurel.intra.city-fan.org> On Mon, 2006-06-19 at 09:47 -0700, Chris Chabot wrote: > Author: chabotc > > Update of /cvs/extras/owners > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14345 > > Modified Files: > owners.list > Log Message: > Renaming php-apc to php-pecl-apc > > > Index: owners.list > =================================================================== > RCS file: /cvs/extras/owners/owners.list,v > retrieving revision 1.1146 > retrieving revision 1.1147 > diff -u -r1.1146 -r1.1147 > --- owners.list 19 Jun 2006 15:32:20 -0000 1.1146 > +++ owners.list 19 Jun 2006 16:47:56 -0000 1.1147 > @@ -1339,7 +1339,7 @@ > Fedora Extras|pgadmin3|Graphical client for PostgreSQL|ghenry at suretecsystems.com|extras-qa at fedoraproject.org| > Fedora Extras|pgp-tools|Collection of several utilities related to OpenPGP|Matt_Domsch at dell.com|extras-qa at fedoraproject.org| > Fedora Extras|php-adodb|Active Data Objects Data Base|gauret at free.fr|extras-qa at fedoraproject.org| > -Fedora Extras|php-apc|APC caches and optimizes PHP intermediate code|chabotc at xs4all.nl|extras-qa at fedoraproject.org| > +Fedora Extras|php-pecl-apc|APC caches and optimizes PHP intermediate code|chabotc at xs4all.nl|extras-qa at fedoraproject.org| > Fedora Extras|php-eaccelerator|PHP accelerator, optimizer, encoder and dynamic content cacher|matthias at rpmforge.net|extras-qa at fedoraproject.org| > Fedora Extras|php-extras|Additional PHP modules from the standard PHP distribution|dmitry at butskoy.name|extras-qa at fedoraproject.org| > Fedora Extras|php-idn|PHP API for GNU LibIDN|redhat-bugzilla at linuxnetz.de|extras-qa at fedoraproject.org| The php-pecl-apc line needs to move down the file now to maintain sort order. Paul. From chabotc at xs4all.nl Mon Jun 19 17:29:06 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Mon, 19 Jun 2006 19:29:06 +0200 Subject: owners owners.list,1.1146,1.1147 In-Reply-To: <1150736708.23418.24.camel@laurel.intra.city-fan.org> References: <200606191647.k5JGlwbk014362@cvs-int.fedora.redhat.com> <1150736708.23418.24.camel@laurel.intra.city-fan.org> Message-ID: <1150738146.2609.0.camel@chris.lan> Corrected, sorry about that, guess i know php better then abc :-) On Mon, 2006-06-19 at 18:05 +0100, Paul Howarth wrote: > On Mon, 2006-06-19 at 09:47 -0700, Chris Chabot wrote: > > Author: chabotc > > > > Update of /cvs/extras/owners > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14345 > > > > Modified Files: > > owners.list > > Log Message: > > Renaming php-apc to php-pecl-apc > > > > > > Index: owners.list > > =================================================================== > > RCS file: /cvs/extras/owners/owners.list,v > > retrieving revision 1.1146 > > retrieving revision 1.1147 > > diff -u -r1.1146 -r1.1147 > > --- owners.list 19 Jun 2006 15:32:20 -0000 1.1146 > > +++ owners.list 19 Jun 2006 16:47:56 -0000 1.1147 > > @@ -1339,7 +1339,7 @@ > > Fedora Extras|pgadmin3|Graphical client for PostgreSQL|ghenry at suretecsystems.com|extras-qa at fedoraproject.org| > > Fedora Extras|pgp-tools|Collection of several utilities related to OpenPGP|Matt_Domsch at dell.com|extras-qa at fedoraproject.org| > > Fedora Extras|php-adodb|Active Data Objects Data Base|gauret at free.fr|extras-qa at fedoraproject.org| > > -Fedora Extras|php-apc|APC caches and optimizes PHP intermediate code|chabotc at xs4all.nl|extras-qa at fedoraproject.org| > > +Fedora Extras|php-pecl-apc|APC caches and optimizes PHP intermediate code|chabotc at xs4all.nl|extras-qa at fedoraproject.org| > > Fedora Extras|php-eaccelerator|PHP accelerator, optimizer, encoder and dynamic content cacher|matthias at rpmforge.net|extras-qa at fedoraproject.org| > > Fedora Extras|php-extras|Additional PHP modules from the standard PHP distribution|dmitry at butskoy.name|extras-qa at fedoraproject.org| > > Fedora Extras|php-idn|PHP API for GNU LibIDN|redhat-bugzilla at linuxnetz.de|extras-qa at fedoraproject.org| > > The php-pecl-apc line needs to move down the file now to maintain sort > order. > > Paul. > From fedora at camperquake.de Mon Jun 19 18:14:49 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Jun 2006 20:14:49 +0200 Subject: Packing audacious - Funny plugins Message-ID: <20060619201449.76afb9a3@nausicaa.camperquake.de> Hi. I am currently looking into packing audacious, the followup project to bmp, which is (was) a GTK2 port of xmms. Now audacious has a slew of input plugins, some of which I am not sure about regarding their legal status. Here goes. mp3 (Nope) aac (Nope) wma (Nope) musepack (Unsure) modplug (Yes) timidity (Yes) wav (Yes) vorbis (Yes) flac (Yes, although the code is... strange) sid [C64 sound files] (Unsure) spc, ndf, gbs [Console sound files] (Unsure) psf [PSX sound files] (Unsure) adlib (Unsure) Any help on the missing items? -- Mary had a little lamb, Its fleece was brown as mud. And every time the axe did strike, It splattered her with blood. From ville.skytta at iki.fi Mon Jun 19 18:26:44 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 19 Jun 2006 21:26:44 +0300 Subject: Packing audacious - Funny plugins In-Reply-To: <20060619201449.76afb9a3@nausicaa.camperquake.de> References: <20060619201449.76afb9a3@nausicaa.camperquake.de> Message-ID: <1150741604.17415.29.camel@localhost.localdomain> On Mon, 2006-06-19 at 20:14 +0200, Ralf Ertzinger wrote: > musepack (Unsure) libmpcdec is in Extras, so I guess there are no fundamental blockers. > sid [C64 sound files] (Unsure) libsidplay, ditto. From toshio at tiki-lounge.com Mon Jun 19 18:40:48 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Jun 2006 11:40:48 -0700 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <4496D5F2.4020202@fedoraproject.org> References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> <4496D5F2.4020202@fedoraproject.org> Message-ID: <1150742448.3115.8.camel@localhost> On Mon, 2006-06-19 at 11:50 -0500, Mike McGrath wrote: > Thorsten Leemhuis wrote: > > > > I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this mail) > > for that job -- he was in the old FESCo, is not nominated for the new > > one, is admin of the accounts system and seems to be the right one for > > the job. > > > > That okay for everybody? > > > > Sopwith, can you do that? > > > > CU > > thl > > > Sounds good to me, if he can't or isn't available I'll volunteer. +1 for either sopwith or mmcgrath. Let me know if you need any help on the database structure. You should be able to just query the tallysheet view in order to get the election results. To do an audit you'll need to dive into the ballots and votes tables to confirm one user <= 13 votes and do some comparisons between the voter id's in the ballot table against their records in the accounts database. -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 jeremy at jeremysanders.net Mon Jun 19 18:46:54 2006 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Mon, 19 Jun 2006 19:46:54 +0100 (BST) Subject: A python GUI program - naming Message-ID: Hi - I've got a scientific plotting application called Veusz which I'd like to contribute to extras. It is written in Python using PyQt. The application is primarily a GUI, but functionality is also exposed for other programs via a python module, veusz. This allows it to be embedded in other programs. Should I name the package python-veusz or veusz? It doesn't make any sense to split the functionality up into two, as the code is interdependent. Thanks Jeremy -- Jeremy Sanders http://www.jeremysanders.net/ Cambridge, UK Public Key Server PGP Key ID: E1AAE053 From rdieter at math.unl.edu Mon Jun 19 19:04:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Jun 2006 14:04:36 -0500 Subject: A python GUI program - naming References: Message-ID: Jeremy Sanders wrote: > Hi - > > I've got a scientific plotting application called Veusz which I'd like to > contribute to extras. It is written in Python using PyQt. > > The application is primarily a GUI, but functionality is also exposed for > other programs via a python module, veusz. This allows it to be embedded > in other programs. > > Should I name the package python-veusz or veusz? It doesn't make any sense > to split the functionality up into two, as the code is interdependent. It *would* make sese to split so that apps using the exposed functionality wouldn't necessarily have to pull in the GUI bit(s). If that's not practicle, I'd say lean toward simply packaging it as veusz, and have include something like: Provides: python-veusz -- Rex From jeremy at jeremysanders.net Mon Jun 19 19:17:08 2006 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Mon, 19 Jun 2006 20:17:08 +0100 (BST) Subject: A python GUI program - naming In-Reply-To: References: Message-ID: On Mon, 19 Jun 2006, Rex Dieter wrote: > It *would* make sese to split so that apps using the exposed > functionality wouldn't necessarily have to pull in the GUI bit(s). Yes, but in this case the exposed functionality is also the GUI, in the form of a plotting window. There is very little code that isn't shared. > If that's not practicle, I'd say lean toward simply packaging it as veusz, > and have include something like: > Provides: python-veusz That makes sense. Thanks Jeremy -- Jeremy Sanders http://www.jeremysanders.net/ Cambridge, UK Public Key Server PGP Key ID: E1AAE053 From wart at kobold.org Mon Jun 19 19:22:43 2006 From: wart at kobold.org (Wart) Date: Mon, 19 Jun 2006 12:22:43 -0700 Subject: FC4 minimal build root Message-ID: <4496F983.9000907@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been testing out FC4 builds with the minimal build root, and came across one problem: binaries aren't stripped because /usr/bin/eu-strip is missing. It seems that rpm-build in FC5/rawhide both "Requires: elfutils", but rpm-build on FC4 does not. I spotted a couple of bugzilla reports[1] on this issue, but there doesn't seem to be an agreement on what, if anything, should pull in the elfutils requirement. Apparently somebody eventually decided to add "Requires: elfutls" to rpm-build for FC5 and devel. It seems to me that we need to either backport "Requires: elfutils" to FC4, or add elfutils to the minimal build root, at least for FC4. - --Mike [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132633 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111363 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFElvmCDeYlPfs40g8RAvYjAJ9uHWULBcWiaV7U1Z0fhu1C9W2Q0wCfV7OW v45L3dts8MruUbHqobrrx80= =G8Po -----END PGP SIGNATURE----- From sopwith at redhat.com Mon Jun 19 19:53:46 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 19 Jun 2006 15:53:46 -0400 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657968.2210.36.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> Message-ID: I and the rest of the sysadmins will defend against attacks by marauding aliens... I don't think there is a lot we can do to verify 100% that the results weren't faked (that is up to Toshio's good coding skills). I'm more than happy to certify a preliminary report of the results so you can put it up for comment. And Toshio, let me know when to revoke your login access before the election begins. :) Best, -- Elliot On Jun 18, 2006, at 15:12, Thorsten Leemhuis wrote: > I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this > mail) > for that job -- he was in the old FESCo, is not nominated for the new > one, is admin of the accounts system and seems to be the right one for > the job. From paul at all-the-johnsons.co.uk Mon Jun 19 20:00:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 19 Jun 2006 21:00:23 +0100 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-18 In-Reply-To: <20060619000125.23805.60224@extras64.linux.duke.edu> References: <20060619000125.23805.60224@extras64.linux.duke.edu> Message-ID: <1150747223.20915.2.camel@T7.Linux> On Mon, 2006-06-19 at 00:01 +0000, Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > paul AT all-the-johnsons.co.uk > amaya - 8.5-2.x86_64 > amaya - 9.5-1.fc6.i386 > amaya - 9.5-1.fc6.ppc amaya has a BZ filed against both it and libpng. I can only see 9.5-1.src.rpm in the devel branch of the fedora FTP site. I think it's safe to drop 8.5-2 anyway. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Mon Jun 19 21:32:29 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 19 Jun 2006 16:32:29 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-19 Message-ID: <20060619213229.GA2525@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Mon Jun 19 12:13:36 CDT 2006 Number failed to build: 164 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 153 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 149 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dejavu-fonts nicolas.mailhot at laposte.net dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk+ rdieter at math.unl.edu gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 CLOSED'] tla at rasmil.dk 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 Mon Jun 19 21:32:58 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 19 Jun 2006 16:32:58 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-19 Message-ID: <20060619213258.GB2525@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnupg2 194079 NEW gtkhtml36 193476 ASSIGNED libgpg-error 193550 NEW xffm 194145 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Mon Jun 19 12:15:11 CDT 2006 Number failed to build: 143 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 142 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 138 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Hermes thomas at apestaart.org MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mfstools tcallawa at redhat.com multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 CLOSED'] tla at rasmil.dk 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 peter at thecodergeek.com Tue Jun 20 00:59:13 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 19 Jun 2006 17:59:13 -0700 Subject: permissions on gdm session files In-Reply-To: <1150735994.17415.24.camel@localhost.localdomain> References: <1150735994.17415.24.camel@localhost.localdomain> Message-ID: <44974861.7040602@thecodergeek.com> Ville Skytt wrote: > I'm pretty sure those are plain packaging bugs. So we should report these as they are found to Bugzilla then? > Based on a quick look into gdm sources, as expected, it doesn't care > about the x bits but will just try to open those files for reading. Excellent. I'll keep Openbox's without the x bit set. > No it doesn't, the message id is just a bit misleading. Use the -i or > -I switches to rpmlint (see the man page) to get the explanation what it > really thinks. I've grown quite fond of rpmlint -i` while testing my built binary/source RPMs. ;) Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From hugo at devin.com.br Tue Jun 20 02:27:34 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Mon, 19 Jun 2006 23:27:34 -0300 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606171820.44076.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> Message-ID: <200606192327.35389.hugo@devin.com.br> A good discussion on this topic is going on in the kdegames' review request on bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194374 If anyone have interest at it, please discuss :) -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From rc040203 at freenet.de Tue Jun 20 03:11:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 05:11:48 +0200 Subject: %makeinstall vs DESTDIR (was: Re: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9) In-Reply-To: <1150734410.17415.17.camel@localhost.localdomain> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <1149915924.12112.107.camel@mccallum.corsepiu.local> <1150702503.2597.201.camel@otto.amantes> <1150703967.13102.46.camel@laurel.intra.city-fan.org> <1150734410.17415.17.camel@localhost.localdomain> Message-ID: <1150773108.19696.5.camel@mccallum.corsepiu.local> On Mon, 2006-06-19 at 19:26 +0300, Ville Skytt? wrote: > On Mon, 2006-06-19 at 08:59 +0100, Paul Howarth wrote: > > > Actually the single best reason hasn't been included here. > [...] > > Additionally, note that the DESTDIR approach is the documented way of > doing staged installs with automake and the Makefile Conventions section > of the GNU Coding Standards. That in addition to personal experience > makes me think many upstreams are much more likely to pay attention to > having a working DESTDIR setup compared to the one %makeinstall > currently expands to, Well, all properly packaged automake-based projects support both styles, equally. "make distcheck" tests for both styles :) Ralf From jdennis at redhat.com Tue Jun 20 03:43:23 2006 From: jdennis at redhat.com (John Dennis) Date: Mon, 19 Jun 2006 23:43:23 -0400 Subject: %makeinstall vs DESTDIR (was: Re: rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9) In-Reply-To: <1150773108.19696.5.camel@mccallum.corsepiu.local> References: <200606100429.k5A4TLSV030019@cvs-int.fedora.redhat.com> <1149914075.12112.89.camel@mccallum.corsepiu.local> <1149915924.12112.107.camel@mccallum.corsepiu.local> <1150702503.2597.201.camel@otto.amantes> <1150703967.13102.46.camel@laurel.intra.city-fan.org> <1150734410.17415.17.camel@localhost.localdomain> <1150773108.19696.5.camel@mccallum.corsepiu.local> Message-ID: <1150775004.5808.96.camel@localhost.localdomain> On Tue, 2006-06-20 at 05:11 +0200, Ralf Corsepius wrote: > On Mon, 2006-06-19 at 19:26 +0300, Ville Skytt? wrote: > > On Mon, 2006-06-19 at 08:59 +0100, Paul Howarth wrote: > > > > > Actually the single best reason hasn't been included here. > > [...] > > > > Additionally, note that the DESTDIR approach is the documented way of > > doing staged installs with automake and the Makefile Conventions section > > of the GNU Coding Standards. That in addition to personal experience > > makes me think many upstreams are much more likely to pay attention to > > having a working DESTDIR setup compared to the one %makeinstall > > currently expands to, > Well, all properly packaged automake-based projects support both styles, > equally. "make distcheck" tests for both styles :) Sorry, I missed the original thread, but I it is my belief %makeinstall is fundamentally broken because of hardcoded assumptions. %makeinstall is evil because it works under limited conditions which leads to the mistaken belief it is a robust and proven mechanism which it is not. "make install" with DESTDIR set to the buildroot is to the best of my knowledge the most correct and robust idiom for populating the buildroot for RPM's based on automake sources. I can't comment on "distcheck", but %makeinstall should be avoided in favor of DESTDIR installations IMHO. This is topical for me because I just helped someone debug a spec file which was using %makeinstall and was blowing up as it tried to install into the build machine's /usr during the %install phase. -- John Dennis From eric.tanguy at univ-nantes.fr Tue Jun 20 04:40:46 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Tue, 20 Jun 2006 06:40:46 +0200 Subject: docs packaging Message-ID: <1150778447.2565.9.camel@bureau.maison> Hi all, i'm trying to modify the libupnp spec file to include the programming doc i forgot at the beginning. My problem is where to put the doc and if i have to split it in the 2 packages (libupnp and libupnp-devel). In the doc build by the package i have LICENSE NEWS README THANKS TODO UPnP_Programming_Guide.pd and a directory examples/ Either i put all this stuff in usr/share/doc/libupnp-1.4.0-1/ in the devel package (which is the easier to do) or usr/share/doc/libupnp-1.4.0-1/ containing LICENSE NEWS README THANKS TODO in libupnp package and usr/share/doc/libupnp-devel-1.4.0-1/ containing UPnP_Programming_Guide.pdf and examples/ in devel package. But for the second solution (which seems the better solution to me) i have to create directory (RPM_BUILD_ROOT/usr/share/doc/libupnp-devel-1.4.0-1/) and mv UPnP_Programming_Guide.pdf and examples/ in it at the end of make install. It makes the spec file a bit ugly... What do you think of this ? Thanks Eric From garrick at usc.edu Tue Jun 20 04:58:56 2006 From: garrick at usc.edu (Garrick Staples) Date: Mon, 19 Jun 2006 21:58:56 -0700 Subject: docs packaging In-Reply-To: <1150778447.2565.9.camel@bureau.maison> References: <1150778447.2565.9.camel@bureau.maison> Message-ID: <20060620045856.GI4298@polop.usc.edu> On Tue, Jun 20, 2006 at 06:40:46AM +0200, Eric Tanguy alleged: > Hi all, i'm trying to modify the libupnp spec file to include the > programming doc i forgot at the beginning. > My problem is where to put the doc and if i have to split it in the 2 > packages (libupnp and libupnp-devel). > In the doc build by the package i have LICENSE NEWS README THANKS TODO > UPnP_Programming_Guide.pd and a directory examples/ > Either i put all this stuff in usr/share/doc/libupnp-1.4.0-1/ in the > devel package (which is the easier to do) or > usr/share/doc/libupnp-1.4.0-1/ containing LICENSE NEWS README THANKS > TODO in libupnp package and usr/share/doc/libupnp-devel-1.4.0-1/ > containing UPnP_Programming_Guide.pdf and examples/ in devel package. > But for the second solution (which seems the better solution to me) i > have to create directory > (RPM_BUILD_ROOT/usr/share/doc/libupnp-devel-1.4.0-1/) and mv > UPnP_Programming_Guide.pdf and examples/ in it at the end of make > install. It makes the spec file a bit ugly... > What do you think of this ? > Thanks > Eric What's the matter with 2 %doc macros? %files %doc LICENSE NEWS README THANKS TODO %files devel %doc UPnP_Programming_Guide.pdf examples Either way, "better solution" beats "pretty spec file" any day. -- 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 peter at thecodergeek.com Tue Jun 20 05:25:30 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 19 Jun 2006 22:25:30 -0700 Subject: docs packaging In-Reply-To: <1150778447.2565.9.camel@bureau.maison> References: <1150778447.2565.9.camel@bureau.maison> Message-ID: <449786CA.4080201@thecodergeek.com> Eric Tanguy wrote: > Hi all, i'm trying to modify the libupnp spec file to include the > programming doc i forgot at the beginning. > My problem is where to put the doc and if i have to split it in the 2 > packages (libupnp and libupnp-devel). > In the doc build by the package i have LICENSE NEWS README THANKS TODO > UPnP_Programming_Guide.pd and a directory examples/ > Either i put all this stuff in usr/share/doc/libupnp-1.4.0-1/ in the > devel package (which is the easier to do) or > usr/share/doc/libupnp-1.4.0-1/ containing LICENSE NEWS README THANKS > TODO in libupnp package and usr/share/doc/libupnp-devel-1.4.0-1/ > containing UPnP_Programming_Guide.pdf and examples/ in devel package. > But for the second solution (which seems the better solution to me) i > have to create directory > (RPM_BUILD_ROOT/usr/share/doc/libupnp-devel-1.4.0-1/) and mv > UPnP_Programming_Guide.pdf and examples/ in it at the end of make > install. It makes the spec file a bit ugly... > What do you think of this ? > Thanks > Eric Maybe you could create a -docs subpackage for just these? So its spec might contain something like the following components: %package docs Description: Programming documentation and examples for %{name} [...] %files docs %defattr(-,root,root-) %doc LICENSE README NEWS UPnP_Programming_Guide.pdf %doc examples/ -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From chris.stone at gmail.com Tue Jun 20 07:07:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Jun 2006 00:07:53 -0700 Subject: docs packaging In-Reply-To: <449786CA.4080201@thecodergeek.com> References: <1150778447.2565.9.camel@bureau.maison> <449786CA.4080201@thecodergeek.com> Message-ID: On 6/19/06, Peter Gordon wrote: > %package docs doc subpackages should be named -doc not -docs From paul at city-fan.org Tue Jun 20 08:02:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Jun 2006 09:02:50 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> Message-ID: <1150790571.23418.57.camel@laurel.intra.city-fan.org> On Mon, 2006-06-19 at 15:00 -0700, Paul F. Johnson wrote: > Author: pfj > > Update of /cvs/extras/rpms/monodoc/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30153/devel > > Modified Files: > monodoc.spec > Log Message: > auto-import monodoc-1.1.13-12 on branch devel from monodoc-1.1.13-12.src.rpm > > > Index: monodoc.spec > =================================================================== > RCS file: /cvs/extras/rpms/monodoc/devel/monodoc.spec,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- monodoc.spec 17 Jun 2006 22:05:03 -0000 1.3 > +++ monodoc.spec 19 Jun 2006 22:00:32 -0000 1.4 > @@ -1,16 +1,15 @@ > %define debug_package %{nil} The setting of %debug_package to %{nil} shouldn't be needed for a noarch package. > -%define libdir %{_exec_prefix}/lib > > Summary: The mono documentation system > Name: monodoc > Version: 1.1.13 > -Release: 11%{?dist} > +Release: 12%{?dist} > License: GPL > Group: Documentation > Source0: http://go-mono.com/sources/monodoc/monodoc-%{version}.tar.gz > URL: http://go-mono.com/sources/monodoc/ > Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > -BuildRequires: mono-data, mono-devel, gtk-sharp2, gtk-sharp2-gapi, pkgconfig > +BuildRequires: mono-data, mono-devel, gtk-sharp2, gtk-sharp2-gapi, pkgconfig, autoconf > Requires: mono-core > BuildArch: noarch > > @@ -28,8 +27,10 @@ > %prep > rm -rf %{_buildroot} > %setup -q > +sed -i 's/AC_CANONICAL_TARGET//' configure.in monodoc's configure.in has AC_CANONICAL_SYSTEM rather than AC_CANONICAL_TARGET > %build > +autoconf > %configure --target=sparc86x With AC_CANONICAL_SYSTEM removed from configure.in, the sparc86x hack *shouldn't* be needed either. Paul. From rc040203 at freenet.de Tue Jun 20 08:48:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 10:48:37 +0200 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150790571.23418.57.camel@laurel.intra.city-fan.org> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> Message-ID: <1150793317.29303.1.camel@mccallum.corsepiu.local> On Tue, 2006-06-20 at 09:02 +0100, Paul Howarth wrote: > On Mon, 2006-06-19 at 15:00 -0700, Paul F. Johnson wrote: > > %prep > > rm -rf %{_buildroot} > > %setup -q > > +sed -i 's/AC_CANONICAL_TARGET//' configure.in > > monodoc's configure.in has AC_CANONICAL_SYSTEM rather than > AC_CANONICAL_TARGET > > %build > > +autoconf > > %configure --target=sparc86x > > With AC_CANONICAL_SYSTEM removed from configure.in, the sparc86x hack > *shouldn't* be needed either. I would propose to push this package back to review. Adding --target=sparc86x is complete non-sense. Ralf From Eric.Tanguy at univ-nantes.fr Tue Jun 20 08:52:52 2006 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Tue, 20 Jun 2006 10:52:52 +0200 (CEST) Subject: docs packaging In-Reply-To: <20060620045856.GI4298@polop.usc.edu> References: <1150778447.2565.9.camel@bureau.maison> <20060620045856.GI4298@polop.usc.edu> Message-ID: <3968.172.22.95.30.1150793572.squirrel@webmail.univ-nantes.fr> > On Tue, Jun 20, 2006 at 06:40:46AM +0200, Eric Tanguy alleged: >> Hi all, i'm trying to modify the libupnp spec file to include the >> programming doc i forgot at the beginning. >> My problem is where to put the doc and if i have to split it in the 2 >> packages (libupnp and libupnp-devel). >> In the doc build by the package i have LICENSE NEWS README THANKS TODO >> UPnP_Programming_Guide.pd and a directory examples/ >> Either i put all this stuff in usr/share/doc/libupnp-1.4.0-1/ in the >> devel package (which is the easier to do) or >> usr/share/doc/libupnp-1.4.0-1/ containing LICENSE NEWS README THANKS >> TODO in libupnp package and usr/share/doc/libupnp-devel-1.4.0-1/ >> containing UPnP_Programming_Guide.pdf and examples/ in devel package. >> But for the second solution (which seems the better solution to me) i >> have to create directory >> (RPM_BUILD_ROOT/usr/share/doc/libupnp-devel-1.4.0-1/) and mv >> UPnP_Programming_Guide.pdf and examples/ in it at the end of make >> install. It makes the spec file a bit ugly... >> What do you think of this ? >> Thanks >> Eric > > What's the matter with 2 %doc macros? > %files > %doc LICENSE NEWS README THANKS TODO > > %files devel > %doc UPnP_Programming_Guide.pdf examples > > Yes but the problem is the package put all doc files in /usr/share/doc/libupnp-1.4.0-1/ and and %doc look for files in this directory for libupnp but for libupnp-devel %doc macro look for files in /usr/share/doc/libupnp-devel-1.4.0-1/ which does not exist unless i create it and put the devel doc files in it manually in the spec file. Eric From paul at all-the-johnsons.co.uk Tue Jun 20 08:55:05 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 20 Jun 2006 09:55:05 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150793317.29303.1.camel@mccallum.corsepiu.local> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> Message-ID: <1150793705.7019.1.camel@mrwibble.mrwobble> Hi, > I would propose to push this package back to review. > > Adding --target=sparc86x is complete non-sense. The target was recommended by spot to get things to compile using noarch. The AC_CANONICAL needs a small play with to get right. It's about 10 minutes work for when I get home tonight. Not sure if it's worth pushing back to review for that amount of work. However, if it is the feeling it should be, I'll stand by that and will go through the vetting procedure again. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rc040203 at freenet.de Tue Jun 20 09:28:16 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 11:28:16 +0200 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150793705.7019.1.camel@mrwibble.mrwobble> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> <1150793705.7019.1.camel@mrwibble.mrwobble> Message-ID: <1150795697.29303.13.camel@mccallum.corsepiu.local> On Tue, 2006-06-20 at 09:55 +0100, PFJ wrote: > Hi, > > > I would propose to push this package back to review. > > > > Adding --target=sparc86x is complete non-sense. > > The target was recommended by spot to get things to compile using > noarch. Bummer. > The AC_CANONICAL needs a small play with to get right. It's > about 10 minutes work for when I get home tonight. The AC_CANONICAL* stuff is the very core of triggering cross compilation in autoconf scripts. Using it affects everything inside of a autoconf generated configure script. > Not sure if it's worth pushing back to review for that amount of work. I don't know (You know I refuse to look into mono-packages). > However, if it is the feeling it should be, I'll stand by that and will > go through the vetting procedure again. All I can say is: --target=sparc86x doesn't make any sense. Autoconf scripts should bomb out on it. You trying to patch around AC_CANONICAL* inside of the configure script indicates the configure script to correctly refuses to support this crap. A correctly working configure scripts is supposed to handle --host, --build and --target as being setup by %configure correctly. If it doesn't, the work around would be not to pass them to configure, i.e. not to use %configure, but to explicitly set it up manually. Ralf From fedora at leemhuis.info Tue Jun 20 10:38:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Jun 2006 12:38:52 +0200 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> Message-ID: <4497D03C.8000703@leemhuis.info> Hi all! Elliot Lee schrieb: > I and the rest of the sysadmins will defend against attacks by marauding > aliens... thx > I don't think there is a lot we can do to verify 100% that the > results weren't faked 100% should not be needed -- but a check if the results look sane would be helpful. > (that is up to Toshio's good coding skills). Well, the code is up for review for a good reason ;-) > I'm > more than happy to certify a preliminary report of the results so you > can put it up for comment. That would be great. > And Toshio, let me know when to revoke your login access before the > election begins. :) :-) CU thl > On Jun 18, 2006, at 15:12, Thorsten Leemhuis wrote: > >> I'll hereby nominate Elliot Lee (aka "Sopwith", he's CCed to this mail) >> for that job -- he was in the old FESCo, is not nominated for the new >> one, is admin of the accounts system and seems to be the right one for >> the job. > > From jonathan.underwood at gmail.com Tue Jun 20 10:58:05 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 Jun 2006 11:58:05 +0100 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <4497D03C.8000703@leemhuis.info> References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> <4497D03C.8000703@leemhuis.info> Message-ID: <645d17210606200358k6ea291f3nd5c1770c156c15a0@mail.gmail.com> On 20/06/06, Thorsten Leemhuis wrote: > > I don't think there is a lot we can do to verify 100% that the > > results weren't faked > > 100% should not be needed -- but a check if the results look sane would > be helpful. > Perhaps we should ask all candidates to declare whether or not they have a brother who is governor of florida. Ahem, sorry. Jonathan. From rdieter at math.unl.edu Tue Jun 20 12:16:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 07:16:14 -0500 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606171820.44076.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> Message-ID: Hugo Cisneiros wrote: > I have just submitted a blog post on this: > http://www.devin.com.br/eitch/blog/2006/06/17/kde-sub-packaging-approach-on-fedora/ > > And I'm bringing this discussion into the list too. I'll paste the post here > too: > > KDE Sub-Packaging Approach on Fedora > ======= ... > The Current Approach > ======= > I talked with many people (20+) and all of them said the same thing: this is > really annoying. ?There?s got to be a way to install only kopete or kmail, > instead of the whole collection of programs?. > > The Solution: A Sub-Packaging Approach > ======= > This is already used in some distributions, and users appear to like it. ... > Downside: Maintainership > ======= > While having these advantages above, we gain a more complicated specfile, My personal take (following one of Fedora's core mantras)... upstream, upstream, upstream... how does upstream distribute/package things? IMO, packaging should generally follow suit, and if you don't like that, take your beef upstream(*). KDE sub-packaging is/will-be a lot more work, for what I consider to be little benefit: primarly less disk space used (and what's a few MB between friends these days?). OTOH, if package maintainers can handle the extra complexity and don't mind extra workload associated with supporting the sub-package approach, then I don't think anyone is going to tell you that you can't do it. -- Rex (*) Unfortunately, I've seen people take this particular beef upstream before, and kde dev's responses are generally disappointing: they (generally) claim this is the job of the distro packager(s). *sigh*. From rdieter at math.unl.edu Tue Jun 20 12:17:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 07:17:52 -0500 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606171820.44076.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> Message-ID: Hugo Cisneiros wrote: > Updates: > ======= > - Using -n in the subpackages %package could give us the "simple package name" > instead of using "Provides:". Is it better? It will not polute the specfile? > Opinion: Some think it's better. If it really is, task for Eitch: make > changes into the kdegames example. If you *are* to do this, I'd lean toward keeping the namespace clean an keep things like kdegames-foo1, kdegames-foo2 and then possibly use Provides: foo1 and Provides: foo2 > - Bring this into FESCo attention? IMO, no need for that (yet). -- Rex From jonathan.underwood at gmail.com Tue Jun 20 12:41:16 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 Jun 2006 13:41:16 +0100 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> Message-ID: <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> Hi, One part of the proposal that I think should be considered more carefully is the strategy of having the main package Require all of the subpackages. At first glance, this seems like a good idea, allowing the user to install eg. all of kdegames with a yum install kdegames, OR just installing game foo, with yum install kdegames-foo. BUT, if having dones a yum install kdegames, Joe decides he doesn't want foo, he does a yum remove kdegames-foo, and then yum of course decides that it's necessary to remove kdegames. That is, if I understand the proposal correctly (I may have misunderstood). In short, I think this points to a missuse of rpm Requires that shouldn't really be encouraged. It probably also points to the need for some mechanism in rpm to accomplish what is trying to be achieved here, perhaps an Includes: kdegames-foo directive, or somesuch. Or perhaps a more finely grained Group - i.e. kdegames as a subgroup. Jonathan. From paul at city-fan.org Tue Jun 20 12:54:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Jun 2006 13:54:12 +0100 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> Message-ID: <4497EFF4.5010802@city-fan.org> Jonathan Underwood wrote: > Hi, > > One part of the proposal that I think should be considered more > carefully is the strategy of having the main package Require all of > the subpackages. At first glance, this seems like a good idea, > allowing the user to install eg. all of kdegames with a yum install > kdegames, OR just installing game foo, with yum install kdegames-foo. > BUT, if having dones a yum install kdegames, Joe decides he doesn't > want foo, he does a yum remove kdegames-foo, and then yum of course > decides that it's necessary to remove kdegames. What's the problem with that? Removing the kdegames base package won't result in the removal of all of the other subpackages. So Joe's left with the subset of games that he wants. Paul. From hugo at devin.com.br Tue Jun 20 13:09:14 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 20 Jun 2006 10:09:14 -0300 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> Message-ID: <200606201009.14575.hugo@devin.com.br> On Tuesday 20 June 2006 09:41, Jonathan Underwood wrote: > Hi, Hau > One part of the proposal that I think should be considered more > carefully is the strategy of having the main package Require all of > the subpackages. At first glance, this seems like a good idea, > allowing the user to install eg. all of kdegames with a yum install > kdegames, OR just installing game foo, with yum install kdegames-foo. > BUT, if having dones a yum install kdegames, Joe decides he doesn't > want foo, he does a yum remove kdegames-foo, and then yum of course > decides that it's necessary to remove kdegames. That is, if I > understand the proposal correctly (I may have misunderstood). In > short, I think this points to a missuse of rpm Requires that shouldn't > really be encouraged. It probably also points to the need for some > mechanism in rpm to accomplish what is trying to be achieved here, > perhaps an Includes: kdegames-foo directive, or somesuch. Or perhaps a > more finely grained Group - i.e. kdegames as a subgroup. The kdegames package does require its sub-packages, but the sub-packages does *not* require the main package. This is called "meta-packaging". Take a look at the specfile and you will see. For example: if you install kdegames with yum, it adds all the sub-packages as dependencies. But if you later uninstall kdegames-foo, it wil only uninstall kdegames-foo and the kdegames meta-package. All other subpackages will remain untouched. The idea on creating yum groups would satisfy this "problem" and the issue in comment #10 at bugzilla. But IMO creating such groups in yum would pollute the yum's groups and it's not exactly what we want. > Jonathan. -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From jonathan.underwood at gmail.com Tue Jun 20 13:11:59 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 Jun 2006 14:11:59 +0100 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606201009.14575.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> <200606201009.14575.hugo@devin.com.br> Message-ID: <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> On 20/06/06, Hugo Cisneiros wrote: > For example: if you install kdegames with yum, it adds all the sub-packages as > dependencies. But if you later uninstall kdegames-foo, it wil only uninstall > kdegames-foo and the kdegames meta-package. All other subpackages will remain > untouched. OK - I'd missed that subtelty, sorry. I suppose that's the best (most consistent) situation that can be hoped for. From rc040203 at freenet.de Tue Jun 20 13:16:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 15:16:15 +0200 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150795697.29303.13.camel@mccallum.corsepiu.local> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> <1150793705.7019.1.camel@mrwibble.mrwobble> <1150795697.29303.13.camel@mccallum.corsepiu.local> Message-ID: <1150809375.29303.45.camel@mccallum.corsepiu.local> Paul, I had a look into monodoc's configuration ... .. You are facing several bugs interacting 1. %configure .. passes --target=noarch-redhat-linux This is an invalid canonicalization triple, causing AC_CANONICAL_SYSTEM (actually config.sub) to abort => bug in RPM. --target=sparc86x is a canonicalization triple which happens to let config.sub silently accept it by random accident, and therefore doesn't cause configure to abort, i.e. this is an ugly hack. A better ugly hack to achieve the same effect would be --target=none 2. This package's configure.in uses AC_CANONICAL_SYSTEM. AC_CANONICAL_SYSTEM adds --build, --host and --target to a configure script, were --target is the target a cross-tool running on $host being built on $build is supposed to generate code for. This normally is only useful for cross-compilers and their components, but isn't useful for normal applications. In this case it is not useful. The whole configuration only applies $host, i.e. the configure script wants AC_CANONICAL_HOST, not AC_CANONICAL_SYSTEM nor AC_CANONICAL_TARGET. I.e. the ultimate fix would be to let upstream replace this AC_CANONICAL_SYSTEM with AC_CANONICAL_HOST. Afterwards, the rpm bug should not have any effect, anymore. As a minimal invasive short-term work-around, without having to patch the packages and to run the autotools, two approaches are possible: a) Don't use %configure, instead explicitly invoke ./configure with appropriate options (and --target removed). AFAIS, the packages only uses --prefix and --bindir, so most of the other options %configure passes to ./configure are unused, anyway, so ./configure --prefix=%{_prefix} --bindir=%{_bindir} probably would be sufficient. b) Use this (and don't patch configure*): %configure --target=none For the moment, I'd recommend you to remove all traces of patching config-files and invoking the autotools and to use b). Ralf From hugo at devin.com.br Tue Jun 20 13:28:23 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 20 Jun 2006 10:28:23 -0300 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> Message-ID: <200606201028.23739.hugo@devin.com.br> On Tuesday 20 June 2006 09:16, Rex Dieter wrote: > Hugo Cisneiros wrote: > > I have just submitted a blog post on this: > > http://www.devin.com.br/eitch/blog/2006/06/17/kde-sub-packaging-approach- > >on-fedora/ > > > > And I'm bringing this discussion into the list too. I'll paste the post > > here too: > > > > KDE Sub-Packaging Approach on Fedora > > ======= > > ... > [...] > My personal take (following one of Fedora's core mantras)... upstream, > upstream, upstream... how does upstream distribute/package things? IMO, > packaging should generally follow suit, and if you don't like that, take > your beef upstream(*). I agree with working *always* with the upstream, but not exactly as the upstream. Sometimes we have to make adjustments tat fits our users needs and the distro layout. In our case here, we will not do something nasty and with incompatibilities... The package names (kdenetwork, kdeutils, kdegames) will remain the same (but now as meta-packages), the applications will be the same, the "official" packages will be the same. The only thing that we are changing is bringing one more option to users: further customization of KDE applications (customization is a Really Good Thing), menus (cleaning up things we don't use), and benefiting users (as it appears they like this approach). > (*) Unfortunately, I've seen people take this particular beef upstream > before, and kde dev's responses are generally disappointing: they > (generally) claim this is the job of the distro packager(s). *sigh*. I partially agree with them :) They package things in a really easy and straight-forward way. Much better than many applications out there. But they don't do final binary packages for distros, they do mostly source packages, and it's very different from binary distribution. This also gives us flexibility to do this meta-package approach. It will be much more difficult if each program from a kdebranch package is separated on the source. We were to create each spec, compile each package, create each dependency. It's the same work we are doing here (but we are doing in only one specfile, only one proccess and only one tarball). You know KDE rocks :) Sometimes we have to do some effort to grant users a better experience. I'm willing to do a little sacrifice myself, and trying to explain other why this is important ;) > KDE sub-packaging is/will-be a lot more work, for what I consider to be > little benefit: primarly less disk space used (and what's a few MB > between friends these days?). I agree that it's lot of more work, but I have to add that this should be difficult mostly on the beginning, changing specfiles, separating files, creating dependencies. After all that is done, they should easy to maintain (not as easy as the current one, but still easy). I understand that not everyone has time or is wanting to do this dirty work, and that's the reason I'm already doing it, then getting feedback, then fixing stuff and trying to do a really quality package. > OTOH, if package maintainers can handle the extra complexity and don't > mind extra workload associated with supporting the sub-package approach, > then I don't think anyone is going to tell you that you can't do it. That's why I'm trying to advocate this here and being a little annoying :) > -- Rex Thanks for your feedback! Cheers, -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From rdieter at math.unl.edu Tue Jun 20 13:33:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 08:33:12 -0500 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> <200606201009.14575.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > On 20/06/06, Hugo Cisneiros > wrote: > >> For example: if you install kdegames with yum, it adds all the >> sub-packages as >> dependencies. But if you later uninstall kdegames-foo, it wil only >> uninstall >> kdegames-foo and the kdegames meta-package. All other subpackages will >> remain >> untouched. > > > OK - I'd missed that subtelty, sorry. I suppose that's the best (most > consistent) situation that can be hoped for. Or, follow what koffice in Extras did, and use a meta-package named koffice-suite. A nice advantage of this approach is that since the old name is no longer being used, we have the opportunity to drop all those darn Epoch's from kde packaging. -- Rex From paul at all-the-johnsons.co.uk Tue Jun 20 13:43:58 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 20 Jun 2006 14:43:58 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150809375.29303.45.camel@mccallum.corsepiu.local> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> <1150793705.7019.1.camel@mrwibble.mrwobble> <1150795697.29303.13.camel@mccallum.corsepiu.local> <1150809375.29303.45.camel@mccallum.corsepiu.local> Message-ID: <1150811038.7019.44.camel@mrwibble.mrwobble> Hi, > 1. %configure .. passes --target=noarch-redhat-linux > This is an invalid canonicalization triple, causing AC_CANONICAL_SYSTEM > (actually config.sub) to abort => bug in RPM. I know. I've put this into BZ, but it's been marked as not a bug quite a few times. > --target=sparc86x is a canonicalization triple which happens to let > config.sub silently accept it by random accident, and therefore doesn't > cause configure to abort, i.e. this is an ugly hack. > > A better ugly hack to achieve the same effect would be --target=none Again, I'm just going of spot's recommendation with that one rather than anything else. > 2. This package's configure.in uses AC_CANONICAL_SYSTEM. > > AC_CANONICAL_SYSTEM adds --build, --host and --target to a configure > script, were --target is the target a cross-tool running on $host being > built on $build is supposed to generate code for. > > This normally is only useful for cross-compilers and their components, > but isn't useful for normal applications. In this case it is not useful. > > The whole configuration only applies $host, i.e. the configure script > wants AC_CANONICAL_HOST, not AC_CANONICAL_SYSTEM nor > AC_CANONICAL_TARGET. Yep - again, this was from discussion on the packagers list as well as on IRC over the past week. IIRC, this method was fine with an existing package and again, recommended that this is what was done (as well as altering the other two members of the AC_CANONICAL triple, but I'd gone to bed at that point!) > As a minimal invasive short-term work-around, without having to patch > the packages and to run the autotools, two approaches are possible: > a) Don't use %configure, instead explicitly invoke ./configure with > appropriate options (and --target removed). > > AFAIS, the packages only uses --prefix and --bindir, so most of the > other options %configure passes to ./configure are unused, anyway, so > > ./configure --prefix=%{_prefix} --bindir=%{_bindir} > probably would be sufficient. What about _libdir? > b) Use this (and don't patch configure*): > %configure --target=none > For the moment, I'd recommend you to remove all traces of patching > config-files and invoking the autotools and to use b). Okay. Do you mind if I pop this onto the mono packaging thread to see what they say? I can see both sides of the argument here with both of them having solid arguments as to why they should and shouldn't be used. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From hugo at devin.com.br Tue Jun 20 13:54:10 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 20 Jun 2006 10:54:10 -0300 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> Message-ID: <200606201054.10222.hugo@devin.com.br> On Tuesday 20 June 2006 10:33, Rex Dieter wrote: > Jonathan Underwood wrote: > > OK - I'd missed that subtelty, sorry. I suppose that's the best (most > > consistent) situation that can be hoped for. > > Or, follow what koffice in Extras did, and use a meta-package named > koffice-suite. A nice advantage of this approach is that since the old > name is no longer being used, we have the opportunity to drop all those > darn Epoch's from kde packaging. And break with upstream package name, package name that the current users are already accustomed, and kdebase and kdelibs should not be sub-packaged, so they will still have these nasty Epochs. I see no advantages here. BTW, I had difficulties into installing koffice because of this reason: a simply yum install koffice didn't work. Then I installed one for one until I found out koffice-suite exists (dumb me!) :) > > -- Rex -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From paul at city-fan.org Tue Jun 20 13:52:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Jun 2006 14:52:24 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150811038.7019.44.camel@mrwibble.mrwobble> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> <1150793705.7019.1.camel@mrwibble.mrwobble> <1150795697.29303.13.camel@mccallum.corsepiu.local> <1150809375.29303.45.camel@mccallum.corsepiu.local> <1150811038.7019.44.camel@mrwibble.mrwobble> Message-ID: <4497FD98.9080500@city-fan.org> PFJ wrote: Ralf wrote: >> AFAIS, the packages only uses --prefix and --bindir, so most of the >> other options %configure passes to ./configure are unused, anyway, so >> >> ./configure --prefix=%{_prefix} --bindir=%{_bindir} >> probably would be sufficient. > > What about _libdir? monodoc appears to install the dll into %{_prefix}/lib and all other "lib" stuff into %{_libdir}; I discovered this by running rpmbuild with _libdir defined as /opt/lib to see what would happen. Paul. From jonathan.underwood at gmail.com Tue Jun 20 14:01:24 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 Jun 2006 15:01:24 +0100 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606201054.10222.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> <200606201054.10222.hugo@devin.com.br> Message-ID: <645d17210606200701g2670c24fs106a66257c3805cf@mail.gmail.com> On 20/06/06, Hugo Cisneiros wrote: > BTW, I had difficulties into installing koffice because of this reason: a > simply yum install koffice didn't work. Then I installed one for one until I > found out koffice-suite exists (dumb me!) :) Yup - call me dumb, but I totally missed koffice-suite as well. I didn't want to be the first to admit it :) From rc040203 at freenet.de Tue Jun 20 14:01:38 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 16:01:38 +0200 Subject: rpms/monodoc/devel monodoc.spec,1.3,1.4 In-Reply-To: <1150811038.7019.44.camel@mrwibble.mrwobble> References: <200606192201.k5JM14xm032122@cvs-int.fedora.redhat.com> <1150790571.23418.57.camel@laurel.intra.city-fan.org> <1150793317.29303.1.camel@mccallum.corsepiu.local> <1150793705.7019.1.camel@mrwibble.mrwobble> <1150795697.29303.13.camel@mccallum.corsepiu.local> <1150809375.29303.45.camel@mccallum.corsepiu.local> <1150811038.7019.44.camel@mrwibble.mrwobble> Message-ID: <1150812099.29303.70.camel@mccallum.corsepiu.local> On Tue, 2006-06-20 at 14:43 +0100, PFJ wrote: > Hi, > Yep - again, this was from discussion on the packagers list as well as > on IRC over the past week. IIRC, this method was fine with an existing > package and again, recommended that this is what was done (as well as > altering the other two members of the AC_CANONICAL triple, but I'd gone > to bed at that point!) Actually, I doubt, they need any AC_CANONICAL* macros at all. I think, they actually want AC_CANONCIAL_BUILD and use $build instead of $host, but I would not exclude they even need this. They seem to use $host to distinguish building on Cygwin from building elsewhere and to trigger using cygpath - I.e. build-system characteristic ==> $build. Furthermore, using cygpath in many cases can be avoided, which would render the whole stuff superfluous. > > As a minimal invasive short-term work-around, without having to patch > > the packages and to run the autotools, two approaches are possible: > > a) Don't use %configure, instead explicitly invoke ./configure with > > appropriate options (and --target removed). > > > > AFAIS, the packages only uses --prefix and --bindir, so most of the > > other options %configure passes to ./configure are unused, anyway, so > > > > ./configure --prefix=%{_prefix} --bindir=%{_bindir} > > probably would be sufficient. > > What about _libdir? You are right, a grep tells, it's used at 3 locations. At many other places they are using a hard-coded $(prefix)/lib > > b) Use this (and don't patch configure*): > > %configure --target=none > > > For the moment, I'd recommend you to remove all traces of patching > > config-files and invoking the autotools and to use b). > > Okay. Do you mind if I pop this onto the mono packaging thread to see > what they say? Nope, this is a public list, so feel free ... Ralf From rdieter at math.unl.edu Tue Jun 20 14:11:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 09:11:30 -0500 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606201054.10222.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> <200606201054.10222.hugo@devin.com.br> Message-ID: Hugo Cisneiros wrote: > On Tuesday 20 June 2006 10:33, Rex Dieter wrote: > >>Jonathan Underwood wrote: >> >>>OK - I'd missed that subtelty, sorry. I suppose that's the best (most >>>consistent) situation that can be hoped for. >> >>Or, follow what koffice in Extras did, and use a meta-package named >>koffice-suite. A nice advantage of this approach is that since the old >>name is no longer being used, we have the opportunity to drop all those >>darn Epoch's from kde packaging. > > > And break with upstream package name, package name that the current users are > already accustomed, and kdebase and kdelibs should not be sub-packaged, so > they will still have these nasty Epochs. I see no advantages here. Not if you properly Provides/Obsoletes the old name. Obviously, the subpackaging idea doesn't extend to *all* kde packages, only for the ones for which it makes sense. > BTW, I had difficulties into installing koffice because of this reason: a > simply yum install koffice didn't work. Then I installed one for one until I > found out koffice-suite exists (dumb me!) :) I consider that a bug/shortcoming of yum. koffice-suite properly Provides/Obsoletes "koffice", but 'yum install' doesn't grok "Provides", only real pkgs. ): -- rex From rdieter at math.unl.edu Tue Jun 20 14:21:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 09:21:19 -0500 Subject: dbus-qt4 bindings Message-ID: FYI, since dbus-0.62 (in fc6/devel branch) has functional/buildable dbus-qt4 bindings, I'm planning on enabling it in the next build of dbus-qt (so it will also produce dbus-qt4, dbus-qt4-devel pkgs as well). -- Rex From paul at city-fan.org Tue Jun 20 14:23:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Jun 2006 15:23:29 +0100 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> <200606201054.10222.hugo@devin.com.br> Message-ID: <449804E1.5050202@city-fan.org> Rex Dieter wrote: > Hugo Cisneiros wrote: >> On Tuesday 20 June 2006 10:33, Rex Dieter wrote: >> >>> Jonathan Underwood wrote: >>> >>>> OK - I'd missed that subtelty, sorry. I suppose that's the best (most >>>> consistent) situation that can be hoped for. >>> >>> Or, follow what koffice in Extras did, and use a meta-package named >>> koffice-suite. A nice advantage of this approach is that since the old >>> name is no longer being used, we have the opportunity to drop all those >>> darn Epoch's from kde packaging. >> >> >> And break with upstream package name, package name that the current >> users are already accustomed, and kdebase and kdelibs should not be >> sub-packaged, so they will still have these nasty Epochs. I see no >> advantages here. > > Not if you properly Provides/Obsoletes the old name. Obviously, the > subpackaging idea doesn't extend to *all* kde packages, only for the > ones for which it makes sense. > >> BTW, I had difficulties into installing koffice because of this >> reason: a simply yum install koffice didn't work. Then I installed one >> for one until I found out koffice-suite exists (dumb me!) :) > > I consider that a bug/shortcoming of yum. koffice-suite properly > Provides/Obsoletes "koffice", Really? It Obsoletes koffice but there's no explicit Provide: $ rpm -qp --provides koffice-suite-1.5.1-1.fc5.i386.rpm koffice-suite = 1.5.1-1.fc5 # rpm -qp --obsoletes koffice-suite-1.5.1-1.fc5.i386.rpm koffice <= 4:1.5.1-1.fc5 koffice-i18n < 4:1.5.1 > but 'yum install' doesn't grok "Provides", > only real pkgs. ): So how come things like "yum install libstdc++.so.5" work? Paul. From hugo at devin.com.br Tue Jun 20 14:36:57 2006 From: hugo at devin.com.br (Hugo Cisneiros) Date: Tue, 20 Jun 2006 11:36:57 -0300 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> <200606201054.10222.hugo@devin.com.br> Message-ID: <200606201136.57312.hugo@devin.com.br> On Tuesday 20 June 2006 11:11, Rex Dieter wrote: > Hugo Cisneiros wrote: > > On Tuesday 20 June 2006 10:33, Rex Dieter wrote: > >>Jonathan Underwood wrote: > >>>OK - I'd missed that subtelty, sorry. I suppose that's the best (most > >>>consistent) situation that can be hoped for. > >> > >>Or, follow what koffice in Extras did, and use a meta-package named > >>koffice-suite. A nice advantage of this approach is that since the old > >>name is no longer being used, we have the opportunity to drop all those > >>darn Epoch's from kde packaging. > > > > And break with upstream package name, package name that the current users > > are already accustomed, and kdebase and kdelibs should not be > > sub-packaged, so they will still have these nasty Epochs. I see no > > advantages here. > > Not if you properly Provides/Obsoletes the old name. Obviously, the > subpackaging idea doesn't extend to *all* kde packages, only for the > ones for which it makes sense. Oh, you're completely right... With this I changed my mind: now IMO it's better to do this. Some naming suggestions? - kdegames-all - kdegames-meta (yummy (*)) - kdegames-suite - kdegames-group - kdegames-suite (*) - This also resolves the problem when removing a sub-package, the "meta" word will tell the user that there's no big problem removing the packaging (it will not remove its main subpackages). > > BTW, I had difficulties into installing koffice because of this reason: a > > simply yum install koffice didn't work. Then I installed one for one > > until I found out koffice-suite exists (dumb me!) :) > > I consider that a bug/shortcoming of yum. koffice-suite properly > Provides/Obsoletes "koffice", but 'yum install' doesn't grok "Provides", > only real pkgs. ): Hummm, this is really annoying... If this is really a yum bug, we would get a lot of trouble. I asked Seth's adivce on IRC somedays ago and he said that yum recognizes Provides well. Is this fixed in current development yum versions? (aka 2.9.0) Anyway, I have a rawhide test system here, I'll test this and inform the list. later. > > -- rex -- []'s Eitch http://www.devin.com.br/eitch/ "Talk is cheap. Show me the code." - Linus Torvalds From rdieter at math.unl.edu Tue Jun 20 14:33:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 09:33:50 -0500 Subject: KDE Sub-Packaging Approach on Fedora References: <200606171820.44076.hugo@devin.com.br> <645d17210606200611r4c579c84h58cab749114a6a03@mail.gmail.com> <200606201054.10222.hugo@devin.com.br> <449804E1.5050202@city-fan.org> Message-ID: Paul Howarth wrote: > Rex Dieter wrote: >> Hugo Cisneiros wrote: >>> On Tuesday 20 June 2006 10:33, Rex Dieter wrote: >>> >>>> Jonathan Underwood wrote: >>>> >>>>> OK - I'd missed that subtelty, sorry. I suppose that's the best (most >>>>> consistent) situation that can be hoped for. >>>> >>>> Or, follow what koffice in Extras did, and use a meta-package named >>>> koffice-suite. A nice advantage of this approach is that since the old >>>> name is no longer being used, we have the opportunity to drop all those >>>> darn Epoch's from kde packaging. >>> >>> >>> And break with upstream package name, package name that the current >>> users are already accustomed, and kdebase and kdelibs should not be >>> sub-packaged, so they will still have these nasty Epochs. I see no >>> advantages here. >> >> Not if you properly Provides/Obsoletes the old name. Obviously, the >> subpackaging idea doesn't extend to *all* kde packages, only for the >> ones for which it makes sense. >> >>> BTW, I had difficulties into installing koffice because of this >>> reason: a simply yum install koffice didn't work. Then I installed one >>> for one until I found out koffice-suite exists (dumb me!) :) >> >> I consider that a bug/shortcoming of yum. koffice-suite properly >> Provides/Obsoletes "koffice", > > Really? It Obsoletes koffice but there's no explicit Provide: > > $ rpm -qp --provides koffice-suite-1.5.1-1.fc5.i386.rpm > koffice-suite = 1.5.1-1.fc5 > # rpm -qp --obsoletes koffice-suite-1.5.1-1.fc5.i386.rpm > koffice <= 4:1.5.1-1.fc5 > koffice-i18n < 4:1.5.1 > > > but 'yum install' doesn't grok "Provides", >> only real pkgs. ): > > So how come things like "yum install libstdc++.so.5" work? OK, maybe not as bad a bug in yum afterall. IMO, koffice-suite should Provides: koffice as well I *do* know that if a real pkg 'foo-1' exists, but a another package 'bar-2' includes Provides: foo = 2 that 'yum install' foo will pull in foo-1. -- Rex -- Rex From jwboyer at jdub.homelinux.org Tue Jun 20 14:35:44 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Jun 2006 09:35:44 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150814145.26810.1.camel@weaponx.rchland.ibm.com> On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > > You are a Fedora Extras Packager and want to be in the next FESCo? Well, > then hurry up and nominate yourself until Tuesday, 20 June 23:59 UTC by > adding yourself to above wiki page. For some details on the nominations > and the background of the decision to actually make it one see: > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html I got back from vacation and finally added an entry for myself. Sorry for the last minute addition. I look forward to having a great election! josh From rdieter at math.unl.edu Tue Jun 20 14:35:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 09:35:20 -0500 Subject: KDE Sub-Packaging Approach on Fedora References: <200606171820.44076.hugo@devin.com.br> <200606201054.10222.hugo@devin.com.br> <200606201136.57312.hugo@devin.com.br> Message-ID: Hugo Cisneiros wrote: >> I consider that a bug/shortcoming of yum. koffice-suite properly >> Provides/Obsoletes "koffice", but 'yum install' doesn't grok "Provides", >> only real pkgs. ): > > Hummm, this is really annoying... If this is really a yum bug, we would > get a lot of trouble. I asked Seth's adivce on IRC somedays ago and he > said that yum recognizes Provides well. Is this fixed in current > development yum versions? (aka 2.9.0) > > Anyway, I have a rawhide test system here, I'll test this and inform the > list. later. Thanks. I'm pretty sure the "bug" isn't as bad as I originally described. Last I knew, however, was that yum did prefer an older "real" pkg over a newer "Provides:" one. -- Rex From denis at poolshark.org Tue Jun 20 15:40:13 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 20 Jun 2006 17:40:13 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: <20060618111844.ffde77e9.bugs.michael@gmx.net> References: <4494AC7B.2090202@knox.net.nz> <20060618111844.ffde77e9.bugs.michael@gmx.net> Message-ID: <449816DD.3020008@poolshark.org> Michael Schwendt wrote: > On Sun, 18 Jun 2006 13:29:31 +1200, Michael J. Knox wrote: > > >>Owners file stats: > > >> - 43 packages not available in extras devel or release > > > What is this based on? > > The list contains many packages which are NOT included anymore on > purpose. Either obsoleted or not needed anymore (and mind you, we don't > have any meta package where to put global obsoletes forever). At least > these need not be put into this report: > [snip] >> denis at poolshark dot org gtkmm20 >> denis at poolshark dot org libgnomemm20 >> denis at poolshark dot org libglademm20 >> denis at poolshark dot org libgnomecanvasmm20 >> denis at poolshark dot org libgnomeuimm20 >> denis at poolshark dot org gconfmm20 Right, see here : http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00936.html Can we cvs-remove the files from the trunk somehow ? Or check in a special 'deleted' flag/file ? -denis From ville.skytta at iki.fi Tue Jun 20 15:42:38 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 20 Jun 2006 18:42:38 +0300 Subject: permissions on gdm session files In-Reply-To: <44974861.7040602@thecodergeek.com> References: <1150735994.17415.24.camel@localhost.localdomain> <44974861.7040602@thecodergeek.com> Message-ID: <1150818158.17415.69.camel@localhost.localdomain> On Mon, 2006-06-19 at 17:59 -0700, Peter Gordon wrote: > Ville Skytt wrote: > > I'm pretty sure those are plain packaging bugs. > So we should report these as they are found to Bugzilla then? Bugs belong in Bugzilla, yes :) From Christian.Iseli at licr.org Tue Jun 20 15:48:05 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 20 Jun 2006 17:48:05 +0200 Subject: FE Package Status of Jun 18, 2006 In-Reply-To: Your message of "Tue, 20 Jun 2006 17:40:13 +0200." <449816DD.3020008@poolshark.org> Message-ID: <200606201548.k5KFm5sQ030676@ludwig-alpha.unil.ch> denis at poolshark.org said: > Can we cvs-remove the files from the trunk somehow ? Or check in a special > 'deleted' flag/file ? The current convention is to "cvs delete" all the files in the devel directory, and to "cvs add" a dead.package file (maybe containing explanations about what happened to the package). Then the QA script will know that those packages are dead. Cheers, Christian From eric.tanguy at univ-nantes.fr Tue Jun 20 17:14:41 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Tue, 20 Jun 2006 19:14:41 +0200 Subject: rpmbuild and selinux Message-ID: <1150823681.2538.1.camel@bureau.maison> Since the update this morning when i try to build a package using rpmbuild i obtain this kind of errors in the log : Traitement des fichiers: libupnp-devel-1.4.0-1 file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t file_contexts: invalid context system_u:object_r:usr_t someone could explain me why and how to solve this ? Thanks Eric From Matt_Domsch at dell.com Tue Jun 20 18:12:00 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 20 Jun 2006 13:12:00 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-20 Message-ID: <20060620181200.GC19084@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Tue Jun 20 12:09:17 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gtkhtml36 193476 ASSIGNED Number failed to build: 143 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 142 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 138 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Hermes thomas at apestaart.org MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mfstools tcallawa at redhat.com multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 CLOSED'] tla at rasmil.dk 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 Tue Jun 20 18:12:22 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 20 Jun 2006 13:12:22 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-20 Message-ID: <20060620181222.GD19084@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Tue Jun 20 12:07:43 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gtkhtml36 193476 ASSIGNED Number failed to build: 163 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 152 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 148 ---------------------------------- Gtk-Perl matthias at rpmforge.net GtkAda gemi at bluewin.ch Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org NetworkManager-vpnc davidz at redhat.com SDL_ttf bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com WindowMaker andreas.bierfert at lowlatency.de airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net colorscheme gauret at free.fr contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net dbus-qt rdieter at math.unl.edu ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com epylog icon at fedoraproject.org exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fillets-ng matthias at rpmforge.net fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net fontforge roozbeh at farsiweb.info foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info gtk+ rdieter at math.unl.edu gtk-gnutella dmitry at butskoy.name gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gtktalog matthias at rpmforge.net gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libgda j.w.r.degoede at hhs.nl libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch pygame chris.stone at gmail.com python-TestGears ivazquez at ivazquez.net python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stow gauret at free.fr stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net tetex-eurofont aportal at univ-montp2.fr ucarp matthias at rpmforge.net uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xmms-crossfade matthias at rpmforge.net xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de yumex ['193549 CLOSED'] tla at rasmil.dk 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 j.w.r.degoede at hhs.nl Tue Jun 20 17:34:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 20 Jun 2006 19:34:03 +0200 Subject: Packing audacious - Funny plugins In-Reply-To: <20060619201449.76afb9a3@nausicaa.camperquake.de> References: <20060619201449.76afb9a3@nausicaa.camperquake.de> Message-ID: <4498318B.7050902@hhs.nl> Ralf Ertzinger wrote: > Hi. > > > I am currently looking into packing audacious, the followup project to > bmp, which is (was) a GTK2 port of xmms. > > Now audacious has a slew of input plugins, some of which I am not sure > about regarding their legal status. Here goes. > > mp3 (Nope) > aac (Nope) > wma (Nope) Agreed > musepack (Unsure) As already said: libmpcdec is in Extras, so I guess there are no fundamental blockers. > modplug (Yes) > timidity (Yes) > wav (Yes) > vorbis (Yes) > flac (Yes, although the code is... strange) Agreed > sid [C64 sound files] (Unsure) xmms-sid is alreayd in Extras so definetly yes > spc, ndf, gbs [Console sound files] (Unsure) I don't think so I don't think it will even be acceptable in that other repo, atleast they don't accept emulators because of possible contributary copyright (not patent?) infringement > psf [PSX sound files] (Unsure) Same > adlib (Unsure) Should be just Fine for Extras. Regards, Hans From jkeating at redhat.com Tue Jun 20 19:29:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Jun 2006 15:29:37 -0400 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: References: <200606171820.44076.hugo@devin.com.br> <200606201054.10222.hugo@devin.com.br> <200606201136.57312.hugo@devin.com.br> Message-ID: <1150831777.18766.20.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-06-20 at 09:35 -0500, Rex Dieter wrote: > Thanks. I'm pretty sure the "bug" isn't as bad as I originally described. > Last I knew, however, was that yum did prefer an older "real" pkg over a > newer "Provides:" one. Here is the scoop. you have 'foo-0:2.4.6-1' as a package. You then create 'foobar-0:1.2-3' which has Obsoletes: foo; Provides: foo. 'foo' is left in the repository. 'yum install foo' will find the package 'foo' and install that instead of 'foobar'. This is by design according to Seth when I last talked to him about it. Because you are asking for the package name not a provides. The package itself would have to be removed from the repository. Seth, is this still true? I don't want to speak for you. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Jun 20 20:04:17 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Jun 2006 01:34:17 +0530 Subject: rrdtool query In-Reply-To: <44956EA8.5030802@homer.se> References: <44950D14.9000708@homer.se> <449534C7.4030608@sunnmore.net> <44956EA8.5030802@homer.se> Message-ID: <1150833857.20056.49.camel@sundaram.pnq.redhat.com> On Sun, 2006-06-18 at 17:18 +0200, Lars E. Pettersson wrote: > On 06/18/2006 01:11 PM, Roy-Magne Mo wrote: > > Lars E. Pettersson wrote: > >> I have a question. Why do these subpackages have the following names: > >> > >> perl-rrdtool > >> php-rrdtool > >> python-rrdtool > > > > It's all explained in the packaging guidelines: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > But is not the parent in this case rrdtool, and therefore rrdtool-* the > correct name? The perl-rrdtool package, as one example, adds a new > functionality to the rrdtool package, and can not be used on its own, > you need rrdtool (and perl also, I have to admit.) As the package also > is very tightly coupled to the rrdtool package (comes from the same tar > file, except php that uses a patch), rrdtool-perl seems much more > logical than the reverse, IMHO. > > I can see a chicken or egg problem here, though... I think rrdtool* for sub packages works better from a end user stand point. Rahul From jwilson at redhat.com Tue Jun 20 20:12:23 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Jun 2006 16:12:23 -0400 Subject: rrdtool query In-Reply-To: <1150833857.20056.49.camel@sundaram.pnq.redhat.com> References: <44950D14.9000708@homer.se> <449534C7.4030608@sunnmore.net> <44956EA8.5030802@homer.se> <1150833857.20056.49.camel@sundaram.pnq.redhat.com> Message-ID: <1150834343.3711.2.camel@xavier.boston.redhat.com> On Wed, 2006-06-21 at 01:34 +0530, Rahul Sundaram wrote: > On Sun, 2006-06-18 at 17:18 +0200, Lars E. Pettersson wrote: > > On 06/18/2006 01:11 PM, Roy-Magne Mo wrote: > > > Lars E. Pettersson wrote: > > >> I have a question. Why do these subpackages have the following names: > > >> > > >> perl-rrdtool > > >> php-rrdtool > > >> python-rrdtool > > > > > > It's all explained in the packaging guidelines: > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > > > But is not the parent in this case rrdtool, and therefore rrdtool-* the > > correct name? The perl-rrdtool package, as one example, adds a new > > functionality to the rrdtool package, and can not be used on its own, > > you need rrdtool (and perl also, I have to admit.) As the package also > > is very tightly coupled to the rrdtool package (comes from the same tar > > file, except php that uses a patch), rrdtool-perl seems much more > > logical than the reverse, IMHO. > > > > I can see a chicken or egg problem here, though... > > I think rrdtool* for sub packages works better from a end user stand > point. And I think I already changed the packages all over to rrdtool-* yesterday. :) http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/rrdtool/ (though only for the development branch, I'll get to fc5 and 4 shortly) -- 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 bugs.michael at gmx.net Tue Jun 20 21:48:34 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Jun 2006 23:48:34 +0200 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <1150831777.18766.20.camel@dhcp83-49.boston.redhat.com> References: <200606171820.44076.hugo@devin.com.br> <200606201054.10222.hugo@devin.com.br> <200606201136.57312.hugo@devin.com.br> <1150831777.18766.20.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060620234834.6202b1ab.bugs.michael@gmx.net> On Tue, 20 Jun 2006 15:29:37 -0400, Jesse Keating wrote: > On Tue, 2006-06-20 at 09:35 -0500, Rex Dieter wrote: > > Thanks. I'm pretty sure the "bug" isn't as bad as I originally described. > > Last I knew, however, was that yum did prefer an older "real" pkg over a > > newer "Provides:" one. > > Here is the scoop. > > you have 'foo-0:2.4.6-1' as a package. You then create 'foobar-0:1.2-3' > which has Obsoletes: foo; Provides: foo. 'foo' is left in the > repository. > > 'yum install foo' will find the package 'foo' and install that instead > of 'foobar'. This is by design according to Seth when I last talked to > him about it. Because you are asking for the package name not a > provides. The package itself would have to be removed from the > repository. > > Seth, is this still true? I don't want to speak for you. https://bugzilla.redhat.com/190116 From skvidal at linux.duke.edu Tue Jun 20 21:54:41 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Jun 2006 17:54:41 -0400 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <20060620234834.6202b1ab.bugs.michael@gmx.net> References: <200606171820.44076.hugo@devin.com.br> <200606201054.10222.hugo@devin.com.br> <200606201136.57312.hugo@devin.com.br> <1150831777.18766.20.camel@dhcp83-49.boston.redhat.com> <20060620234834.6202b1ab.bugs.michael@gmx.net> Message-ID: <1150840481.9213.27.camel@cutter> On Tue, 2006-06-20 at 23:48 +0200, Michael Schwendt wrote: > On Tue, 20 Jun 2006 15:29:37 -0400, Jesse Keating wrote: > > > On Tue, 2006-06-20 at 09:35 -0500, Rex Dieter wrote: > > > Thanks. I'm pretty sure the "bug" isn't as bad as I originally described. > > > Last I knew, however, was that yum did prefer an older "real" pkg over a > > > newer "Provides:" one. > > > > Here is the scoop. > > > > you have 'foo-0:2.4.6-1' as a package. You then create 'foobar-0:1.2-3' > > which has Obsoletes: foo; Provides: foo. 'foo' is left in the > > repository. > > > > 'yum install foo' will find the package 'foo' and install that instead > > of 'foobar'. This is by design according to Seth when I last talked to > > him about it. Because you are asking for the package name not a > > provides. The package itself would have to be removed from the > > repository. > > > > Seth, is this still true? I don't want to speak for you. > > https://bugzilla.redhat.com/190116 yep - seems to be in NEEDINFO state. but it works for me just fine. I believe yum in cvs and soon to be in rawhide fixes it. -sv From jkeating at redhat.com Tue Jun 20 22:41:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Jun 2006 18:41:48 -0400 Subject: New mock package coming out soon Message-ID: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> I've taken over maintainership of mock in Extras, with Seth's approval. I've packaged up the 0.6 release and built it for FE-4, FE-5, and devel. Please give these a good workout. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Tue Jun 20 23:39:10 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Jun 2006 16:39:10 -0700 Subject: BuildSys Hosed? Message-ID: For some reason it looks like BuildSys is not building anything on i386 or x86_64. From chris.stone at gmail.com Wed Jun 21 00:20:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Jun 2006 17:20:18 -0700 Subject: BuildSys Hosed? In-Reply-To: References: Message-ID: hmm nevermind, my packages eventually got built. Seems that 3 of the 6 slots are hosed and are taking up half the queue slots. On 6/20/06, Christopher Stone wrote: > For some reason it looks like BuildSys is not building anything on > i386 or x86_64. > From tibbs at math.uh.edu Wed Jun 21 01:06:06 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 20 Jun 2006 20:06:06 -0500 Subject: New mock package coming out soon In-Reply-To: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> (Jesse Keating's message of "Tue, 20 Jun 2006 18:41:48 -0400") References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> I've taken over maintainership of mock in Extras, with Seth's JK> approval. I've packaged up the 0.6 release and built it for FE-4, JK> FE-5, and devel. Please give these a good workout. I'm not sure if the buildsys machines are even running Fedora, but if they are, someone might want to make sure mock doesn't get updated until things have been well-tested. Otherwise if there's a problem we might be stuck in a position of not being able to build a fixed package. - J< From katzj at redhat.com Wed Jun 21 01:21:25 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Jun 2006 21:21:25 -0400 Subject: New mock package coming out soon In-Reply-To: References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> Message-ID: <1150852885.6680.1.camel@aglarond.local> On Tue, 2006-06-20 at 20:06 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > JK> I've taken over maintainership of mock in Extras, with Seth's > JK> approval. I've packaged up the 0.6 release and built it for FE-4, > JK> FE-5, and devel. Please give these a good workout. > > I'm not sure if the buildsys machines are even running Fedora, but if > they are, someone might want to make sure mock doesn't get updated > until things have been well-tested. Otherwise if there's a problem we > might be stuck in a position of not being able to build a fixed > package. They mostly[1] are. But they won't grab the new packages automatically, never fear. And even if they did, we could pretty easily then go and downgrade them if we really had to. Jeremy [1] I think there's still one or two running RHEL4, but I'd have to go login to them to check From peter at thecodergeek.com Wed Jun 21 01:52:40 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 20 Jun 2006 18:52:40 -0700 Subject: docs packaging In-Reply-To: References: <1150778447.2565.9.camel@bureau.maison> <449786CA.4080201@thecodergeek.com> Message-ID: <4498A668.60709@thecodergeek.com> Christopher Stone wrote: > On 6/19/06, Peter Gordon wrote: >> %package docs > > doc subpackages should be named -doc not -docs > Thanks for that information. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From seg at haxxed.com Wed Jun 21 02:22:17 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 Jun 2006 21:22:17 -0500 Subject: KDE Sub-Packaging Approach on Fedora In-Reply-To: <200606201009.14575.hugo@devin.com.br> References: <200606171820.44076.hugo@devin.com.br> <645d17210606200541s5219a95dgf34a3ace66a2cb8a@mail.gmail.com> <200606201009.14575.hugo@devin.com.br> Message-ID: <1150856537.3220.1.camel@localhost> On Tue, 2006-06-20 at 10:09 -0300, Hugo Cisneiros wrote: > The idea on creating yum groups would satisfy this "problem" and the issue in > comment #10 at bugzilla. But IMO creating such groups in yum would pollute > the yum's groups and it's not exactly what we want. Don't we have a comps thingy that exists for exactly this kind of thing? Rather than abusing package dependencies. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Wed Jun 21 03:51:35 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 20 Jun 2006 20:51:35 -0700 Subject: permissions on gdm session files In-Reply-To: <1150818158.17415.69.camel@localhost.localdomain> References: <1150735994.17415.24.camel@localhost.localdomain> <44974861.7040602@thecodergeek.com> <1150818158.17415.69.camel@localhost.localdomain> Message-ID: <4498C247.3090000@thecodergeek.com> Ville Skytt wrote: > On Mon, 2006-06-19 at 17:59 -0700, Peter Gordon wrote: >> Ville Skytt wrote: >>> I'm pretty sure those are plain packaging bugs. >> So we should report these as they are found to Bugzilla then? > > Bugs belong in Bugzilla, yes :) > Thanks, Ville. I've submitted them as bugs #196105 (for gnome-session) and #196106 (for fluxbox). -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wtogami at redhat.com Wed Jun 21 03:59:14 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Jun 2006 23:59:14 -0400 Subject: FE6 Buildsys Lockups Message-ID: <4498C412.1020809@redhat.com> http://buildsys.fedoraproject.org/build-status/ During the past 2-3 weeks or so, gcc and sed have been deadlocking during FE6 builds in our plague+mock based Extras buildsys. This has been happening consistently when building certain packages, and always the i386 arch deadlocking. Our attempts of getting any useful info from strace or gdb have failed. Our x86_64 Extras buildsys hosts appear to be FC3 with kernel-2.6.12-1.1376_FC3smp. Meanwhile we haven't seem to run into similar deadlock problems of our FC6 mock builds inside of Red Hat, where the host is RHEL4 U3. Several of us suspect some kind of kernel problem on the buildhosts. Here are the next steps that I am trying: 1) Testing those builds on our existing FC3 buildhosts, but with RHEL4 kernels. 2) Testing those builds on Red Hat's internal buildsys, which is also mock based but with RHEL4 hosts. I am proceeding to install RHEL4 kernels and rebooting the Extras build hosts now. Warren Togami wtogami at redhat.com From toshio at tiki-lounge.com Wed Jun 21 05:23:01 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 20 Jun 2006 22:23:01 -0700 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: References: <1150657448.2210.26.camel@localhost.localdomain> <1150657968.2210.36.camel@localhost.localdomain> Message-ID: <1150867382.2792.19.camel@localhost> On Mon, 2006-06-19 at 15:53 -0400, Elliot Lee wrote: > I and the rest of the sysadmins will defend against attacks by > marauding aliens... I don't think there is a lot we can do to verify > 100% that the results weren't faked (that is up to Toshio's good > coding skills). I'm more than happy to certify a preliminary report > of the results so you can put it up for comment. > > And Toshio, let me know when to revoke your login access before the > election begins. :) * Josh Boyer has been added to the candidates list. * The test data has been dumped from the database. * I've recreated the election to start on June 22nd 00:00:00 UTC and end on July 2 23:59:59 UTC. * All sources have been checked into cvs. * Clarified the wording to show that once the ballot is cast, you cannot vote again. Elliot, if the app1 server problem has indeed been resolved, you can go ahead and take away my permissions to change the database and edit the application files. Otherwise I better stay on for a little longer to try and find that and recreate the db afterwards. -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 wtogami at redhat.com Wed Jun 21 05:23:59 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Jun 2006 01:23:59 -0400 Subject: FE6 Buildsys Lockups In-Reply-To: <4498C412.1020809@redhat.com> References: <4498C412.1020809@redhat.com> Message-ID: <4498D7EF.8080401@redhat.com> Warren Togami wrote: > http://buildsys.fedoraproject.org/build-status/ > > During the past 2-3 weeks or so, gcc and sed have been deadlocking > during FE6 builds in our plague+mock based Extras buildsys. This has > been happening consistently when building certain packages, and always > the i386 arch deadlocking. Our attempts of getting any useful info from > strace or gdb have failed. > > Our x86_64 Extras buildsys hosts appear to be FC3 with > kernel-2.6.12-1.1376_FC3smp. Meanwhile we haven't seem to run into > similar deadlock problems of our FC6 mock builds inside of Red Hat, > where the host is RHEL4 U3. Several of us suspect some kind of kernel > problem on the buildhosts. > > Here are the next steps that I am trying: > > 1) Testing those builds on our existing FC3 buildhosts, but with RHEL4 > kernels. > 2) Testing those builds on Red Hat's internal buildsys, which is also > mock based but with RHEL4 hosts. > > I am proceeding to install RHEL4 kernels and rebooting the Extras build > hosts now. > All 3 hammer Extras buildsys machines are now running RHEL4 kernels. gurlchecker seems to have built successfully. Please try the other packages and let this thread know if you run into any more trouble related to this. Warren Togami wtogami at redhat.com From lars at homer.se Wed Jun 21 07:01:54 2006 From: lars at homer.se (Lars E. Pettersson) Date: Wed, 21 Jun 2006 09:01:54 +0200 Subject: rrdtool query In-Reply-To: <1150834343.3711.2.camel@xavier.boston.redhat.com> References: <44950D14.9000708@homer.se> <449534C7.4030608@sunnmore.net> <44956EA8.5030802@homer.se> <1150833857.20056.49.camel@sundaram.pnq.redhat.com> <1150834343.3711.2.camel@xavier.boston.redhat.com> Message-ID: <4498EEE2.2040800@homer.se> On 06/20/2006 10:12 PM, Jarod Wilson wrote: > And I think I already changed the packages all over to rrdtool-* > yesterday. :) Ah, good. Thanks! Lars -- Lars E. Pettersson http://www.sm6rpz.se/ From gajownik at gmail.com Wed Jun 21 07:27:58 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Wed, 21 Jun 2006 09:27:58 +0200 Subject: debuginfo on PPC platform Message-ID: <4498F4FE.2040100@gmail.com> Hi! I've updated today python-sqlite2 to newer version. I noticed this warning in the logs [1]: extracting debug info from /var/tmp/python-sqlite2-2.3.1-1.fc6-root-mockbuild/usr/lib/python2.4/site-packages/pysqlite2/_sqlite.so cpio: gcc-4.1.1-20060612/obj-ppc64-redhat-linux/gcc/crtsavres.S: No such file or directory 281 blocks Does that mean that this debuginfo package will be useless? On FE5 there is no such a warning [2]. I ask about it because I don't have access to PPC machine and cannot test it. Thanks, Dawid [1] http://buildsys.fedoraproject.org/logs/fedora-development-extras/11323-python-sqlite2-2.3.1-1.fc6/ppc/build.log [2] http://buildsys.fedoraproject.org/logs/fedora-5-extras/11325-python-sqlite2-2.3.1-1.fc5/ppc/build.log -- ^_* From buildsys at fedoraproject.org Wed Jun 21 11:03:17 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Jun 2006 07:03:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-21 Message-ID: <20060621110317.F088515217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 41 PyQt-qscintilla-3.15-2.fc5 SIBsim4-0.13-1.fc5 TeXmacs-1.0.6.3-1.fc5 amsn-0.96-0.11.rc1.fc5 cksfv-1.3.9-1.fc5 dbus-qt-0.61-4.fc5 dogtail-0.5.1-4.fc5 drivel-2.1.0-0.1.20060527cvs.fc5 epylog-1.0.3-4.fc5 fcron-3.0.1-11.fc5 ganglia-3.0.3-7.fc5 geomview-1.8.2-0.5.cvs20040221.fc5 hugs98-2006.05-3.fc5 lat-1.0.5-6.fc5 mock-0.6-1.fc5 monodoc-1.1.13-12.fc5 mysql-administrator-1.1.10-1.fc5 openct-0.6.8-1.fc5 osgcal-0.1.40-2.fc5 paps-0.6.6-5.fc5 pengupop-2.0.2-2.fc5 perl-HTTP-Server-Simple-0.20-1.fc5 perl-List-MoreUtils-0.21-1.fc5 perl-POE-0.3502-1.fc5 perl-Test-WWW-Mechanize-1.10-1.fc5 plt-scheme-350-1.fc5 poedit-1.3.4-2.fc5 proftpd-1.3.0-4.fc5 pyspi-0.5.4-3.fc5 python-simpy-1.7.1-2.fc5 python-sqlite2-2.3.1-1.fc5 rsibreak-0.7.1-1.fc5 smb4k-0.7.1-1.fc5 srecord-1.26-1.fc5 tcpick-0.2.1-8.fc5 uim-1.1.0-1.fc5 wordpress-2.0.3-2.fc5 xchat-gnome-0.12-1.fc5 xmms-crossfade-0.3.10-2.fc5 xsp-1.1.15-6.fc5 yumex-1.0.2-1.0.fc5 Packages built and released for Fedora Extras 4: 26 SIBsim4-0.13-1.fc4 TeXmacs-1.0.6.3-1.fc4 cksfv-1.3.9-1.fc4 dbus-qt-0.33-7.fc4 epylog-1.0.3-4.fc4 fcron-3.0.1-11.fc4 ganglia-3.0.3-7.fc4 geomview-1.8.2-0.5.cvs20040221.fc4 hugs98-2006.05-3.fc4 mock-0.6-1.fc4 mysql-administrator-1.1.10-1.fc4 osgcal-0.1.40-2.fc4 pengupop-2.0.2-2.fc4 perl-HTTP-Server-Simple-0.20-1.fc4 perl-List-MoreUtils-0.21-1.fc4 perl-POE-0.3502-1.fc4 perl-Test-WWW-Mechanize-1.10-1.fc4 plt-scheme-350-1.fc4 poedit-1.3.4-2.fc4 python-simpy-1.7.1-2.fc4 smb4k-0.7.1-1.fc4 srecord-1.26-1.fc4 tcpick-0.2.1-8.fc4 uim-1.1.0-1.fc4 wordpress-2.0.3-2.fc4 yumex-1.0.2-1.0.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 67 SIBsim4-0.13-1.fc6 TeXmacs-1.0.6.3-1.fc6 amavisd-new-2.4.1-1.fc6 amsn-0.96-0.11.rc1.fc6 buoh-0.8.1-8 cksfv-1.3.9-1.fc6.1 colorscheme-0.3.91-2.fc6 darcs-1.0.8-1.fc6 dbus-qt-0.62-2.fc6 dogtail-0.5.1-4.fc6 drivel-2.1.0-0.1.20060527cvs.fc6 epylog-1.0.3-4.fc6 fcron-3.0.1-11.fc6 fillets-ng-0.7.3-4.fc6 fontforge-20060125-7.fc6 geomview-1.8.2-0.5.cvs20040221.fc6 html401-dtds-4.01-19991224.2.fc6 hugs98-2006.05-3.fc6 jack-audio-connection-kit-0.101.1-10.fc6 lat-1.0.5-6.fc6 libgda-1.9.100-9.fc6 mlmmj-1.2.11-4.fc6 mock-0.6-1.fc6 monodoc-1.1.13-12.fc6 mysql-administrator-1.1.10-1.fc6 nexuiz-2.0-1.fc6 nexuiz-data-2.0-1 openct-0.6.8-1.fc6 osgcal-0.1.40-2.fc6 otrs-2.0.4-3.fc6 paps-0.6.6-5.fc6 pengupop-2.0.2-2.fc6 perl-HTTP-Server-Simple-0.20-1.fc6 perl-List-MoreUtils-0.21-1.fc6 perl-POE-0.3502-1.fc6 perl-Test-WWW-Mechanize-1.10-1.fc6 perl-X11-Protocol-0.55-4.fc6 php-apc-5.1.4_3.0.10-1.fc6 php-pecl-apc-3.0.10-3.fc6 plt-scheme-350-1.fc6 poedit-1.3.4-2.fc6 powerman-1.0.24-1.fc6 proftpd-1.3.0-4.fc6 pyspi-0.5.4-3.fc6 python-GeoIP-1.2.1-4.fc6 python-simpy-1.7.1-2.fc6 python-sqlite2-2.3.1-1.fc6 pyxmms-2.06-2.fc6 qt4-4.1.3-9.fc6 rrdtool-1.2.13-6.fc6 rsibreak-0.7.1-1.fc6 sbcl-0.9.13-3.fc6 scim-skk-0.5.2-5.fc6 sextractor-2.4.4-2.fc6 smb4k-0.7.1-1.fc6 srecord-1.26-1.fc6 stow-1.3.3-4.fc6 taskjuggler-2.2.0-1.fc6 tcpick-0.2.1-8.fc6 tetex-tex4ht-1.0.2006_06_19_1646-1.fc6 ucarp-1.2-1.fc6 uim-1.1.0-1.fc6 wordpress-2.0.3-2.fc6 xchat-gnome-0.12-2.fc6 xmms-crossfade-0.3.10-2.fc6 xsp-1.1.15-6.fc6 yumex-1.1.0-2.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 Jun 21 11:03:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Jun 2006 07:03:40 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-21 Message-ID: <20060621110340.219A115217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvirt: 5: 0:0.1.0-1.FC5 (FC5-updates) 6: 0:0.1.0-1 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.4-3.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-hangul: 4: 0:0.2.2-2.fc4 (FE4) 5: 0:0.2.2-1.fc5.1 (FC5-updates) 6: 0:0.2.2-4.fc6 (FC6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) showimg: 5: 0:0.9.5-7.fc5 (FE5) 6: 0:0.9.5-5.fc5 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.15-1.fc3 (FE3) 4: 0:0.9.15-0.1.fc4 (FE4) 5: 0:0.9.15-1.fc5 (FE5) 6: 0:0.9.15-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) xmms: 5: 1:1.2.10-25.fc5 (FE5) 6: 1:1.2.10-24.fc6 (FE6) From buildsys at fedoraproject.org Wed Jun 21 11:21:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 21 Jun 2006 11:21:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-21 Message-ID: <20060621112127.22614.28262@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Wed Jun 21 11:21:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 21 Jun 2006 11:21:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-21 Message-ID: <20060621112127.22626.17908@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 gauret AT free.fr showimg-pgsql - 0.9.5-5.fc5.i386 showimg-pgsql - 0.9.5-5.fc5.ppc showimg-pgsql - 0.9.5-5.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc jwilson AT redhat.com perl-rrdtool - 1.2.13-4.fc6.i386 perl-rrdtool - 1.2.13-4.fc6.ppc perl-rrdtool - 1.2.13-4.fc6.x86_64 php-rrdtool - 1.2.13-4.fc6.i386 php-rrdtool - 1.2.13-4.fc6.ppc php-rrdtool - 1.2.13-4.fc6.x86_64 python-rrdtool - 1.2.13-4.fc6.i386 python-rrdtool - 1.2.13-4.fc6.ppc python-rrdtool - 1.2.13-4.fc6.x86_64 kevin-redhat-bugzilla AT tummy.com bmp-xosd - 2.2.14-6.fc6.i386 bmp-xosd - 2.2.14-6.fc6.ppc bmp-xosd - 2.2.14-6.fc6.x86_64 xmms-xosd - 2.2.14-6.fc6.i386 xmms-xosd - 2.2.14-6.fc6.ppc xmms-xosd - 2.2.14-6.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 nos AT utelsystems.com soundtracker - 0.6.7-3.x86_64 soundtracker - 0.6.7-4.i386 soundtracker - 0.6.7-4.ppc oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.i386 requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.i386 requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 soundtracker-0.6.7-4.i386 requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.i386 requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_pixbuf.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bmp-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.ppc requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 showimg-pgsql-0.9.5-5.fc5.ppc requires libpqxx-2.5.5.so sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 soundtracker-0.6.7-4.ppc requires libgdk_pixbuf.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.ppc requires libgdk_pixbuf.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_pixbuf.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bmp-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) showimg-pgsql-0.9.5-5.fc5.x86_64 requires libpqxx-2.5.5.so()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) soundtracker-0.6.7-3.x86_64 requires libgdk_pixbuf.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xmms-xosd-2.2.14-6.fc6.x86_64 requires libgdk_pixbuf.so.2()(64bit) ====================================================================== New report for: jwilson AT redhat.com package: python-rrdtool - 1.2.13-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: php-rrdtool - 1.2.13-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: perl-rrdtool - 1.2.13-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: perl-rrdtool - 1.2.13-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: python-rrdtool - 1.2.13-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: php-rrdtool - 1.2.13-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: python-rrdtool - 1.2.13-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: perl-rrdtool - 1.2.13-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: rrdtool = 0:1.2.13-4.fc6 package: php-rrdtool - 1.2.13-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: rrdtool = 0:1.2.13-4.fc6 From buildsys at fedoraproject.org Wed Jun 21 11:21:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 21 Jun 2006 11:21:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-21 Message-ID: <20060621112127.22624.17501@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From dcbw at redhat.com Wed Jun 21 14:02:45 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 21 Jun 2006 10:02:45 -0400 Subject: FE6 Buildsys Lockups In-Reply-To: <4498D7EF.8080401@redhat.com> References: <4498C412.1020809@redhat.com> <4498D7EF.8080401@redhat.com> Message-ID: <1150898565.2725.4.camel@localhost.localdomain> On Wed, 2006-06-21 at 01:23 -0400, Warren Togami wrote: > Warren Togami wrote: > > http://buildsys.fedoraproject.org/build-status/ > > > > During the past 2-3 weeks or so, gcc and sed have been deadlocking > > during FE6 builds in our plague+mock based Extras buildsys. This has > > been happening consistently when building certain packages, and always > > the i386 arch deadlocking. Our attempts of getting any useful info from > > strace or gdb have failed. > > > > Our x86_64 Extras buildsys hosts appear to be FC3 with > > kernel-2.6.12-1.1376_FC3smp. Meanwhile we haven't seem to run into > > similar deadlock problems of our FC6 mock builds inside of Red Hat, > > where the host is RHEL4 U3. Several of us suspect some kind of kernel > > problem on the buildhosts. > > > > Here are the next steps that I am trying: > > > > 1) Testing those builds on our existing FC3 buildhosts, but with RHEL4 > > kernels. > > 2) Testing those builds on Red Hat's internal buildsys, which is also > > mock based but with RHEL4 hosts. > > > > I am proceeding to install RHEL4 kernels and rebooting the Extras build > > hosts now. > > > > All 3 hammer Extras buildsys machines are now running RHEL4 kernels. > gurlchecker seems to have built successfully. Please try the other > packages and let this thread know if you run into any more trouble > related to this. Thanks a ton for taking a look at this Warren, lets hope this does the trick. Dan > Warren Togami > wtogami at redhat.com > From alcapcom at gmail.com Wed Jun 21 14:10:34 2006 From: alcapcom at gmail.com (alcapcom) Date: Wed, 21 Jun 2006 16:10:34 +0200 Subject: Some problems to packaging a java app Message-ID: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> Hello List, Some problems to packaging a java application (bugid:192438 comment #4): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192438#c4 - rpmlint give warning about "class-path-in-manifest" which is the way of making for fedora-extra about classpatch. - During extracting debug information, there is : cpio error: /path/to/class.java: No such file or directory, for all classes in the sources. Any idea? ps: I have already wrote about that on #fedora-devel-java-list, but i think, that for these two question this list is a best place. Regards, Al From jwilson at redhat.com Wed Jun 21 14:27:12 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 21 Jun 2006 10:27:12 -0400 Subject: Time to make Extras multi-lib? Message-ID: <1150900032.3850.3.camel@xavier.boston.redhat.com> Not sure exactly what needs to be done, but I'm currently looking at a package (libhugetlbfs) that builds both 64-bit and 32-bit binaries and libraries on 64-bit systems. I think the ideal way to handle this is to build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit packages available in the 64-bit tree as well. At the moment, this isn't possible, so the 64-bit packages would have to contain the 32-bit parts and some ugly #ifarch junk to build across both 32-bit and 64-bit. I'm thinking its time to make Extras multi-lib. Thoughts? Concerns? -- 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 wart at kobold.org Wed Jun 21 14:56:40 2006 From: wart at kobold.org (Wart) Date: Wed, 21 Jun 2006 07:56:40 -0700 Subject: FE6 Buildsys Lockups In-Reply-To: <4498D7EF.8080401@redhat.com> References: <4498C412.1020809@redhat.com> <4498D7EF.8080401@redhat.com> Message-ID: <44995E28.6090700@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren Togami wrote: > All 3 hammer Extras buildsys machines are now running RHEL4 kernels. > gurlchecker seems to have built successfully. Please try the other > packages and let this thread know if you run into any more trouble > related to this. manaworld (job #11081) build successfully on devel with this new kernel, after repeated build hangs with the previous kernel. Thank you for fixing this, Warren! - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEmV4mDeYlPfs40g8RAr4qAJ9fL45s32ax4lFvgJ4R6VHfOf0reACfUn6v Xi5c+zCJblReMIlHiM9BmsA= =GBhL -----END PGP SIGNATURE----- From tibbs at math.uh.edu Wed Jun 21 15:00:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 10:00:59 -0500 Subject: Some problems to packaging a java app In-Reply-To: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> (alcapcom@gmail.com's message of "Wed, 21 Jun 2006 16:10:34 +0200") References: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> Message-ID: >>>>> "a" == alcapcom writes: a> - During extracting debug information, there is : cpio error: a> /path/to/class.java: No such file or directory, for all classes in a> the sources. -debuginfo package generation is somewhat busted for java apps; check the ganymed review ticket for info on one way to work around some of the bustedness. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191014 - J< From tibbs at math.uh.edu Wed Jun 21 15:02:56 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 10:02:56 -0500 Subject: New mock package coming out soon In-Reply-To: <1150852885.6680.1.camel@aglarond.local> (Jeremy Katz's message of "Tue, 20 Jun 2006 21:21:25 -0400") References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> But they won't grab the new packages automatically, never fear. Thanks. Will you be packaging the buildsys-build package as well? If not, what is the expected method for populating the buildroot? - J< From skvidal at linux.duke.edu Wed Jun 21 15:08:28 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Jun 2006 11:08:28 -0400 Subject: New mock package coming out soon In-Reply-To: References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> Message-ID: <1150902508.11582.51.camel@cutter> On Wed, 2006-06-21 at 10:02 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jeremy Katz writes: > > JK> But they won't grab the new packages automatically, never fear. > > Thanks. Will you be packaging the buildsys-build package as well? If > not, what is the expected method for populating the buildroot? that package is already in the buildgroups location at: http://buildsys.fedoraproject.org/buildgroups/ -sv From katzj at redhat.com Wed Jun 21 15:10:55 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Jun 2006 11:10:55 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1150900032.3850.3.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> Message-ID: <1150902656.22378.11.camel@orodruin.boston.redhat.com> On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > Not sure exactly what needs to be done, but I'm currently looking at a > package (libhugetlbfs) that builds both 64-bit and 32-bit binaries and > libraries on 64-bit systems. I think the ideal way to handle this is to > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > packages available in the 64-bit tree as well. At the moment, this isn't > possible, so the 64-bit packages would have to contain the 32-bit parts > and some ugly #ifarch junk to build across both 32-bit and 64-bit. I'm > thinking its time to make Extras multi-lib. Thoughts? Concerns? As we're moving Core to having an algorithmic way of determining multilib packages (if there's a -devel, then it's wanted in the tree + depsolve), I think that we now actually *can* do multilib for Extras. And the time is probably right... I've now had to enable the i386 extras repo a few times to get libraries onto my x86_64 workstation. Jeremy From dcbw at redhat.com Wed Jun 21 15:27:00 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 21 Jun 2006 11:27:00 -0400 Subject: FE6 Buildsys Lockups In-Reply-To: <44995E28.6090700@kobold.org> References: <4498C412.1020809@redhat.com> <4498D7EF.8080401@redhat.com> <44995E28.6090700@kobold.org> Message-ID: <1150903620.2725.21.camel@localhost.localdomain> On Wed, 2006-06-21 at 07:56 -0700, Wart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Warren Togami wrote: > > > All 3 hammer Extras buildsys machines are now running RHEL4 kernels. > > gurlchecker seems to have built successfully. Please try the other > > packages and let this thread know if you run into any more trouble > > related to this. > > manaworld (job #11081) build successfully on devel with this new kernel, > after repeated build hangs with the previous kernel. I just requeued xmms #9945, another sure buildhang; lets see how it goes. dan > Thank you for fixing this, Warren! > > - --Mike > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFEmV4mDeYlPfs40g8RAr4qAJ9fL45s32ax4lFvgJ4R6VHfOf0reACfUn6v > Xi5c+zCJblReMIlHiM9BmsA= > =GBhL > -----END PGP SIGNATURE----- > From i.pilcher at comcast.net Wed Jun 21 15:35:58 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 21 Jun 2006 10:35:58 -0500 Subject: Noob: Error tagging FC-5 branch Message-ID: I am trying to follow the instructions at http://fedoraproject.org/wiki/Extras/Contributors I have reached the "Tag Your Branches" stage, and I am getting an error when I try to tag the FC-5 branch: [pilcher at home devel]$ cd ../FC-5 [pilcher at home FC-5]$ ls branch CVS fedora-wifi-radar.desktop Makefile sources wifi-radar-pam.d wifi-radar.spec [pilcher at home FC-5]$ make tag cvs tag -c wifi-radar-1_9_6-2 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs ERROR: The tag wifi-radar-1_9_6-2 is already applied on a different branch ERROR: You can not forcibly move tags between branches wifi-radar-1_9_6-2:devel:pilcher:1150786745 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 It looks like this may be caused by the fact that the FC-5 and devel branches have the same package version/release. Is this guess correct? If so, is there a macro that I can add to the Release tag in the SPEC file which will automatically append something meaningful to the release? (The two branches are *exactly* the same right now, and I'm not eager to maintain two separate versions of the SPEC file for no good reason.) Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From tibbs at math.uh.edu Wed Jun 21 15:51:30 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 10:51:30 -0500 Subject: New mock package coming out soon In-Reply-To: <1150902508.11582.51.camel@cutter> (seth vidal's message of "Wed, 21 Jun 2006 11:08:28 -0400") References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> <1150902508.11582.51.camel@cutter> Message-ID: >>>>> "sv" == seth vidal writes: sv> that package is already in the buildgroups location at: sv> http://buildsys.fedoraproject.org/buildgroups/ Hmm, I've been running all this time using no external repositories (just my local mirror). I'll go ahead and mirror that repo as well. - J< From tibbs at math.uh.edu Wed Jun 21 16:00:43 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 11:00:43 -0500 Subject: Noob: Error tagging FC-5 branch In-Reply-To: (Ian Pilcher's message of "Wed, 21 Jun 2006 10:35:58 -0500") References: Message-ID: >>>>> "IP" == Ian Pilcher writes: IP> It looks like this may be caused by the fact that the FC-5 and IP> devel branches have the same package version/release. Is this IP> guess correct? Looks like it. I checked your package out of CVS and it looks like you're not using the dist tag. IP> If so, is there a macro that I can add to the Release tag in the IP> SPEC file which will automatically append something meaningful to IP> the release? That's the dist tag. You should always use it unless you know what you're doing. Just append %{?dist} to the end of your Release:. - J< From rc040203 at freenet.de Wed Jun 21 16:23:59 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jun 2006 18:23:59 +0200 Subject: New mock package coming out soon In-Reply-To: References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> <1150902508.11582.51.camel@cutter> Message-ID: <1150907039.10251.9.camel@mccallum.corsepiu.local> On Wed, 2006-06-21 at 10:51 -0500, Jason L Tibbitts III wrote: > >>>>> "sv" == seth vidal writes: > > sv> that package is already in the buildgroups location at: > > sv> http://buildsys.fedoraproject.org/buildgroups/ > > Hmm, I've been running all this time using no external repositories > (just my local mirror). I never understood why this isn't packaged into a "fedora-mock-config rpm" or the like. > I'll go ahead and mirror that repo as well. That's what I've been doing for quite a while. Pretty inconvenient. Ralf From alcapcom at gmail.com Wed Jun 21 16:25:26 2006 From: alcapcom at gmail.com (alcapcom) Date: Wed, 21 Jun 2006 18:25:26 +0200 Subject: Some problems to packaging a java app In-Reply-To: References: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> Message-ID: <4ccd9dcb0606210925s3798caa8nb3e554b996fcafad@mail.gmail.com> > -debuginfo package generation is somewhat busted for java apps; check > the ganymed review ticket for info on one way to work around some of > the bustedness. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191014 > > - J< Hehe, The work around solve the problem, but so as explained in the above ticket, find-debuginfo.sh script doesn't find files contains a $ character (inner classes). Al From tibbs at math.uh.edu Wed Jun 21 16:55:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 11:55:58 -0500 Subject: Some problems to packaging a java app In-Reply-To: <4ccd9dcb0606210925s3798caa8nb3e554b996fcafad@mail.gmail.com> (alcapcom@gmail.com's message of "Wed, 21 Jun 2006 18:25:26 +0200") References: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> <4ccd9dcb0606210925s3798caa8nb3e554b996fcafad@mail.gmail.com> Message-ID: >>>>> "a" == alcapcom writes: a> The work around solve the problem, but so as explained in the above a> ticket, find-debuginfo.sh script doesn't find files contains a $ a> character (inner classes). More accurately, it thinks it should be able to find files containing and named after inner classes even though such files don't exist. I believe you do get a useful debuginfo package out of it, although I haven't a clue as to how I would actually test that. - J< From i.pilcher at comcast.net Wed Jun 21 17:02:15 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 21 Jun 2006 12:02:15 -0500 Subject: Noob: Error tagging FC-5 branch In-Reply-To: References: Message-ID: Jason L Tibbitts III wrote: > That's the dist tag. You should always use it unless you know what > you're doing. Just append %{?dist} to the end of your Release:. ?Muchas gracias! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From alcapcom at gmail.com Wed Jun 21 18:06:52 2006 From: alcapcom at gmail.com (alcapcom) Date: Wed, 21 Jun 2006 20:06:52 +0200 Subject: Some problems to packaging a java app In-Reply-To: References: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> <4ccd9dcb0606210925s3798caa8nb3e554b996fcafad@mail.gmail.com> Message-ID: <4ccd9dcb0606211106u2eed6634jf4d79a01b65551ac@mail.gmail.com> > More accurately, it thinks it should be able to find files containing > and named after inner classes even though such files don't exist. It's well that. From roland at redhat.com Wed Jun 21 18:24:13 2006 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Jun 2006 11:24:13 -0700 (PDT) Subject: debuginfo on PPC platform In-Reply-To: Dawid Gajownik's message of Wednesday, 21 June 2006 09:27:58 +0200 <4498F4FE.2040100@gmail.com> Message-ID: <20060621182413.3347218004B@magilla.sf.frob.com> > extracting debug info from > /var/tmp/python-sqlite2-2.3.1-1.fc6-root-mockbuild/usr/lib/python2.4/site-packages/pysqlite2/_sqlite.so > cpio: gcc-4.1.1-20060612/obj-ppc64-redhat-linux/gcc/crtsavres.S: No such > file or directory > 281 blocks > > Does that mean that this debuginfo package will be useless? On FE5 there > is no such a warning [2]. I ask about it because I don't have access to > PPC machine and cannot test it. This only means that some source file was not found to put into the package. It doesn't mean the .debug files themselves had any problem. It's worth figuring out why this happened, but it's not a big deal. From chitlesh at fedoraproject.org Wed Jun 21 18:31:38 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Jun 2006 20:31:38 +0200 Subject: cpio: kdmtheme-1.1.2/src/: No such file or directory Message-ID: <13dbfe4f0606211131g245bd3cfk3f08ecb7bbcf97b3@mail.gmail.com> Helllo, its the second time Im having the same problem with cpio Im sure doing something wrong at some point or did grab something carefully. Can anyone point to me what it is ? I have 2 packages which Im building. - crystal - kdmtheme manager They build successfully and rpmlint does not complain. But on the konsole, i have kdmtheme: + desktop-file-install --vendor fedora --add-category X-Fedora --add-category System --delete-original --dir /var/tmp/kdmtheme-1.1.2-1-root-chitlesh/usr/share/applications/ /var/tmp/kdmtheme-1.1.2-1-root-chitlesh/usr/share/applications/kde/kdmtheme.desktop + /usr/lib/rpm/find-debuginfo.sh /home/chitlesh/rpmbuild/BUILD/kdmtheme-1.1.2 extracting debug info from /var/tmp/kdmtheme-1.1.2-1-root-chitlesh/usr/lib/kde3/kcm_kdmtheme.so cpio: kdmtheme-1.1.2/src/: No such file or directory 62 blocks + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + crystal: + /usr/lib/rpm/find-debuginfo.sh /home/chitlesh/rpmbuild/BUILD/crystal-1.0.0 extracting debug info from /var/tmp/crystal-1.0.0-1-root-chitlesh/usr/lib/kde3/kwin_crystal_config.so extracting debug info from /var/tmp/crystal-1.0.0-1-root-chitlesh/usr/lib/kde3/kwin3_crystal.so cpio: crystal-1.0.0/client/: No such file or directory cpio: crystal-1.0.0/client/config/: No such file or directory 1151 blocks + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip Chitlesh -- http://clunixchit.blogspot.com From ville.skytta at iki.fi Wed Jun 21 18:41:15 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 21 Jun 2006 21:41:15 +0300 Subject: Time to make Extras multi-lib? In-Reply-To: <1150900032.3850.3.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> Message-ID: <1150915275.7016.41.camel@localhost.localdomain> On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > I think the ideal way to handle this is to > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > packages available in the 64-bit tree as well. At the moment, this isn't > possible, It ain't pretty, but it's possible from the repo management POV, we already do copy i386 Wine packages + some dependencies over to the x86_64 repo as part of the signing/pushing process. See "copydict" at http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup From rdieter at math.unl.edu Wed Jun 21 18:43:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 13:43:24 -0500 Subject: cpio: kdmtheme-1.1.2/src/: No such file or directory References: <13dbfe4f0606211131g245bd3cfk3f08ecb7bbcf97b3@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Helllo, > its the second time Im having the same problem with cpio > > Im sure doing something wrong at some point or did grab something > carefully. Can anyone point to me what it is ? > > I have 2 packages which Im building. > - crystal > - kdmtheme manager > > They build successfully and rpmlint does not complain. IMO, no harm, no foul... no worries. (: -- Rex From ville.skytta at iki.fi Wed Jun 21 18:48:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 21 Jun 2006 21:48:08 +0300 Subject: Some problems to packaging a java app In-Reply-To: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> References: <4ccd9dcb0606210710o5932b983gc6f6784dc717ea3f@mail.gmail.com> Message-ID: <1150915688.7016.48.camel@localhost.localdomain> On Wed, 2006-06-21 at 16:10 +0200, alcapcom wrote: > - rpmlint give warning about "class-path-in-manifest" > which is the way of making for fedora-extra about classpatch. I'm not aware of Fedora specific guidelines for this, but at JPackage we removed all of them during the build, and let application launcher scripts etc take care of setting up the classpath. I suppose that would apply to Fedora too. From ville.skytta at iki.fi Wed Jun 21 18:50:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 21 Jun 2006 21:50:53 +0300 Subject: FE6 Buildsys Lockups In-Reply-To: <1150903620.2725.21.camel@localhost.localdomain> References: <4498C412.1020809@redhat.com> <4498D7EF.8080401@redhat.com> <44995E28.6090700@kobold.org> <1150903620.2725.21.camel@localhost.localdomain> Message-ID: <1150915853.7016.50.camel@localhost.localdomain> On Wed, 2006-06-21 at 11:27 -0400, Dan Williams wrote: > I just requeued xmms #9945, another sure buildhang; lets see how it > goes. Works, thanks. Actually it built just fine twice as I had some pending changes to the package :) From chitlesh at fedoraproject.org Wed Jun 21 18:52:12 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Jun 2006 20:52:12 +0200 Subject: cpio: kdmtheme-1.1.2/src/: No such file or directory In-Reply-To: References: <13dbfe4f0606211131g245bd3cfk3f08ecb7bbcf97b3@mail.gmail.com> Message-ID: <13dbfe4f0606211152r127ccb4bh8cf9029d67fdbe6b@mail.gmail.com> On 6/21/06, Rex Dieter wrote: > IMO, no harm, no foul... no worries. (: > Ok, Ill file them for review. -- http://clunixchit.blogspot.com From jwilson at redhat.com Wed Jun 21 18:59:19 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 21 Jun 2006 14:59:19 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1150915275.7016.41.camel@localhost.localdomain> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> Message-ID: <1150916359.3850.6.camel@xavier.boston.redhat.com> On Wed, 2006-06-21 at 21:41 +0300, Ville Skytt? wrote: > On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > > > I think the ideal way to handle this is to > > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > > packages available in the 64-bit tree as well. At the moment, this isn't > > possible, > > It ain't pretty, but it's possible from the repo management POV, we > already do copy i386 Wine packages + some dependencies over to the > x86_64 repo as part of the signing/pushing process. See "copydict" at > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup I suppose that would do as a workaround until something more like the ne algorithm used to determine what should be multilib in core gets implemented for extras as well... -- 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 chitlesh at fedoraproject.org Wed Jun 21 19:26:38 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Jun 2006 21:26:38 +0200 Subject: cpio: kdmtheme-1.1.2/src/: No such file or directory In-Reply-To: <13dbfe4f0606211152r127ccb4bh8cf9029d67fdbe6b@mail.gmail.com> References: <13dbfe4f0606211131g245bd3cfk3f08ecb7bbcf97b3@mail.gmail.com> <13dbfe4f0606211152r127ccb4bh8cf9029d67fdbe6b@mail.gmail.com> Message-ID: <13dbfe4f0606211226v2825910ex25f9b72e9f41688e@mail.gmail.com> On 6/21/06, Chitlesh GOORAH wrote: > Ok, Ill file them for review. Here they are https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196176 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196177 Chitlesh -- http://clunixchit.blogspot.com From sopwith at redhat.com Wed Jun 21 20:56:24 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 21 Jun 2006 16:56:24 -0400 Subject: Removing access for election nominees Message-ID: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> Hi all (especially Toshio, Warren, and Seth), I know we mentioned this for Toshio already, but... Unless there is any major objection, I'd like to remove the Fedora Infrastructure logins for skvidal, toshio, and wtogami during the Extras election (i.e. their shell accounts on the web servers and related systems). I don't think there will be any real problems from any of them as far as tampering, and it's not like this election has as much at stake as national parlimentary elections, but it seems like one way to avoid any unpleasantness down the road. Speak now or forever hold your peace. :) And if there's anyone else I missed who is in the sysadmin-main or sysadmin-web groups and nominated for FESCO, please let me know. Best, -- Elliot From wtogami at redhat.com Wed Jun 21 20:59:09 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Jun 2006 16:59:09 -0400 Subject: Removing access for election nominees In-Reply-To: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> References: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> Message-ID: <4499B31D.6010603@redhat.com> Elliot Lee wrote: > Hi all (especially Toshio, Warren, and Seth), > > I know we mentioned this for Toshio already, but... > > Unless there is any major objection, I'd like to remove the Fedora > Infrastructure logins for skvidal, toshio, and wtogami during the Extras > election (i.e. their shell accounts on the web servers and related > systems). I don't think there will be any real problems from any of them > as far as tampering, and it's not like this election has as much at > stake as national parlimentary elections, but it seems like one way to > avoid any unpleasantness down the road. > > Speak now or forever hold your peace. :) And if there's anyone else I > missed who is in the sysadmin-main or sysadmin-web groups and nominated > for FESCO, please let me know. Does this mean I can't login to cvs.fedora? I need to do work there on a daily basis. Warren From toshio at tiki-lounge.com Wed Jun 21 21:20:17 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 21 Jun 2006 14:20:17 -0700 Subject: Removing access for election nominees In-Reply-To: <1150923939.15457.11.camel@cutter> References: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> <1150923939.15457.11.camel@cutter> Message-ID: <1150924817.3227.26.camel@localhost> On Wed, 2006-06-21 at 17:05 -0400, seth vidal wrote: > So I won't be able to login to push packages on extras64/buildsys for 2 > weeks? > > I'm not pushing pkgs often right now but this seems a bit stupid. > > How about just keeping us off of the system that has the election stuff > and let the builders alone. Those systems would be app1, app2, and access to the elections and accounts databases on db1. -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 tibbs at math.uh.edu Wed Jun 21 22:31:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 21 Jun 2006 17:31:36 -0500 Subject: Removing access for election nominees In-Reply-To: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> (Elliot Lee's message of "Wed, 21 Jun 2006 16:56:24 -0400") References: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> Message-ID: >>>>> "EL" == Elliot Lee writes: EL> Unless there is any major objection, I'd like to remove the Fedora EL> Infrastructure logins for skvidal, toshio, and wtogami during the EL> Extras election Surely I can't be alone in thinking that this is excessive. We must already trust these people, and certainly don't trust them any less than the other people who will retain their access to that machine. - J< From chris.stone at gmail.com Thu Jun 22 01:26:57 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 Jun 2006 18:26:57 -0700 Subject: mock is no longer working for me Message-ID: I upgraded mock today and now it is no longer working. The config files have for the [groups] repository: [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/5/x86_64/ But there is no such URL present on this server... From skvidal at linux.duke.edu Thu Jun 22 01:53:10 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Jun 2006 21:53:10 -0400 Subject: mock is no longer working for me In-Reply-To: References: Message-ID: <1150941191.15457.12.camel@cutter> On Wed, 2006-06-21 at 18:26 -0700, Christopher Stone wrote: > I upgraded mock today and now it is no longer working. The config > files have for the [groups] repository: > > [groups] > name=groups > baseurl=http://buildsys.fedoraproject.org/buildgroups/5/x86_64/ > > But there is no such URL present on this server... fixed - symlink following was off for that directory. -sv From chris.stone at gmail.com Thu Jun 22 03:11:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 Jun 2006 20:11:26 -0700 Subject: mock is no longer working for me In-Reply-To: <1150941191.15457.12.camel@cutter> References: <1150941191.15457.12.camel@cutter> Message-ID: On 6/21/06, seth vidal wrote: > On Wed, 2006-06-21 at 18:26 -0700, Christopher Stone wrote: > > I upgraded mock today and now it is no longer working. The config > > files have for the [groups] repository: > > > > [groups] > > name=groups > > baseurl=http://buildsys.fedoraproject.org/buildgroups/5/x86_64/ > > > > But there is no such URL present on this server... > > fixed - symlink following was off for that directory. okay thanks, but mock takes forever now. It seems my squid cache is no longer working, is this because the mock configs are using mirrorlists now? Why bother with the mirrorlists if its going to take ages every time you run mock? From skvidal at linux.duke.edu Thu Jun 22 03:37:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Jun 2006 23:37:30 -0400 Subject: mock is no longer working for me In-Reply-To: References: <1150941191.15457.12.camel@cutter> Message-ID: <1150947450.15457.20.camel@cutter> On Wed, 2006-06-21 at 20:11 -0700, Christopher Stone wrote: > On 6/21/06, seth vidal wrote: > > On Wed, 2006-06-21 at 18:26 -0700, Christopher Stone wrote: > > > I upgraded mock today and now it is no longer working. The config > > > files have for the [groups] repository: > > > > > > [groups] > > > name=groups > > > baseurl=http://buildsys.fedoraproject.org/buildgroups/5/x86_64/ > > > > > > But there is no such URL present on this server... > > > > fixed - symlink following was off for that directory. > > okay thanks, but mock takes forever now. It seems my squid cache is > no longer working, is this because the mock configs are using > mirrorlists now? Why bother with the mirrorlists if its going to take > ages every time you run mock? We bother with the mirrorlists b/c using the mirrors speed up for a lot of folks who are not using proxies. You can change your configs all you want. So just use the baseurls you want instead of mirrorlists. -sv From j.w.r.degoede at hhs.nl Thu Jun 22 05:20:40 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Jun 2006 07:20:40 +0200 Subject: Removing access for election nominees In-Reply-To: References: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> Message-ID: <449A28A8.8070006@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "EL" == Elliot Lee writes: > > EL> Unless there is any major objection, I'd like to remove the Fedora > EL> Infrastructure logins for skvidal, toshio, and wtogami during the > EL> Extras election > > Surely I can't be alone in thinking that this is excessive. We must > already trust these people, and certainly don't trust them any less > than the other people who will retain their access to that machine. > Exactly what I was thinking but I was too tired yesterday evening to type anything about this, +1 . Regards, Hans From eric.tanguy at univ-nantes.fr Thu Jun 22 05:39:44 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 22 Jun 2006 07:39:44 +0200 Subject: new mock package Message-ID: <1150954784.2562.0.camel@bureau.maison> Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : init clean prep This may take a while Could not find useradd in chroot, maybe the install failed? ending done What is the problem ? Eric From seg at haxxed.com Thu Jun 22 06:18:40 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 01:18:40 -0500 Subject: Packing audacious - Funny plugins In-Reply-To: <20060619201449.76afb9a3@nausicaa.camperquake.de> References: <20060619201449.76afb9a3@nausicaa.camperquake.de> Message-ID: <1150957121.14729.10.camel@localhost> On Mon, 2006-06-19 at 20:14 +0200, Ralf Ertzinger wrote: > spc, ndf, gbs [Console sound files] (Unsure) > psf [PSX sound files] (Unsure) As long as the player itself doesn't include any copyrighted ROM code, and there's no patent problems with emulating the hardware, I would think these would be okay. (They work the same way .sid does, a minimal emulation of the platform, enough to play music.) Obviously the files it plays can have copyright problems, but that applies to most everything. (ogg, mp3, jpegs, web pages, pdfs...) > adlib (Unsure) Is this based on adplug? Because that recently made it into Extras. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Jun 22 06:37:31 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Jun 2006 08:37:31 +0200 Subject: Packing audacious - Funny plugins In-Reply-To: <1150957121.14729.10.camel@localhost> References: <20060619201449.76afb9a3@nausicaa.camperquake.de> <1150957121.14729.10.camel@localhost> Message-ID: <1150958252.10251.33.camel@mccallum.corsepiu.local> On Thu, 2006-06-22 at 01:18 -0500, Callum Lerwick wrote: > On Mon, 2006-06-19 at 20:14 +0200, Ralf Ertzinger wrote: > > spc, ndf, gbs [Console sound files] (Unsure) > > psf [PSX sound files] (Unsure) > > As long as the player itself doesn't include any copyrighted ROM code, You are mixing up copyright and license. ... unless the license being applied ... complies to FE conventions .... probably is what you had wanted to express. Ralf From paul at city-fan.org Thu Jun 22 07:13:45 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 Jun 2006 08:13:45 +0100 Subject: new mock package In-Reply-To: <1150954784.2562.0.camel@bureau.maison> References: <1150954784.2562.0.camel@bureau.maison> Message-ID: <1150960426.14748.14.camel@laurel.intra.city-fan.org> On Thu, 2006-06-22 at 07:39 +0200, Eric Tanguy wrote: > Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : > init > clean > prep > This may take a while > Could not find useradd in chroot, maybe the install failed? > ending > done > > What is the problem ? Look in your root.log and try to figure out why shadow-utils (a dependency of rpm) didn't get installed. Paul. From paul at city-fan.org Thu Jun 22 07:41:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 Jun 2006 08:41:19 +0100 Subject: new mock package In-Reply-To: <1150954784.2562.0.camel@bureau.maison> References: <1150954784.2562.0.camel@bureau.maison> Message-ID: <1150962079.14748.23.camel@laurel.intra.city-fan.org> On Thu, 2006-06-22 at 07:39 +0200, Eric Tanguy wrote: > Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : > init > clean > prep > This may take a while > Could not find useradd in chroot, maybe the install failed? > ending > done > > What is the problem ? Just seen this here for an FC4 target. My guess is that you're still using a mock config file from the old mock package, and you haven't looked at the changes in the .rpmnew config files in /etc/mock. Pay particular attention to config_opts['chroot_setup_cmd'] (inherited from defaults.cfg); if you have a local "groups" repo, you'll need to rebuild it to include a buildsys-build package, like the one at http://buildsys.fedoraproject.org/buildgroups/4/i386/ And for FC4, you'll probably want: config_opts['chroot_setup_cmd'] = 'install buildsys-build elfutils' for useful debuginfo packages. Paul. From chris.stone at gmail.com Thu Jun 22 07:42:07 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 22 Jun 2006 00:42:07 -0700 Subject: pkgconfig question Message-ID: If an rpm contains a .pc file and is otherwise noarch, does the fact that it has a .pc file automatically make it unqualified as a noarch package? noarch packages will put the .pc file under /usr/lib/pkgconfig which does not work so well on 64bit arches with /usr/lib64/pkgconfig Additionally, I noticed that the gtk2-engines rpm owns %{_libdir}/pkgconfig/ directory. Shouldn't this directory be owned by the pkgconfig package? It seems this goes against packaging guidelines. From seg at haxxed.com Thu Jun 22 08:20:44 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 03:20:44 -0500 Subject: Packing audacious - Funny plugins In-Reply-To: <1150958252.10251.33.camel@mccallum.corsepiu.local> References: <20060619201449.76afb9a3@nausicaa.camperquake.de> <1150957121.14729.10.camel@localhost> <1150958252.10251.33.camel@mccallum.corsepiu.local> Message-ID: <1150964445.14729.25.camel@localhost> On Thu, 2006-06-22 at 08:37 +0200, Ralf Corsepius wrote: > > As long as the player itself doesn't include any copyrighted ROM code, > You are mixing up copyright and license. D'oh. Make that "Non-redistributable ROM code" maybe. In my quick glance through the code, I see no binary blobs. The PSF player has a re-implemented Playstation BIOS in it, thunked to native code, and seems to contain mostly basic C library stuff. My guess is this is clean. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Jun 22 08:33:51 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 03:33:51 -0500 Subject: New mock package coming out soon In-Reply-To: <1150907039.10251.9.camel@mccallum.corsepiu.local> References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> <1150902508.11582.51.camel@cutter> <1150907039.10251.9.camel@mccallum.corsepiu.local> Message-ID: <1150965232.14729.29.camel@localhost> On Wed, 2006-06-21 at 18:23 +0200, Ralf Corsepius wrote: > On Wed, 2006-06-21 at 10:51 -0500, Jason L Tibbitts III wrote: > > >>>>> "sv" == seth vidal writes: > > > > sv> that package is already in the buildgroups location at: > > > > sv> http://buildsys.fedoraproject.org/buildgroups/ > > > > Hmm, I've been running all this time using no external repositories > > (just my local mirror). > I never understood why this isn't packaged into a "fedora-mock-config > rpm" or the like. I've actually been meaning to ask for the mock configs in /etc/mock to be split off into a separate package so they can be easily overridden, much like what has recently been happening with yum/apt/smart configs. Not sure you'd want the buildroots mixed in with that. Maybe use a third package for that... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Jun 22 08:38:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Jun 2006 10:38:12 +0200 Subject: New mock package coming out soon In-Reply-To: <1150965232.14729.29.camel@localhost> References: <1150843308.18766.29.camel@dhcp83-49.boston.redhat.com> <1150852885.6680.1.camel@aglarond.local> <1150902508.11582.51.camel@cutter> <1150907039.10251.9.camel@mccallum.corsepiu.local> <1150965232.14729.29.camel@localhost> Message-ID: <1150965492.10251.86.camel@mccallum.corsepiu.local> On Thu, 2006-06-22 at 03:33 -0500, Callum Lerwick wrote: > On Wed, 2006-06-21 at 18:23 +0200, Ralf Corsepius wrote: > > On Wed, 2006-06-21 at 10:51 -0500, Jason L Tibbitts III wrote: > > > >>>>> "sv" == seth vidal writes: > > > > > > sv> that package is already in the buildgroups location at: > > > > > > sv> http://buildsys.fedoraproject.org/buildgroups/ > > > > > > Hmm, I've been running all this time using no external repositories > > > (just my local mirror). > > I never understood why this isn't packaged into a "fedora-mock-config > > rpm" or the like. > > I've actually been meaning to ask for the mock configs in /etc/mock to > be split off into a separate package so they can be easily overridden, > much like what has recently been happening with yum/apt/smart configs. +1. These are not of much use for local usage. > Not sure you'd want the buildroots mixed in with that. Maybe use a third > package for that... Exactly. One for the actual mock, one for the buildroots and one for /etc/mock/*.cfg Ralf From seg at haxxed.com Thu Jun 22 08:48:18 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 03:48:18 -0500 Subject: Removing access for election nominees In-Reply-To: References: <8EEDCC20-DF43-4D9C-85F6-5720E2368A31@redhat.com> Message-ID: <1150966099.14729.35.camel@localhost> On Wed, 2006-06-21 at 17:31 -0500, Jason L Tibbitts III wrote: > >>>>> "EL" == Elliot Lee writes: > > EL> Unless there is any major objection, I'd like to remove the Fedora > EL> Infrastructure logins for skvidal, toshio, and wtogami during the > EL> Extras election > > Surely I can't be alone in thinking that this is excessive. We must > already trust these people, and certainly don't trust them any less > than the other people who will retain their access to that machine. Running the elections on a completely isolated machine might not be a bad idea, but removing access to things not directly related to the election system is a bit broken and excessive, yes. -------------- 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 gilboad at gmail.com Thu Jun 22 09:27:03 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 22 Jun 2006 12:27:03 +0300 Subject: Time to make Extras multi-lib? In-Reply-To: <1150916359.3850.6.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> Message-ID: <1150968423.6721.19.camel@gilboa-work-dev> On Wed, 2006-06-21 at 14:59 -0400, Jarod Wilson wrote: > On Wed, 2006-06-21 at 21:41 +0300, Ville Skytt? wrote: > > On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > > > > > I think the ideal way to handle this is to > > > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > > > packages available in the 64-bit tree as well. At the moment, this isn't > > > possible, > > > > It ain't pretty, but it's possible from the repo management POV, we > > already do copy i386 Wine packages + some dependencies over to the > > x86_64 repo as part of the signing/pushing process. See "copydict" at > > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup > > I suppose that would do as a workaround until something more like the ne > algorithm used to determine what should be multilib in core gets > implemented for extras as well... > At least for now, IMHO Wine and SDL are the most important bits. (Both required to run proprietary i386 software [games :-)] ). Gilboa From chitlesh at fedoraproject.org Thu Jun 22 08:50:49 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 22 Jun 2006 10:50:49 +0200 Subject: cpio: kdmtheme-1.1.2/src/: No such file or directory In-Reply-To: <13dbfe4f0606211226v2825910ex25f9b72e9f41688e@mail.gmail.com> References: <13dbfe4f0606211131g245bd3cfk3f08ecb7bbcf97b3@mail.gmail.com> <13dbfe4f0606211152r127ccb4bh8cf9029d67fdbe6b@mail.gmail.com> <13dbfe4f0606211226v2825910ex25f9b72e9f41688e@mail.gmail.com> Message-ID: <13dbfe4f0606220150ve600c29jac2a0381be53a578@mail.gmail.com> The more I package, the more I fall on this cpio thing: extracting debug info from /var/tmp/katapult-0.3.1.3-1-root-chitlesh/usr/lib/kde3/katapult_calculatorcatalog.so extracting debug info from /var/tmp/katapult-0.3.1.3-1-root-chitlesh/usr/lib/kde3/katapult_glassdisplay.so extracting debug info from /var/tmp/katapult-0.3.1.3-1-root-chitlesh/usr/lib/libkatapultcatalog.so.1.0.0 extracting debug info from /var/tmp/katapult-0.3.1.3-1-root-chitlesh/usr/lib/libkatapultdisplay.so.1.0.0 extracting debug info from /var/tmp/katapult-0.3.1.3-1-root-chitlesh/usr/lib/libkatapult.so.1.0.0 cpio: katapult-0.3.1.3/katapult/common/: No such file or directory cpio: katapult-0.3.1.3/katapult/katapult/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/amarokcatalog/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/bookmarkcatalog/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/calculatorcatalog/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/calculatorcatalog/plugins/catalogs/calculatorcatalog/parser.cpp: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/calculatorcatalog/plugins/catalogs/calculatorcatalog/parser.y: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/documentcatalog/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/catalogs/programcatalog/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/display/glassdisplay/: No such file or directory cpio: katapult-0.3.1.3/katapult/plugins/display/puredisplay/: No such file or directory -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Thu Jun 22 10:49:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Jun 2006 12:49:15 +0200 Subject: pkgconfig question In-Reply-To: References: Message-ID: <20060622124915.ac229dd8.bugs.michael@gmx.net> On Thu, 22 Jun 2006 00:42:07 -0700, Christopher Stone wrote: > If an rpm contains a .pc file and is otherwise noarch, does the fact > that it has a .pc file automatically make it unqualified as a noarch > package? No. > noarch packages will put the .pc file under /usr/lib/pkgconfig which > does not work so well on 64bit arches with /usr/lib64/pkgconfig A noarch .pc file must go be stored in /usr/share/pkgconfig > Additionally, I noticed that the gtk2-engines rpm owns > %{_libdir}/pkgconfig/ directory. Shouldn't this directory be owned by > the pkgconfig package? It seems this goes against packaging > guidelines. Preferably it would "Requires: pkgconfig" and not own that directory. But if it doesn't require pkgconfig an doesn't own the directory either, the directory would become an orphan. Hence some packagers include such directories, so it gets installed and remove correctly. This applies to all directories, which don't belong into any filesystem core package and which are optional dependencies. From bugs.michael at gmx.net Thu Jun 22 10:55:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Jun 2006 12:55:51 +0200 Subject: Time to make Extras multi-lib? In-Reply-To: <1150916359.3850.6.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> Message-ID: <20060622125551.a1ddadd0.bugs.michael@gmx.net> On Wed, 21 Jun 2006 14:59:19 -0400, Jarod Wilson wrote: > On Wed, 2006-06-21 at 21:41 +0300, Ville Skytt? wrote: > > On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > > > > > I think the ideal way to handle this is to > > > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > > > packages available in the 64-bit tree as well. At the moment, this isn't > > > possible, > > > > It ain't pretty, but it's possible from the repo management POV, we > > already do copy i386 Wine packages + some dependencies over to the > > x86_64 repo as part of the signing/pushing process. See "copydict" at > > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup > > I suppose that would do as a workaround until something more like the ne > algorithm used to determine what should be multilib in core gets > implemented for extras as well... Is that algorithm documented anywhere? Is discussion about it taking place on a public mailing-list? (if so, I'm failing to follow the right traffic) From chris.stone at gmail.com Thu Jun 22 11:13:37 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 22 Jun 2006 04:13:37 -0700 Subject: pkgconfig question In-Reply-To: <20060622124915.ac229dd8.bugs.michael@gmx.net> References: <20060622124915.ac229dd8.bugs.michael@gmx.net> Message-ID: On 6/22/06, Michael Schwendt wrote: > On Thu, 22 Jun 2006 00:42:07 -0700, Christopher Stone wrote: > > noarch packages will put the .pc file under /usr/lib/pkgconfig which > > does not work so well on 64bit arches with /usr/lib64/pkgconfig > > A noarch .pc file must go be stored in /usr/share/pkgconfig Ah yes ofcourse! I will patch my packages Makefile.in file to put the .pc file in datadir. I've informed upstream and they are making the change. Thanks for the info. From katzj at redhat.com Thu Jun 22 12:09:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Jun 2006 08:09:47 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <20060622125551.a1ddadd0.bugs.michael@gmx.net> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> Message-ID: <1150978187.2714.3.camel@aglarond.local> On Thu, 2006-06-22 at 12:55 +0200, Michael Schwendt wrote: > On Wed, 21 Jun 2006 14:59:19 -0400, Jarod Wilson wrote: > > On Wed, 2006-06-21 at 21:41 +0300, Ville Skytt? wrote: > > > On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > > > > > > > I think the ideal way to handle this is to > > > > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > > > > packages available in the 64-bit tree as well. At the moment, this isn't > > > > possible, > > > > > > It ain't pretty, but it's possible from the repo management POV, we > > > already do copy i386 Wine packages + some dependencies over to the > > > x86_64 repo as part of the signing/pushing process. See "copydict" at > > > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup > > > > I suppose that would do as a workaround until something more like the ne > > algorithm used to determine what should be multilib in core gets > > implemented for extras as well... > > Is that algorithm documented anywhere? The basics of it were discussed in the thread on fedora-maintainers from last month titled "Improving the way we select multilib packages for trees". Jeremy From Axel.Thimm at ATrpms.net Thu Jun 22 12:21:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 22 Jun 2006 14:21:30 +0200 Subject: Time to make Extras multi-lib? In-Reply-To: <20060622125551.a1ddadd0.bugs.michael@gmx.net> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> Message-ID: <20060622122130.GC17779@neu.nirvana> On Thu, Jun 22, 2006 at 12:55:51PM +0200, Michael Schwendt wrote: > On Wed, 21 Jun 2006 14:59:19 -0400, Jarod Wilson wrote: > > > On Wed, 2006-06-21 at 21:41 +0300, Ville Skytt? wrote: > > > On Wed, 2006-06-21 at 10:27 -0400, Jarod Wilson wrote: > > > > > > > I think the ideal way to handle this is to > > > > build only 64-bit on 64-bit, 32-bit on 32-bit, but make the 32-bit > > > > packages available in the 64-bit tree as well. At the moment, this isn't > > > > possible, > > > > > > It ain't pretty, but it's possible from the repo management POV, we > > > already do copy i386 Wine packages + some dependencies over to the > > > x86_64 repo as part of the signing/pushing process. See "copydict" at > > > http://cvs.fedora.redhat.com/viewcvs/extras-buildsys/utils/extras-sign-move.py?root=fedora&rev=.&view=markup > > > > I suppose that would do as a workaround until something more like the ne > > algorithm used to determine what should be multilib in core gets > > implemented for extras as well... > > Is that algorithm documented anywhere? I think there are two possible approaches: o Minimal ("application POV"): only what doesn't natively run: This algorithm should start with a simple manual decision of what top-level packages to pull to 64 bits at all (including such not existing in Fedora space, e.g. ISV products), and then pull in all run-time dependencies, too. o Full compat bloat ("lib POV"): In addition to the above approach, one would blindly copy every lib containing package over. Until now FC had been following more the former method, but from the comments in this thread it sounds like the bloat-lib method might be in discussion. Within ATrpms I've been manually marking a few packages considered multilib-sensible and have been automatically pulling in their dependencies too. That looks like the smallest effort needed and possibly easy to deploy in fedora extras' repo compilation setup. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Jun 22 12:52:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Jun 2006 07:52:28 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150980748.26810.4.camel@weaponx.rchland.ibm.com> On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > The actual election will start on Thursday, 22 June 0:01 UTC and will > last until Sunday, 02 July 23:59 UTC. The results will be posted to this The election has started. Get out there and vote for your next FESCo! josh From jwboyer at jdub.homelinux.org Thu Jun 22 12:59:03 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Jun 2006 07:59:03 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150980748.26810.4.camel@weaponx.rchland.ibm.com> References: <1150657448.2210.26.camel@localhost.localdomain> <1150980748.26810.4.camel@weaponx.rchland.ibm.com> Message-ID: <1150981143.26810.6.camel@weaponx.rchland.ibm.com> On Thu, 2006-06-22 at 07:52 -0500, Josh Boyer wrote: > On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > > > The actual election will start on Thursday, 22 June 0:01 UTC and will > > last until Sunday, 02 July 23:59 UTC. The results will be posted to this > > The election has started. Get out there and vote for your next FESCo! With "there" being: https://admin.fedoraproject.org/voting/vote.cgi josh From mclasen at redhat.com Thu Jun 22 13:26:24 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 22 Jun 2006 09:26:24 -0400 Subject: pkgconfig question In-Reply-To: References: Message-ID: <1150982784.2966.8.camel@localhost.localdomain> On Thu, 2006-06-22 at 00:42 -0700, Christopher Stone wrote: > If an rpm contains a .pc file and is otherwise noarch, does the fact > that it has a .pc file automatically make it unqualified as a noarch > package? > > noarch packages will put the .pc file under /usr/lib/pkgconfig which > does not work so well on 64bit arches with /usr/lib64/pkgconfig > > Additionally, I noticed that the gtk2-engines rpm owns > %{_libdir}/pkgconfig/ directory. Shouldn't this directory be owned by > the pkgconfig package? It seems this goes against packaging > guidelines. > Truely arch-independent .pc files should be installed in /usr/share/pkgconfig. Can you file a pkgconfig bug about the directory ownership issue, please ? From Christian.Iseli at licr.org Thu Jun 22 14:35:56 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 22 Jun 2006 16:35:56 +0200 Subject: FE Package Status of Jun 22, 2006 Message-ID: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> Hi folks, Here is the newest batch. I have updated the script to directly grab the needed info from the BZ server. It seems to work just fine and makes things quite a bit easier to generate those reports. I have also tried to reduce the noise in the "packages not available in extras devel or release" section... There's a couple funnies in the "dropped from extras" section (CVS and README, at least). BTW, shouldn't kimdaba and php-apc be removed from CVS ? Don't hesitate to send comments... Cheers, Christian ---- FE Package Status of Jun 22, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1894 packages - 38 orphans - 32 packages not available in extras devel or release cgoorah at yahoo dot com dot au kadischi danken at cs dot technion dot ac dot il tetex-fonts-hebrew davidhart at tqmcube dot com leafnode fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon i dot pilcher at comcast dot net wifi-radar icon at fedoraproject dot org yaz ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-WWW-Bugzilla jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin jwilson at redhat dot com conman matteo dot ricchetti at libero dot it ss5 matthias at rpmforge dot net fillets-ng-data-cs michael at knox dot net dot nz gdk-pixbuf notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard paul at all-the-johnsons dot co dot uk CastPodder redhat-bugzilla at linuxnetz dot de eggdrop spr at astrax dot fis dot ucm dot es xpa tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com iiimf-le-simplehangul - 7 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep dakingun at gmail dot com baobab noa at resare dot com vorbisgain wart at kobold dot org manaworld zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 4 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=189375,195292 Maelstrom notting at redhat.com Openbox peter at thecodergeek.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=165689,184080 SquidGuard oliver at linux-kernel.at webmin jvdias at redhat.com - 1 packages present in the development repo which have no owners entry php-apc - 2 orphaned packages, yet available in extras devel gtkglarea2 soundtracker - 39 packages that moved to core Packages appearing both in Core and Extras: - 1 packages duplicated for devel: petersen at redhat dot com scim-bridge FE-ACCEPT packages stats: - 951 accepted, closed package reviews - 7 accepted, closed package reviews not in repo - 1 accepted, closed package reviews not in owners - 10 accepted, open package reviews older than 4 weeks; - 6 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 97 open tickets - 24 tickets with no activity in eight weeks - 14 tickets with no activity in four weeks - 2 closed tickets FE-NEW packages stats: - 177 open tickets - 20 tickets with no activity in eight weeks - 45 tickets with no activity in four weeks - 1 closed tickets FE-NEEDSPONSOR packages stats: - 32 open tickets - 9 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 209 open tickets - 145 tickets with no activity in eight weeks - 18 tickets with no activity in four weeks CVS stats: - 1857 packages with a devel directory - 7 packages with no owners entry initng kile-i18n kimdaba muse pcb perl-Maypole php-apc - 1 packages in CVS devel *and* Core libevent - 101 packages were dropped from extras Maintainers stats: - 204 maintainers - 14 inactive maintainers with open bugs - 25 inactive maintainers Dropped FC packages: - 259 packages were dropped from core since FC 1 From seg at haxxed.com Thu Jun 22 16:54:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 11:54:49 -0500 Subject: Time to make Extras multi-lib? In-Reply-To: <20060622122130.GC17779@neu.nirvana> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> Message-ID: <1150995289.14729.46.camel@localhost> On Thu, 2006-06-22 at 14:21 +0200, Axel Thimm wrote: > o Minimal ("application POV"): only what doesn't natively run: > > This algorithm should start with a simple manual decision of what > top-level packages to pull to 64 bits at all (including such not > existing in Fedora space, e.g. ISV products), and then pull in all > run-time dependencies, too. > > o Full compat bloat ("lib POV"): In addition to the above approach, > one would blindly copy every lib containing package over. Yeah I'm somewhat confused as to what the goal is. In the case of x86_64, IMHO multilib exists only for legacy compatability, (Mostly, for running Wine, and maybe flash...) and in the long run, 32bit needs to die die die. Thus the minimal approach makes sense here. But the situation on other platforms is much different. PPC64 runs a mostly 32bit userspace. Apparently PPC64 is better off with 32bit software in the majority of cases. Conflicting needs! Fun! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu Jun 22 17:05:53 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Jun 2006 13:05:53 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1150995289.14729.46.camel@localhost> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> Message-ID: <1150995953.3424.1.camel@aglarond.local> On Thu, 2006-06-22 at 11:54 -0500, Callum Lerwick wrote: > On Thu, 2006-06-22 at 14:21 +0200, Axel Thimm wrote: > > o Minimal ("application POV"): only what doesn't natively run: > > > > This algorithm should start with a simple manual decision of what > > top-level packages to pull to 64 bits at all (including such not > > existing in Fedora space, e.g. ISV products), and then pull in all > > run-time dependencies, too. > > > > o Full compat bloat ("lib POV"): In addition to the above approach, > > one would blindly copy every lib containing package over. > > Yeah I'm somewhat confused as to what the goal is. In the case of > x86_64, IMHO multilib exists only for legacy compatability, (Mostly, for > running Wine, and maybe flash...) and in the long run, 32bit needs to > die die die. Thus the minimal approach makes sense here. Except that people want to be able to continue to run older apps. The 32-bit compatibility is the primary thing that makes migration to x86_64 far easier than another arch (such as ppc or ia64). While originally I was a proponent of the minimal approach, a few years of experience have me changing my mind about what's desired Jeremy From eric.tanguy at univ-nantes.fr Thu Jun 22 18:37:58 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 22 Jun 2006 20:37:58 +0200 Subject: new mock package In-Reply-To: <1150960426.14748.14.camel@laurel.intra.city-fan.org> References: <1150954784.2562.0.camel@bureau.maison> <1150960426.14748.14.camel@laurel.intra.city-fan.org> Message-ID: <1151001478.2794.2.camel@bureau.maison> Le jeudi 22 juin 2006 ? 08:13 +0100, Paul Howarth a ?crit : > On Thu, 2006-06-22 at 07:39 +0200, Eric Tanguy wrote: > > Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : > > init > > clean > > prep > > This may take a while > > Could not find useradd in chroot, maybe the install failed? > > ending > > done > > > > What is the problem ? > > Look in your root.log and try to figure out why shadow-utils (a > dependency of rpm) didn't get installed. > > Paul. > Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root install buildsys-build No Match for argument: buildsys-build Eric From jwilson at redhat.com Thu Jun 22 19:27:02 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 22 Jun 2006 15:27:02 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1150995953.3424.1.camel@aglarond.local> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> Message-ID: <1151004422.2976.12.camel@xavier.boston.redhat.com> On Thu, 2006-06-22 at 13:05 -0400, Jeremy Katz wrote: > On Thu, 2006-06-22 at 11:54 -0500, Callum Lerwick wrote: > > On Thu, 2006-06-22 at 14:21 +0200, Axel Thimm wrote: > > > o Minimal ("application POV"): only what doesn't natively run: > > > > > > This algorithm should start with a simple manual decision of what > > > top-level packages to pull to 64 bits at all (including such not > > > existing in Fedora space, e.g. ISV products), and then pull in all > > > run-time dependencies, too. > > > > > > o Full compat bloat ("lib POV"): In addition to the above approach, > > > one would blindly copy every lib containing package over. > > > > Yeah I'm somewhat confused as to what the goal is. In the case of > > x86_64, IMHO multilib exists only for legacy compatability, (Mostly, for > > running Wine, and maybe flash...) and in the long run, 32bit needs to > > die die die. Thus the minimal approach makes sense here. > > Except that people want to be able to continue to run older apps. The > 32-bit compatibility is the primary thing that makes migration to x86_64 > far easier than another arch (such as ppc or ia64). While originally I > was a proponent of the minimal approach, a few years of experience have > me changing my mind about what's desired +1. Making all possible i386 bits available in the x86_64 tree does nothing to hurt folks who want pure x86_64 -- they simply don't install any of the i386 bits (or only the bits they want). At the same time, it makes life much easier for those who need i386 libxyz for whatever reason, be that some app that is still only 32-bit, for 32-bit development, or what have you (remember, a fairly significant part of the user base is still 32-bit). Neither the folks who want pure 64-bit or the folks who want the full-b(l)oat lose here. The minimal approach suits the people who want pure 64-bit more, but leaves the other (loose) grouping of people out in the cold, having to manually suck bits from the i386 tree. -- 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 nicolas.mailhot at laposte.net Thu Jun 22 19:48:19 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 Jun 2006 21:48:19 +0200 Subject: Time to make Extras multi-lib? In-Reply-To: <1151004422.2976.12.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> <1151004422.2976.12.camel@xavier.boston.redhat.com> Message-ID: <1151005699.2720.4.camel@rousalka.dyndns.org> Le jeudi 22 juin 2006 ? 15:27 -0400, Jarod Wilson a ?crit : > +1. Making all possible i386 bits available in the x86_64 tree does > nothing to hurt folks who want pure x86_64 Unfortunately, that's not true. If you do full mixing it's all too easy to start relying on the 386 bits. How many developers will run a pure 64bit system and check it works ? > The minimal approach suits the people who want > pure 64-bit more, but leaves the other (loose) grouping of people out in > the cold, having to manually suck bits from the i386 tree. Speaking as one of the current i386 suckers, but with no illusions on the full mixing consequences -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From michael at knox.net.nz Thu Jun 22 19:54:17 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 23 Jun 2006 07:54:17 +1200 Subject: new mock package In-Reply-To: <1151001478.2794.2.camel@bureau.maison> References: <1150954784.2562.0.camel@bureau.maison> <1150960426.14748.14.camel@laurel.intra.city-fan.org> <1151001478.2794.2.camel@bureau.maison> Message-ID: <449AF569.5050409@knox.net.nz> Eric Tanguy wrote: > Le jeudi 22 juin 2006 ? 08:13 +0100, Paul Howarth a ?crit : > >>On Thu, 2006-06-22 at 07:39 +0200, Eric Tanguy wrote: >> >>>Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : >>>init >>>clean >>>prep >>>This may take a while >>>Could not find useradd in chroot, maybe the install failed? >>>ending >>>done >>> >>>What is the problem ? >> >>Look in your root.log and try to figure out why shadow-utils (a >>dependency of rpm) didn't get installed. >> >>Paul. >> > > Executing /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-development-i386-core/root install > buildsys-build > No Match for argument: buildsys-build > > Eric > > I am not sure the differnce, but in the /etc/mock/defaults.cfg file there are two lines that look like this: config_opts['chroot_setup_cmd'] = 'install buildsys-build' #config_opts['chroot_setup_cmd'] = 'groupinstall build' I made it look like: #config_opts['chroot_setup_cmd'] = 'install buildsys-build' config_opts['chroot_setup_cmd'] = 'groupinstall build' And my mock setup is working again..... Michael From seg at haxxed.com Thu Jun 22 20:08:35 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 22 Jun 2006 15:08:35 -0500 Subject: Time to make Extras multi-lib? In-Reply-To: <1150995953.3424.1.camel@aglarond.local> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> Message-ID: <1151006915.14729.56.camel@localhost> On Thu, 2006-06-22 at 13:05 -0400, Jeremy Katz wrote: > Except that people want to be able to continue to run older apps. The > 32-bit compatibility is the primary thing that makes migration to x86_64 > far easier than another arch (such as ppc or ia64). While originally I > was a proponent of the minimal approach, a few years of experience have > me changing my mind about what's desired I thought that's what I said. Older apps. Legacy. And generally, closed source apps. If it were open source, it would be compiled 64bit, unless the source is really really broken. (WTF is with nx, anyway? Supposedly OpenOffice is at least getting close to 64bit clean...) Developing for i386 on x86_64 is another matter, which really seems better served by a chroot environment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Thu Jun 22 20:28:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 Jun 2006 21:28:57 +0100 Subject: new mock package In-Reply-To: <449AF569.5050409@knox.net.nz> References: <1150954784.2562.0.camel@bureau.maison> <1150960426.14748.14.camel@laurel.intra.city-fan.org> <1151001478.2794.2.camel@bureau.maison> <449AF569.5050409@knox.net.nz> Message-ID: <1151008137.21735.4.camel@laurel.intra.city-fan.org> On Fri, 2006-06-23 at 07:54 +1200, Michael J. Knox wrote: > Eric Tanguy wrote: > > Le jeudi 22 juin 2006 ? 08:13 +0100, Paul Howarth a ?crit : > > > >>On Thu, 2006-06-22 at 07:39 +0200, Eric Tanguy wrote: > >> > >>>Since i updated mock to 0.6-1.fc5 when i try to run it i obtain : > >>>init > >>>clean > >>>prep > >>>This may take a while > >>>Could not find useradd in chroot, maybe the install failed? > >>>ending > >>>done > >>> > >>>What is the problem ? > >> > >>Look in your root.log and try to figure out why shadow-utils (a > >>dependency of rpm) didn't get installed. > >> > >>Paul. > >> > > > > Executing /usr/sbin/mock-helper yum > > --installroot /var/lib/mock/fedora-development-i386-core/root install > > buildsys-build > > No Match for argument: buildsys-build > > > > Eric > > > > > > I am not sure the differnce, but in the /etc/mock/defaults.cfg file > there are two lines that look like this: > > config_opts['chroot_setup_cmd'] = 'install buildsys-build' > #config_opts['chroot_setup_cmd'] = 'groupinstall build' > > I made it look like: > > #config_opts['chroot_setup_cmd'] = 'install buildsys-build' > config_opts['chroot_setup_cmd'] = 'groupinstall build' > > And my mock setup is working again..... You'll get this if you have a local groups repo. You need to add the buildsys-build package to it. You can get it from here: http://buildsys.fedoraproject.org/buildgroups/development/i386/ Paul. From buildsys at fedoraproject.org Thu Jun 22 20:40:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Jun 2006 16:40:16 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-22 Message-ID: <20060622204016.440BB15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 22 apt-0.5.15lorg3.2-6.fc5 asymptote-1.08-1.fc5 bigloo-2.8b-2.fc5 conman-0.1.9.1-3.fc5 darcs-1.0.8-1.fc5 emacs-vm-7.19-3.fc5 fcron-3.0.1-12.fc5 gnupg2-1.9.21-3.fc5 html401-dtds-4.01-19991224.2.fc5 hugs98-2006.05-4.fc5 libksba-0.9.15-2.fc5 mock-0.6-3.fc5 monodoc-1.1.13-13.fc5 muine-0.8.5-1.fc5 perl-WWW-Bugzilla-0.8-1.fc5 php-extras-5.1.4-2.fc5 powerman-1.0.24-1.fc5 rrdtool-1.2.13-3.fc5 sextractor-2.4.4-2.fc5 testdisk-6.4-2.fc5 tetex-fonts-hebrew-0.1-5.fc5 wifi-radar-1.9.6-2.fc5 Packages built and released for Fedora Extras 4: 17 apt-0.5.15lorg3.2-6.fc4 asymptote-1.08-1.fc4 bigloo-2.8b-2.fc4 conman-0.1.9.1-3.fc4 darcs-1.0.8-1.fc4 emacs-vm-7.19-3.fc4 fcron-3.0.1-12.fc4 gnupg2-1.9.21-3.fc4 hugs98-2006.05-4.fc4 libksba-0.9.15-2.fc4 mock-0.6-3.fc4 perl-WWW-Bugzilla-0.8-1.fc4 powerman-1.0.24-1.fc4 rrdtool-1.2.13-3.fc4 sextractor-2.4.4-2.fc4 testdisk-6.4-2.fc4 tetex-fonts-hebrew-0.1-5.fc4 Packages built and released for Fedora Extras 3: 3 gnupg2-1.9.21-3.fc3 libksba-0.9.15-2.fc3 testdisk-6.4-2.fc3 Packages built and released for Fedora Extras development: 28 CastPodder-5.0-6.fc6 apt-0.5.15lorg3.2-6.fc6 asymptote-1.08-1.fc6 bigloo-2.8b-2.fc6 conman-0.1.9.1-3.fc6 denyhosts-2.5-1.fc6 emacs-vm-7.19-3.fc6 esmtp-0.5.1-12.fc6 fcron-3.0.1-12.fc6 gdk-pixbuf-0.22.0-29.fc6 ghdl-0.23-0.57svn.0.fc6 gnome-blog-0.9.1-2.fc6 gnupg2-1.9.21-3.fc6 hugs98-2006.05-4.fc6 libksba-0.9.15-2.fc6 manaworld-0.0.19-1.fc6 mock-0.6-3.fc6 monodoc-1.1.13-13.fc6 muine-0.8.5-1.fc6 nagios-plugins-1.4.3-11.fc6 perl-WWW-Bugzilla-0.8-1.fc6 php-extras-5.1.4-2.fc6 showimg-0.9.5-8.fc6 tetex-fonts-hebrew-0.1-5.fc6 ucarp-1.2-2.fc6 wifi-radar-1.9.6-2.fc6 xmms-1.2.10-27.fc6 xpa-2.1.6-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jun 22 20:40:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Jun 2006 16:40:43 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-22 Message-ID: <20060622204043.9286C15217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) kexec-tools: 5: 0:1.101-18 (FC5-updates) 6: 0:1.101-16 (FC6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nfs-utils: 5: 0:1.0.8.rc2-5.FC5 (FC5-updates) 6: 0:1.0.8-2 (FC6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.4-3.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-hangul: 4: 0:0.2.2-2.fc4 (FE4) 5: 0:0.2.2-1.fc5.1 (FC5-updates) 6: 0:0.2.2-4.fc6 (FC6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.15-1.fc3 (FE3) 4: 0:0.9.15-0.1.fc4 (FE4) 5: 0:0.9.15-1.fc5 (FE5) 6: 0:0.9.15-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) From i.pilcher at comcast.net Thu Jun 22 20:57:04 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 22 Jun 2006 15:57:04 -0500 Subject: FE Package Status of Jun 22, 2006 In-Reply-To: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> References: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> Message-ID: Christian.Iseli at licr.org wrote: > - 32 packages not available in extras devel or release > i dot pilcher at comcast dot net wifi-radar What's the expected delay between a successful build and the package actually showing up -- or have I missed a step? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From wart at kobold.org Thu Jun 22 20:58:32 2006 From: wart at kobold.org (Wart) Date: Thu, 22 Jun 2006 13:58:32 -0700 Subject: FE Package Status of Jun 22, 2006 In-Reply-To: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> References: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> Message-ID: <449B0478.60407@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian.Iseli at licr.org wrote: > - 7 packages not available in extras devel but present in release > andreas at bawue dot net echoping > andreas at bawue dot net mboxgrep > dakingun at gmail dot com baobab > noa at resare dot com vorbisgain > wart at kobold dot org manaworld manaworld has finally been built and pushed on devel. See today's FE package build report. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEmwRyDeYlPfs40g8RAs9vAJ9eYzaLfOAeLjjn9ZSEJT4BBPti5QCcCvFw 7n9Ht8QPdwr3eg3IA/D9TSs= =VgGa -----END PGP SIGNATURE----- From wart at kobold.org Thu Jun 22 21:00:07 2006 From: wart at kobold.org (Wart) Date: Thu, 22 Jun 2006 14:00:07 -0700 Subject: Broken upgrade paths in FC+FE 2006-06-22 In-Reply-To: <20060622204043.9286C15217B@buildsys.fedoraproject.org> References: <20060622204043.9286C15217B@buildsys.fedoraproject.org> Message-ID: <449B04D7.103@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 buildsys at fedoraproject.org wrote: > abiword: > 5: 1:2.4.4-4.fc5 (FE5) > 6: 1:2.4.4-2.fc6 (FE6) [...] Could we have the package owners' names added to this report? It will make it easier to scan for one's own packages. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEmwTVDeYlPfs40g8RAq2bAJ0So0R7X+gxgHYCQKmphmJQOgeCxACfZ+WF 1C/fPJOBz7GNQR9rwSaNEXM= =iOqf -----END PGP SIGNATURE----- From michael at knox.net.nz Thu Jun 22 21:01:48 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 23 Jun 2006 09:01:48 +1200 Subject: FE Package Status of Jun 22, 2006 In-Reply-To: References: <200606221435.k5MEZvES026153@ludwig-alpha.unil.ch> Message-ID: <449B053C.8060507@knox.net.nz> Ian Pilcher wrote: > Christian.Iseli at licr.org wrote: > >> - 32 packages not available in extras devel or release >> i dot pilcher at comcast dot net wifi-radar > > > What's the expected delay between a successful build and the package > actually showing up -- or have I missed a step? > > Hi Ian, wifi-radar was pushed today. There was a report not long ago detailing the packages built and pushed. Michael From ville.skytta at iki.fi Thu Jun 22 21:28:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 23 Jun 2006 00:28:19 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-22 In-Reply-To: <449B04D7.103@kobold.org> References: <20060622204043.9286C15217B@buildsys.fedoraproject.org> <449B04D7.103@kobold.org> Message-ID: <1151011699.7175.11.camel@localhost.localdomain> On Thu, 2006-06-22 at 14:00 -0700, Wart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > buildsys at fedoraproject.org wrote: > > abiword: > > 5: 1:2.4.4-4.fc5 (FE5) > > 6: 1:2.4.4-2.fc6 (FE6) > [...] > > Could we have the package owners' names added to this report? It will > make it easier to scan for one's own packages. Agreed. But it would be very nice if someone could extract the functionality for mapping packages and maintainers into a shared python module so it wouldn't have to be implemented in every script separately... rc-report.py in the repoclosure scripts seems to contain good candidate code for that and various other bits. Anyone? http://cvs.fedora.redhat.com/viewcvs/extras-repoclosure/rc-report.py?root=fedora&rev=.&view=auto http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora From jwilson at redhat.com Thu Jun 22 22:47:31 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 22 Jun 2006 18:47:31 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1151005699.2720.4.camel@rousalka.dyndns.org> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> <1151004422.2976.12.camel@xavier.boston.redhat.com> <1151005699.2720.4.camel@rousalka.dyndns.org> Message-ID: <1151016451.2976.22.camel@xavier.boston.redhat.com> On Thu, 2006-06-22 at 21:48 +0200, Nicolas Mailhot wrote: > Le jeudi 22 juin 2006 ? 15:27 -0400, Jarod Wilson a ?crit : > > > +1. Making all possible i386 bits available in the x86_64 tree does > > nothing to hurt folks who want pure x86_64 > > Unfortunately, that's not true. If you do full mixing it's all too easy > to start relying on the 386 bits. If someone wants pure x86_64, it can be done, they just have to not give in to temptation. ;) I know folks who've done it. Of course, they missed out on OpenOffice (but that's about to change). Really not a whole lot else though -- the basics are all there. Every app I use on a regular basis works fine on pure x86_64. What if there were an option in yum.conf (dunno, could already be doable) to not install any i?86 bits, unless the user explicitly overrides that setting? > How many developers will run a pure > 64bit system and check it works ? I've got a pair of spare x86_64 boxes atm, I'd be happy to give it a try. Lots of development work on my primary workstation though, so it stays multilib. :) -- 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 bugs.michael at gmx.net Thu Jun 22 23:14:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Jun 2006 01:14:44 +0200 Subject: Fedora Extras Package Build Report 2006-06-22 In-Reply-To: <20060622204016.440BB15217B@buildsys.fedoraproject.org> References: <20060622204016.440BB15217B@buildsys.fedoraproject.org> Message-ID: <20060623011444.456105bf.bugs.michael@gmx.net> On Thu, 22 Jun 2006 16:40:16 -0400 (EDT), buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras 5: 22 Huh? Where's the broken deps report? From katzj at redhat.com Fri Jun 23 00:12:42 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Jun 2006 20:12:42 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1151016451.2976.22.camel@xavier.boston.redhat.com> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> <1151004422.2976.12.camel@xavier.boston.redhat.com> <1151005699.2720.4.camel@rousalka.dyndns.org> <1151016451.2976.22.camel@xavier.boston.redhat.com> Message-ID: <1151021562.9341.10.camel@aglarond.local> On Thu, 2006-06-22 at 18:47 -0400, Jarod Wilson wrote: > What if there were an option in yum.conf (dunno, could already be > doable) to not install any i?86 bits, unless the user explicitly > overrides that setting? It already exists... just do exclude=*.i?86.rpm in your yum.conf > > How many developers will run a pure > > 64bit system and check it works ? > > I've got a pair of spare x86_64 boxes atm, I'd be happy to give it a > try. Lots of development work on my primary workstation though, so it > stays multilib. :) Realistically, I don't see this as something that's likely to be a big problem Jeremy From Matt_Domsch at dell.com Fri Jun 23 02:21:50 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 22 Jun 2006 21:21:50 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-22 Message-ID: <20060623022150.GC15027@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Thu Jun 22 16:53:28 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gtkhtml36 193476 ASSIGNED Number failed to build: 135 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 134 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 131 ---------------------------------- abiword uwog at uwog.net airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com drivel stickster at gmail.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-plugins bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org perl-Test-WWW-Mechanize jpo at di.uminho.pt pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 3 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de 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 Fri Jun 23 02:22:10 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 22 Jun 2006 21:22:10 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-22 Message-ID: <20060623022210.GD15027@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Thu Jun 22 16:51:48 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: gtkhtml36 193476 ASSIGNED Number failed to build: 156 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 145 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 142 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com drivel stickster at gmail.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com geomview rdieter at math.unl.edu gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08 bdpepple at ameritech.net gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libgalago bdpepple at ameritech.net libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Test-WWW-Mechanize jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com pygame chris.stone at gmail.com python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de tagtool bdpepple at ameritech.net Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org wesnoth bdpepple at ameritech.net WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xpilot-ng wart at kobold.org xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 3 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de 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 jwilson at redhat.com Fri Jun 23 13:28:16 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 23 Jun 2006 09:28:16 -0400 Subject: Time to make Extras multi-lib? In-Reply-To: <1151021562.9341.10.camel@aglarond.local> References: <1150900032.3850.3.camel@xavier.boston.redhat.com> <1150915275.7016.41.camel@localhost.localdomain> <1150916359.3850.6.camel@xavier.boston.redhat.com> <20060622125551.a1ddadd0.bugs.michael@gmx.net> <20060622122130.GC17779@neu.nirvana> <1150995289.14729.46.camel@localhost> <1150995953.3424.1.camel@aglarond.local> <1151004422.2976.12.camel@xavier.boston.redhat.com> <1151005699.2720.4.camel@rousalka.dyndns.org> <1151016451.2976.22.camel@xavier.boston.redhat.com> <1151021562.9341.10.camel@aglarond.local> Message-ID: <1151069296.11779.9.camel@xavier.boston.redhat.com> On Thu, 2006-06-22 at 20:12 -0400, Jeremy Katz wrote: > On Thu, 2006-06-22 at 18:47 -0400, Jarod Wilson wrote: > > What if there were an option in yum.conf (dunno, could already be > > doable) to not install any i?86 bits, unless the user explicitly > > overrides that setting? > > It already exists... just do > exclude=*.i?86.rpm > in your yum.conf I had a feeling something like that would do it. > > > How many developers will run a pure > > > 64bit system and check it works ? [...] > Realistically, I don't see this as something that's likely to be a big > problem Me neither, but I'll go ahead and install a box or two w/a pure 64-bit FC6t1 later today, to remove any doubt. (One or two boxes isn't exactly a huge sampling, but I presume the worry is that it wouldn't be usable at all, so if it is on one box, it should be on another). So what needs to happen to make this pipe dream a reality? I'm guessing the issue needs to be raised at the next FESCo meeting, discussed, possibly voted on, so on and so forth... -- 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 buildsys at fedoraproject.org Fri Jun 23 15:00:51 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 23 Jun 2006 15:00:51 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-23 Message-ID: <20060623150051.10853.63884@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- jwilson AT redhat.com perl-rrdtool - 1.2.13-2.fc5.i386 perl-rrdtool - 1.2.13-2.fc5.ppc perl-rrdtool - 1.2.13-2.fc5.x86_64 php-rrdtool - 1.2.13-2.fc5.i386 php-rrdtool - 1.2.13-2.fc5.ppc php-rrdtool - 1.2.13-2.fc5.x86_64 python-rrdtool - 1.2.13-2.fc5.i386 python-rrdtool - 1.2.13-2.fc5.ppc python-rrdtool - 1.2.13-2.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- perl-rrdtool-1.2.13-2.fc5.i386 requires rrdtool = 0:1.2.13-2.fc5 php-rrdtool-1.2.13-2.fc5.i386 requires rrdtool = 0:1.2.13-2.fc5 python-rrdtool-1.2.13-2.fc5.i386 requires rrdtool = 0:1.2.13-2.fc5 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- perl-rrdtool-1.2.13-2.fc5.ppc requires rrdtool = 0:1.2.13-2.fc5 php-rrdtool-1.2.13-2.fc5.ppc requires rrdtool = 0:1.2.13-2.fc5 python-rrdtool-1.2.13-2.fc5.ppc requires rrdtool = 0:1.2.13-2.fc5 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 perl-rrdtool-1.2.13-2.fc5.x86_64 requires rrdtool = 0:1.2.13-2.fc5 php-rrdtool-1.2.13-2.fc5.x86_64 requires rrdtool = 0:1.2.13-2.fc5 python-rrdtool-1.2.13-2.fc5.x86_64 requires rrdtool = 0:1.2.13-2.fc5 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: jwilson AT redhat.com package: python-rrdtool - 1.2.13-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: perl-rrdtool - 1.2.13-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: php-rrdtool - 1.2.13-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: php-rrdtool - 1.2.13-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: python-rrdtool - 1.2.13-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: perl-rrdtool - 1.2.13-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: php-rrdtool - 1.2.13-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: perl-rrdtool - 1.2.13-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc5 package: python-rrdtool - 1.2.13-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc5 ====================================================================== New report for: zipsonic AT gmail.com package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 From buildsys at fedoraproject.org Fri Jun 23 15:00:51 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 23 Jun 2006 15:00:51 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-23 Message-ID: <20060623150051.10850.84527@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- jwilson AT redhat.com perl-rrdtool - 1.2.13-2.fc4.i386 perl-rrdtool - 1.2.13-2.fc4.ppc perl-rrdtool - 1.2.13-2.fc4.x86_64 php-rrdtool - 1.2.13-2.fc4.i386 php-rrdtool - 1.2.13-2.fc4.ppc php-rrdtool - 1.2.13-2.fc4.x86_64 python-rrdtool - 1.2.13-2.fc4.i386 python-rrdtool - 1.2.13-2.fc4.ppc python-rrdtool - 1.2.13-2.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- perl-rrdtool-1.2.13-2.fc4.i386 requires rrdtool = 0:1.2.13-2.fc4 php-rrdtool-1.2.13-2.fc4.i386 requires rrdtool = 0:1.2.13-2.fc4 python-rrdtool-1.2.13-2.fc4.i386 requires rrdtool = 0:1.2.13-2.fc4 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- perl-rrdtool-1.2.13-2.fc4.ppc requires rrdtool = 0:1.2.13-2.fc4 php-rrdtool-1.2.13-2.fc4.ppc requires rrdtool = 0:1.2.13-2.fc4 python-rrdtool-1.2.13-2.fc4.ppc requires rrdtool = 0:1.2.13-2.fc4 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- perl-rrdtool-1.2.13-2.fc4.x86_64 requires rrdtool = 0:1.2.13-2.fc4 php-rrdtool-1.2.13-2.fc4.x86_64 requires rrdtool = 0:1.2.13-2.fc4 python-rrdtool-1.2.13-2.fc4.x86_64 requires rrdtool = 0:1.2.13-2.fc4 ====================================================================== New report for: jwilson AT redhat.com package: perl-rrdtool - 1.2.13-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: python-rrdtool - 1.2.13-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: php-rrdtool - 1.2.13-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: php-rrdtool - 1.2.13-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: python-rrdtool - 1.2.13-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: perl-rrdtool - 1.2.13-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: perl-rrdtool - 1.2.13-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: php-rrdtool - 1.2.13-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc4 package: python-rrdtool - 1.2.13-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: rrdtool = 0:1.2.13-2.fc4 From buildsys at fedoraproject.org Fri Jun 23 15:00:51 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 23 Jun 2006 15:00:51 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-23 Message-ID: <20060623150051.10842.89525@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Fri Jun 23 15:00:51 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 23 Jun 2006 15:00:51 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-23 Message-ID: <20060623150051.10856.28699@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc jwilson AT redhat.com perl-rrdtool - 1.2.13-4.fc6.i386 perl-rrdtool - 1.2.13-4.fc6.ppc perl-rrdtool - 1.2.13-4.fc6.x86_64 php-rrdtool - 1.2.13-4.fc6.i386 php-rrdtool - 1.2.13-4.fc6.ppc php-rrdtool - 1.2.13-4.fc6.x86_64 python-rrdtool - 1.2.13-4.fc6.i386 python-rrdtool - 1.2.13-4.fc6.ppc python-rrdtool - 1.2.13-4.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 michael AT knox.net.nz gdk-pixbuf-devel - 1:0.22.0-29.fc6.i386 gdk-pixbuf-devel - 1:0.22.0-29.fc6.ppc gdk-pixbuf-devel - 1:0.22.0-29.fc6.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdk-pixbuf-devel-1:0.22.0-29.fc6.i386 requires gnome-libs-devel gdk-pixbuf-devel-1:0.22.0-29.fc6.i386 requires gdk-pixbuf-gnome = 1:0.22.0-29.fc6 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.i386 requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.i386 requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdk-pixbuf-devel-1:0.22.0-29.fc6.ppc requires gnome-libs-devel gdk-pixbuf-devel-1:0.22.0-29.fc6.ppc requires gdk-pixbuf-gnome = 1:0.22.0-29.fc6 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.ppc requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.ppc requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdk-pixbuf-devel-1:0.22.0-29.fc6.x86_64 requires gnome-libs-devel gdk-pixbuf-devel-1:0.22.0-29.fc6.x86_64 requires gdk-pixbuf-gnome = 1:0.22.0-29.fc6 gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 php-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 python-rrdtool-1.2.13-4.fc6.x86_64 requires rrdtool = 0:1.2.13-4.fc6 qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: michael AT knox.net.nz package: gdk-pixbuf-devel - 1:0.22.0-29.fc6.i386 from fedora-extras-development-i386 unresolved deps: gnome-libs-devel gdk-pixbuf-gnome = 1:0.22.0-29.fc6 package: gdk-pixbuf-devel - 1:0.22.0-29.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gnome-libs-devel gdk-pixbuf-gnome = 1:0.22.0-29.fc6 package: gdk-pixbuf-devel - 1:0.22.0-29.fc6.ppc from fedora-extras-development-ppc unresolved deps: gnome-libs-devel gdk-pixbuf-gnome = 1:0.22.0-29.fc6 ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors nagios-plugins = 0:1.4.3-6.fc6 From kevin-fedora-extras at scrye.com Fri Jun 23 16:39:24 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 23 Jun 2006 10:39:24 -0600 (MDT) Subject: Xfce 4.4beta1 test repo (was Re: XFCE4.4) Message-ID: <20060623.103924.692068298.kevin@scrye.com> Thought I would cross post this over here on the extras list as well, as there might be some interested folks here. >>>>> "Paul" == Paul Michael Reilly writes: >> Yeah, I was intending to do something like that. Note that I don't >> have a "people" directory, since I don't work for redhat (Xfce is >> in extras. ;) I will see about setting up a repo here later tonight >> with the beta1 packages I have now. testing appreciated. Would >> devel/fc6 be sufficent? Or would folks like fc5 versions as well? Paul> Kevin, I'm only concerned with devel, FWIW. And let us know if Paul> a repo server for this special xfce4.4 test is an issue. I Paul> suspect we can solve that one fairly easily. Ok, by popular demand... I've got a repo setup for Xfce 4.4beta1. NOTE: This is a beta1 release. It could eat your data, blow up your computer and drive off to vegas with your valuables. ;) A few other things to note: - I don't have a orage package ready yet. orage is the new xfcalendar. - I don't have my mousepad package ready yet. Mousepad is a simple and lightweight text editor that will be shipped with 4.4. - I don't have a thunar package ready yet. Thunar is the Xfce 4.4 file manager, replacing xffm. The following packages that are in 4.2 are no longer in 4.4: xfce4-iconbox xfce4-systray xfce4-toys xfce4-trigger-launcher xffm - I have only done minimal testing so far on things, so more testing is welcome. I can also probibly make fc5 rpms if there is a demand. - Please send bug reports/patches to me. I will try and keep the repo up to date with betas moving forward. for your /etc/yum.repos.d/xfce44beta.repo --- cut --- [xfce44beta] name=Xfce 4.4 beta1 baseurl=http://www.scrye.com/xfce-4.4b1/development/RPMS enabled=1 gpgcheck=0 --- cut --- enjoy. Paul> -pmr 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 Fri Jun 23 22:49:49 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 24 Jun 2006 00:49:49 +0200 Subject: Xfce 4.4beta1 test repo (was Re: XFCE4.4) In-Reply-To: <20060623.103924.692068298.kevin@scrye.com> References: <20060623.103924.692068298.kevin@scrye.com> Message-ID: <20060623224949.GA28369@free.fr> > - I don't have a thunar package ready yet. Thunar is the Xfce 4.4 file > manager, replacing xffm. I allready said it, but still... I have a Thunar package srpm here, I have tested that it works with your 4.4 beta I am using right now, though it segfaults now and then. http://www.environnement.ens.fr/perso/dumas/fc-srpms/Thunar-0.3.0-0.beta1.src.rpm In the menu there is still an entry for xffm, I guess it should be replaced by thunar (may be a configuration issue on my side, though). -- Pat From kevin-fedora-extras at scrye.com Fri Jun 23 23:07:20 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Fri, 23 Jun 2006 17:07:20 -0600 (MDT) Subject: Xfce 4.4beta1 test repo References: <20060623.103924.692068298.kevin@scrye.com> <20060623224949.GA28369@free.fr> Message-ID: <20060623.170720.70923786.kevin@scrye.com> >>>>> "Patrice" == Patrice Dumas writes: >> - I don't have a thunar package ready yet. Thunar is the Xfce 4.4 >> file manager, replacing xffm. Patrice> I allready said it, but still... I have a Thunar package srpm Patrice> here, I have tested that it works with your 4.4 beta I am Patrice> using right now, though it segfaults now and then. Patrice> http://www.environnement.ens.fr/perso/dumas/fc-srpms/Thunar-0.3.0-0.beta1.src.rpm Yeah, hopefully beta2 will be out soon and I will push new exo/Terminal out, which should allow Thunar to be in... If you want to go ahead and submit it for review I would be happy to review it for you. ;) Patrice> In the menu there is still an entry for xffm, I guess it Patrice> should be replaced by thunar (may be a configuration issue on Patrice> my side, though). Yeah, I noticed that too... but my test machine still had xffm on it, so I wasn't sure what was causing that. Will investigate. Patrice> -- Pat Patrice> -- fedora-extras-list mailing list Patrice> fedora-extras-list at redhat.com Patrice> https://www.redhat.com/mailman/listinfo/fedora-extras-list kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gemi at bluewin.ch Sat Jun 24 10:59:43 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 24 Jun 2006 12:59:43 +0200 Subject: Squeak License Message-ID: <1151146783.26300.1.camel@scriabin.tannenrauch.ch> Hi, Is the Squeak license compatible with anything allowable in Fedora Extras: http://www.squeak.org/SqueakLicense I would like to introduce Squeak to FE, but there seem to be some problems with the license. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From pertusus at free.fr Sat Jun 24 11:53:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 24 Jun 2006 13:53:35 +0200 Subject: Squeak License In-Reply-To: <1151146783.26300.1.camel@scriabin.tannenrauch.ch> References: <1151146783.26300.1.camel@scriabin.tannenrauch.ch> Message-ID: <20060624115335.GA2251@free.fr> > Is the Squeak license compatible with anything allowable in > Fedora Extras: > http://www.squeak.org/SqueakLicense In my opinion it is not compatible since a modified version cannot be sold, nor can the fonts be sold. "You may distribute and sublicense the Fonts only as a part of and for use with Modified Software, and not as a part of or for use with Modified Software that is distributed or sublicensed for a fee or for other valuable consideration." and "such modified, overwritten, replaced, deleted, added and ported portions of the Modified Software must be made publicly available, preferably by means of download from a website, at no charge" -- Pat From buildsys at fedoraproject.org Sat Jun 24 18:08:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 24 Jun 2006 14:08:09 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-24 Message-ID: <20060624180809.03E1015217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 22 asymptote-1.09-1.fc5 drivel-2.1.0-0.2.20060527cvs.fc5 esmtp-0.5.1-12.fc5 ghdl-0.23-0.57svn.1.fc5 grip-3.2.0-12.fc5 gstreamer08-0.8.12-5.fc5 gstreamer08-plugins-0.8.12-3.fc5 hugs98-2006.05-5.fc5 libgalago-0.5.1-3.fc5 mail-notification-3.0-1.fc5 mock-0.6-4.fc5 nagios-plugins-1.4.3-12.fc5 perl-Sub-Uplevel-0.13-1.fc5 poker-engine-1.0.15-4.fc5 qt4-4.1.4-1.fc5 rapidsvn-0.9.3-1.fc5 scite-1.70-1.fc5 shorewall-3.0.8-1.fc5 source-highlight-2.3-2.fc5 tagtool-0.12.2-6.fc5 torque-2.1.1-3.fc5 yaz-2.1.22-1.fc5 Packages built and released for Fedora Extras 4: 14 asymptote-1.09-1.fc4 esmtp-0.5.1-12.fc4 grip-3.2.0-12.fc4 hugs98-2006.05-5.fc4 mock-0.6-4.fc4 nagios-plugins-1.4.3-12.fc4 perl-Sub-Uplevel-0.13-1.fc4 poker-engine-1.0.15-4.fc4 qt4-4.1.4-1.fc4 scite-1.70-1.fc4 shorewall-3.0.8-1.fc4 source-highlight-2.3-2.fc4 torque-2.1.1-3.fc4 yaz-2.1.22-1.fc4 Packages built and released for Fedora Extras 3: 2 perl-Net-SNMP-5.2.0-1.fc3 torque-2.1.1-3.fc3 Packages built and released for Fedora Extras development: 26 asymptote-1.09-1.fc6 drivel-2.1.0-0.2.20060527cvs.fc6 ejabberd-1.1.1-7.fc6 gdk-pixbuf-0.22.0-30.fc6 geomview-1.8.2-0.5.cvs20060623.fc6 grip-3.2.0-12.fc6 gstreamer08-0.8.12-6.fc6 gstreamer08-plugins-0.8.12-4.fc6 hugs98-2006.05-5.fc6 libgalago-0.5.1-4.fc6 mock-0.6-4.fc6 nagios-plugins-1.4.3-12.fc6 perl-Calendar-Simple-1.13-3.fc6 perl-Sub-Uplevel-0.13-1.fc6 poker-engine-1.0.15-4.fc6 qt4-4.1.4-1.fc6 rapidsvn-0.9.3-1.fc6 rt3-3.6.0-2.fc6 scite-1.70-1.fc6 shorewall-3.2.0-0.1.RC4.fc6 source-highlight-2.3-2.fc6 tagtool-0.12.2-7.fc6 torque-2.1.1-3.fc6 xosd-2.2.14-7.fc6 xscreensaver-5.00-8.fc6 yaz-2.1.22-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jun 24 18:08:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 24 Jun 2006 14:08:32 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-24 Message-ID: <20060624180832.1797715217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) cscope: 5: 0:15.5-13.7 (FC5-updates) 6: 0:15.5-13.5 (FC6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) ghdl: 5: 0:0.23-0.57svn.1.fc5 (FE5) 6: 0:0.23-0.57svn.0.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nfs-utils: 5: 0:1.0.8.rc2-5.FC5 (FC5-updates) 6: 0:1.0.8-2 (FC6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.4-3.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-hangul: 4: 0:0.2.2-2.fc4 (FE4) 5: 0:0.2.2-1.fc5.1 (FC5-updates) 6: 0:0.2.2-4.fc6 (FC6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.15-1.fc3 (FE3) 4: 0:0.9.15-0.1.fc4 (FE4) 5: 0:0.9.15-1.fc5 (FE5) 6: 0:0.9.15-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) From buildsys at fedoraproject.org Sat Jun 24 19:57:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 24 Jun 2006 19:57:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-24 Message-ID: <20060624195706.20305.56876@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Sat Jun 24 19:57:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 24 Jun 2006 19:57:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-24 Message-ID: <20060624195706.20307.19595@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de koffice-devel - 1.5.1-1.fc6.i386 koffice-devel - 1.5.1-1.fc6.ppc koffice-devel - 1.5.1-1.fc6.x86_64 koffice-filters - 1.5.1-1.fc6.i386 koffice-filters - 1.5.1-1.fc6.ppc koffice-filters - 1.5.1-1.fc6.x86_64 koffice-karbon - 1.5.1-1.fc6.i386 koffice-karbon - 1.5.1-1.fc6.ppc koffice-karbon - 1.5.1-1.fc6.x86_64 koffice-krita - 1.5.1-1.fc6.i386 koffice-krita - 1.5.1-1.fc6.ppc koffice-krita - 1.5.1-1.fc6.x86_64 qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.i386 requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 qiv-2.0-4.i386 requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 koffice-devel-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-filters-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-karbon-1.5.1-1.fc6.ppc requires libMagick.so.9 koffice-krita-1.5.1-1.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 qiv-2.0-4.ppc requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-devel-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-filters-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-karbon-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) koffice-krita-1.5.1-1.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: orion AT cora.nwra.com package: gdl - 0.9-0.pre.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 package: gdl - 0.9-0.pre.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) package: gdl - 0.9-0.pre.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 ====================================================================== New report for: enrico.scholz AT informatik.tu-chemnitz.de package: kismet-extras - 0.0.2006.04.R1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: kismet-extras - 0.0.2006.04.R1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: koffice-filters - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-karbon - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-krita - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: koffice-karbon - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-devel - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-filters - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-krita - 1.5.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: koffice-krita - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-karbon - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-filters - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 package: koffice-devel - 1.5.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: qspencer AT ieee.org package: octave-forge - 2006.03.17-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 libMagick.so.9 package: octave-forge - 2006.03.17-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) libMagick.so.9()(64bit) package: octave-forge - 2006.03.17-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 libMagick.so.9 From buildsys at fedoraproject.org Sat Jun 24 19:57:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 24 Jun 2006 19:57:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-24 Message-ID: <20060624195706.20296.23050@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From michael at knox.net.nz Sun Jun 25 21:44:36 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 26 Jun 2006 09:44:36 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <44906B36.7030207@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> <44906B36.7030207@knox.net.nz> Message-ID: <449F03C4.8000709@knox.net.nz> Hi all... I have finally drafted this guide/policy. Thanks to those that chipped in. Kevin, I mostly used your email, just reworded and what not. Fell free to pick holes: http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy I would like too see this presented at the next FESCo meeting. Thanks! Michael From j.w.r.degoede at hhs.nl Mon Jun 26 05:39:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jun 2006 07:39:18 +0200 Subject: AWOL owners and stale packages. In-Reply-To: <449F03C4.8000709@knox.net.nz> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> <44906B36.7030207@knox.net.nz> <449F03C4.8000709@knox.net.nz> Message-ID: <449F7306.8050906@hhs.nl> Michael J. Knox wrote: > Hi all... > > I have finally drafted this guide/policy. Thanks to those that chipped in. > > Kevin, I mostly used your email, just reworded and what not. > > Fell free to pick holes: > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > I would like too see this presented at the next FESCo meeting. > > Thanks! > > Michael > Looks very good! Although it might benefit from somewhat clearer wording of this: -FESCo and/or Extra members can then have their say to approve the take over. Silence must not be considered approval. Thats a bit ambigious how about: -If atleast one FESco member approves the take over and noone objects within 3 days, you may take over the package. Regards, Hans From michael at knox.net.nz Mon Jun 26 05:44:54 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 26 Jun 2006 17:44:54 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <449F7306.8050906@hhs.nl> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> <44906B36.7030207@knox.net.nz> <449F03C4.8000709@knox.net.nz> <449F7306.8050906@hhs.nl> Message-ID: <449F7456.5070804@knox.net.nz> Hans de Goede wrote: > > Michael J. Knox wrote: >> Hi all... >> >> I have finally drafted this guide/policy. Thanks to those that chipped in. >> >> Kevin, I mostly used your email, just reworded and what not. >> >> Fell free to pick holes: >> >> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy >> >> I would like too see this presented at the next FESCo meeting. >> >> Thanks! >> >> Michael >> > > Looks very good! Although it might benefit from somewhat clearer wording > of this: > -FESCo and/or Extra members can then have their say to approve the take > over. Silence must not be considered approval. > > Thats a bit ambigious how about: > -If atleast one FESco member approves the take over and noone objects > within 3 days, you may take over the package. Thanks Hans! Thats the kind of feed back I am looking for :) I made that change. Michael From j.w.r.degoede at hhs.nl Mon Jun 26 12:51:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jun 2006 14:51:30 +0200 Subject: onwers.list initial-CC list not working? Message-ID: <449FD852.2030703@hhs.nl> Hi, I just became aware of this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196616 Because I saw a mail about it being fixed to the commits list. However I'm co-maintaing this package with J. Jindrich and because of this my mail is in the initial-CC field of owners.list (and has been for a long long time). However I didn't actaully get put into the initial-CC field. Can someone take a look at this? Regards, Hans From fedora at leemhuis.info Mon Jun 26 18:40:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Jun 2006 20:40:55 +0200 Subject: Summary for the FESCo Meeting from June 08 Message-ID: <44A02A37.2040409@leemhuis.info> Hi all! Sorry, I didn't find time to write the summary earlier. Better late than never :-/ == Summary == Present from FESCo: thl, warren, Sopwith, mschwendt, scop, thomasvs * FESCo future/election * abadger1999 working on it * buildsys-build * new mock in the works * Encourage Extras reviews * tibbs is working on better documentation; Initial work at http://www.fedoraproject.org/wiki/Extras/HowToGetSponsored * some discussions how to improve the situation in general -- see 0:10 and later for details * MIA/AWOL maintainers * we might track this with the package database ( http://fedoraproject.org/wiki/Infrastructure/PackageDatabase ) in the long term; no other progress * kmod's enhanced ( see kerneldrivers.org ) * Seems there is no real benefit nor detriment for Fedora -- we'll wait and look what falls out of the work from jcmasters work for RHEL5 * Free discussion * CTRL-C-Problem -- cvs-commits-mails can be prevented by hitting CTRL+C during commit. Warren and the infrastructure group will look into fixing this (if possible) == Full Log == http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060608 From fedora at leemhuis.info Mon Jun 26 19:05:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Jun 2006 21:05:08 +0200 Subject: Summary for the FESCo Meeting from June 15 Message-ID: <44A02FE4.7060803@leemhuis.info> == Summary == Present from FESCo: warren, scop, thl (late) * Short meeting only -- thl had other things to manage and joined late * some discussions at 0:07 on http://fedoraproject.org/wiki/Extras/HowToGetSponsored * tibbs> | The idea was that people needing sponsorship are not understanding the process; Many think that sponsorship comes automatically. * tibbs> | I'll try to find the info from the logs and cook up an Extras/SponsorResponsibilities page. The HowToGetSponsored page could then link there. * tibbs> | So, I'll go ahead and cook up a page of sponsor responsibilities and we can discuss it next week. * voting / voting system https://admin.fedoraproject.org/voting/ * thl> | abadger1999, shall we post this url and a point to the code in cvs so people can review it before we do the actual election? * abadger1999 did that in between * some guys tested it and some minor problems were found (and fixed) * How long would the voting last? It was areed on one and a half week; open on June 22 close on July 2 * no revotes are allowed/possible -- If people complain we might implement it in the next election == Full Log == http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060615 From fedora at leemhuis.info Mon Jun 26 19:41:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Jun 2006 21:41:53 +0200 Subject: Summary for the FESCo Meeting from June 22 Message-ID: <44A03881.1090805@leemhuis.info> == Summary == Present from FESCo: thl, Sopwith, jpo, scop, jeremy (somewhat), warren, skvidal, ensc * thl apologizes -- he didn't write the meeting summaries for the past two Meetings yet * FESCo future/election * thl > | everything working as expected so far? * abadger1999> | No one's complained. And I haven't received any mails from the system that thing aren't working. * warren's access to some machines was limited due to the election -- he can't do CVS branching anymore. We should make sure that such things aren't necessary in the future (if possible). Sopwith / the infrastructure group will take care of creating CVS branches duing the meeting * Encourage Extras reviews * FAB is watching us -- see http://fedoraproject.org/wiki/Board/Meetings/2006-06-20 in the part "Fedora Extras Steering Committee discussed the sponsorship lag question. A summary, as provided by SethVidal, follows. [...]" * thl> | everyone should read that summary and we really need to find ways to improve the whole situation -> Topic for next FESCo * warren> | I maintain that the only solution is more education and better documentation. I think Tibbs' mail on this topic is right on track. * tibbs will take care of improving the documentation in the wiki from now on * Incompatible package upgrade policy * still on the schedule * directfb still was not updated * It's a bit unclear on just what this topic covers. * we really need somebody to driver this forward; we'll put it on the plate for the new FESCo and ignore it for now * scop> | just to remind, spot said that he'd work something out of the discussions * FC3 branch of perl-Net-SNMP * one of the nagios plugins requires it and Infrastructure machines run FC3 it seems. * creation of that branch permitted * minimal buildroot problem * wart posted to f-e-l on that topic. Any ideas what we can do about it? (missing elfutils -> binaries don't get stripped) * elfutils probably needs to be added to the build roots on FC4 (maybe FC3 also) * here seem to be some kind of problem with python as well * if was agreed on to simply discuss this further on the list; if it looks like it should be necessary that elfutils or python need to be added we simply do it without further discussion == Full Log == http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060622 From j.w.r.degoede at hhs.nl Mon Jun 26 20:46:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jun 2006 22:46:46 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package Message-ID: <44A047B6.9030102@hhs.nl> Hi all, I've just finished up packaging a 3D chess game called chess, which I mainly packaged to have something to test OGRE an OO 3D engine. I've finally managed to get everything to work, but unfortunately chess is very slow on my radeon 9200, like 2 fps. So I've got two questions: -can someone with good 3D card be it with binary drivers test this for me and see if it does work properly there? -can someone with a radeon 9600 or 9800 who is using the new opensource dri drivers for this card test this, to see how it works there? You need to download (and build) the ogre, chess and coldet SRPMS from here: http://people.atrpms.net/~hdegoede chess needs both colder and ogre, so you must build and install those first. For those interested here are the review requests: coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 Thanks & Regards, Hans From dan at danny.cz Mon Jun 26 20:57:10 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 26 Jun 2006 22:57:10 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A047B6.9030102@hhs.nl> References: <44A047B6.9030102@hhs.nl> Message-ID: <1151355430.3500.7.camel@eagle.danny.cz> Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: > Hi all, > > I've just finished up packaging a 3D chess game called chess, which I > mainly packaged to have something to test OGRE an OO 3D engine. > > I've finally managed to get everything to work, but unfortunately chess > is very slow on my radeon 9200, like 2 fps. > > So I've got two questions: > -can someone with good 3D card be it with binary drivers test this for > me and see if it does work properly there? > -can someone with a radeon 9600 or 9800 who is using the new opensource > dri drivers for this card test this, to see how it works there? > > You need to download (and build) the ogre, chess and coldet SRPMS from here: > http://people.atrpms.net/~hdegoede > > chess needs both colder and ogre, so you must build and install those first. > > For those interested here are the review requests: > coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 > ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 > chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 I could test it on NVidia 6600GT with binary drivers. Dan From dan at danny.cz Mon Jun 26 21:32:29 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 26 Jun 2006 23:32:29 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151355430.3500.7.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> Message-ID: <1151357549.3500.10.camel@eagle.danny.cz> Dan Hor?k p??e v Po 26. 06. 2006 v 22:57 +0200: > Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: > > Hi all, > > > > I've just finished up packaging a 3D chess game called chess, which I > > mainly packaged to have something to test OGRE an OO 3D engine. > > > > I've finally managed to get everything to work, but unfortunately chess > > is very slow on my radeon 9200, like 2 fps. > > > > So I've got two questions: > > -can someone with good 3D card be it with binary drivers test this for > > me and see if it does work properly there? > > -can someone with a radeon 9600 or 9800 who is using the new opensource > > dri drivers for this card test this, to see how it works there? > > > > You need to download (and build) the ogre, chess and coldet SRPMS from here: > > http://people.atrpms.net/~hdegoede > > > > chess needs both colder and ogre, so you must build and install those first. > > > > For those interested here are the review requests: > > coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 > > ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 > > chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 > > I could test it on NVidia 6600GT with binary drivers. I am getting a segfault on FC4 when trying to run the Chess. I will look at this problem during the next days. Dan From paul at city-fan.org Mon Jun 26 21:31:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 26 Jun 2006 22:31:59 +0100 Subject: Mock and old distributions Message-ID: <1151357520.2911.17.camel@laurel.intra.city-fan.org> Seeing that the need for elfutils in the buildroot for FC4 was discussed in the latest FESCO meeting, I thought I'd report the results of my efforts to build packages for various old distributions using the current version of mock on FC5: 1. For all Fedora Core distributions before Fedora Core 5, and also Red Hat Linux 9, an additional package, elfutils, is needed in the default buildroot. It's needed because redhat-rpm-config turns on the creation of debuginfo packages, and eu-strip from the elfutils package is needed for this. In Fedora Core 5, elfutils is a dependency of rpm-build, so it gets pulled in automatically, but this doesn't happen for earlier distributions. There is disagreement about where the dependency should really be (see Bug #111363, Bug #132633, and Bug #155129) so in the meantime (and certainly for end-of-lifed distributions), it needs to be a dependency of buildsys-build. 2. For all Fedora Core and Red Hat Linux distributions before Fedora Core 3, runuser isn't available and so the mock configuration file needs: config_opts['runuser'] = '/bin/su' 3. I can't get mock to build for a Fedora Core 2 target on an x86_32 host, though I'm told it works on an x86_64 host, and it might work with SELinux disabled (not just permissive mode). The symptom is that it hangs up at the useradd mockbuild stage. I'd be interested to hear from anyone that has this working. 4. To build for a target of Fedora Core 1, you need to set in the host's /etc/sysctl.conf: kernel.vdso = 0 This is due to a glibc bug (Bug #121351). 5. Building for any Red Hat Linux target requires rebuilding of many of the original packages, which have broken dependencies due to the use of Epoch: tags and the omission of the epoch in exact version dependencies, such as between foo and foo-devel. 6. Building for any Red Hat Linux target older than Red Hat Linux 9 requires file, fileutils, and findutils in the buildroot rather than coreutils (these are needed for the post-build scripts). 7. Red Hat Linux 7 does not include the redhat-rpm-config package, so it must not be included in the buildroot. Some of the above (e.g. the need for "su" rather than "runuser") could be fixed in the mock package. The other items could perhaps be added to a README or perhaps I should update the Legacy/Mock page on the wiki? As for what's needed in the buildroot, I rolled my own buildsys-build package, with deps as follows: # packages that populate a buildsys chroot Requires: bash Requires: buildsys-macros Requires: bzip2 Requires: cpio Requires: diffutils Requires: gcc Requires: gcc-c++ Requires: gzip Requires: make Requires: patch Requires: perl Requires: rpm-build Requires: sed Requires: tar Requires: unzip # The rather long-winded format of the conditionals is needed for compatibility # with old rpm versions such as were supplied with Red Hat Linux 7 %if "%{?fedora}" != "" Requires: coreutils Requires: fedora-release Requires: redhat-rpm-config %if "%{?fedora}" == "4" || "%{?fedora}" == "3" || "%{?fedora}" == "2" || "%{?fedora}" == "1" Requires: elfutils %endif %endif %if "%{?rhl}" != "" Requires: redhat-release %if "%{?rhl}" == "9" Requires: coreutils Requires: elfutils Requires: redhat-rpm-config %else Requires: file Requires: fileutils Requires: findutils %endif # Cater for alternative versions of buildsys-macros %if "%{?rhl}" == "8" || "%{?rhl}" == "8.0" Requires: redhat-rpm-config %endif %endif "which" should probably be added to the list too; it was a late addition to the buildreq exceptions list and didn't get included in my package. Paul. From jkeating at redhat.com Mon Jun 26 23:17:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Jun 2006 19:17:47 -0400 Subject: Mock and old distributions In-Reply-To: <1151357520.2911.17.camel@laurel.intra.city-fan.org> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> Message-ID: <1151363867.23849.11.camel@ender> On Mon, 2006-06-26 at 22:31 +0100, Paul Howarth wrote: > Seeing that the need for elfutils in the buildroot for FC4 was > discussed > in the latest FESCO meeting, I thought I'd report the results of my > efforts to build packages for various old distributions using the > current version of mock on FC5: > Thats awesome Paul! Any chance I could get you to add this to the wiki somewhere so that it won't be lost? I'm sure we'll need this info at some point. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Tue Jun 27 00:28:51 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 26 Jun 2006 19:28:51 -0500 Subject: knetworkmanager In-Reply-To: References: <80b4f5eb0605282318y5017a8e4j43619ff27e4e78ff@mail.gmail.com> <200605290857.33486.dennis@ausil.us> Message-ID: <200606261928.51593.dennis@ausil.us> On Thursday 08 June 2006 6:38 am, Rex Dieter wrote: > Dennis Gilmore wrote: > > On Monday 29 May 2006 5:07 am, Rahul Sundaram wrote: > >> On Sun, 2006-05-28 at 23:18 -0700, Phil Baltar wrote: > >> > I was wondering if there were any current plans to include > >> > knetworkmanager in extras. If not, then I'd like to request that it > >> > be. I'm sure I'm not the only one who's been waiting for a way to use > >> > NetworkManager with KDE. > >> > >> I havent seen any submissions. Would you like to get involved in > >> packaging it? > >> http://fedoraproject.org/wiki/Extras > > > > Ive started work on packaging it. Im using it currently. I need to > > finish my review of the dbus-qt bindings and then submit for review. > > FYI, Dennis' review is complete, so dbus-qt (and dbus-qt-devel) are now > available from Extras. > > -- Rex as an update knetworkmanager has been approved and built and will be available with the next package update -- Dennis Gilmore, RHCE Proud Australian From buildsys at fedoraproject.org Tue Jun 27 01:40:43 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 26 Jun 2006 21:40:43 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-26 Message-ID: <20060627014043.51B1015217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 30 abcMIDI-20060625-1.fc5 abcm2ps-5.0.1-2.fc5 bugzilla-2.22-5.fc5 bzr-0.8.2-2.fc5 denyhosts-2.5-1.fc5 eggdrop-1.6.17-4.fc5 ejabberd-1.1.1-8.fc5 geomview-1.8.2-0.7.cvs20060623.fc5 glibmm24-2.8.9-1 gtkmm24-2.8.8-1.fc5 jigdo-0.7.3-1.fc5 kile-1.9.1-1.fc5 kipi-plugins-0.1.0-1.fc5 knemo-0.4.2-1.fc5 knetworkmanager-0.1-0.3.svn20060625.fc5 liferea-1.0.16-2.fc5 nagios-2.4-2.fc5 nethack-vultures-2.1.0-2.fc5 perl-Net-LibIDN-0.08-5.fc5 perl-Text-Unidecode-0.04-3.fc5 python-lxml-1.0.1-1.fc5 python-sqlalchemy-0.2.3-1.fc5 rrdtool-1.2.13-4.fc5 scribes-0.2.5-2.fc5 smart-0.42-34.fc5 sylpheed-2.2.6-2.fc5 sylpheed-claws-2.3.1-1.fc5 sylpheed-claws-plugins-2.3.0-1.fc5 wine-docs-0.9.16-1.fc5 xpa-2.1.6-4.fc5 Packages built and released for Fedora Extras 4: 26 abcMIDI-20060625-1.fc4 abcm2ps-5.0.1-2.fc4 bugzilla-2.22-5.fc4 bzr-0.8.2-2.fc4 denyhosts-2.5-1.fc4 eggdrop-1.6.17-4.fc4 ejabberd-1.1.1-8.fc4 geomview-1.8.2-0.7.cvs20060623.fc4 glibmm24-2.6.5-1 gtkmm24-2.6.9-2.fc4 inkscape-0.44-1.fc4 jigdo-0.7.3-1.fc4 kile-1.9.1-1.fc4 kipi-plugins-0.1.0-1.fc4 knemo-0.4.2-1.fc4 nagios-2.4-2.fc4 nethack-vultures-2.1.0-2.fc4 perl-Net-LibIDN-0.08-5.fc4 python-lxml-1.0.1-1.fc4 python-sqlalchemy-0.2.3-1.fc4 raptor-1.4.9-2.fc4 rrdtool-1.2.13-4.fc4 smart-0.42-34.fc4 sylpheed-claws-2.3.1-1.fc4 tetex-fonts-hebrew-0.1-6.fc4 wine-docs-0.9.16-0.1.fc4 Packages built and released for Fedora Extras 3: 7 abcm2ps-5.0.1-2.fc3 denyhosts-2.5-1.fc3 kile-1.9.1-1.fc3 kipi-plugins-0.1.0-1.fc3 nagios-2.4-2.fc3 nethack-vultures-2.1.0-2.fc3 wine-docs-0.9.16-1.fc3 Packages built and released for Fedora Extras development: 43 abcMIDI-20060625-1.fc6 abcm2ps-5.0.1-2.fc6 allegro-4.2.0-14.fc6 balsa-2.3.13-1.fc6 bugzilla-2.22-5.fc6 bzr-0.8.2-2.fc6 dirmngr-0.9.4-4.fc6 edb-1.0.5.007-2.fc6 eggdrop-1.6.17-4.fc6 ejabberd-1.1.1-8.fc6 gconfmm26-2.14.2-1.fc6 geomview-1.8.2-0.7.cvs20060623.fc6 ghdl-0.23-0.58svn.0.fc6 glibmm24-2.10.4-1 gtkmm24-2.8.8-2.fc6 jigdo-0.7.3-1.fc6 kile-1.9.1-1.fc6 kipi-plugins-0.1.0-1.fc6 knemo-0.4.2-1.fc6 knetworkmanager-0.1-0.3.svn20060625.fc6 koffice-1.5.1-2.fc6 lash-0.5.1-5.fc6 libupnp-1.4.0-3.fc6 liferea-1.0.16-3.fc6 nagios-2.4-2.fc6 nethack-vultures-2.1.0-2.fc6 nexuiz-2.0-2.fc6 nexuiz-data-2.0-2 nsd-2.3.5-1.fc6 paps-0.6.6-6.fc6 perl-MP3-Info-1.20-2.fc6 perl-Net-LibIDN-0.08-5.fc6 perl-Text-Unidecode-0.04-3.fc6 python-lxml-1.0.1-1.fc6 python-sqlalchemy-0.2.3-1.fc6 rrdtool-1.2.13-7.fc6 sbcl-0.9.14-1.fc6 scribes-0.2.5-2.fc6 sylpheed-2.2.6-2.fc6 sylpheed-claws-2.3.1-1.fc6 sylpheed-claws-plugins-2.3.0-1.fc6 wcstools-3.6.5-1.fc6 wine-docs-0.9.16-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Jun 27 01:41:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 26 Jun 2006 21:41:07 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-26 Message-ID: <20060627014107.1563415217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) cscope: 5: 0:15.5-13.7 (FC5-updates) 6: 0:15.5-13.5 (FC6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) inkscape: 4: 0:0.44-1.fc4 (FE4) 5: 0:0.43-3.fc5 (FE5) 6: 0:0.43-3.fc5 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nfs-utils: 5: 0:1.0.8.rc2-5.FC5 (FC5-updates) 6: 0:1.0.8-2 (FC6) nsd: 3: 0:2.3.4-5.fc3 (FE3) 4: 0:2.3.4-4.fc4 (FE4) 5: 0:2.3.4-4.fc5 (FE5) 6: 0:2.3.5-1.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pygame: 5: 0:1.7.1-7.fc5 (FE5) 6: 0:1.7.1-6.fc6 (FE6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) scponly: 5: 0:4.6-3.fc5 (FE5) 6: 0:4.6-1.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tetex-fonts-hebrew: 4: 0:0.1-6.fc4 (FE4) 5: 0:0.1-5.fc5 (FE5) 6: 0:0.1-5.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) From buildsys at fedoraproject.org Tue Jun 27 02:00:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 27 Jun 2006 02:00:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-26 Message-ID: <20060627020009.24047.17337@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Tue Jun 27 02:00:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 27 Jun 2006 02:00:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-26 Message-ID: <20060627020009.24066.48965@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- jwb AT redhat.com bugzilla-contrib - 2.22-5.fc5.noarch bugzilla-contrib - 2.22-5.fc5.noarch bugzilla-contrib - 2.22-5.fc5.noarch oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc5.noarch requires perl(BugzillaEmail) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc5.noarch requires perl(BugzillaEmail) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc5.noarch requires perl(BugzillaEmail) freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: jwb AT redhat.com package: bugzilla-contrib - 2.22-5.fc5.noarch from fedora-extras-5-i386 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc5.noarch from fedora-extras-5-ppc unresolved deps: perl(BugzillaEmail) From buildsys at fedoraproject.org Tue Jun 27 02:00:09 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 27 Jun 2006 02:00:09 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-26 Message-ID: <20060627020009.24055.59631@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- dakingun AT gmail.com gparted - 0.0.9-3.fc4.i386 gparted - 0.0.9-3.fc4.ppc gparted - 0.0.9-3.fc4.x86_64 denis AT poolshark.org gcdmaster - 1.2.1-3.fc4.i386 gcdmaster - 1.2.1-3.fc4.ppc gcdmaster - 1.2.1-3.fc4.x86_64 libglademm24 - 2.6.0-1.i386 libglademm24 - 2.6.0-1.ppc libglademm24 - 2.6.0-1.x86_64 libgnomecanvasmm26 - 2.10.0-1.i386 libgnomecanvasmm26 - 2.10.0-1.ppc libgnomecanvasmm26 - 2.10.0-1.x86_64 libgnomemm26 - 2.10.0-1.i386 libgnomemm26 - 2.10.0-1.ppc libgnomemm26 - 2.10.0-1.x86_64 libgnomeuimm26 - 2.10.0-1.i386 libgnomeuimm26 - 2.10.0-1.ppc libgnomeuimm26 - 2.10.0-1.x86_64 dennis AT ausil.us mysql-administrator - 1.1.10-1.fc4.i386 mysql-administrator - 1.1.10-1.fc4.ppc mysql-administrator - 1.1.10-1.fc4.x86_64 fedora.wickert AT arcor.de regexxer - 0.8-2.fc4.i386 regexxer - 0.8-2.fc4.ppc regexxer - 0.8-2.fc4.x86_64 gauret AT free.fr colorscheme - 0.3-1.fc4.i386 colorscheme - 0.3-1.fc4.ppc colorscheme - 0.3-1.fc4.x86_64 ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 jwb AT redhat.com bugzilla-contrib - 2.22-5.fc4.noarch bugzilla-contrib - 2.22-5.fc4.noarch bugzilla-contrib - 2.22-5.fc4.noarch lmacken AT redhat.com gobby - 0.3.0-2.fc4.i386 gobby - 0.3.0-2.fc4.ppc gobby - 0.3.0-2.fc4.x86_64 tmraz AT redhat.com workrave - 1.8.3-1.fc4.i386 workrave - 1.8.3-1.fc4.ppc workrave - 1.8.3-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc4.noarch requires perl(BugzillaEmail) colorscheme-0.3-1.fc4.i386 requires libatkmm-1.6.so.1 gcdmaster-1.2.1-3.fc4.i386 requires libatkmm-1.6.so.1 gobby-0.3.0-2.fc4.i386 requires libatkmm-1.6.so.1 gparted-0.0.9-3.fc4.i386 requires libatkmm-1.6.so.1 libglademm24-2.6.0-1.i386 requires libatkmm-1.6.so.1 libgnomecanvasmm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 libgnomemm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 libgnomeuimm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 mysql-administrator-1.1.10-1.fc4.i386 requires libatkmm-1.6.so.1 regexxer-0.8-2.fc4.i386 requires libatkmm-1.6.so.1 workrave-1.8.3-1.fc4.i386 requires libatkmm-1.6.so.1 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc4.noarch requires perl(BugzillaEmail) colorscheme-0.3-1.fc4.ppc requires libatkmm-1.6.so.1 gcdmaster-1.2.1-3.fc4.ppc requires libatkmm-1.6.so.1 gobby-0.3.0-2.fc4.ppc requires libatkmm-1.6.so.1 gparted-0.0.9-3.fc4.ppc requires libatkmm-1.6.so.1 libglademm24-2.6.0-1.ppc requires libatkmm-1.6.so.1 libgnomecanvasmm26-2.10.0-1.ppc requires libatkmm-1.6.so.1 libgnomemm26-2.10.0-1.ppc requires libatkmm-1.6.so.1 libgnomeuimm26-2.10.0-1.ppc requires libatkmm-1.6.so.1 mysql-administrator-1.1.10-1.fc4.ppc requires libatkmm-1.6.so.1 regexxer-0.8-2.fc4.ppc requires libatkmm-1.6.so.1 workrave-1.8.3-1.fc4.ppc requires libatkmm-1.6.so.1 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- bugzilla-contrib-2.22-5.fc4.noarch requires perl(BugzillaEmail) colorscheme-0.3-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) gcdmaster-1.2.1-3.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) gobby-0.3.0-2.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) gparted-0.0.9-3.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) libglademm24-2.6.0-1.x86_64 requires libatkmm-1.6.so.1()(64bit) libgnomecanvasmm26-2.10.0-1.x86_64 requires libatkmm-1.6.so.1()(64bit) libgnomemm26-2.10.0-1.x86_64 requires libatkmm-1.6.so.1()(64bit) libgnomeuimm26-2.10.0-1.x86_64 requires libatkmm-1.6.so.1()(64bit) mysql-administrator-1.1.10-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) regexxer-0.8-2.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) workrave-1.8.3-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: tmraz AT redhat.com package: workrave - 1.8.3-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: workrave - 1.8.3-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: workrave - 1.8.3-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: denis AT poolshark.org package: gcdmaster - 1.2.1-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: libgnomecanvasmm26 - 2.10.0-1.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: libgnomeuimm26 - 2.10.0-1.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: libglademm24 - 2.6.0-1.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: libgnomemm26 - 2.10.0-1.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: gcdmaster - 1.2.1-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: libgnomeuimm26 - 2.10.0-1.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: libgnomemm26 - 2.10.0-1.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: libgnomecanvasmm26 - 2.10.0-1.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: libglademm24 - 2.6.0-1.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: libgnomeuimm26 - 2.10.0-1.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 package: libglademm24 - 2.6.0-1.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 package: libgnomemm26 - 2.10.0-1.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 package: libgnomecanvasmm26 - 2.10.0-1.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 package: gcdmaster - 1.2.1-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: dennis AT ausil.us package: mysql-administrator - 1.1.10-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: mysql-administrator - 1.1.10-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: mysql-administrator - 1.1.10-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: gauret AT free.fr package: colorscheme - 0.3-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: colorscheme - 0.3-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: colorscheme - 0.3-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: jwb AT redhat.com package: bugzilla-contrib - 2.22-5.fc4.noarch from fedora-extras-4-i386 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc4.noarch from fedora-extras-4-ppc unresolved deps: perl(BugzillaEmail) ====================================================================== New report for: dakingun AT gmail.com package: gparted - 0.0.9-3.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: gparted - 0.0.9-3.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: gparted - 0.0.9-3.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: lmacken AT redhat.com package: gobby - 0.3.0-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: gobby - 0.3.0-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: gobby - 0.3.0-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: fedora.wickert AT arcor.de package: regexxer - 0.8-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: regexxer - 0.8-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: regexxer - 0.8-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 ====================================================================== New report for: ivazquez AT ivazquez.net package: wp_tray - 0.5.1-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: wp_tray - 0.5.1-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: wp_tray - 0.5.1-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 From buildsys at fedoraproject.org Tue Jun 27 02:00:10 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 27 Jun 2006 02:00:10 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-26 Message-ID: <20060627020010.24067.98602@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc jwb AT redhat.com bugzilla-contrib - 2.22-5.fc6.noarch bugzilla-contrib - 2.22-5.fc6.noarch bugzilla-contrib - 2.22-5.fc6.noarch lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc6.i386 maxima-runtime-sbcl - 5.9.3-4.fc6.ppc maxima-runtime-sbcl - 5.9.3-4.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bugzilla-contrib-2.22-5.fc6.noarch requires perl(BugzillaEmail) diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 maxima-runtime-sbcl-5.9.3-4.fc6.i386 requires sbcl = 0:0.9.13 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 qiv-2.0-4.i386 requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bugzilla-contrib-2.22-5.fc6.noarch requires perl(BugzillaEmail) diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 maxima-runtime-sbcl-5.9.3-4.fc6.ppc requires sbcl = 0:0.9.13 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 qiv-2.0-4.ppc requires libgdk_imlib.so.1 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bugzilla-contrib-2.22-5.fc6.noarch requires perl(BugzillaEmail) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) maxima-runtime-sbcl-5.9.3-4.fc6.x86_64 requires sbcl = 0:0.9.13 obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: jwb AT redhat.com package: bugzilla-contrib - 2.22-5.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(BugzillaEmail) package: bugzilla-contrib - 2.22-5.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(BugzillaEmail) ====================================================================== New report for: rdieter AT math.unl.edu package: maxima-runtime-sbcl - 5.9.3-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: sbcl = 0:0.9.13 From michael at knox.net.nz Tue Jun 27 02:40:46 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 27 Jun 2006 14:40:46 +1200 Subject: pam_mount Message-ID: <44A09AAE.5030209@knox.net.nz> This package is listed as an orphan on the wiki.. if there is no objection, I will take this package. Michael From kevin-fedora-extras at scrye.com Tue Jun 27 02:49:24 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Mon, 26 Jun 2006 20:49:24 -0600 (MDT) Subject: AWOL owners and stale packages. References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> <44906B36.7030207@knox.net.nz> <449F03C4.8000709@knox.net.nz> Message-ID: <20060626.204924.545358813.kevin@scrye.com> >>>>> "Michael" == Michael J Knox writes: Michael> Hi all... I have finally drafted this guide/policy. Thanks Michael> to those that chipped in. Michael> Kevin, I mostly used your email, just reworded and what not. I just reworded other emails. ;) Michael> Fell free to pick holes: Michael> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy It might be good to to not use "AWOL/MIA". There are probibly lots of people who don't know what that means. How about "Unavailable to continue maintainership" or something like that? In addition to changing the owners.list file, new maintainers should reassign all open bugs to themselves. Michael> I would like too see this presented at the next FESCo Michael> meeting. yeah, me too. :) Michael> Thanks! Michael> Michael kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Tue Jun 27 03:01:07 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Jun 2006 20:01:07 -0700 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-26 In-Reply-To: <20060627020009.24055.59631@extras64.linux.duke.edu> References: <20060627020009.24055.59631@extras64.linux.duke.edu> Message-ID: <44A09F73.2010100@poolshark.org> Fedora Extras repoclosure wrote: > Summary of broken packages in fedora-extras-4-i386: > ---------------------------------------------------------------------- > colorscheme-0.3-1.fc4.i386 requires libatkmm-1.6.so.1 > gcdmaster-1.2.1-3.fc4.i386 requires libatkmm-1.6.so.1 > gobby-0.3.0-2.fc4.i386 requires libatkmm-1.6.so.1 > gparted-0.0.9-3.fc4.i386 requires libatkmm-1.6.so.1 > libglademm24-2.6.0-1.i386 requires libatkmm-1.6.so.1 > libgnomecanvasmm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 > libgnomemm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 > libgnomeuimm26-2.10.0-1.i386 requires libatkmm-1.6.so.1 > mysql-administrator-1.1.10-1.fc4.i386 requires libatkmm-1.6.so.1 > regexxer-0.8-2.fc4.i386 requires libatkmm-1.6.so.1 > workrave-1.8.3-1.fc4.i386 requires libatkmm-1.6.so.1 > wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Argh, the gtkmm update no longer provides libatkmm so. These packages only need to be rebuilt. -denis From j.w.r.degoede at hhs.nl Tue Jun 27 04:16:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 06:16:18 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151357549.3500.10.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> Message-ID: <44A0B112.3020507@hhs.nl> Dan Hor?k wrote: > Dan Hor?k p??e v Po 26. 06. 2006 v 22:57 +0200: >> Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: >>> Hi all, >>> >>> I've just finished up packaging a 3D chess game called chess, which I >>> mainly packaged to have something to test OGRE an OO 3D engine. >>> >>> I've finally managed to get everything to work, but unfortunately chess >>> is very slow on my radeon 9200, like 2 fps. >>> >>> So I've got two questions: >>> -can someone with good 3D card be it with binary drivers test this for >>> me and see if it does work properly there? >>> -can someone with a radeon 9600 or 9800 who is using the new opensource >>> dri drivers for this card test this, to see how it works there? >>> >>> You need to download (and build) the ogre, chess and coldet SRPMS from here: >>> http://people.atrpms.net/~hdegoede >>> >>> chess needs both colder and ogre, so you must build and install those first. >>> >>> For those interested here are the review requests: >>> coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 >>> ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 >>> chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 >> I could test it on NVidia 6600GT with binary drivers. > > I am getting a segfault on FC4 when trying to run the Chess. I will look > at this problem during the next days. > Hmm, Thats not so good news, I hope you'll be able to get it running. Regards, Hans From dragoran at feuerpokemon.de Tue Jun 27 05:34:17 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 27 Jun 2006 07:34:17 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A0B112.3020507@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> Message-ID: <44A0C359.6080804@feuerpokemon.de> Hans de Goede wrote: > > > Dan Hor?k wrote: >> Dan Hor?k p??e v Po 26. 06. 2006 v 22:57 +0200: >>> Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: >>>> Hi all, >>>> >>>> I've just finished up packaging a 3D chess game called chess, which I >>>> mainly packaged to have something to test OGRE an OO 3D engine. >>>> >>>> I've finally managed to get everything to work, but unfortunately >>>> chess >>>> is very slow on my radeon 9200, like 2 fps. >>>> >>>> So I've got two questions: >>>> -can someone with good 3D card be it with binary drivers test this for >>>> me and see if it does work properly there? >>>> -can someone with a radeon 9600 or 9800 who is using the new >>>> opensource >>>> dri drivers for this card test this, to see how it works there? >>>> >>>> You need to download (and build) the ogre, chess and coldet SRPMS >>>> from here: >>>> http://people.atrpms.net/~hdegoede >>>> >>>> chess needs both colder and ogre, so you must build and install >>>> those first. >>>> >>>> For those interested here are the review requests: >>>> coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 >>>> ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 >>>> chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 >>> I could test it on NVidia 6600GT with binary drivers. >> >> I am getting a segfault on FC4 when trying to run the Chess. I will look >> at this problem during the next days. >> > > Hmm, > > Thats not so good news, I hope you'll be able to get it running. > > Regards, > > Hans > I tryed to test it on my 7800GTX on FC5 x86_64 but the ogre build failed due to multilib issues: riptCompiler.o .libs/OgreCompiler2Pass.o .libs/OgreILImageCodec.o .libs/OgreILCodecs.o .libs/OgreILUtil.o -L/usr/local/lib /usr/local/lib/libfreetype.so -lzzip -lILU -lIL -lz -ldl -L/usr/lib64 -lSDL -lpthread -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.1/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crtn.o -m64 -mtune=generic -Wl,--rpath -Wl,/usr/local/lib -Wl,-soname -Wl,libOgreMain.so.11 -o .libs/libOgreMain.so.11.0.1 /usr/local/lib/libfreetype.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [libOgreMain.la] Error 1 make[2]: Leaving directory `/home/dragoran/rpm/BUILD/ogrenew/OgreMain/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dragoran/rpm/BUILD/ogrenew/OgreMain' make: *** [all-recursive] Error 1 It tryes to link against a 32bit lib :( From peter at thecodergeek.com Tue Jun 27 06:08:57 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Jun 2006 23:08:57 -0700 Subject: Unorphaning Openbox: Commiting new stuff to multiple CVS branches properly? Message-ID: <44A0CB79.6000002@thecodergeek.com> Hi, all. I've submitted a package of Openbox to unorphan it and got it approved with a review from Chris Ricker (and have now taken ownership of it in owners/owners.list). However, it has CVS branch directories for everything from RHL-8 through FC-5 and devel. Do I simply run common/cvs-import.sh with my source RPM and copy the resultant stuff in devel to the FC-4 and FC-5 branches? Is there a cleaner or preffered way to accomplish this? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Tue Jun 27 07:42:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 09:42:03 +0200 Subject: soname change policy proposal Message-ID: <44A0E14B.9010200@hhs.nl> Hi all, I've been thinking about this for a while and I think its time for a brain dump, so here is a first shot at a soname change policy: 1) When a package update would cause an soname change then a compat package with the old libraries must be provided for all release repos, that is for all repos except devel. 1a) This compat package must be successfully build before a build of the update causing the change may be requested. 1b) If an update causing a soname change will only be build for devel a compat package is not mandatory. In this case however other packagers must be warned, with the warning containing a way for them to get the new version. After the warning one must wait 7 days minimum before the new version may be build. 2) When a compat package must be created there are 2 possible scenarios. When the soname is changed the ABI is changed, however sometimes the API is not changed or kept compatible. When the API is not changed then the compat package must not come with a -devel subpackage and the quick and dirty method described below may be used. When the API is changed the compat package is concidered a new package and must go through the review process as usual, in this case the compat-package must come with a -devel subpackage. 2a) If there is: -a small incompatible API change which can _not_ create silent (not detected by the compiler) breakage, and -other packages using the package can easily be fixed to compile and run with the new version, then The quick and dirty method may also be used. An example of this would be a function getting an additional parameter which can be set to 0 to get the old behaviour. In this case however other packagers must be warned and the warning must include a description what changes are necessary and howto make these changes. 2b) When a compat-xxx-devel package is created this package must be parallel installable with the real -devel package. In cases where this is very hard to achieve in a good way an exception to this rule may be made by the reviewer. 3) The quick and dirty method consists of: * renaming the spec file and "Name: " field to: compat- Where is the for the soname relevant part of the version without the dots. For example if a new SDL 1.3 would be released then the EVR of the compat package would be compat-SDL12-1.2.10-1, and thus _not_ compat-SDL1210-1.2.10-1 because the .10 is not relevant for the soname since SDL-1.2.0 had the same soname. * Remove the -devel subpackage * Add the files from %files devel to %files with %exclude in front. * Add a Changelog entry describing the changes and the reason for this. * Create a Review request for this and approve it yourself in order to keep Chris' scripts happy. This also makes other other FE contributers aware of what your doing through the review-list. * Import, request branches etc. Well thats it I hope verybody likes it and FESco can vote on this sometime soon :) Notice that I have no direct interest in this, it is just something I've been thinking about after the directfb discussion. Regards, Hans From j.w.r.degoede at hhs.nl Tue Jun 27 07:46:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 09:46:08 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A0C359.6080804@feuerpokemon.de> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> <44A0C359.6080804@feuerpokemon.de> Message-ID: <44A0E240.60902@hhs.nl> dragoran wrote: > Hans de Goede wrote: >> >> >> Dan Hor?k wrote: >>> Dan Hor?k p??e v Po 26. 06. 2006 v 22:57 +0200: >>>> Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: >>>>> Hi all, >>>>> >>>>> I've just finished up packaging a 3D chess game called chess, which I >>>>> mainly packaged to have something to test OGRE an OO 3D engine. >>>>> >>>>> I've finally managed to get everything to work, but unfortunately >>>>> chess >>>>> is very slow on my radeon 9200, like 2 fps. >>>>> >>>>> So I've got two questions: >>>>> -can someone with good 3D card be it with binary drivers test this for >>>>> me and see if it does work properly there? >>>>> -can someone with a radeon 9600 or 9800 who is using the new >>>>> opensource >>>>> dri drivers for this card test this, to see how it works there? >>>>> >>>>> You need to download (and build) the ogre, chess and coldet SRPMS >>>>> from here: >>>>> http://people.atrpms.net/~hdegoede >>>>> >>>>> chess needs both colder and ogre, so you must build and install >>>>> those first. >>>>> >>>>> For those interested here are the review requests: >>>>> coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 >>>>> ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 >>>>> chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 >>>> I could test it on NVidia 6600GT with binary drivers. >>> >>> I am getting a segfault on FC4 when trying to run the Chess. I will look >>> at this problem during the next days. >>> >> >> Hmm, >> >> Thats not so good news, I hope you'll be able to get it running. >> >> Regards, >> >> Hans >> > I tryed to test it on my 7800GTX on FC5 x86_64 but the ogre build failed > due to multilib issues: > riptCompiler.o .libs/OgreCompiler2Pass.o .libs/OgreILImageCodec.o > .libs/OgreILCodecs.o .libs/OgreILUtil.o -L/usr/local/lib > /usr/local/lib/libfreetype.so -lzzip -lILU -lIL -lz -ldl -L/usr/lib64 > -lSDL -lpthread -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1 > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64 > -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s > /usr/lib/gcc/x86_64-redhat-linux/4.1.1/crtendS.o > /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crtn.o -m64 > -mtune=generic -Wl,--rpath -Wl,/usr/local/lib -Wl,-soname > -Wl,libOgreMain.so.11 -o .libs/libOgreMain.so.11.0.1 > /usr/local/lib/libfreetype.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > make[2]: *** [libOgreMain.la] Error 1 > make[2]: Leaving directory `/home/dragoran/rpm/BUILD/ogrenew/OgreMain/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dragoran/rpm/BUILD/ogrenew/OgreMain' > make: *** [all-recursive] Error 1 > It tryes to link against a 32bit lib :( > I think thats because you've done a local install of freetype and have /usr/local/bin in your PATH before /usr/bin causing ./configure to find and use /usr/local/bin/freetype-config for freetype-config Regards, Hans From ville.skytta at iki.fi Tue Jun 27 08:55:45 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 27 Jun 2006 11:55:45 +0300 Subject: soname change policy proposal In-Reply-To: <44A0E14B.9010200@hhs.nl> References: <44A0E14B.9010200@hhs.nl> Message-ID: <1151398545.2768.52.camel@localhost.localdomain> On Tue, 2006-06-27 at 09:42 +0200, Hans de Goede wrote: > I've been thinking about this for a while and I think its time for a > brain dump, so here is a first shot at a soname change policy: My opinions/comments below: 0) Try hard to avoid incompatible upgrades within non-devel distro branches. Note: this is not limited to library sonames, but to all packages! If you're convinced that it doesn't make sense in the case at hand, then: > 1b) If an update causing a soname change will only be build for devel > a compat package is not mandatory. In this case however other packagers > must be warned, with the warning containing a way for them to get the > new version. This warning must be posted in public, to the fedora-maintainers mailing list. > After the warning one must wait 7 days minimum before the > new version may be build. 7 days is too much. If Core devel is not in the post-last-testX freeze before the next release, 1 day is enough. If Core devel is in that freeze, rules for released distro branches apply to devel too. Example: according to the current http://fedoraproject.org/wiki/Core/Schedule, the final post-last-testX freeze would be 23 Aug - 27 Sep. For released branches, we assume that a smoothly working compat-foo has been already created before the incompatible upgrade is pushed and it has stayed in a review for a little while anyway. So there's no wait period, but the notice must be posted to the fedora-maintainers list when the new compat package is posted for review, and the review bug number is included in that notice. > 2) When a compat package must be created there are 2 possible scenarios. > When the soname is changed the ABI is changed, however sometimes the > API is not changed or kept compatible. When the API is not changed then > the compat package must not come with a -devel subpackage and the quick > and dirty method described below may be used. When the API is changed > the compat package is concidered a new package and must go through the > review process as usual, in this case the compat-package must come with > a -devel subpackage. All compat-* need to go through a review. Shipping compat-*-devel is discouraged, and in addition to the above, may be done only if there are existing packages in FC+FE which will actually have to use it (where "have to" expands to "a simple rebuild against the new version is not enough"). > -other packages using the package can easily be fixed to compile and > run with the new version, then Enumerating "other packages" is not possible. > 2b) [...] 2c) Only one compat-foo per foo by default, no automatic compat-foo10, compat-foo11, compat-foo12 proliferation. More than one compat-foo per released distro branch requires FESCO approval. > * Create a Review request for this and approve it yourself -1, all new packages need to go through the usual review process, and compat-foo is a new package, even if it rises from the ashes and is reintroduced in a new distro branch when it existed for earlier ones but not yet for the new. > Well thats it I hope verybody likes it and FESco can vote on this > sometime soon :) Open issues: - Q: How do compat- become purged on distro upgrades? A: New distros should under normal circumstances start with no compat-* packages and packages that did have compat-* ones in earlier distros must have appropriately versioned "Obsoletes: compat-foo < V-R" for each such compat (usually only one). Ditto for devel/compat-foo-devel. If an obsoleted compat-foo has to be reintroduced to the new branch, the corresponding Obsoletes needs to be dropped at that point, and an update pushed for the new main package at the same time as the new compat package. - Should compat-foo = $ver-$rel have "Provides: foo = $ver-$rel"? What about "Provides: compat-foo = $ver-$rel"? If not, breakage is likely if packages need to use something else than the autogenerated library/soname dependency (eg. for versioning not adequately accomplished through sonames). What about compat-foo-devel <-> "Provides: foo-devel = $ver-$rel" and "Provides: compat-foo-devel = $ver-$rel"? There have been some depsolver issues in the past with setups like this, dunno if the world has been fixed since. > Notice that I have no direct interest in this, Everyone does... ;) From ville.skytta at iki.fi Tue Jun 27 08:58:18 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 27 Jun 2006 11:58:18 +0300 Subject: Unorphaning Openbox: Commiting new stuff to multiple CVS branches properly? In-Reply-To: <44A0CB79.6000002@thecodergeek.com> References: <44A0CB79.6000002@thecodergeek.com> Message-ID: <1151398699.2768.56.camel@localhost.localdomain> On Mon, 2006-06-26 at 23:08 -0700, Peter Gordon wrote: > However, it has CVS branch directories for everything from RHL-8 through > FC-5 and devel. Do I simply run common/cvs-import.sh with my source RPM > and copy the resultant stuff in devel to the FC-4 and FC-5 branches? Is > there a cleaner or preffered way to accomplish this? Mileages vary which way is cleaner, but cvs-import.sh can be used to import stuff to existing branches (one at a time), run it without any options for usage info. From laurent.rineau__fedora_extras at normalesup.org Tue Jun 27 10:06:54 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Tue, 27 Jun 2006 12:06:54 +0200 Subject: %{_libexecdir} Message-ID: <200606271206.54213@rineau.schtroumpfette> "rpmlint?-i", on emacs packages, says: W: emacs non-standard-dir-in-usr libexec Your package is creating a non-standard subdirectory in /usr. The standard directories are: -X11R6 -X386 -bin -games -include -lib -local -sbin -share -src -spool -tmp -lib64 Actually, the %configure macros specifies-libexecdir=%{_libexecdir}, with: %_libexecdir %{_exec_prefix}/libexec If /usr/libexec is not a "standard" directory. What should be the correct value of %_libexecdir?? Why not just %{_exec_prefix}/%{_lib}?? -- Laurent Rineau Note: I am compiling the emacs-22.0.50 of bug #176171, and tried rpmlint on the result. From paul at city-fan.org Tue Jun 27 10:44:21 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 27 Jun 2006 11:44:21 +0100 Subject: Mock and old distributions In-Reply-To: <1151363867.23849.11.camel@ender> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> <1151363867.23849.11.camel@ender> Message-ID: <44A10C05.3010405@city-fan.org> Jesse Keating wrote: > On Mon, 2006-06-26 at 22:31 +0100, Paul Howarth wrote: >> Seeing that the need for elfutils in the buildroot for FC4 was >> discussed >> in the latest FESCO meeting, I thought I'd report the results of my >> efforts to build packages for various old distributions using the >> current version of mock on FC5: >> > > Thats awesome Paul! Any chance I could get you to add this to the wiki > somewhere so that it won't be lost? I'm sure we'll need this info at > some point. I'll update the Legacy/Mock page on the wiki. However, first I'd like to know what, if anything, will get fixed upstream or in the infrastructure. For instance, the mock package in Extras is currently shipping with config files for Red Hat Linux 7.3 and 9, plus Fedora Core 1-devel. The best place to fix the issue of needing "su" rather than "runuser" for FC2 and earlier would be in these config files (i.e. an upstream fix). Similarly, the differing requirements for packages needed in the buildroots would best be addressed by having the existing infrastructure at http://buildsys.fedoraproject.org/buildgroups/ updated to include buildsys-build packages for all of the mock-supported distributions with the correct dependencies for each. I can raise bugs for these issues if that's preferred. That would then just leave the issues that end users need to address on their own systems, which are best described on the wiki (though adding a reference to the wiki pages might be a useful addition to the mock README). Paul. From jkeating at redhat.com Tue Jun 27 11:33:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Jun 2006 07:33:58 -0400 Subject: Mock and old distributions In-Reply-To: <44A10C05.3010405@city-fan.org> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> <1151363867.23849.11.camel@ender> <44A10C05.3010405@city-fan.org> Message-ID: <1151408038.23849.28.camel@ender> On Tue, 2006-06-27 at 11:44 +0100, Paul Howarth wrote: > I can raise bugs for these issues if that's preferred. Bugs are best. They'll go to me anyway (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Tue Jun 27 11:59:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 13:59:03 +0200 Subject: soname change policy proposal In-Reply-To: <1151398545.2768.52.camel@localhost.localdomain> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> Message-ID: <44A11D87.8030802@hhs.nl> Ville Skytt? wrote: > On Tue, 2006-06-27 at 09:42 +0200, Hans de Goede wrote: > >> * Create a Review request for this and approve it yourself > > -1, all new packages need to go through the usual review process, and > compat-foo is a new package, even if it rises from the ashes and is > reintroduced in a new distro branch when it existed for earlier ones but > not yet for the new. > Erm, if you mandate this then many packages may start to suffer from bitrot unfortunatly there are quite a few packages which _always_ bump the .soname each (minor) release. Directfb is but one example of this, the whole idea behind this quick 'n dirty compat rules is to make it easier for people todo compat packages, thus avoiding breakage as we;ve seen in the past. Maybe the plan I gave howto create a quick and dirty compat package should be ammended to say that the changes listed there are the only changes allowed? please reread the little howto I wrote, then you'll that the package is effectivly unchanged, just renamed and stripped of its -develo subpackage. I just realized that if its a mixed lib and binary package it should actually be stripped of everything except the libs and %doc. So maybe the howto needs some rewording, but as said the idea is that this isn't a _new_ package is just a rename of an exisiting one! >> Well thats it I hope verybody likes it and FESco can vote on this >> sometime soon :) > > Open issues: > > - Q: How do compat- become purged on distro upgrades? A: New > distros should under normal circumstances start with no compat-* > packages and packages that did have compat-* ones in earlier distros > must have appropriately versioned "Obsoletes: compat-foo < V-R" > for each such compat (usually only one). Ditto for > devel/compat-foo-devel. If an obsoleted compat-foo has to be > reintroduced to the new branch, the corresponding Obsoletes needs to be > dropped at that point, and an update pushed for the new main package at > the same time as the new compat package. > EWONTFIX, we have this issue with core provided compat-xxxx packages already. This can be best handled by anaconda at update time, either way I do _not_ want to have this problem tagged ontop of this policy, its IMHO a seperate problem. > - Should compat-foo = $ver-$rel have "Provides: foo = $ver-$rel"? > What about "Provides: compat-foo = $ver-$rel"? If not, breakage is > likely if packages need to use something else than the autogenerated > library/soname dependency (eg. for versioning not adequately > accomplished through sonames). What about compat-foo-devel <-> > "Provides: foo-devel = $ver-$rel" and "Provides: compat-foo-devel = > $ver-$rel"? There have been some depsolver issues in the past with > setups like this, dunno if the world has been fixed since. > I think that provides like this will cause more breakage then they fix. Thanks for your input & Regards, Hans From rdieter at math.unl.edu Tue Jun 27 11:56:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Jun 2006 06:56:23 -0500 Subject: %{_libexecdir} References: <200606271206.54213@rineau.schtroumpfette> Message-ID: Laurent Rineau wrote: > "rpmlint?-i", on emacs packages, says: > > W: emacs non-standard-dir-in-usr libexec ... > Actually, the %configure macros specifies-libexecdir=%{_libexecdir}, with: > %_libexecdir %{_exec_prefix}/libexec .. > If /usr/libexec is not a "standard" directory. IMO, until an official policy is stated otherwise, in this case, I'd say don't worry too much about rpmlint's warning... -- Rex From rdieter at math.unl.edu Tue Jun 27 12:00:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Jun 2006 07:00:33 -0500 Subject: soname change policy proposal References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> Message-ID: Ville Skytt? wrote: > - Should compat-foo = $ver-$rel have "Provides: foo = $ver-$rel"? AFAIK, won't work, because of rpm's (relatively new) "feature" of automatically doing equivalent of Obsoletes: foo < %{version}-%{release} on any install/upgrade of foo, which will result in removing compat-foo. -- Rex From kevin.kofler at chello.at Tue Jun 27 12:23:10 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 27 Jun 2006 12:23:10 +0000 (UTC) Subject: soname change policy proposal References: <44A0E14B.9010200@hhs.nl> Message-ID: Hans de Goede writes: > 1) When a package update would cause an soname change then a compat > package with the old libraries must be provided for all release repos, > that is for all repos except devel. IMHO this is ridiculous. Even Core doesn't follow such a strict policy. This is going to hinder critical security upgrades for packages such as SeaMonkey, and also leave rapidly-changing libraries (which are the ones needing version upgrades the most!) stale at old versions (and you can quickly end up with dozens of compat packages for the same library if it is _really_ rapidly changing). I think the current policy of simply getting packages rebuilt if a soname changes (which is also what is done when Core upgrades a soname) works well. Kevin Kofler From jkeating at redhat.com Tue Jun 27 12:37:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Jun 2006 08:37:26 -0400 Subject: %{_libexecdir} In-Reply-To: References: <200606271206.54213@rineau.schtroumpfette> Message-ID: <1151411846.23849.40.camel@ender> On Tue, 2006-06-27 at 06:56 -0500, Rex Dieter wrote: > > IMO, until an official policy is stated otherwise, in this case, I'd > say > don't worry too much about rpmlint's warning... > I'd say take this as official. libexec is fine, and will continue to be used. We need to fix rpmlint to accept it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laurent.rineau__fedora_extras at normalesup.org Tue Jun 27 13:23:52 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Tue, 27 Jun 2006 15:23:52 +0200 Subject: %{_libexecdir} In-Reply-To: <1151411846.23849.40.camel@ender> References: <200606271206.54213@rineau.schtroumpfette> <1151411846.23849.40.camel@ender> Message-ID: <200606271523.52105@rineau.schtroumpfette> On Tuesday 27 June 2006 14:37, Jesse Keating wrote: > On Tue, 2006-06-27 at 06:56 -0500, Rex Dieter wrote: > > IMO, until an official policy is stated otherwise, in this case, I'd > > say > > don't worry too much about rpmlint's warning... > > I'd say take this as official. libexec is fine, and will continue to be > used. We need to fix rpmlint to accept it. On x86_64, should /usr/libexec be 64bits or 32bits? From rc040203 at freenet.de Tue Jun 27 13:59:41 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 27 Jun 2006 15:59:41 +0200 Subject: %{_libexecdir} In-Reply-To: <200606271523.52105@rineau.schtroumpfette> References: <200606271206.54213@rineau.schtroumpfette> <1151411846.23849.40.camel@ender> <200606271523.52105@rineau.schtroumpfette> Message-ID: <1151416781.9369.16.camel@mccallum.corsepiu.local> On Tue, 2006-06-27 at 15:23 +0200, Laurent Rineau wrote: > On Tuesday 27 June 2006 14:37, Jesse Keating wrote: > > On Tue, 2006-06-27 at 06:56 -0500, Rex Dieter wrote: > > > IMO, until an official policy is stated otherwise, in this case, I'd > > > say > > > don't worry too much about rpmlint's warning... > > > > I'd say take this as official. libexec is fine, and will continue to be > > used. We need to fix rpmlint to accept it. > > On x86_64, should /usr/libexec be 64bits or 32bits? This is a controversal point. Some people want to see $libexecdir multiarch'ed, but most (all?) packages I am aware about to be actively using $libexecdir use it with an architecture corresponding to $bindir. On a single-arch'ed x86_64 $libexecdir would be 64bit, on a single-arch'ed i386 it would be 32bit, on a multiarched, the contents of $libexecdir would have to correspond to the architecture of the binaries in $bindir. Ralf From Axel.Thimm at ATrpms.net Tue Jun 27 14:40:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Jun 2006 16:40:38 +0200 Subject: %{_libexecdir} In-Reply-To: <200606271523.52105@rineau.schtroumpfette> References: <200606271206.54213@rineau.schtroumpfette> <1151411846.23849.40.camel@ender> <200606271523.52105@rineau.schtroumpfette> Message-ID: <20060627144038.GA3762@neu.nirvana> On Tue, Jun 27, 2006 at 03:23:52PM +0200, Laurent Rineau wrote: > On Tuesday 27 June 2006 14:37, Jesse Keating wrote: > > On Tue, 2006-06-27 at 06:56 -0500, Rex Dieter wrote: > > > IMO, until an official policy is stated otherwise, in this case, I'd > > > say > > > don't worry too much about rpmlint's warning... > > > > I'd say take this as official. libexec is fine, and will continue to be > > used. We need to fix rpmlint to accept it. > > On x86_64, should /usr/libexec be 64bits or 32bits? Treat it like %{_bindir} -- 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 katzj at redhat.com Tue Jun 27 15:47:20 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 27 Jun 2006 11:47:20 -0400 Subject: soname change policy proposal In-Reply-To: <44A11D87.8030802@hhs.nl> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> <44A11D87.8030802@hhs.nl> Message-ID: <1151423240.27257.41.camel@orodruin.boston.redhat.com> On Tue, 2006-06-27 at 13:59 +0200, Hans de Goede wrote: > please reread the little howto I wrote, then you'll that the package > is effectivly unchanged, just renamed and stripped of its -develo > subpackage. I just realized that if its a mixed lib and binary package > it should actually be stripped of everything except the libs and %doc. > So maybe the howto needs some rewording, but as said the idea is that > this isn't a _new_ package is just a rename of an exisiting one! ... in that case, it should be quick and easy for the review to happen :-) Jeremy From katzj at redhat.com Tue Jun 27 15:53:15 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 27 Jun 2006 11:53:15 -0400 Subject: %{_libexecdir} In-Reply-To: <20060627144038.GA3762@neu.nirvana> References: <200606271206.54213@rineau.schtroumpfette> <1151411846.23849.40.camel@ender> <200606271523.52105@rineau.schtroumpfette> <20060627144038.GA3762@neu.nirvana> Message-ID: <1151423596.27257.46.camel@orodruin.boston.redhat.com> On Tue, 2006-06-27 at 16:40 +0200, Axel Thimm wrote: > On Tue, Jun 27, 2006 at 03:23:52PM +0200, Laurent Rineau wrote: > > On Tuesday 27 June 2006 14:37, Jesse Keating wrote: > > > On Tue, 2006-06-27 at 06:56 -0500, Rex Dieter wrote: > > > > IMO, until an official policy is stated otherwise, in this case, I'd > > > > say > > > > don't worry too much about rpmlint's warning... > > > > > > I'd say take this as official. libexec is fine, and will continue to be > > > used. We need to fix rpmlint to accept it. > > > > On x86_64, should /usr/libexec be 64bits or 32bits? > > Treat it like %{_bindir} Yep. Since libexec is basically used for helper binaries that users don't directly execute Jeremy From dragoran at feuerpokemon.de Tue Jun 27 17:26:54 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 27 Jun 2006 19:26:54 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A0E240.60902@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> <44A0C359.6080804@feuerpokemon.de> <44A0E240.60902@hhs.nl> Message-ID: <44A16A5E.6090602@feuerpokemon.de> Hans de Goede wrote: > > > dragoran wrote: >> Hans de Goede wrote: >>> >>> >>> Dan Hor?k wrote: >>>> Dan Hor?k p??e v Po 26. 06. 2006 v 22:57 +0200: >>>>> Hans de Goede p??e v Po 26. 06. 2006 v 22:46 +0200: >>>>>> Hi all, >>>>>> >>>>>> I've just finished up packaging a 3D chess game called chess, >>>>>> which I >>>>>> mainly packaged to have something to test OGRE an OO 3D engine. >>>>>> >>>>>> I've finally managed to get everything to work, but unfortunately >>>>>> chess >>>>>> is very slow on my radeon 9200, like 2 fps. >>>>>> >>>>>> So I've got two questions: >>>>>> -can someone with good 3D card be it with binary drivers test >>>>>> this for >>>>>> me and see if it does work properly there? >>>>>> -can someone with a radeon 9600 or 9800 who is using the new >>>>>> opensource >>>>>> dri drivers for this card test this, to see how it works there? >>>>>> >>>>>> You need to download (and build) the ogre, chess and coldet SRPMS >>>>>> from here: >>>>>> http://people.atrpms.net/~hdegoede >>>>>> >>>>>> chess needs both colder and ogre, so you must build and install >>>>>> those first. >>>>>> >>>>>> For those interested here are the review requests: >>>>>> coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710 >>>>>> ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740 >>>>>> chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744 >>>>> I could test it on NVidia 6600GT with binary drivers. >>>> >>>> I am getting a segfault on FC4 when trying to run the Chess. I will >>>> look >>>> at this problem during the next days. >>>> >>> >>> Hmm, >>> >>> Thats not so good news, I hope you'll be able to get it running. >>> >>> Regards, >>> >>> Hans >>> >> I tryed to test it on my 7800GTX on FC5 x86_64 but the ogre build >> failed due to multilib issues: >> riptCompiler.o .libs/OgreCompiler2Pass.o .libs/OgreILImageCodec.o >> .libs/OgreILCodecs.o .libs/OgreILUtil.o -L/usr/local/lib >> /usr/local/lib/libfreetype.so -lzzip -lILU -lIL -lz -ldl -L/usr/lib64 >> -lSDL -lpthread -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1 >> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64 >> -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s >> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/crtendS.o >> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crtn.o -m64 >> -mtune=generic -Wl,--rpath -Wl,/usr/local/lib -Wl,-soname >> -Wl,libOgreMain.so.11 -o .libs/libOgreMain.so.11.0.1 >> /usr/local/lib/libfreetype.so: could not read symbols: File in wrong >> format >> collect2: ld returned 1 exit status >> make[2]: *** [libOgreMain.la] Error 1 >> make[2]: Leaving directory >> `/home/dragoran/rpm/BUILD/ogrenew/OgreMain/src' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/dragoran/rpm/BUILD/ogrenew/OgreMain' >> make: *** [all-recursive] Error 1 >> It tryes to link against a 32bit lib :( >> > > I think thats because you've done a local install of freetype and have > /usr/local/bin in your PATH before /usr/bin causing ./configure to > find and use /usr/local/bin/freetype-config for freetype-config > > Regards, > > Hans > ok sorry for this build fine now... it runs but some issues: 1) after the first start it does not work; (rendering errors and does not quit; needs to be killed) 2)enabling FSAA give me this error on startup: GLRenderSystem::createRenderWindow "OGRE Render Window", 1280x1024 fullscreen miscParams: FSAA=6 title=OGRE Render Window Could not make screen: Couldn't find matching GLX visual 800x600 window (no FS/ no FSAA) = Render Target 'OGRE Render Window' Average FPS: 137.35 Best FPS: 150.943 Worst FPS: 123.26 System: 7800GTX w nvidia driver FC5 x86_64 Opteron 170 @2x2.7GHz (overclocked) 2048MB Ram From j.w.r.degoede at hhs.nl Tue Jun 27 18:00:51 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 20:00:51 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A16A5E.6090602@feuerpokemon.de> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> <44A0C359.6080804@feuerpokemon.de> <44A0E240.60902@hhs.nl> <44A16A5E.6090602@feuerpokemon.de> Message-ID: <44A17253.7040201@hhs.nl> dragoran wrote: > 1) after the first start it does not work; (rendering errors and does > not quit; needs to be killed) Hmm strange > 2)enabling FSAA give me this error on startup: > GLRenderSystem::createRenderWindow "OGRE Render Window", 1280x1024 > fullscreen miscParams: FSAA=6 title=OGRE Render Window > Could not make screen: Couldn't find matching GLX visual Yes it would be nice if it would try again without FSAA if it can't get it to work. > 800x600 window (no FS/ no FSAA) = > Render Target 'OGRE Render Window' Average FPS: 137.35 Best FPS: 150.943 > Worst FPS: 123.26 Well thats better then my puny 2 fps :) Atleast it really is a 3D card / driver problem and not a packaging bug, good. Thanks for testing, Hans p.s. Anyone with an 9600 / 9800 out there, I would really like to know how that works in combination with the new opensource driver. I'm somewhat reluctant to upgrade to a videocard without opensource 3D support. From j.w.r.degoede at hhs.nl Tue Jun 27 18:03:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 20:03:17 +0200 Subject: soname change policy proposal In-Reply-To: <1151423240.27257.41.camel@orodruin.boston.redhat.com> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> <44A11D87.8030802@hhs.nl> <1151423240.27257.41.camel@orodruin.boston.redhat.com> Message-ID: <44A172E5.6040709@hhs.nl> Jeremy Katz wrote: > On Tue, 2006-06-27 at 13:59 +0200, Hans de Goede wrote: >> please reread the little howto I wrote, then you'll that the package >> is effectivly unchanged, just renamed and stripped of its -develo >> subpackage. I just realized that if its a mixed lib and binary package >> it should actually be stripped of everything except the libs and %doc. >> So maybe the howto needs some rewording, but as said the idea is that >> this isn't a _new_ package is just a rename of an exisiting one! > > ... in that case, it should be quick and easy for the review to > happen :-) > > Jeremy > Its unnescesarry pain for the maintainer and an unnescesarry burden on the Review process which is already overloaded as is. Also see what Kevin Kofler wrote: > Hans de Goede writes: >> 1) When a package update would cause an soname change then a compat >> package with the old libraries must be provided for all release repos, >> that is for all repos except devel. > > IMHO this is ridiculous. Even Core doesn't follow such a strict policy. This is > going to hinder critical security upgrades for packages such as SeaMonkey, and > also leave rapidly-changing libraries (which are the ones needing version > upgrades the most!) stale at old versions (and you can quickly end up with > dozens of compat packages for the same library if it is _really_ rapidly > changing). I think the current policy of simply getting packages rebuilt if a > soname changes (which is also what is done when Core upgrades a soname) works > well. > So he thinks that even mandating a compat package is a bad idea, I'm tryign to find some middle ground here. Regards, Hans From j.w.r.degoede at hhs.nl Tue Jun 27 18:10:04 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jun 2006 20:10:04 +0200 Subject: soname change policy proposal In-Reply-To: References: <44A0E14B.9010200@hhs.nl> Message-ID: <44A1747C.20107@hhs.nl> Kevin Kofler wrote: > Hans de Goede writes: >> 1) When a package update would cause an soname change then a compat >> package with the old libraries must be provided for all release repos, >> that is for all repos except devel. > > IMHO this is ridiculous. Even Core doesn't follow such a strict policy. This is > going to hinder critical security upgrades for packages such as SeaMonkey, and > also leave rapidly-changing libraries (which are the ones needing version > upgrades the most!) stale at old versions (and you can quickly end up with > dozens of compat packages for the same library if it is _really_ rapidly > changing). I think the current policy of simply getting packages rebuilt if a > soname changes (which is also what is done when Core upgrades a soname) works > well. > Did you even bother to read the entire proposal? Thats _exactly_ what the quick and dirty compat rule is for and without these rules we have things like a directfb update causing yum update to fail for days in a row, locking out most users of those o so vital security updates you're defending over here! Also if such a security update is indeed done without any rule on howto properly handle / coordinate the soname change yum update will simply refuse to update, so the fix won't reach its intended audience (the end users). I do agree with you that "you can quickly end up with dozens of compat packages for the same library if it is _really_ rapidly changing" although that can easily be solved simply by: 1) asking maintainers to rebuild against the newest release 2) when releasing a new compat package remove all of the older compat package under the condition that no other package requires that older compat packages. And have you ever considered that if upstream changes the soname every few days that upstream then is seriously borked and you thus have a much bigger problem? Regards, Hans From dragoran at feuerpokemon.de Tue Jun 27 18:10:41 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 27 Jun 2006 20:10:41 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A17253.7040201@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> <44A0C359.6080804@feuerpokemon.de> <44A0E240.60902@hhs.nl> <44A16A5E.6090602@feuerpokemon.de> <44A17253.7040201@hhs.nl> Message-ID: <44A174A1.5050902@feuerpokemon.de> Hans de Goede wrote: > dragoran wrote: > >> 1) after the first start it does not work; (rendering errors and does >> not quit; needs to be killed) >> > Hmm strange > > I still don't know whats going on here after rm -rf ~/.chess setting the config again the first start is broken (black figures looks ugly and there is no menu and no way to quiet the app) >> 2)enabling FSAA give me this error on startup: >> GLRenderSystem::createRenderWindow "OGRE Render Window", 1280x1024 >> fullscreen miscParams: FSAA=6 title=OGRE Render Window >> Could not make screen: Couldn't find matching GLX visual >> > Yes it would be nice if it would try again without FSAA if it can't get > it to work. > > without it works and enabling it using the nvidia controll panel works fine too (and it looks much better with AA ;) ) >> 800x600 window (no FS/ no FSAA) = >> Render Target 'OGRE Render Window' Average FPS: 137.35 Best FPS: 150.943 >> Worst FPS: 123.26 >> > Well thats better then my puny 2 fps :) Atleast it really is a 3D card / > driver problem and not a packaging bug, good. > > Thanks for testing, > np, if you need more feedback/testing just tell me > Hans > > > p.s. > > Anyone with an 9600 / 9800 out there, I would really like to know how > that works in combination with the new opensource driver. I'm somewhat > reluctant to upgrade to a videocard without opensource 3D support. > > From wtogami at redhat.com Tue Jun 27 18:47:45 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Jun 2006 14:47:45 -0400 Subject: FYI: gaim-2.0.0 beta3 in FC6 Message-ID: <44A17D51.8070203@redhat.com> Tomorrow's rawhide will have gaim-2.0.0. This will break API compatibility with the gaim-* plugins currently in FE6, so those respective maintainers need to fix those plugins. gaim-gaym cweyl at alumni.drew.edu gaim-guifications byte at fedoraproject.org gaim-meanwhile jwboyer at jdub.homelinux.org gaim-otr paul at xtdnet.nl Missing from Core will be gadu gadu protocol support because we don't want to add this external library to Core. If anybody really wants that protocol, it must be refactored and built as a modular plugin in Extras. Warren Togami wtogami at redhat.com From jwboyer at jdub.homelinux.org Tue Jun 27 19:36:45 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Jun 2006 14:36:45 -0500 Subject: FYI: gaim-2.0.0 beta3 in FC6 In-Reply-To: <44A17D51.8070203@redhat.com> References: <44A17D51.8070203@redhat.com> Message-ID: <1151437005.22623.7.camel@weaponx.rchland.ibm.com> On Tue, 2006-06-27 at 14:47 -0400, Warren Togami wrote: > Tomorrow's rawhide will have gaim-2.0.0. This will break API > compatibility with the gaim-* plugins currently in FE6, so those > respective maintainers need to fix those plugins. Thanks for the heads up! josh From seg at haxxed.com Tue Jun 27 21:41:48 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 27 Jun 2006 16:41:48 -0500 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A17253.7040201@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <44A0B112.3020507@hhs.nl> <44A0C359.6080804@feuerpokemon.de> <44A0E240.60902@hhs.nl> <44A16A5E.6090602@feuerpokemon.de> <44A17253.7040201@hhs.nl> Message-ID: <1151444508.4684.1.camel@localhost> On Tue, 2006-06-27 at 20:00 +0200, Hans de Goede wrote: > Anyone with an 9600 / 9800 out there, I would really like to know how > that works in combination with the new opensource driver. I'm somewhat > reluctant to upgrade to a videocard without opensource 3D support. I have a 9800 SE, however I can't actually use it as multihead seems to be broken on x86_64. The int10 module doesn't seem to work. As a workaround, I have to use all nvidia cards and use the binary drivers. ;P -------------- 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 Tue Jun 27 21:42:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 28 Jun 2006 00:42:24 +0300 Subject: soname change policy proposal In-Reply-To: <44A11D87.8030802@hhs.nl> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> <44A11D87.8030802@hhs.nl> Message-ID: <1151444545.6570.21.camel@localhost.localdomain> On Tue, 2006-06-27 at 13:59 +0200, Hans de Goede wrote: > Ville Skytt? wrote: > please reread the little howto I wrote, No thanks, I understood it well enough the first time, and my opinions have not changed. > > - Q: How do compat- become purged on distro upgrades? [...] > > EWONTFIX, we have this issue with core provided compat-xxxx packages > already. Seriously? Since when a problem somewhere is a good reason to willingly keep inflicting it elsewhere when simple and effective solutions exist? From kevin.kofler at chello.at Tue Jun 27 21:55:03 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 27 Jun 2006 21:55:03 +0000 (UTC) Subject: soname change policy proposal References: <44A0E14B.9010200@hhs.nl> <44A1747C.20107@hhs.nl> Message-ID: Hans de Goede writes: > Did you even bother to read the entire proposal? Thats _exactly_ what > the quick and dirty compat rule is for and without these rules we have > things like a directfb update causing yum update to fail for days in a > row, locking out most users of those o so vital security updates you're > defending over here! There's an easy fix for that: yum install apt This yum misdesign is the problem, not the soname changes. > Also if such a security update is indeed done > without any rule on howto properly handle / coordinate the soname change > yum update will simply refuse to update, so the fix won't reach its > intended audience (the end users). The update will be done (doable at least, see above paragraph) a few hours later when the reverse dependencies have been rebuilt. Compare this to the compat packages situation where packages can be running against the vulnerable version for months with nobody noticing (no "broken dependencies" report, for example). Also, I want vulnerable packages the h*ll OFF my systems, not put in a compat library! I also generally don't want to have 2+ versions of each library cluttering my hard disk, I want the packages to be updated to work with the latest, and compat packages encourage exactly the opposite (and if I hit the hopefully short window where the package is not rebuilt, instead of the library being held back by apt-rpm, I'll get a compat library installed which will become unnecessary only hours later, what a waste). As for packages outside of Extras, I don't see why they shouldn't be rebuilt too if Extras changes. As a packager of a few unofficial RPMs (which need some cleanups before I can consider submitting them to Extras), I'll definitely rebuild my RPMs as quickly as possible if a soname change in Extras requires it, I don't see why Extras should be forced to provide compat libraries just to allow me or others to be lazy. > I do agree with you that "you can quickly end up with dozens of compat > packages for the same library if it is _really_ rapidly changing" > although that can easily be solved simply by: > 1) asking maintainers to rebuild against the newest release > 2) when releasing a new compat package remove all of the older compat > package under the condition that no other package requires that older > compat packages. It can be solved much MORE simply by not introducing the compat library clutter in the first place and just doing 1). > And have you ever considered that if upstream changes the soname every > few days that upstream then is seriously borked and you thus have a much > bigger problem? That's not something Extras can fix, so it's pointless to discuss here. Kevin Kofler From peter at thecodergeek.com Wed Jun 28 00:32:24 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 27 Jun 2006 17:32:24 -0700 Subject: [solved] Re: Unorphaning Openbox: Commiting new stuff to multiple CVS branches properly? In-Reply-To: <1151398699.2768.56.camel@localhost.localdomain> References: <44A0CB79.6000002@thecodergeek.com> <1151398699.2768.56.camel@localhost.localdomain> Message-ID: <44A1CE18.3040000@thecodergeek.com> Ville Skytt wrote: > On Mon, 2006-06-26 at 23:08 -0700, Peter Gordon wrote: > >> However, it has CVS branch directories for everything from RHL-8 through >> FC-5 and devel. Do I simply run common/cvs-import.sh with my source RPM >> and copy the resultant stuff in devel to the FC-4 and FC-5 branches? Is >> there a cleaner or preffered way to accomplish this? > > Mileages vary which way is cleaner, but cvs-import.sh can be used to > import stuff to existing branches (one at a time), run it without any > options for usage info. > Beautiful. Thank you, Ville. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From michael at knox.net.nz Wed Jun 28 01:43:53 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 28 Jun 2006 13:43:53 +1200 Subject: AWOL owners and stale packages. In-Reply-To: <20060626.204924.545358813.kevin@scrye.com> References: <4463F78F.1080908@knox.net.nz> <20060512131955.5d5055a4.bugs.michael@gmx.net> <446507F2.1060303@knox.net.nz> <20060513204201.b6fdcc5e.bugs.michael@gmx.net> <4469877D.8030505@knox.net.nz> <44878898.4020305@knox.net.nz> <20060608.115125.96779216.kevin@scrye.com> <448A5F2A.7000303@knox.net.nz> <20060612.153858.931257500.kevin@scrye.com> <44906B36.7030207@knox.net.nz> <449F03C4.8000709@knox.net.nz> <20060626.204924.545358813.kevin@scrye.com> Message-ID: <44A1DED9.2090208@knox.net.nz> Kevin Fenzi wrote: >>>>>>"Michael" == Michael J Knox writes: > > > Michael> Hi all... I have finally drafted this guide/policy. Thanks > Michael> to those that chipped in. > > Michael> Kevin, I mostly used your email, just reworded and what not. > > I just reworded other emails. ;) > > Michael> Fell free to pick holes: > > Michael> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > It might be good to to not use "AWOL/MIA". There are probibly lots of > people who don't know what that means. > > How about "Unavailable to continue maintainership" or something like > that? > > In addition to changing the owners.list file, new maintainers should > reassign all open bugs to themselves. > OK, made it read like: unavailable to continue maintainership, often refered to as AWOL (absent without leave) or MIA (missing in action) AWOL/MIA are terms often used, so explaining them here like that might help remove any potential confussion. I also added the comment regarding open bug reports. Thanks! Michael From Matt_Domsch at dell.com Wed Jun 28 03:28:04 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 27 Jun 2006 22:28:04 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-27 Message-ID: <20060628032804.GE10991@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Tue Jun 27 22:08:13 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 126 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 125 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 121 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org perl-Test-WWW-Mechanize jpo at di.uminho.pt pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 4 ---------------------------------- abiword ['196690 NEW'] uwog at uwog.net alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed Jun 28 03:28:41 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 27 Jun 2006 22:28:41 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-27 Message-ID: <20060628032841.GF10991@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Tue Jun 27 22:07:15 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 147 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 136 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 133 ---------------------------------- airsnort andreas.bierfert at lowlatency.de amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora.wickert at arcor.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 3 ---------------------------------- alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora.wickert at arcor.de 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 peter at thecodergeek.com Wed Jun 28 05:07:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 27 Jun 2006 22:07:27 -0700 Subject: Importing Openbox with common/cvs-import.sh: No rule to make target 'upload' Message-ID: <44A20E8F.2090204@thecodergeek.com> Hello, list. I'm attempting to import my Openbox stuff into Extras CVS using cvs-import.sh as mentioned in UsingCvs on the wiki[1], but every time I attempt this, it fails with the error mention in the subject. This is the exact message I receive: [peter at tuxhugger /home/peter/rpmbuild/cvs]$ ./common/cvs-import.sh \ -m "Unorphaning Openbox; update to 3.3-rc2" \ ../SRPMS/openbox-3.3-0.7.rc2.src.rpm Checking out the modules file... Module 'openbox' already exists... Checking out module: 'openbox' Unpacking source package: openbox-3.3-0.7.rc2.src.rpm... L openbox-3.3-rc2.tar.gz A openbox.desktop A openbox.spec make: *** No rule to make target `upload'. Stop. ERROR: Uploading the source tarballs failed! I've attempted to run 'make upload FILES=openbox-3.3-rc2.tar.bz2' with the Makefile.common within the common/ directory, and that appears to have succeeded. Suggestions on how to further proceed would be much appreciated. Would be safe, since the source is already uploaded, to simply comment-out that section of the cvs-import.sh script and run it again? Thanks. [1] http://fedoraproject.org/wiki/UsingCvs -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Wed Jun 28 10:40:12 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Jun 2006 12:40:12 +0200 Subject: Importing Openbox with common/cvs-import.sh: No rule to make target 'upload' In-Reply-To: <44A20E8F.2090204@thecodergeek.com> References: <44A20E8F.2090204@thecodergeek.com> Message-ID: <20060628124012.d959f21d.bugs.michael@gmx.net> On Tue, 27 Jun 2006 22:07:27 -0700, Peter Gordon wrote: > Hello, list. > > I'm attempting to import my Openbox stuff into Extras CVS using > cvs-import.sh as mentioned in UsingCvs on the wiki[1], but every time I > attempt this, it fails with the error mention in the subject. This is > the exact message I receive: > > [peter at tuxhugger /home/peter/rpmbuild/cvs]$ ./common/cvs-import.sh \ > -m "Unorphaning Openbox; update to 3.3-rc2" \ > ../SRPMS/openbox-3.3-0.7.rc2.src.rpm > > Checking out the modules file... > Module 'openbox' already exists... > Checking out module: 'openbox' > Unpacking source package: openbox-3.3-0.7.rc2.src.rpm... > L openbox-3.3-rc2.tar.gz > A openbox.desktop > A openbox.spec > make: *** No rule to make target `upload'. Stop. > ERROR: Uploading the source tarballs failed! > > I've attempted to run 'make upload FILES=openbox-3.3-rc2.tar.bz2' with > the Makefile.common within the common/ directory, and that appears to > have succeeded. > > Suggestions on how to further proceed would be much appreciated. Just try again. I've restored the "Makefile"s for openbox. The cvs-import.sh doesn't cope with missing make-files in existing modules. From paul at city-fan.org Wed Jun 28 12:04:03 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Jun 2006 13:04:03 +0100 Subject: Mock and old distributions In-Reply-To: <44A10C05.3010405@city-fan.org> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> <1151363867.23849.11.camel@ender> <44A10C05.3010405@city-fan.org> Message-ID: <44A27033.8030103@city-fan.org> Paul Howarth wrote: > Jesse Keating wrote: >> On Mon, 2006-06-26 at 22:31 +0100, Paul Howarth wrote: >>> Seeing that the need for elfutils in the buildroot for FC4 was >>> discussed >>> in the latest FESCO meeting, I thought I'd report the results of my >>> efforts to build packages for various old distributions using the >>> current version of mock on FC5: >>> >> >> Thats awesome Paul! Any chance I could get you to add this to the wiki >> somewhere so that it won't be lost? I'm sure we'll need this info at >> some point. > > I'll update the Legacy/Mock page on the wiki. I was about to do that but as I'm not a member of LegacyGroup, I can no longer edit the page. This is another page to add to the growing list of pages that I've edited previously but no longer have edit access to. If someone with the appropriate permissions would like to update the page, a modified version can be found here: http://fedoraproject.org/wiki/PaulHowarth/Legacy/Mock Paul. From buildsys at fedoraproject.org Wed Jun 28 13:10:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Jun 2006 09:10:00 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-28 Message-ID: <20060628131000.D585B15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 22 adplay-1.5-1.fc5 bugzilla-2.22-6.fc5 clips-6.24-8.fc5 conman-0.1.9.2-2.fc5 crystal-1.0.1-2.fc5 dirmngr-0.9.4-4.fc5 inkscape-0.44-2.fc5 lash-0.5.1-5.fc5 libqalculate-0.9.4-3.fc5 munin-1.2.4-9.fc5 nsd-2.3.5-2.fc5 perl-MP3-Info-1.20-2.fc5 php-pecl-apc-3.0.10-3.fc5 python-vobject-0.3.0-1.fc5 sbcl-0.9.14-1.fc5.1 scponly-4.6-5.fc5 sylpheed-2.2.6-3.fc5 taskjuggler-2.2.0-1.fc5 tetex-IEEEtran-1.6c-2.fc5 tetex-perltex-1.3-1.fc5 xmms-adplug-1.2-1.fc5 xwrits-2.22-3.fc5 Packages built and released for Fedora Extras 4: 29 adplay-1.5-1.fc4 bugzilla-2.22-6.fc4 colorscheme-0.3-2.fc4 conman-0.1.9.2-2.fc4 crystal-1.0.1-2.fc4 dirmngr-0.9.4-4.fc4 gcdmaster-1.2.1-4.fc4 gconfmm26-2.10.0-3 gnomad2-2.8.6-1.fc4 gnome-vfsmm26-2.10.0-2 gobby-0.3.0-3.fc4 gparted-0.0.9-4.fc4 inkscape-0.44-2.fc4 libglademm24-2.6.0-2 libgnomecanvasmm26-2.10.0-2 libgnomemm26-2.10.0-2 libgnomeuimm26-2.10.0-2 libqalculate-0.9.4-1.fc4 munin-1.2.4-9.fc4 mysql-administrator-1.1.10-1.fc4.1 nsd-2.3.5-2.fc4 perl-MP3-Info-1.20-2.fc4 regexxer-0.8-4.fc4 sbcl-0.9.14-1.fc4.1 scponly-4.6-5.fc4 taskjuggler-2.2.0-1.fc4 tetex-IEEEtran-1.6c-2.fc4 workrave-1.8.3-1.fc4.1 xmms-adplug-1.2-1.fc4 Packages built and released for Fedora Extras 3: 3 gnomad2-2.8.6-2.fc3 nsd-2.3.5-1.fc3 scponly-4.6-5.fc3 Packages built and released for Fedora Extras development: 25 adplay-1.5-1.fc6 bugzilla-2.22-6.fc6 clips-6.24-8.fc6 conman-0.1.9.2-2.fc6 crystal-1.0.1-2.fc6 exim-4.62-3.fc6 gnomad2-2.8.6-1.fc6 gphpedit-0.9.80-5.fc6 libqalculate-0.9.4-1.fc6 maxima-5.9.3-5.fc6 munin-1.2.4-9.fc6 nsd-2.3.5-3.fc6 perl-Params-Validate-0.85-1.fc6 perl-RRD-Simple-1.39-1.fc6 php-pear-DB-1.7.6-6 pygame-1.7.1-7.fc6.1 python-vobject-0.3.0-1.fc6 qalculate-kde-0.9.4-1.fc6 qt4-4.1.4-2.fc6 scponly-4.6-5.fc6 sylpheed-2.2.6-3.fc6 tetex-IEEEtran-1.6c-2.fc6 tetex-perltex-1.3-1.fc6 xmms-adplug-1.2-1.fc6 xscreensaver-5.00-9.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 Jun 28 13:10:24 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Jun 2006 09:10:24 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-28 Message-ID: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) cscope: 5: 0:15.5-13.7 (FC5-updates) 6: 0:15.5-13.5 (FC6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dillo: 3: 0:0.8.6-1.fc3 (FE3) 4: 0:0.8.5-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-1.fc6 (FE6) dkms: 5: 0:2.0.10-2.fc5 (FE5) 6: 0:2.0.10-1.fc5 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) haddock: 5: 0:0.7-2.fc5 (FE5) 6: 0:0.7-1.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hping2: 5: 0:2.0.0-0.8.rc3 (FE5) 6: 0:2.0.0-0.7.rc3.fc6 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) inkscape: 5: 0:0.44-2.fc5 (FE5) 6: 0:0.43-3.fc5 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libqalculate: 5: 0:0.9.4-3.fc5 (FE5) 6: 0:0.9.4-1.fc6 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) libxml++: 5: 0:2.14.0-1.fc5 (FE5) 6: 0:2.12.0-2.1.fc5 (FE6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nessus-libraries: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) nfs-utils: 5: 0:1.0.8.rc2-5.FC5 (FC5-updates) 6: 0:1.0.8-2 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) pylint: 5: 0:0.11.0-1.fc5 (FE5) 6: 0:0.10.0-1.fc5 (FE6) python-astng: 5: 0:0.16.0-0.fc5 (FE5) 6: 0:0.15.1-1.fc5 (FE6) python-logilab-common: 5: 0:0.15.0-1.fc5 (FE5) 6: 0:0.14.1-2.fc5 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-eurofont: 4: 0:1.1.3-5.fc4 (FE4) 5: 0:1.1.3-2 (FE5) 6: 0:1.1.3-2 (FE6) tetex-fonts-hebrew: 4: 0:0.1-6.fc4 (FE4) 5: 0:0.1-5.fc5 (FE5) 6: 0:0.1-5.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) From jkeating at redhat.com Wed Jun 28 13:47:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 09:47:08 -0400 Subject: Mock and old distributions In-Reply-To: <44A27033.8030103@city-fan.org> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> <44A10C05.3010405@city-fan.org> <44A27033.8030103@city-fan.org> Message-ID: <200606280947.08938.jkeating@redhat.com> On Wednesday 28 June 2006 08:04, Paul Howarth wrote: > I was about to do that but as I'm not a member of LegacyGroup, I can no > longer edit the page. > > This is another page to add to the growing list of pages that I've > edited previously but no longer have edit access to. > > If someone with the appropriate permissions would like to update the > page, a modified version can be found here: > http://fedoraproject.org/wiki/PaulHowarth/Legacy/Mock I've added you to the Legacy Group. have fun! -- 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 paul at city-fan.org Wed Jun 28 14:25:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Jun 2006 15:25:49 +0100 Subject: Mock and old distributions In-Reply-To: <200606280947.08938.jkeating@redhat.com> References: <1151357520.2911.17.camel@laurel.intra.city-fan.org> <44A10C05.3010405@city-fan.org> <44A27033.8030103@city-fan.org> <200606280947.08938.jkeating@redhat.com> Message-ID: <1151504750.7470.13.camel@laurel.intra.city-fan.org> On Wed, 2006-06-28 at 09:47 -0400, Jesse Keating wrote: > On Wednesday 28 June 2006 08:04, Paul Howarth wrote: > > I was about to do that but as I'm not a member of LegacyGroup, I can no > > longer edit the page. > > > > This is another page to add to the growing list of pages that I've > > edited previously but no longer have edit access to. > > > > If someone with the appropriate permissions would like to update the > > page, a modified version can be found here: > > http://fedoraproject.org/wiki/PaulHowarth/Legacy/Mock > > I've added you to the Legacy Group. have fun! Thanks. Page now updated. Paul. From icon at fedoraproject.org Wed Jun 28 14:26:07 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 28 Jun 2006 10:26:07 -0400 Subject: Taking over python-setuptools Message-ID: Ignacio seems to still be away, so I'm going to take over the maintenance of python-setuptools until he reclaims it. I've been blocking on this dependency for a while, since a few projects require a newer version. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From buildsys at fedoraproject.org Wed Jun 28 14:55:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 28 Jun 2006 14:55:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-28 Message-ID: <20060628145544.23517.336@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- dakingun AT gmail.com qalculate-gtk - 0.9.3-1.fc4.i386 qalculate-gtk - 0.9.3-1.fc4.ppc qalculate-gtk - 0.9.3-1.fc4.x86_64 qalculate-kde - 0.9.3.1-2.fc4.i386 qalculate-kde - 0.9.3.1-2.fc4.ppc qalculate-kde - 0.9.3.1-2.fc4.x86_64 ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc4.i386 requires libqalculate.so.2 qalculate-kde-0.9.3.1-2.fc4.i386 requires libqalculate.so.2 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc4.ppc requires libqalculate.so.2 qalculate-kde-0.9.3.1-2.fc4.ppc requires libqalculate.so.2 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc4.x86_64 requires libqalculate.so.2()(64bit) qalculate-kde-0.9.3.1-2.fc4.x86_64 requires libqalculate.so.2()(64bit) wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: dakingun AT gmail.com package: qalculate-gtk - 0.9.3-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libqalculate.so.2 package: qalculate-kde - 0.9.3.1-2.fc4.i386 from fedora-extras-4-i386 unresolved deps: libqalculate.so.2 package: qalculate-gtk - 0.9.3-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libqalculate.so.2()(64bit) package: qalculate-kde - 0.9.3.1-2.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libqalculate.so.2()(64bit) package: qalculate-kde - 0.9.3.1-2.fc4.ppc from fedora-extras-4-ppc unresolved deps: libqalculate.so.2 package: qalculate-gtk - 0.9.3-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libqalculate.so.2 ====================================================================== New report for: rdieter AT math.unl.edu package: maxima-runtime-sbcl - 5.9.3-4.fc4.i386 from fedora-extras-4-i386 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc4.ppc from fedora-extras-4-ppc unresolved deps: sbcl = 0:0.9.13 From buildsys at fedoraproject.org Wed Jun 28 14:55:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 28 Jun 2006 14:55:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-28 Message-ID: <20060628145544.23521.68938@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- dakingun AT gmail.com qalculate-gtk - 0.9.3-1.fc5.i386 qalculate-gtk - 0.9.3-1.fc5.ppc qalculate-gtk - 0.9.3-1.fc5.x86_64 qalculate-kde - 0.9.3.1-2.fc5.i386 qalculate-kde - 0.9.3.1-2.fc5.ppc qalculate-kde - 0.9.3.1-2.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc5.i386 requires libqalculate.so.2 qalculate-kde-0.9.3.1-2.fc5.i386 requires libqalculate.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc5.ppc requires libqalculate.so.2 qalculate-kde-0.9.3.1-2.fc5.ppc requires libqalculate.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 qalculate-gtk-0.9.3-1.fc5.x86_64 requires libqalculate.so.2()(64bit) qalculate-kde-0.9.3.1-2.fc5.x86_64 requires libqalculate.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: dakingun AT gmail.com package: qalculate-gtk - 0.9.3-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libqalculate.so.2 package: qalculate-kde - 0.9.3.1-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libqalculate.so.2 package: qalculate-gtk - 0.9.3-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libqalculate.so.2()(64bit) package: qalculate-kde - 0.9.3.1-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libqalculate.so.2()(64bit) package: qalculate-gtk - 0.9.3-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libqalculate.so.2 package: qalculate-kde - 0.9.3.1-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libqalculate.so.2 ====================================================================== New report for: rdieter AT math.unl.edu package: maxima-runtime-sbcl - 5.9.3-4.fc5.i386 from fedora-extras-5-i386 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: sbcl = 0:0.9.13 package: maxima-runtime-sbcl - 5.9.3-4.fc5.ppc from fedora-extras-5-ppc unresolved deps: sbcl = 0:0.9.13 From buildsys at fedoraproject.org Wed Jun 28 14:55:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 28 Jun 2006 14:55:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-28 Message-ID: <20060628145544.23525.27036@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 dakingun AT gmail.com qalculate-gtk - 0.9.3-1.fc6.i386 qalculate-gtk - 0.9.3-1.fc6.ppc qalculate-gtk - 0.9.3-1.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 rdieter AT math.unl.edu qt4-config - 4.1.4-1.fc6.i386 qt4-config - 4.1.4-1.fc6.ppc qt4-config - 4.1.4-1.fc6.x86_64 skvidal AT phy.duke.edu seahorse - 0.8-3.fc5.i386 seahorse - 0.8-3.fc5.ppc seahorse - 0.8-3.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 qalculate-gtk-0.9.3-1.fc6.i386 requires libqalculate.so.2 qiv-2.0-4.i386 requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.i386 requires qt4 = 0:4.1.4-1.fc6 seahorse-0.8-3.fc5.i386 requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 qalculate-gtk-0.9.3-1.fc6.ppc requires libqalculate.so.2 qiv-2.0-4.ppc requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.ppc requires qt4 = 0:4.1.4-1.fc6 seahorse-0.8-3.fc5.ppc requires libgnutls.so.12 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) qalculate-gtk-0.9.3-1.fc6.x86_64 requires libqalculate.so.2()(64bit) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) qt4-config-4.1.4-1.fc6.x86_64 requires qt4 = 0:4.1.4-1.fc6 seahorse-0.8-3.fc5.x86_64 requires libgnutls.so.12()(64bit) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: cweyl AT alumni.drew.edu package: gaim-gaym - 0.96-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: gaim < 1:2.0.0 package: gaim-gaym - 0.96-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gaim < 1:2.0.0 package: gaim-gaym - 0.96-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: gaim < 1:2.0.0 ====================================================================== New report for: byte AT fedoraproject.org package: gaim-guifications - 2.12-3.fc5.i386 from fedora-extras-development-i386 unresolved deps: gaim < 1:2 package: gaim-guifications - 2.12-3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: gaim < 1:2 package: gaim-guifications - 2.12-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: gaim < 1:2 ====================================================================== New report for: dakingun AT gmail.com package: qalculate-gtk - 0.9.3-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libqalculate.so.2 package: qalculate-gtk - 0.9.3-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libqalculate.so.2()(64bit) package: qalculate-gtk - 0.9.3-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libqalculate.so.2 ====================================================================== New report for: caillon AT redhat.com package: banshee - 0.10.8-1.i386 from fedora-extras-development-i386 unresolved deps: libnautilus-burn.so.3 package: banshee - 0.10.8-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnautilus-burn.so.3()(64bit) package: banshee - 0.10.8-1.ppc from fedora-extras-development-ppc unresolved deps: libnautilus-burn.so.3 ====================================================================== New report for: rdieter AT math.unl.edu package: qt4-config - 4.1.4-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: qt4 = 0:4.1.4-1.fc6 package: qt4-config - 4.1.4-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: qt4 = 0:4.1.4-1.fc6 package: qt4-config - 4.1.4-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: qt4 = 0:4.1.4-1.fc6 ====================================================================== New report for: matthias AT rpmforge.net package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgdk_imlib.so.1 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgdk_imlib.so.1 libgnomeui.so.32 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgdk_imlib.so.1 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: Gtk-Perl - 0.7008-40.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) libgnomesupport.so.0()(64bit) libglade.so.0()(64bit) libart_lgpl.so.2()(64bit) libgtkxmhtml.so.1()(64bit) libgnome.so.32()(64bit) libzvt.so.2()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: Gtk-Perl - 0.7008-40.fc5.ppc from fedora-extras-development-ppc unresolved deps: libglade.so.0 libart_lgpl.so.2 libgnomesupport.so.0 libgnome.so.32 libgdk_imlib.so.1 libgtkxmhtml.so.1 libgnomeui.so.32 libzvt.so.2 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgdk_imlib.so.1 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgdk_imlib.so.1 libgnomeui.so.32 From buildsys at fedoraproject.org Wed Jun 28 14:55:44 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 28 Jun 2006 14:55:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-28 Message-ID: <20060628145544.23508.96443@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From brkamikaze at gmail.com Wed Jun 28 16:32:18 2006 From: brkamikaze at gmail.com (Nikolai) Date: Wed, 28 Jun 2006 13:32:18 -0300 Subject: Looking for a host for a package under review In-Reply-To: References: Message-ID: I was looking for a host for a package under review on the Fedora bugzilla, because the host I am using deletes the files when 2 weeks pass since the upload. The package name is glob2 and is on the 'Bug' 191005 (https://bugzilla.redhat.com /bugzilla/show_bug.cgi?id =191005 ). Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at thecodergeek.com Wed Jun 28 16:53:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 28 Jun 2006 09:53:53 -0700 (PDT) Subject: Looking for a host for a package under review In-Reply-To: References: Message-ID: <41682.127.0.0.1.1151513633.squirrel@www.thecodergeek.com> Nikolai wrote: > I was looking for a host for a package under review on the Fedora > bugzilla, because the host I am using deletes the files when 2 weeks > pass since the upload. The package name is glob2 and is on the 'Bug' > 191005 I've got a lot of unused space/bandwidth on my host, some of which I'd be happy to lend you. Email me the source RPM and spec and I'd be happy to mirror them for you. Alternatively, I could give a decent chunk of FTP space so that you could upload it yourself if you wish (which would probably be simpler in the long run as you could upload new specs/SRPMS yourself). Email me off-list if you're further interested and I'll get the details to you. :) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From Matt_Domsch at dell.com Wed Jun 28 16:58:48 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Jun 2006 11:58:48 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-28 Message-ID: <20060628165848.GC23330@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Wed Jun 28 11:48:51 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 126 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 125 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 120 ---------------------------------- amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net compat-erlang gemi at bluewin.ch contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com erlang gemi at bluewin.ch exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grads pertusus at free.fr grhino michel.salim at gmail.com gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora at christoph-wickert.de Hermes thomas at apestaart.org hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libnasl andreas.bierfert at lowlatency.de librx tcallawa at redhat.com libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com MagicPoint byte at fedoraproject.org mfstools tcallawa at redhat.com multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org orange andreas.bierfert at lowlatency.de p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com python-cheetah mikeb at redhat.com python-goopy pjones at redhat.com python-TestGears ivazquez at ivazquez.net quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru syck oliver at linux-kernel.at synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com With bugs filed: 5 ---------------------------------- abiword ['196690 NEW'] uwog at uwog.net airsnort ['197102 NEW'] andreas.bierfert at lowlatency.de alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed Jun 28 16:59:01 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Jun 2006 11:59:01 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-28 Message-ID: <20060628165901.GD23330@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Wed Jun 28 11:47:20 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 147 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 136 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 132 ---------------------------------- amaya paul at all-the-johnsons.co.uk argus somlo at cmu.edu atitvout andreas.bierfert at lowlatency.de azureus green at redhat.com bazaar shahms at shahms.com bidiv danken at cs.technion.ac.il bmp redhat-bugzilla at camperquake.de camstream nomis80 at nomis80.org ccrtp andreas at bawue.net contact-lookup-applet bdpepple at ameritech.net cowbell foolish at guezz.net ddskk petersen at redhat.com dillo andreas.bierfert at lowlatency.de diradmin matthias at rpmforge.net directfb thomas at apestaart.org drgeo eric.tanguy at univ-nantes.fr driftnet bnocera at redhat.com ebtables tcallawa at redhat.com epiphany-extensions caillon at redhat.com exim dwmw2 at redhat.com exo kevin-redhat-bugzilla at tummy.com factory rdieter at math.unl.edu fish oliver at linux-kernel.at flim petersen at redhat.com flow-tools i at stingr.net foobillard mitr at redhat.com gambas tcallawa at redhat.com gazpacho icon at fedoraproject.org gdesklets luya256 at yahoo.com gif2png enrico.scholz at informatik.tu-chemnitz.de glabels jspaleta at gmail.com gnomad2 triad at df.lth.se gnome-applet-music ivazquez at ivazquez.net gnome-applet-rhythmbox ivazquez at ivazquez.net gnome-schedule frank at scirocco-5v-turbo.de gobby lmacken at redhat.com gphpedit rpm at timj.co.uk grhino michel.salim at gmail.com gstreamer08-python thomas at apestaart.org gsynaptics fedora at leemhuis.info GtkAda gemi at bluewin.ch gtk-gnutella dmitry at butskoy.name Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtk-xfce-engine kevin-redhat-bugzilla at tummy.com gwget fedora at christoph-wickert.de hercules matthias at rpmforge.net hping2 paul at xtdnet.nl ifplugd aaron.bennett at olin.edu jack-audio-connection-kit andy at smile.org.ua jam tcallawa at redhat.com john ghenry at suretecsystems.com kanatest robert at marcanoonline.com kdissert icon at fedoraproject.org kmymoney2 rdieter at math.unl.edu kover adrian at lisas.de ladspa thomas at apestaart.org leafpad ivazquez at ivazquez.net libfac rdieter at math.unl.edu libnasl andreas.bierfert at lowlatency.de libpolyxmass andreas.bierfert at lowlatency.de libtabe llch at redhat.com libtomoe-gtk ryo-dairiki at users.sourceforge.net libtranslate dmitry at butskoy.name licq pvrabec at redhat.com linkchecker redhat at flyn.org logjam tcallawa at redhat.com lucidlife peter at thecodergeek.com Macaulay2 rdieter at math.unl.edu MagicPoint byte at fedoraproject.org mhonarc gauret at free.fr monodoc paul at all-the-johnsons.co.uk multisync andreas.bierfert at lowlatency.de mysql-administrator dennis at ausil.us nautilus-search-tool ivazquez at ivazquez.net ncmpc andreas.bierfert at lowlatency.de nco ed at eh3.com nessus-core andreas.bierfert at lowlatency.de nessus-libraries andreas.bierfert at lowlatency.de NetworkManager-vpnc davidz at redhat.com new redhat at flyn.org ngrep oliver at linux-kernel.at openal andreas.bierfert at lowlatency.de opencv nomis80 at nomis80.org p0f kevin-redhat-bugzilla at tummy.com pam_keyring redhat at flyn.org pam_mount redhat at flyn.org perl-Image-Info jpo at di.uminho.pt perl-Unicode-Map8 gauret at free.fr perl-Unicode-MapUTF8 gauret at free.fr php-pear-DB rpm at timj.co.uk pitivi redhat at flyn.org pl gemi at bluewin.ch powerman jwilson at redhat.com python-cheetah mikeb at redhat.com python-dateutil orion at cora.nwra.com python-goopy pjones at redhat.com python-reportlab bdpepple at ameritech.net python-TestGears ivazquez at ivazquez.net q gemi at bluewin.ch quarry michel.salim at gmail.com rpmDirectoryCheck enrico.scholz at informatik.tu-chemnitz.de rss-glx nphilipp at redhat.com rssowl green at redhat.com sabayon markmc at redhat.com scanssh oliver at linux-kernel.at scmxx andreas at bawue.net scponly wtogami at redhat.com SDL_ttf bdpepple at ameritech.net ser andreas at bawue.net serpentine foolish at guezz.net sloccount bnocera at redhat.com stratagus lemenkov at newmail.ru synce andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de Terminal kevin-redhat-bugzilla at tummy.com tetex-eurofont aportal at univ-montp2.fr uqm icon at fedoraproject.org ushare eric.tanguy at univ-nantes.fr verbiste icon at fedoraproject.org WindowMaker andreas.bierfert at lowlatency.de wlassistant tcallawa at redhat.com wv2 andreas.bierfert at lowlatency.de xaos gemi at bluewin.ch xbindkeys gauret at free.fr xbsql tcallawa at redhat.com xcin llch at redhat.com xplanet jylitalo at iki.fi xprobe2 lmacken at redhat.com xsp paul at all-the-johnsons.co.uk z88dk paul at all-the-johnsons.co.uk With bugs filed: 4 ---------------------------------- airsnort ['197102 NEW'] andreas.bierfert at lowlatency.de alacarte ['194250 NEW'] jpmahowald at gmail.com banshee ['194505 NEW'] caillon at redhat.com xfce4-weather-plugin ['193973 ASSIGNED'] fedora at christoph-wickert.de 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 cweyl at alumni.drew.edu Wed Jun 28 17:44:22 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 28 Jun 2006 10:44:22 -0700 Subject: Looking for a host for a package under review In-Reply-To: References: Message-ID: <7dd7ab490606281044k45a45412o23ec5e97eee69875@mail.gmail.com> On 6/28/06, Nikolai wrote: > I was looking for a host for a package under review on the Fedora > bugzilla, because the host I am using deletes the files when 2 weeks > pass since the upload. The package name is glob2 and is on the 'Bug' > 191005 ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191005). > Thanks in advance. Semi off-topic, perhaps, but for situations like these can't we just attach the spec/srpm into bugzilla directly? Or is this frowned upon? -Chris -- Chris Weyl Ex astris, scientia From ville.skytta at iki.fi Wed Jun 28 18:14:18 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 28 Jun 2006 21:14:18 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> Message-ID: <1151518458.6570.95.camel@localhost.localdomain> On Wed, 2006-06-28 at 09:10 -0400, buildsys at fedoraproject.org wrote: [lots of broken upgrade paths] Sadly, it seems that this whine mail hasn't helped noticeably to kick folks to fix up their packages' upgrade paths, especially between FC-5 and devel. I've filed bugs about a bunch of others cases, and most of them have been fixed, but more breakage is introduced all the time. So, I'm inclined to omit devel from this report for now, and re-enable it closer to the FC6 release, hoping that doing so would trigger people to fix their stuff at least in released distro branches so they're easier to notice and won't be lost in the noise of current FC5->devel brokenness. Objections? Below is an edited version of the previous report; this is what it would have looked like if devel wasn't included. > dillo: > 3: 0:0.8.6-1.fc3 (FE3) > 4: 0:0.8.5-2.fc4 (FE4) > 5: 0:0.8.6-1.fc5 (FE5) > > fish: > 4: 0:1.14.0-1.fc4 (FE4) > 5: 0:1.12.0-1.fc5 (FE5) > > gdesklets: > 4: 0:0.35.3-8.1.fc4 (FE4) > 5: 0:0.35.3-8.fc5 (FE5) > > gnomad2: > 3: 0:2.8.6-2.fc3 (FE3) > 4: 0:2.8.6-1.fc4 (FE4) > 5: 0:2.8.5-1.fc5 (FE5) > > Hermes: > 4: 0:1.3.3-9.fc4 (FE4) > 5: 0:1.3.3-7 (FE5) > > hspell: > 4: 0:1.0-4.fc4 (FE4) > 5: 0:1.0-3.fc5 (FE5) > > m17n-db: > 4: 0:1.3.3-1.fc4 (FE4) > 5: 0:1.3.3-1 (FC5) > > mozilla: > 3: 37:1.7.13-1.3.1.legacy (FL3-updates) > 4: 37:1.7.13-1.1.fc4 (FC4-updates) > 5: 37:1.7.13-1.1.fc5 (FC5-updates) > > paraview: > 4: 0:2.4.3-7.fc4 (FE4) > 5: 0:2.4.3-6.fc5 (FE5) > > perl-String-CRC32: > 4: 0:1.4-1.fc4 (FE4) > 5: 0:1.4-1.FC5 (FC5-updates) > > tetex-eurofont: > 4: 0:1.1.3-5.fc4 (FE4) > 5: 0:1.1.3-2 (FE5) > > tetex-fonts-hebrew: > 4: 0:0.1-6.fc4 (FE4) > 5: 0:0.1-5.fc5 (FE5) > > wine-docs: > 3: 0:0.9.16-1.fc3 (FE3) > 4: 0:0.9.16-0.1.fc4 (FE4) > 5: 0:0.9.16-1.fc5 (FE5) From mmcgrath at fedoraproject.org Wed Jun 28 18:33:05 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 28 Jun 2006 13:33:05 -0500 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <44A2CB61.3090002@fedoraproject.org> Ville Skytt? wrote: > On Wed, 2006-06-28 at 09:10 -0400, buildsys at fedoraproject.org wrote: > [lots of broken upgrade paths] > > Sadly, it seems that this whine mail hasn't helped noticeably to kick > folks to fix up their packages' upgrade paths, especially between FC-5 > and devel. I've filed bugs about a bunch of others cases, and most of > them have been fixed, but more breakage is introduced all the time. > > So, I'm inclined to omit devel from this report for now, and re-enable > it closer to the FC6 release, hoping that doing so would trigger people > to fix their stuff at least in released distro branches so they're > easier to notice and won't be lost in the noise of current FC5->devel > brokenness. Objections? > > Below is an edited version of the previous report; this is what it would > have looked like if devel wasn't included. > > Would it be a lot of work to include a check during the "make tag" or "make plague" that checks to see if it will break an upgrade path? If so exit or require a flag to override? -Mike From nicolas.mailhot at laposte.net Wed Jun 28 19:11:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jun 2006 21:11:23 +0200 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <1151521883.17910.60.camel@rousalka.dyndns.org> Le mercredi 28 juin 2006 ? 21:14 +0300, Ville Skytt? a ?crit : > So, I'm inclined to omit devel from this report for now, and re-enable > it closer to the FC6 release, hoping that doing so would trigger people > to fix their stuff at least in released distro branches so they're > easier to notice and won't be lost in the noise of current FC5->devel > brokenness. Objections? Please don't. You won't get the problems fixed faster by hiding them. Let the report continue to point the problems, and the Fedora release master drill in Red Hat maintainers they should really pay attention to it and fix their stuff. Changing habits take time. Don't give it now. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwilson at redhat.com Wed Jun 28 20:08:02 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Jun 2006 16:08:02 -0400 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <1151525282.3474.6.camel@xavier.boston.redhat.com> On Wed, 2006-06-28 at 21:14 +0300, Ville Skytt? wrote: > On Wed, 2006-06-28 at 09:10 -0400, buildsys at fedoraproject.org wrote: > [lots of broken upgrade paths] > > Sadly, it seems that this whine mail hasn't helped noticeably to kick > folks to fix up their packages' upgrade paths, especially between FC-5 > and devel. I've filed bugs about a bunch of others cases, and most of > them have been fixed, but more breakage is introduced all the time. > > So, I'm inclined to omit devel from this report for now, and re-enable > it closer to the FC6 release, hoping that doing so would trigger people > to fix their stuff at least in released distro branches so they're > easier to notice and won't be lost in the noise of current FC5->devel > brokenness. Objections? I'd keep sending everything. Sooner or later, people might start to actually take notice and start fixing things. I've stripped the output down to the upgrade paths that are broken in core, with the intention of doing something about it rather soonish. -- 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 paul at all-the-johnsons.co.uk Wed Jun 28 21:07:00 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 28 Jun 2006 22:07:00 +0100 Subject: My BZs Message-ID: <1151528821.7981.104.camel@T7.Linux> Hi, I should apologise for not responding to any BZs made since last Thursday. I've been hit by the flu which has just about drained the life out of me. Normal service should resume next week at some point. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 cypherpunks.ca Wed Jun 28 21:16:30 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 28 Jun 2006 23:16:30 +0200 (CEST) Subject: Broken upgrade paths discussion In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: On Wed, 28 Jun 2006, Ville Skytt? wrote: > [lots of broken upgrade paths] > Sadly, it seems that this whine mail hasn't helped noticeably to kick > folks to fix up their packages' upgrade paths, especially between FC-5 > and devel. I've filed bugs about a bunch of others cases, and most of > them have been fixed, but more breakage is introduced all the time. Since ville and me were discussing this on bugzilla's item on a package I maintain that had such an issue, let's talk about it here instead. See previous discussion: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193623 Ville suggested using the following 3: 0:2.3.4-3.fc3.2 4: 0:2.3.4-3.fc4.1 5: 0:2.3.4-3.fc5.1 6: 0:2.3.4-3.fc6 Now to mee this seems like a bad hack. If I fix a bug in FC4, for version 2.3.4-3, then it should have the version number of 2.3.4-4.fc4 and not 2.3.4-3.fc4.2. This just introduces yet another versioning number. If we need to fix upgrade paths by making things obvious, we should pull the disttag more to left, eg: 3: 0:2.3.4.fc3-2 4: 0:2.3.4.fc4-1 5: 0:2.3.4.fc5-1 6: 0:2.3.4.fc6-3 Additionally, what happens if all distros are now upgrade, so they are all version 2.3.5-1, and the user upgrades from fc3 to fc4? Shouldn't it replace the identical version with the package from the newer distribution, instead of leaving the old package there? What if some dependancy changed, so the fc3 version cannot work but the fc4 version with the same version number does work (eg nptl vs no nptl or whatever). Personally, I think an upgrade using anaconda/yum should have the additional logic to do the right thing, and even go from 2.3.4-3.fc3 to 2.3.4-1.fc4 during an upgrade, if that is what is available, and only leave old dist versions of software that is not available in the new dist version (and not Obsoleted: by some other package in the new dist). Apart from this issue, most of my "more fixes in older distributions" were due to make tag breaking halfway through, with as only fix to bump the version. Fixing that problem once and for all would probably greatly reduce the amount of these upgrade path issues. Paul From michael at knox.net.nz Wed Jun 28 21:57:00 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 29 Jun 2006 09:57:00 +1200 Subject: FE Package Status of Jun 29, 2006 Message-ID: <44A2FB2C.1000804@knox.net.nz> Hi all, Here is the "getting close to be weekly" Extras report. Enjoy and keep up that hard work! Michael FE Package Status of Jun 29, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1914 packages - 37 orphans - 33 packages not available in extras devel or release Matt_Domsch at dell dot com aiccu bugs dot michael at gmx dot net libgcrypt1 cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode dennis at ausil dot us cryptplug drfickle at k-lug dot org libhugetlbfs fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin matteo dot ricchetti at libero dot it ss5 matthias at rpmforge dot net php-pecl-pdo matthias at rpmforge dot net php-pecl-pdo-sqlite matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache nomis80 at nomis80 dot org juk notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard peter at thecodergeek dot com openbox tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com openoffice-extras wtogami at redhat dot com iiimf-le-simplehangul - 7 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep dakingun at gmail dot com baobab jlayton at redhat dot com xwrits noa at resare dot com vorbisgain zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 3 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 ktorrent Roland Wolters Maelstrom Bill Nottingham https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=184080 webmin Jason Vas Dias - 1 packages present in the development repo which have no owners entry php-apc - 2 orphaned packages, yet available in extras devel gtkglarea2 soundtracker - 39 packages that moved to core Packages appearing both in Core and Extras: - 2 packages duplicated for devel: petersen at redhat dot com scim-bridge tagoh at redhat dot com paps FE-ACCEPT packages stats: - 968 accepted, closed package reviews - 6 accepted, closed package reviews not in repo - 2 accepted, closed package reviews not in owners - 13 accepted, open package reviews older than 4 weeks; - 9 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 100 open tickets - 23 tickets with no activity in eight weeks - 21 tickets with no activity in four weeks - 2 closed tickets FE-NEW packages stats: - 176 open tickets - 19 tickets with no activity in eight weeks - 33 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 30 open tickets - 9 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets - 1 tickets with no activity in four weeks OPEN-BUGS packages stats: - 218 open tickets - 145 tickets with no activity in eight weeks - 17 tickets with no activity in four weeks CVS stats: - 1921 packages with a devel directory - 28 packages with no owners entry gpasman grandr_applet gsview initng k3b-ape kernel-module-thinkpad kile-i18n kimdaba libexif muse nethack-falconseye pcb perl-Convert-ASN1 perl-DateManip perl-GD-SVG perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX perl-XML-Writer perl-bioperl php-apc python-ldap - 2 packages in CVS devel *and* Core libevent paps - 78 packages were dropped from extras Maintainers stats: - 207 maintainers - 15 inactive maintainers with open bugs - 28 inactive maintainers Dropped FC packages: - 258 packages were dropped from core since FC 1 From dennis at ausil.us Wed Jun 28 22:28:17 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Jun 2006 17:28:17 -0500 (CDT) Subject: Broken upgrade paths discussion In-Reply-To: References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> > On Wed, 28 Jun 2006, Ville Skytt? wrote: > >> [lots of broken upgrade paths] > >> Sadly, it seems that this whine mail hasn't helped noticeably to kick >> folks to fix up their packages' upgrade paths, especially between FC-5 >> and devel. I've filed bugs about a bunch of others cases, and most of >> them have been fixed, but more breakage is introduced all the time. > > Since ville and me were discussing this on bugzilla's item on a package > I maintain that had such an issue, let's talk about it here instead. > > See previous discussion: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193623 > > Ville suggested using the following > > 3: 0:2.3.4-3.fc3.2 > 4: 0:2.3.4-3.fc4.1 > 5: 0:2.3.4-3.fc5.1 > 6: 0:2.3.4-3.fc6 > > Now to mee this seems like a bad hack. If I fix a bug in FC4, for version That is very sane to me > 2.3.4-3, then it should have the version number of 2.3.4-4.fc4 and not > 2.3.4-3.fc4.2. This just introduces yet another versioning number. If > we need to fix upgrade paths by making things obvious, we should pull the > disttag more to left, eg: > > 3: 0:2.3.4.fc3-2 > 4: 0:2.3.4.fc4-1 > 5: 0:2.3.4.fc5-1 > 6: 0:2.3.4.fc6-3 thats now part of the version that is not a good thing the version should always match upstream > Additionally, what happens if all distros are now upgrade, so they are all > version 2.3.5-1, and the user upgrades from fc3 to fc4? Shouldn't it > replace > the identical version with the package from the newer distribution, > instead > of leaving the old package there? What if some dependancy changed, so the > fc3 version cannot work but the fc4 version with the same version number > does work (eg nptl vs no nptl or whatever). It will work the way you describe the dist tag ensures that an upgrade from fc4 to fc5 will work as expected by updating the package 2.3.5-1.fc5 is higher than 2.3.5-1.fc4 why because of the 4 and 5 at the end. > Personally, I think an upgrade using anaconda/yum should have the > additional > logic to do the right thing, and even go from 2.3.4-3.fc3 to 2.3.4-1.fc4 > during an upgrade, if that is what is available, and only leave old dist > versions of software that is not available in the new dist version (and > not > Obsoleted: by some other package in the new dist). Ok lets look at the logic here 2.3.4-3.fc3 2.3.4-1.fc4 yum and rpm look at the above two senarios and say the 2.3.4-3.fc3 is higher than 2.3.4-1.fc4 because of simple math 3.x is higher than 1.x rpm and yum do not understand disttags they are a macro we use to differenciate between the releases. it makes sense to us to go oh fc4 is higher than fc3 but we are mathmeticly doing the comparison > Apart from this issue, most of my "more fixes in older distributions" were > due to make tag breaking halfway through, with as only fix to bump the > version. > Fixing that problem once and for all would probably greatly reduce the > amount > of these upgrade path issues. > add a .x etc to the end is is the least significant bit If you build a package with a disttag outside of the buildsys or mock you will have an empty tag it will not be there. Dennis From notting at redhat.com Wed Jun 28 23:55:32 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jun 2006 19:55:32 -0400 Subject: soname change policy proposal In-Reply-To: <1151398545.2768.52.camel@localhost.localdomain> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> Message-ID: <20060628235532.GH2612@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > For released branches, we assume that a smoothly working compat-foo has > been already created before the incompatible upgrade is pushed and it > has stayed in a review for a little while anyway. So there's no wait > period, but the notice must be posted to the fedora-maintainers list > when the new compat package is posted for review, and the review bug > number is included in that notice. Might want a way here to coordinate release of compat-foo with new-foo, to ensure they aren't pushed out of sync. Bill From jkeating at redhat.com Thu Jun 29 00:36:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 20:36:47 -0400 Subject: Broken upgrade paths discussion In-Reply-To: <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> Message-ID: <200606282036.51362.jkeating@redhat.com> On Wednesday 28 June 2006 18:28, Dennis Gilmore wrote: > If you build a package with a disttag outside of the buildsys or mock you > will have an empty tag ?it will not be there. *cough* rpmbuild --rebuild --define="dist .fc6" foo.src.rpm (; -- 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 paul at cypherpunks.ca Thu Jun 29 01:20:42 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 29 Jun 2006 03:20:42 +0200 (CEST) Subject: pcap.h changed in devel/rawhide (fc6) ? Message-ID: Hi, I don't have a rawhide/devel or FC6test1 box anywhere yet, and mock is not building hping2 because it cannot find pcap.h. Can someone with access to a such a machine tell me what rpm -ql libpcap says about pcap.h and/or pcap-bpf.h? Or did this move to a libpcap-devel package? Thanks, Paul From katzj at redhat.com Thu Jun 29 01:34:55 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Jun 2006 21:34:55 -0400 Subject: pcap.h changed in devel/rawhide (fc6) ? In-Reply-To: References: Message-ID: <1151544895.21379.3.camel@aglarond.local> On Thu, 2006-06-29 at 03:20 +0200, Paul Wouters wrote: > I don't have a rawhide/devel or FC6test1 box anywhere yet, and mock is not > building hping2 because it cannot find pcap.h. > > Can someone with access to a such a machine tell me what rpm -ql libpcap > says about pcap.h and/or pcap-bpf.h? Or did this move to a libpcap-devel > package? Yes, there's now libpcap-devel Note that you can use repoquery against the devel repo to look at such things even if you don't have an install of rawhide Jeremy From peter at thecodergeek.com Thu Jun 29 01:49:19 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 28 Jun 2006 18:49:19 -0700 Subject: [resolved] Re: Importing Openbox with common/cvs-import.sh: No rule to make target 'upload' In-Reply-To: <20060628124012.d959f21d.bugs.michael@gmx.net> References: <44A20E8F.2090204@thecodergeek.com> <20060628124012.d959f21d.bugs.michael@gmx.net> Message-ID: <44A3319F.4090007@thecodergeek.com> Michael Schwendt wrote: > Just try again. I've restored the "Makefile"s for openbox. The > cvs-import.sh doesn't cope with missing make-files in existing modules. That did it. Thank you very much for your help! -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Thu Jun 29 01:50:48 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 28 Jun 2006 18:50:48 -0700 Subject: My BZs In-Reply-To: <1151528821.7981.104.camel@T7.Linux> References: <1151528821.7981.104.camel@T7.Linux> Message-ID: <44A331F8.3090700@thecodergeek.com> Paul wrote: > I should apologise for not responding to any BZs made since last > Thursday. I've been hit by the flu which has just about drained the life > out of me. > > Normal service should resume next week at some point. > Good to hear from you, Paul. Hope you feel better soon. (Chicken soup and hugs heal all!) Take care. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From paul at cypherpunks.ca Thu Jun 29 02:00:52 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 29 Jun 2006 04:00:52 +0200 (CEST) Subject: FYI: gaim-2.0.0 beta3 in FC6 In-Reply-To: <44A17D51.8070203@redhat.com> References: <44A17D51.8070203@redhat.com> Message-ID: On Tue, 27 Jun 2006, Warren Togami wrote: > Tomorrow's rawhide will have gaim-2.0.0. This will break API compatibility > with the gaim-* plugins currently in FE6, so those respective maintainers > need to fix those plugins. > > gaim-gaym cweyl at alumni.drew.edu > gaim-guifications byte at fedoraproject.org > gaim-meanwhile jwboyer at jdub.homelinux.org > gaim-otr paul at xtdnet.nl Thanks. I tried some testing on an fc4 box, but all of gnome needs to be never for gaim-2.0.0 , so I'll have to commit and test using the build system, since I don't have any FC6test1 or even fc5 box available now. But it will be fixed over the next few days. Paul From tibbs at math.uh.edu Thu Jun 29 02:06:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 28 Jun 2006 21:06:42 -0500 Subject: pcap.h changed in devel/rawhide (fc6) ? In-Reply-To: (Paul Wouters's message of "Thu, 29 Jun 2006 03:20:42 +0200 (CEST)") References: Message-ID: >>>>> "PW" == Paul Wouters writes: PW> I don't have a rawhide/devel or FC6test1 box anywhere yet, and PW> mock is not building hping2 because it cannot find pcap.h. I'm wondering if you're reading your bugzilla mail, because I included information about this in my review of hping3. Unfortunately I didn't see any response to the review or the two following pings. You need to BR: libpcap-devel on rawhide. - J< From denis at poolshark.org Thu Jun 29 02:13:47 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 28 Jun 2006 19:13:47 -0700 Subject: wp_tray rebuild Message-ID: <44A3375B.1020800@poolshark.org> Does anyone mind if I deal with bug 196911 myself ? It's just a rebuild of Ignacio's wp_tray. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 -denis From michael at knox.net.nz Thu Jun 29 02:18:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 29 Jun 2006 14:18:21 +1200 Subject: wp_tray rebuild In-Reply-To: <44A3375B.1020800@poolshark.org> References: <44A3375B.1020800@poolshark.org> Message-ID: <44A3386D.5000303@knox.net.nz> Denis Leroy wrote: > Does anyone mind if I deal with bug 196911 myself ? It's just a rebuild > of Ignacio's wp_tray. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 Well I think it would be good karma to wait a little more than 2 days ;) This where a AWOL/MIA policy would come in handy :D Michael From work.eric at gmail.com Thu Jun 29 02:59:14 2006 From: work.eric at gmail.com (Eric Work) Date: Wed, 28 Jun 2006 19:59:14 -0700 Subject: Clarification on Packaging Guidelines Message-ID: I was previously unsure whether %pre/%post ldconfig lines on shared library devel packages were needed. In a recent discussion with some others on #fedora-extras I was informed that they were not needed. Maybe a blurb about this should be added to the Packaging Guidelines in the scriptlet section on shared libraries. What is the opinion of others on this matter? -Eric From dennis at ausil.us Thu Jun 29 03:43:49 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Jun 2006 22:43:49 -0500 Subject: Broken upgrade paths discussion In-Reply-To: <200606282036.51362.jkeating@redhat.com> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> <200606282036.51362.jkeating@redhat.com> Message-ID: <200606282243.49758.dennis@ausil.us> On Wednesday 28 June 2006 7:36 pm, Jesse Keating wrote: > On Wednesday 28 June 2006 18:28, Dennis Gilmore wrote: > > If you build a package with a disttag outside of the buildsys or mock you > > will have an empty tag ?it will not be there. > > *cough* > > rpmbuild --rebuild --define="dist .fc6" foo.src.rpm > > (; unless you define the macro when you build :D or you have the buildsys-macros package installed. which most people will do neither From dennis at ausil.us Thu Jun 29 03:45:23 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Jun 2006 22:45:23 -0500 Subject: pcap.h changed in devel/rawhide (fc6) ? In-Reply-To: References: Message-ID: <200606282245.23502.dennis@ausil.us> On Wednesday 28 June 2006 9:06 pm, Jason L Tibbitts III wrote: > >>>>> "PW" == Paul Wouters writes: > > PW> I don't have a rawhide/devel or FC6test1 box anywhere yet, and > PW> mock is not building hping2 because it cannot find pcap.h. > > I'm wondering if you're reading your bugzilla mail, because I included > information about this in my review of hping3. Unfortunately I didn't > see any response to the review or the two following pings. > > You need to BR: libpcap-devel on rawhide. I did this in the snort package if you want a guide on how to do it Dennis From jwilson at redhat.com Thu Jun 29 03:52:01 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Jun 2006 23:52:01 -0400 Subject: Broken upgrade paths discussion In-Reply-To: <200606282036.51362.jkeating@redhat.com> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> <200606282036.51362.jkeating@redhat.com> Message-ID: <44A34E61.2030408@redhat.com> Jesse Keating wrote: > On Wednesday 28 June 2006 18:28, Dennis Gilmore wrote: >> If you build a package with a disttag outside of the buildsys or mock you >> will have an empty tag it will not be there. > > *cough* > > rpmbuild --rebuild --define="dist .fc6" foo.src.rpm Or if you find yourself running into this often (and caring), throw this in ~/.rpmmacros: %dist .fc6 Craftier ways are available to dynamically determine fc vs. el, 4 vs. 5 vs. 6, etc., but they can get messy in a hurry. -- Jarod Wilson jwilson at redhat.com From Axel.Thimm at ATrpms.net Thu Jun 29 05:29:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Jun 2006 07:29:56 +0200 Subject: soname change policy proposal In-Reply-To: <44A0E14B.9010200@hhs.nl> References: <44A0E14B.9010200@hhs.nl> Message-ID: <20060629052956.GA27753@neu.nirvana> Hi, On Tue, Jun 27, 2006 at 09:42:03AM +0200, Hans de Goede wrote: > I've been thinking about this for a while and I think its time for a > brain dump, so here is a first shot at a soname change policy: I agree with Ville to prepend this with the (soft) requirement to try to remain ABI compatible within a distribution. > 1) When a package update would cause an soname change then a compat > package with the old libraries must be provided for all release repos, > that is for all repos except devel. > 1a) This compat package must be successfully build before a build of > the update causing the change may be requested. > 1b) If an update causing a soname change will only be build for devel > a compat package is not mandatory. In this case however other packagers > must be warned, with the warning containing a way for them to get the > new version. After the warning one must wait 7 days minimum before the > new version may be build. I had a similar suggestion some time back on this list, where I tried to persuade to use compat-like packages from the beginning, so that there is no need to rebuild new old-packages and rereview them, and also no need to sync compat vs new packages, coordinate rebuilds of all dependent packages and the like. It is also both backward and forward compatible: Simply subpackage the library components in libfoo packages like Debian/Mandriva/ATrpms are doing. The libfoos are already your compat packages, when a new bump happens libfoo simply appears in the repo next to the to be outphased libfoo. Applications can be rebuilt against the new foo at their own pace. No review of the compat-becoming libfoo is neccessary, since it hasn't changed, not only in theory, but it is still the same well-known binary with the same rpm metadata. No subtle rpm meta-obsoletes due to Provides: of some common resource (see Rex' comment). The only drawback: Your system doesn't cater for old and unused libfoos. But that's fixable by tagging the packages. For example ATrpms uses Provides: shared-library-package, so all such compat packages can be found with a simple rpm -q --whatprovides shared-library-package, for example: # rpm -q --whatprovides shared-library-package libsrs_alt1-1.0-2_rc1.rhfc5.at libbeecrypt6-4.1.2-9.2_11.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libspf2_2-1.2.5-4.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libdirect-0.9_24-0.9.24-8.rhfc5.at libfusion-0.9_24-0.9.24-8.rhfc5.at Therefore one could easily implement a "package garbage collector". The poor man's implementation would look like rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' --whatprovides shared-library-package | xargs -l1 rpm -e 2> /dev/null [As a side-effect you get multi-repo combinations working better, since repos are using different libfoo. This isn't an argument for Fedora Core/Extras, but it was the motivation for ATrpms to use that method. Still given the size of Fedora Extras having larger time windows for libfoo transitions of dependent packages is a good thing and comparable to the not-synced upgrading of libfoo in different repos, e.g. in Fedora Core/Extras semantics: no need for alarms at fedora-maintainers etc.] This scheme works very nice. The question I still have is whether to only apply it to a very selected set of packages known from the past to aggressively bump sonames, or whether it makes sense to have this as a general guideline to avoid ever getting into such a trap again. I guess in order to find out how well this scheme works the first model could be tried out on the problematic packages and depending on success/failure it could be extended to further 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 Axel.Thimm at ATrpms.net Thu Jun 29 05:35:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Jun 2006 07:35:27 +0200 Subject: Broken upgrade paths discussion In-Reply-To: <200606282036.51362.jkeating@redhat.com> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <58294.68.254.239.133.1151533697.squirrel@webmail.ausil.us> <200606282036.51362.jkeating@redhat.com> Message-ID: <20060629053527.GB27753@neu.nirvana> On Wed, Jun 28, 2006 at 08:36:47PM -0400, Jesse Keating wrote: > On Wednesday 28 June 2006 18:28, Dennis Gilmore wrote: > > If you build a package with a disttag outside of the buildsys or mock you > > will have an empty tag ?it will not be there. > > *cough* > > rpmbuild --rebuild --define="dist .fc6" foo.src.rpm > > (; > The point for %{?dist} was to still allow the package to build w/o special handling on the user's side _and_ place it into a well known upgrade path (below the one from the 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 Thu Jun 29 05:41:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Jun 2006 07:41:53 +0200 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <20060629054153.GC27753@neu.nirvana> On Wed, Jun 28, 2006 at 09:14:18PM +0300, Ville Skytt? wrote: > On Wed, 2006-06-28 at 09:10 -0400, buildsys at fedoraproject.org wrote: > [lots of broken upgrade paths] > > Sadly, it seems that this whine mail hasn't helped noticeably to kick > folks to fix up their packages' upgrade paths, especially between FC-5 > and devel. I've filed bugs about a bunch of others cases, and most of > them have been fixed, but more breakage is introduced all the time. > > So, I'm inclined to omit devel from this report for now, and re-enable > it closer to the FC6 release, hoping that doing so would trigger people > to fix their stuff at least in released distro branches so they're > easier to notice and won't be lost in the noise of current FC5->devel > brokenness. Objections? I wouldn't remove, but sort them differently. E.g. o broken FL issues are highest priority, because they hinder upgrades to current releases and are hard to fix + take quite some time to find a solutions. o Next come FC+FE issues of active releases. No FL or devel o Finally devel issues Some packages hit multiple categories, in that case only mention them in the most urgent category (but with all broken paths, not only the category relevant). Alternatively they could be cast in all categories they are part of. The FL related breakage part could be automatically sent to the FL list, otherwise it will go unnoticed. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Jun 29 05:48:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Jun 2006 07:48:56 +0200 Subject: fedora legacy broken upgrade paths (was: Broken upgrade paths in FC+FE 2006-06-28) In-Reply-To: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> Message-ID: <20060629054856.GD27753@neu.nirvana> Hi, I extracted the FL relevant parts of broken upgrade paths. This is part of an automated mail sent to the fedora-extras list: On Wed, Jun 28, 2006 at 09:10:24AM -0400, buildsys at fedoraproject.org wrote: > mozilla: > 3: 37:1.7.13-1.3.1.legacy (FL3-updates) > 4: 37:1.7.13-1.1.fc4 (FC4-updates) > 5: 37:1.7.13-1.1.fc5 (FC5-updates) > 6: 37:1.7.13-1.1.fc5 (FC6) This happend because instead of "fc3" the disttag was chosen to be simply "3" which is rpm-bigger than any "fcX". The only way to fix FL broken paths is to bump the evr of the subsequent releases :/ FL or a spokesman of FL like Jesse need to lobby FC or FE for something like this to happen. Let's hope there will be some new security issue in mozilla 1.7.13 soon ;) -- 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 chabotc at xs4all.nl Thu Jun 29 07:37:37 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Thu, 29 Jun 2006 09:37:37 +0200 Subject: wp_tray rebuild In-Reply-To: <44A3386D.5000303@knox.net.nz> Message-ID: <000a01c69b4e$e7e9c750$4001a8c0@chabot> In my experience when I reviewed that package, the maintainer can sometimes be slow to respond. Did you try sending him an e-mail directly? -----Original Message----- From: fedora-extras-list-bounces at redhat.com [mailto:fedora-extras-list-bounces at redhat.com] On Behalf Of Michael J. Knox Sent: Thursday, June 29, 2006 04:18 To: Discussion related to Fedora Extras Subject: Re: wp_tray rebuild Denis Leroy wrote: > Does anyone mind if I deal with bug 196911 myself ? It's just a rebuild > of Ignacio's wp_tray. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 Well I think it would be good karma to wait a little more than 2 days ;) This where a AWOL/MIA policy would come in handy :D Michael -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list From dhowells at redhat.com Thu Jun 29 09:07:45 2006 From: dhowells at redhat.com (David Howells) Date: Thu, 29 Jun 2006 10:07:45 +0100 Subject: My BZs In-Reply-To: <44A331F8.3090700@thecodergeek.com> References: <44A331F8.3090700@thecodergeek.com> <1151528821.7981.104.camel@T7.Linux> Message-ID: <7270.1151572065@warthog.cambridge.redhat.com> Peter Gordon wrote: > Good to hear from you, Paul. Hope you feel better soon. > (Chicken soup and hugs heal all!) Nah... Chicken Vindaloo! David From paul at city-fan.org Thu Jun 29 09:29:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 Jun 2006 10:29:20 +0100 Subject: Clarification on Packaging Guidelines In-Reply-To: References: Message-ID: <1151573361.7470.145.camel@laurel.intra.city-fan.org> On Wed, 2006-06-28 at 19:59 -0700, Eric Work wrote: > I was previously unsure whether %pre/%post ldconfig lines on shared > library devel packages were needed. In a recent discussion with some > others on #fedora-extras I was informed that they were not needed. > Maybe a blurb about this should be added to the Packaging Guidelines > in the scriptlet section on shared libraries. What is the opinion of > others on this matter? Not sure what you mean by "shared library devel packages". Do you mean "-devel packages for shared libraries where the shared libraries are actually in the main package" (the normal case), or "-devel packages that include within them shared libraries (not just symlinks)" (the unusual case, e.g. for openais, which recently went into Core)? I believe that ldconfig should be called in %post and %postun for the actual package that contains a shared library (not just symlinks) if (and only if) the shared library is in ldconfig's search path. So in the normal case this would result in ldconfig being used in the main package and not the devel package, and in the openais case it was required in the devel package and not the main package. Paul. From paul at all-the-johnsons.co.uk Thu Jun 29 09:32:35 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 29 Jun 2006 10:32:35 +0100 Subject: My BZs In-Reply-To: <7270.1151572065@warthog.cambridge.redhat.com> References: <44A331F8.3090700@thecodergeek.com> <1151528821.7981.104.camel@T7.Linux> <7270.1151572065@warthog.cambridge.redhat.com> Message-ID: <1151573555.7981.111.camel@T7.Linux> On Thu, 2006-06-29 at 10:07 +0100, David Howells wrote: > Peter Gordon wrote: > > > Good to hear from you, Paul. Hope you feel better soon. > > (Chicken soup and hugs heal all!) > > Nah... Chicken Vindaloo! Chicken soup might as well be chicken vindaloo. Average food intake per day, a couple of slices of bread, some jellies and lots of fluid. If I drink a soup at midday, I'm pretty stuffed until 10 at night by which time, I'm dead on my feet. Thanks anyways :-) TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 dan at danny.cz Thu Jun 29 10:50:25 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 29 Jun 2006 12:50:25 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151357549.3500.10.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> Message-ID: <1151578225.20651.5.camel@eagle.danny.cz> > > > > I could test it on NVidia 6600GT with binary drivers. > > I am getting a segfault on FC4 when trying to run the Chess. I will look > at this problem during the next days. The segfault was caused by Ogre libraries conflict (Extras vs. local). On the NVidia 6600GT it shows a nice rotating board with a hand moving the "objects" (stones/characters?) but I can't press any key and after killing the game the mouse is dead. Dan From j.w.r.degoede at hhs.nl Thu Jun 29 11:25:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jun 2006 13:25:34 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151578225.20651.5.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> Message-ID: <44A3B8AE.6040800@hhs.nl> Dan Hor?k wrote: >>> I could test it on NVidia 6600GT with binary drivers. >> I am getting a segfault on FC4 when trying to run the Chess. I will look >> at this problem during the next days. > > The segfault was caused by Ogre libraries conflict (Extras vs. local). > On the NVidia 6600GT it shows a nice rotating board with a hand moving > the "objects" (stones/characters?) but I can't press any key and after > killing the game the mouse is dead. > Hmm, you see the board but you don't see the menu? Also you don't see chess pieces instead of "objects" ? Regards, Hans From dan at danny.cz Thu Jun 29 11:40:56 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 29 Jun 2006 13:40:56 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A3B8AE.6040800@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> Message-ID: <1151581256.20651.11.camel@eagle.danny.cz> Hans de Goede p??e v ?t 29. 06. 2006 v 13:25 +0200: > Dan Hor?k wrote: > >>> I could test it on NVidia 6600GT with binary drivers. > >> I am getting a segfault on FC4 when trying to run the Chess. I will look > >> at this problem during the next days. > > > > The segfault was caused by Ogre libraries conflict (Extras vs. local). > > On the NVidia 6600GT it shows a nice rotating board with a hand moving > > the "objects" (stones/characters?) but I can't press any key and after > > killing the game the mouse is dead. > > > > Hmm, you see the board but you don't see the menu? Also you don't see Yes, I don't see the menu on both FC4+NVidia and FC6+Ati (without accelerated binary driver). Both were run in fullcscreen mode and in display's native resolution. > chess pieces instead of "objects" ? I did not know the english chess terminology ;-) Yes, there are nice chess pieces. Dan From j.w.r.degoede at hhs.nl Thu Jun 29 11:48:10 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jun 2006 13:48:10 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151581256.20651.11.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> <1151581256.20651.11.camel@eagle.danny.cz> Message-ID: <44A3BDFA.40209@hhs.nl> Dan Hor?k wrote: > Hans de Goede p??e v ?t 29. 06. 2006 v 13:25 +0200: >> Dan Hor?k wrote: >>>>> I could test it on NVidia 6600GT with binary drivers. >>>> I am getting a segfault on FC4 when trying to run the Chess. I will look >>>> at this problem during the next days. >>> The segfault was caused by Ogre libraries conflict (Extras vs. local). >>> On the NVidia 6600GT it shows a nice rotating board with a hand moving >>> the "objects" (stones/characters?) but I can't press any key and after >>> killing the game the mouse is dead. >>> >> Hmm, you see the board but you don't see the menu? Also you don't see > > Yes, I don't see the menu on both FC4+NVidia and FC6+Ati (without > accelerated binary driver). Both were run in fullcscreen mode and in > display's native resolution. > Hmm, thats strange are you sure you're using ogre compiled from my srpm and chess compiled from my srpm? I recently fixed a bug in ogre which caused the menu text to not show, but the menu border should be there. Either way can you download the latest ogre from here: http://people.atrpms.net/~hdegoede Build and install it and give that a spin? Regards, Hans From dennis at ausil.us Thu Jun 29 11:54:52 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 29 Jun 2006 06:54:52 -0500 Subject: fedora legacy broken upgrade paths (was: Broken upgrade paths in FC+FE 2006-06-28) In-Reply-To: <20060629054856.GD27753@neu.nirvana> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <20060629054856.GD27753@neu.nirvana> Message-ID: <200606290654.53300.dennis@ausil.us> On Thursday 29 June 2006 12:48 am, Axel Thimm wrote: > > FL or a spokesman of FL like Jesse need to lobby FC or FE for > something like this to happen. Let's hope there will be some new > security issue in mozilla 1.7.13 soon ;) Just kill mozilla :) replace it with seamonkey -- Dennis Gilmore, RHCE Proud Australian From dan at danny.cz Thu Jun 29 12:21:39 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 29 Jun 2006 14:21:39 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A3BDFA.40209@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> <1151581256.20651.11.camel@eagle.danny.cz> <44A3BDFA.40209@hhs.nl> Message-ID: <1151583699.20651.19.camel@eagle.danny.cz> Hans de Goede p??e v ?t 29. 06. 2006 v 13:48 +0200: > Dan Hor?k wrote: > > Hans de Goede p??e v ?t 29. 06. 2006 v 13:25 +0200: > >> Dan Hor?k wrote: > >>>>> I could test it on NVidia 6600GT with binary drivers. > >>>> I am getting a segfault on FC4 when trying to run the Chess. I will look > >>>> at this problem during the next days. > >>> The segfault was caused by Ogre libraries conflict (Extras vs. local). > >>> On the NVidia 6600GT it shows a nice rotating board with a hand moving > >>> the "objects" (stones/characters?) but I can't press any key and after > >>> killing the game the mouse is dead. > >>> > >> Hmm, you see the board but you don't see the menu? Also you don't see > > > > Yes, I don't see the menu on both FC4+NVidia and FC6+Ati (without > > accelerated binary driver). Both were run in fullcscreen mode and in > > display's native resolution. > > > > Hmm, thats strange are you sure you're using ogre compiled from my srpm > and chess compiled from my srpm? > Yes, the FC6 machine is just installed and these were the only rpms build there. > I recently fixed a bug in ogre which caused the menu text to not show, > but the menu border should be there. Either way can you download the > latest ogre from here: > http://people.atrpms.net/~hdegoede > > Build and install it and give that a spin? When I was running the chess the second time, the menu was there. During the first run (= without the ~/.chess directory) it asks for the graphics settings and plays "a demo" without a menu which I must kill with SIGKILL. The next runs are OK, menu is shown and I can play. Strange ... ;-) Dan From dan at danny.cz Thu Jun 29 12:26:47 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 29 Jun 2006 14:26:47 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A3BDFA.40209@hhs.nl> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> <1151581256.20651.11.camel@eagle.danny.cz> <44A3BDFA.40209@hhs.nl> Message-ID: <1151584007.20651.24.camel@eagle.danny.cz> Here is the result: Pentium4 640 3.2GHz, 1 GB RAM, NVidia 6600GT, FC4 i386 running in a 1024x768 window on 1680x1050 screen, 24 bit depth it gives "Render Target 'OGRE Render Window' Average FPS: 82.1876 Best FPS: 94.246 Worst FPS: 55.1181" Dan From rdieter at math.unl.edu Thu Jun 29 14:22:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Jun 2006 09:22:13 -0500 Subject: Clarification on Packaging Guidelines References: Message-ID: Eric Work wrote: > I was previously unsure whether %pre/%post ldconfig lines on shared > library devel packages were needed. In a recent discussion with some > others on #fedora-extras I was informed that they were not needed. The policy is clear, IMO, ldconfig is needed if said package includes any shared libraries (pkgs with *symlinks* to shared libs, like most -devel ones, don't count). -- Rex From dragoran at feuerpokemon.de Thu Jun 29 15:13:28 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 29 Jun 2006 17:13:28 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <1151583699.20651.19.camel@eagle.danny.cz> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> <1151581256.20651.11.camel@eagle.danny.cz> <44A3BDFA.40209@hhs.nl> <1151583699.20651.19.camel@eagle.danny.cz> Message-ID: <44A3EE18.70603@feuerpokemon.de> Dan Hor?k wrote: > Hans de Goede p??e v ?t 29. 06. 2006 v 13:48 +0200: > >> Dan Hor?k wrote: >> >>> Hans de Goede p??e v ?t 29. 06. 2006 v 13:25 +0200: >>> >>>> Dan Hor?k wrote: >>>> >>>>>>> I could test it on NVidia 6600GT with binary drivers. >>>>>>> >>>>>> I am getting a segfault on FC4 when trying to run the Chess. I will look >>>>>> at this problem during the next days. >>>>>> >>>>> The segfault was caused by Ogre libraries conflict (Extras vs. local). >>>>> On the NVidia 6600GT it shows a nice rotating board with a hand moving >>>>> the "objects" (stones/characters?) but I can't press any key and after >>>>> killing the game the mouse is dead. >>>>> >>>>> >>>> Hmm, you see the board but you don't see the menu? Also you don't see >>>> >>> Yes, I don't see the menu on both FC4+NVidia and FC6+Ati (without >>> accelerated binary driver). Both were run in fullcscreen mode and in >>> display's native resolution. >>> >>> >> Hmm, thats strange are you sure you're using ogre compiled from my srpm >> and chess compiled from my srpm? >> >> > > Yes, the FC6 machine is just installed and these were the only rpms > build there. > > >> I recently fixed a bug in ogre which caused the menu text to not show, >> but the menu border should be there. Either way can you download the >> latest ogre from here: >> http://people.atrpms.net/~hdegoede >> >> Build and install it and give that a spin? >> > > When I was running the chess the second time, the menu was there. During > the first run (= without the ~/.chess directory) it asks for the > graphics settings and plays "a demo" without a menu which I must kill > with SIGKILL. The next runs are OK, menu is shown and I can play. > Strange ... ;-) > > > seems to be the same that I reported .... > Dan > > > From jkeating at redhat.com Thu Jun 29 15:32:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 Jun 2006 11:32:49 -0400 Subject: fedora legacy broken upgrade paths (was: Broken upgrade paths in FC+FE 2006-06-28) In-Reply-To: <20060629054856.GD27753@neu.nirvana> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <20060629054856.GD27753@neu.nirvana> Message-ID: <200606291132.49729.jkeating@redhat.com> On Thursday 29 June 2006 01:48, Axel Thimm wrote: > This happend because instead of "fc3" the disttag was chosen to be > simply "3" which is rpm-bigger than any "fcX". > > The only way to fix FL broken paths is to bump the evr of the > subsequent releases :/ > > FL or a spokesman of FL like Jesse need to lobby FC or FE for > something like this to happen. Let's hope there will be some new > security issue in mozilla 1.7.13 soon ;) Yuk, I missed this when we released the legacy update. There are more mozilla issues coming I've heard. Also I do believe the longer term goal is to switch to seamonkey. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Thu Jun 29 15:49:25 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 29 Jun 2006 08:49:25 -0700 Subject: Clarification on Packaging Guidelines In-Reply-To: References: Message-ID: <44A3F685.7000106@poolshark.org> Rex Dieter wrote: > Eric Work wrote: > > >>I was previously unsure whether %pre/%post ldconfig lines on shared >>library devel packages were needed. In a recent discussion with some >>others on #fedora-extras I was informed that they were not needed. > > > The policy is clear, IMO, ldconfig is needed if said package includes any > shared libraries (pkgs with *symlinks* to shared libs, like most -devel > ones, don't count). I think there's an implicit assumption here that you are installing shared libraries *meant to be picked up by the dynamic linker*. Some packages ship dynamic libraries that are dlopened() directly by the application (plugins), in that case calling ldconfig will not do anything and so is not necessary. -denis From rc040203 at freenet.de Thu Jun 29 15:57:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Jun 2006 17:57:43 +0200 Subject: Clarification on Packaging Guidelines In-Reply-To: <44A3F685.7000106@poolshark.org> References: <44A3F685.7000106@poolshark.org> Message-ID: <1151596663.15566.1.camel@mccallum.corsepiu.local> On Thu, 2006-06-29 at 08:49 -0700, Denis Leroy wrote: > Rex Dieter wrote: > > Eric Work wrote: > > > > > >>I was previously unsure whether %pre/%post ldconfig lines on shared > >>library devel packages were needed. In a recent discussion with some > >>others on #fedora-extras I was informed that they were not needed. > > > > > > The policy is clear, IMO, ldconfig is needed if said package includes any > > shared libraries (pkgs with *symlinks* to shared libs, like most -devel > > ones, don't count). > > I think there's an implicit assumption here that you are installing > shared libraries *meant to be picked up by the dynamic linker*. Some > packages ship dynamic libraries that are dlopened() directly by the > application (plugins), in that case calling ldconfig will not do > anything and so is not necessary. The open question here would be: Should dlopen'ed plugins in $libdir be allowed? IMO, no. Ralf From j.w.r.degoede at hhs.nl Thu Jun 29 16:06:21 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jun 2006 18:06:21 +0200 Subject: Testers with radeon 9600 or 9800 wanted for new 3D package In-Reply-To: <44A3EE18.70603@feuerpokemon.de> References: <44A047B6.9030102@hhs.nl> <1151355430.3500.7.camel@eagle.danny.cz> <1151357549.3500.10.camel@eagle.danny.cz> <1151578225.20651.5.camel@eagle.danny.cz> <44A3B8AE.6040800@hhs.nl> <1151581256.20651.11.camel@eagle.danny.cz> <44A3BDFA.40209@hhs.nl> <1151583699.20651.19.camel@eagle.danny.cz> <44A3EE18.70603@feuerpokemon.de> Message-ID: <44A3FA7D.50105@hhs.nl> dragoran wrote: > Dan Hor?k wrote: >> When I was running the chess the second time, the menu was there. During >> the first run (= without the ~/.chess directory) it asks for the >> graphics settings and plays "a demo" without a menu which I must kill >> with SIGKILL. The next runs are OK, menu is shown and I can play. >> Strange ... ;-) >> >> >> > seems to be the same that I reported .... >> Dan >> I've tried to reproduce this and it works fine for me even after doing rm -fr .chess. Weird. I so 2 possible reasons: 1) selinux (I've to disable selinux for dri to work, which reminds me that I must report this). 2) the graphics driver Regards, Hans From j.w.r.degoede at hhs.nl Thu Jun 29 16:11:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jun 2006 18:11:18 +0200 Subject: Clarification on Packaging Guidelines In-Reply-To: <1151596663.15566.1.camel@mccallum.corsepiu.local> References: <44A3F685.7000106@poolshark.org> <1151596663.15566.1.camel@mccallum.corsepiu.local> Message-ID: <44A3FBA6.90404@hhs.nl> Ralf Corsepius wrote: > The open question here would be: Should dlopen'ed plugins in $libdir be > allowed? > > IMO, no. > I agree, that should not be allowed. Regards, Hans From denis at poolshark.org Thu Jun 29 16:08:44 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 29 Jun 2006 09:08:44 -0700 Subject: Clarification on Packaging Guidelines In-Reply-To: <1151596663.15566.1.camel@mccallum.corsepiu.local> References: <44A3F685.7000106@poolshark.org> <1151596663.15566.1.camel@mccallum.corsepiu.local> Message-ID: <44A3FB0C.8010005@poolshark.org> Ralf Corsepius wrote: > On Thu, 2006-06-29 at 08:49 -0700, Denis Leroy wrote: > >>Rex Dieter wrote: >> >>>Eric Work wrote: >>> >>> >>>>I was previously unsure whether %pre/%post ldconfig lines on shared >>>>library devel packages were needed. In a recent discussion with some >>>>others on #fedora-extras I was informed that they were not needed. >>> >>> >>>The policy is clear, IMO, ldconfig is needed if said package includes any >>>shared libraries (pkgs with *symlinks* to shared libs, like most -devel >>>ones, don't count). >> >>I think there's an implicit assumption here that you are installing >>shared libraries *meant to be picked up by the dynamic linker*. Some >>packages ship dynamic libraries that are dlopened() directly by the >>application (plugins), in that case calling ldconfig will not do >>anything and so is not necessary. > > > The open question here would be: Should dlopen'ed plugins in $libdir be > allowed? Do you mean in %libdir itself, or anywhere under %libdir ? 'pstoedit' is an example of package that has "plugin" dynamic libraries in %libdir/pstoedit/ -denis From j.w.r.degoede at hhs.nl Thu Jun 29 16:16:43 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jun 2006 18:16:43 +0200 Subject: Clarification on Packaging Guidelines In-Reply-To: <44A3FB0C.8010005@poolshark.org> References: <44A3F685.7000106@poolshark.org> <1151596663.15566.1.camel@mccallum.corsepiu.local> <44A3FB0C.8010005@poolshark.org> Message-ID: <44A3FCEB.4090202@hhs.nl> Denis Leroy wrote: > Ralf Corsepius wrote: >> On Thu, 2006-06-29 at 08:49 -0700, Denis Leroy wrote: >> >>> Rex Dieter wrote: >>> >>>> Eric Work wrote: >>>> >>>> >>>>> I was previously unsure whether %pre/%post ldconfig lines on shared >>>>> library devel packages were needed. In a recent discussion with some >>>>> others on #fedora-extras I was informed that they were not needed. >>>> >>>> >>>> The policy is clear, IMO, ldconfig is needed if said package >>>> includes any >>>> shared libraries (pkgs with *symlinks* to shared libs, like most -devel >>>> ones, don't count). >>> >>> I think there's an implicit assumption here that you are installing >>> shared libraries *meant to be picked up by the dynamic linker*. Some >>> packages ship dynamic libraries that are dlopened() directly by the >>> application (plugins), in that case calling ldconfig will not do >>> anything and so is not necessary. >> >> >> The open question here would be: Should dlopen'ed plugins in $libdir be >> allowed? > > Do you mean in %libdir itself, or anywhere under %libdir ? I think he means in %libdir itself, thats how I read it when I posted I agreed :) In a subdir under libdir is not only fine, thats actually mandatory by the FHS. Regards, Hans From bugs.michael at gmx.net Thu Jun 29 17:08:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 29 Jun 2006 19:08:42 +0200 Subject: Clarification on Packaging Guidelines In-Reply-To: <44A3F685.7000106@poolshark.org> References: <44A3F685.7000106@poolshark.org> Message-ID: <20060629190842.2a727721.bugs.michael@gmx.net> On Thu, 29 Jun 2006 08:49:25 -0700, Denis Leroy wrote: > Rex Dieter wrote: > > Eric Work wrote: > > > > > >>I was previously unsure whether %pre/%post ldconfig lines on shared > >>library devel packages were needed. In a recent discussion with some > >>others on #fedora-extras I was informed that they were not needed. > > > > > > The policy is clear, IMO, ldconfig is needed if said package includes any > > shared libraries (pkgs with *symlinks* to shared libs, like most -devel > > ones, don't count). > > I think there's an implicit assumption here that you are installing > shared libraries *meant to be picked up by the dynamic linker*. Some > packages ship dynamic libraries that are dlopened() directly by the > application (plugins), in that case calling ldconfig will not do > anything and so is not necessary. Not true. Only true when dlopen'ing absolute paths. From work.eric at gmail.com Thu Jun 29 17:47:52 2006 From: work.eric at gmail.com (Eric Work) Date: Thu, 29 Jun 2006 10:47:52 -0700 Subject: Clarification on Packaging Guidelines Message-ID: <44A41248.7090902@gmail.com> > The open question here would be: Should dlopen'ed plugins in $libdir > be allowed? Actually my question was for a standard shared library package. This is a GTK widget called 'gtkdatabox' which is currently in bugzilla as a review request (#196529). I have a normal package which has libgtkdatabox.so.* then the -devel package with the headers, pkgconfig files, and .so symlinks. According to previous responses, since the .so files are symlinked the %pre/%postun are not needed. Maybe it is clear but I got confused somewhere in the process. Thanks, Eric From ianburrell at gmail.com Thu Jun 29 17:56:42 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 29 Jun 2006 10:56:42 -0700 Subject: plague-client list failing Message-ID: Doing "plague-client list" fails with the following error: Error: an error ocurred communicating with the server. ' > Error: an error ocurred communicating with the server. ' 'pg.DatabaseError:error \'ERROR: expression > too complex\nDETAIL: Nesting depth exceeds maximum expression depth > 10000.\nHINT: Increase the configuration > parameter "max_expr_depth".\n\' in \'SELECT jobid, parent_uid, > starttime, endtime, arch, builder_addr, status, > builder_status FROM archjobs WHERE parent_uid=5 OR parent_uid=1 OR > parent_uid=3 OR parent_uid=6 OR parent_uid=9 > > The "OR parent_uid = " clauses go on for a few pages (something 226K). > PostgreSQL has a limit of 10,000 clauses in an expression. Limiting > the number of jobs selected would fix the problem. Thanks for the report, I need to fix this server-side. Should be using <> here if the numbers are contiguous. Dan From dgregor at redhat.com Thu Jun 29 18:23:48 2006 From: dgregor at redhat.com (Dennis Gregorovic) Date: Thu, 29 Jun 2006 14:23:48 -0400 Subject: plague-client list failing In-Reply-To: <1151604644.13142.0.camel@localhost.localdomain> References: <1151604644.13142.0.camel@localhost.localdomain> Message-ID: <1151605428.3093.18.camel@localhost.localdomain> On Thu, 2006-06-29 at 14:10 -0400, Dan Williams wrote: > On Thu, 2006-06-29 at 10:56 -0700, Ian Burrell wrote: > > Doing "plague-client list" fails with the following error: > > > > Error: an error ocurred communicating with the server. ' > 'pg.DatabaseError:error \'ERROR: expression > > too complex\nDETAIL: Nesting depth exceeds maximum expression depth > > 10000.\nHINT: Increase the configuration > > parameter "max_expr_depth".\n\' in \'SELECT jobid, parent_uid, > > starttime, endtime, arch, builder_addr, status, > > builder_status FROM archjobs WHERE parent_uid=5 OR parent_uid=1 OR > > parent_uid=3 OR parent_uid=6 OR parent_uid=9 > > > > The "OR parent_uid = " clauses go on for a few pages (something 226K). > > PostgreSQL has a limit of 10,000 clauses in an expression. Limiting > > the number of jobs selected would fix the problem. > > Thanks for the report, I need to fix this server-side. Should be using > <> here if the numbers are contiguous. > > Dan It looks like an IN clause would be simpler. Index: UserInterface.py =================================================================== RCS file: /cvs/fedora/extras-buildsys/server/UserInterface.py,v retrieving revision 1.62 diff -u -r1.62 UserInterface.py --- UserInterface.py 24 Mar 2006 19:13:41 -0000 1.62 +++ UserInterface.py 29 Jun 2006 18:23:41 -0000 @@ -338,11 +338,8 @@ # Mash all returned job UIDs into an SQL query to get all their archjobs uids = '' - for job in jobs: - if len(uids) == 0: - uids = uids + "parent_uid=%d" % job['uid'] - else: - uids = uids + " OR parent_uid=%d" % job['uid'] + if jobs: + uids = 'parent_uid in (' + ','.join([ job['uid'] for job in jobs ]) + ')' # Get all archjobs for this job if len(uids) > 0: From tibbs at math.uh.edu Thu Jun 29 18:28:17 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 13:28:17 -0500 Subject: PHP packaging guidelines not yet accepted Message-ID: The packaging committee met for the first time today, in part to take up the issue of the PHP guidelines. The result was that the current draft was not accepted. So, reviewers take note: as before, submissions of PHP extensions and modules (including PEAR and PECL modules) should not be approved until finalized guidelines are ready. Applications which happen to be written in PHP are OK as always. I know that it's annoying to have packages accumulating for which reviews cannot be completed due to the lack of these guidelines; we will be working on this and hope to have something out soon. The current draft is at: http://fedoraproject.org/wiki/Packaging/PHP You may of course join us in discussing this on the fedora packaging list, fedora-packaging at redhat.com. The packaging committee currently meets on Thursdays at 16:00UTC in #fedora-packaging on irc.freenode.net. - J< From ianburrell at gmail.com Thu Jun 29 18:36:45 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 29 Jun 2006 11:36:45 -0700 Subject: plague-client list failing In-Reply-To: <1151605428.3093.18.camel@localhost.localdomain> References: <1151604644.13142.0.camel@localhost.localdomain> <1151605428.3093.18.camel@localhost.localdomain> Message-ID: On 6/29/06, Dennis Gregorovic wrote: > On Thu, 2006-06-29 at 14:10 -0400, Dan Williams wrote: > > On Thu, 2006-06-29 at 10:56 -0700, Ian Burrell wrote: > > > Doing "plague-client list" fails with the following error: > > > > > > Error: an error ocurred communicating with the server. ' > > 'pg.DatabaseError:error \'ERROR: expression > > > too complex\nDETAIL: Nesting depth exceeds maximum expression depth > > > 10000.\nHINT: Increase the configuration > > > parameter "max_expr_depth".\n\' in \'SELECT jobid, parent_uid, > > > starttime, endtime, arch, builder_addr, status, > > > builder_status FROM archjobs WHERE parent_uid=5 OR parent_uid=1 OR > > > parent_uid=3 OR parent_uid=6 OR parent_uid=9 > > > > > > The "OR parent_uid = " clauses go on for a few pages (something 226K). > > > PostgreSQL has a limit of 10,000 clauses in an expression. Limiting > > > the number of jobs selected would fix the problem. > > > > Thanks for the report, I need to fix this server-side. Should be using > > <> here if the numbers are contiguous. > > > > Dan > > It looks like an IN clause would be simpler. > With PostgreSQL, the IN clause with explciit arguments has the same expression limit. It converts the IN clause into a bunch of "OR" clauses. A subquery IN clause doesn't have the limit. - Ian From ville.skytta at iki.fi Thu Jun 29 19:07:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 22:07:56 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <44A2CB61.3090002@fedoraproject.org> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> <44A2CB61.3090002@fedoraproject.org> Message-ID: <1151608077.6570.175.camel@localhost.localdomain> On Wed, 2006-06-28 at 13:33 -0500, Mike McGrath wrote: > Would it be a lot of work to include a check during the "make tag" or > "make plague" that checks to see if it will break an upgrade path? If the check can be automated in a nonintrusive way, it would be a good thing to have. I don't know if the above are the optimal spots to do the check; perhaps it'd be easiest for the buildsys to check it when it starts a build. And even then, build jobs would have to be queued/run in the correct order so that a job for distro N could start only after the corresponding job for N+1 would have successfully entered the needsign queue... could be more pain than gain. From ville.skytta at iki.fi Thu Jun 29 19:12:51 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 22:12:51 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <1151518458.6570.95.camel@localhost.localdomain> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> Message-ID: <1151608371.6570.177.camel@localhost.localdomain> On Wed, 2006-06-28 at 21:14 +0300, Ville Skytt? wrote: > Objections? Okay, will leave things as they are now. From ville.skytta at iki.fi Thu Jun 29 19:23:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 22:23:24 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-28 In-Reply-To: <20060629054153.GC27753@neu.nirvana> References: <20060628131024.CC79E15217B@buildsys.fedoraproject.org> <1151518458.6570.95.camel@localhost.localdomain> <20060629054153.GC27753@neu.nirvana> Message-ID: <1151609004.6570.188.camel@localhost.localdomain> On Thu, 2006-06-29 at 07:41 +0200, Axel Thimm wrote: > I wouldn't remove, but sort them differently. E.g. [...] AFAICS the easiest way to do this would be to just run the script with different configurations and direct the output to appropriate lists. That'd probably suffice although the priorization would be somewhat, er, coarse. This could and should be done by the respective projects as they see fit; controlling stuff in the FE buildsystem for all combinations doesn't sound optimal to me. On the other hand, the projects are already intertwined and will probably continue to grow to that direction. Adding some priorization to the output of the script itself wouldn't be rocket science, but could make it less generic and thus harder to adapt by other projects. The code is in the fedora CVS root in the upgradecheck module, patches welcome: http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora From Matt_Domsch at dell.com Thu Jun 29 19:57:06 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 29 Jun 2006 14:57:06 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-29 Message-ID: <20060629195706.GC7922@lists.us.dell.com> Now with package version numbers. :-) Extras Rawhide-in-Mock Build Results for x86_64 Thu Jun 29 14:35:17 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 145 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 134 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 126 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com bmp-0.9.7.1-4.fc5 redhat-bugzilla at camperquake.de camstream-0.26.3-9.fc5 nomis80 at nomis80.org ccrtp-1.3.7-1.fc6 andreas at bawue.net contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net cowbell-0.2.7.1-2.fc6 foolish at guezz.net ddskk-12.2.0-7.fc5 petersen at redhat.com dillo-0.8.6-1.fc6 andreas.bierfert at lowlatency.de diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org drgeo-1.1.0-8.fc6 eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 bnocera at redhat.com ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu fish-1.12.0-1.fc5 oliver at linux-kernel.at flim-1.14.7-3 petersen at redhat.com flow-tools-0.68-8.fc6 i at stingr.net foobillard-3.0a-4 mitr at redhat.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gazpacho-0.6.5-1.fc5 icon at fedoraproject.org gdesklets-0.35.3-8.fc6 luya256 at yahoo.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de glabels-2.0.4-2.fc5 jspaleta at gmail.com gnomad2-2.8.6-1.fc6 triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ivazquez at ivazquez.net gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gnome-schedule-1.0.0-1 frank at scirocco-5v-turbo.de gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com grhino-0.15.0-5.fc5 michel.salim at gmail.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org gsynaptics-0.9.5-2.fc5 fedora at leemhuis.info GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtk-gnutella-0.96.1-1.fc5 dmitry at butskoy.name Gtk-Perl-0.7008-40.fc5 extras-orphan at fedoraproject.org gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de hercules-3.02-3 matthias at rpmforge.net hping2-2.0.0-0.7.rc3.fc6 paul at xtdnet.nl ifplugd-0.24-6 aaron.bennett at olin.edu jack-audio-connection-kit-0.101.1-10.fc6 andy at smile.org.ua jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu libnasl-2.2.7-1.fc6 andreas.bierfert at lowlatency.de libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net libtranslate-0.99-7.fc6 dmitry at butskoy.name licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr monodoc-1.1.13-13.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ed at eh3.com nessus-core-2.2.7-1.fc6 andreas.bierfert at lowlatency.de nessus-libraries-2.2.7-1.fc6 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org p0f-2.0.6-1.fc6 kevin-redhat-bugzilla at tummy.com pam_keyring-0.0.7-2 redhat at flyn.org pam_mount-0.13.0-3 redhat at flyn.org perl-Image-Info-1.21-2.fc6 jpo at di.uminho.pt perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com tetex-eurofont-1.1.3-2 aportal at univ-montp2.fr uqm-0.5.0-1.fc5 icon at fedoraproject.org ushare-0.9.7-1.fc5 eric.tanguy at univ-nantes.fr verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbindkeys-1.7.2-5.fc6 gauret at free.fr xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 8 ---------------------------------- airsnort-0.2.7e-8.fc5 ['197102 CLOSED'] andreas.bierfert at lowlatency.de alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk argus-2.0.6.fixes.1-10.fc6 ['197215 NEW'] somlo at cmu.edu banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bazaar-1.4.2-6.fc5 ['197222 NEW'] shahms at shahms.com bidiv-1.5-3.fc5 ['197224 NEW'] danken at cs.technion.ac.il xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de 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 Thu Jun 29 19:57:28 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 29 Jun 2006 14:57:28 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-29 Message-ID: <20060629195727.GD7922@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Thu Jun 29 14:38:45 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 124 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 123 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 114 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com bmp-0.9.7.1-4.fc5 redhat-bugzilla at camperquake.de camstream-0.26.3-9.fc5 nomis80 at nomis80.org ccrtp-1.3.7-1.fc6 andreas at bawue.net compat-erlang-R10B-10.2.fc6 gemi at bluewin.ch contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net cowbell-0.2.7.1-2.fc6 foolish at guezz.net ddskk-12.2.0-7.fc5 petersen at redhat.com dillo-0.8.6-1.fc6 andreas.bierfert at lowlatency.de diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org drgeo-1.1.0-8.fc6 eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 bnocera at redhat.com ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com erlang-R11B-0.1.fc6 gemi at bluewin.ch exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu fish-1.12.0-1.fc5 oliver at linux-kernel.at flim-1.14.7-3 petersen at redhat.com flow-tools-0.68-8.fc6 i at stingr.net gazpacho-0.6.5-1.fc5 icon at fedoraproject.org gdesklets-0.35.3-8.fc6 luya256 at yahoo.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de glabels-2.0.4-2.fc5 jspaleta at gmail.com gnomad2-2.8.6-1.fc6 triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ivazquez at ivazquez.net gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gnome-schedule-1.0.0-1 frank at scirocco-5v-turbo.de gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com grads-1.9b4-11.fc6 pertusus at free.fr grhino-0.15.0-5.fc5 michel.salim at gmail.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org gsynaptics-0.9.5-2.fc5 fedora at leemhuis.info GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtk-gnutella-0.96.1-1.fc5 dmitry at butskoy.name Gtk-Perl-0.7008-40.fc5 extras-orphan at fedoraproject.org gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de Hermes-1.3.3-7 thomas at apestaart.org hping2-2.0.0-0.7.rc3.fc6 paul at xtdnet.nl ifplugd-0.24-6 aaron.bennett at olin.edu jack-audio-connection-kit-0.101.1-10.fc6 andy at smile.org.ua jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu libnasl-2.2.7-1.fc6 andreas.bierfert at lowlatency.de librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net libtranslate-0.99-7.fc6 dmitry at butskoy.name licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ed at eh3.com nessus-core-2.2.7-1.fc6 andreas.bierfert at lowlatency.de nessus-libraries-2.2.7-1.fc6 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de p0f-2.0.6-1.fc6 kevin-redhat-bugzilla at tummy.com pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com tetex-eurofont-1.1.3-2 aportal at univ-montp2.fr ushare-0.9.7-1.fc5 eric.tanguy at univ-nantes.fr verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbindkeys-1.7.2-5.fc6 gauret at free.fr xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com With bugs filed: 9 ---------------------------------- abiword-2.4.4-2.fc6 ['196690 NEW'] uwog at uwog.net airsnort-0.2.7e-8.fc5 ['197102 CLOSED'] andreas.bierfert at lowlatency.de alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk argus-2.0.6.fixes.1-10.fc6 ['197215 NEW'] somlo at cmu.edu banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bazaar-1.4.2-6.fc5 ['197222 NEW'] shahms at shahms.com bidiv-1.5-3.fc5 ['197224 NEW'] danken at cs.technion.ac.il xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de 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 paul at cypherpunks.ca Thu Jun 29 20:04:22 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 29 Jun 2006 22:04:22 +0200 (CEST) Subject: pcap.h changed in devel/rawhide (fc6) ? In-Reply-To: References: Message-ID: On Wed, 28 Jun 2006, Jason L Tibbitts III wrote: > >>>>> "PW" == Paul Wouters writes: > > PW> I don't have a rawhide/devel or FC6test1 box anywhere yet, and > PW> mock is not building hping2 because it cannot find pcap.h. > > I'm wondering if you're reading your bugzilla mail, because I included > information about this in my review of hping3. Unfortunately I didn't > see any response to the review or the two following pings. Sorry about that. I need to change the bugszilla email setup, but created a conflict there. I'll try to deal with that so I see those emails sooner. > You need to BR: libpcap-devel on rawhide. Thanks, I'll update that for hping2 and hping3 Paul From tibbs at math.uh.edu Thu Jun 29 20:24:55 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 15:24:55 -0500 Subject: pcap.h changed in devel/rawhide (fc6) ? In-Reply-To: (Paul Wouters's message of "Thu, 29 Jun 2006 22:04:22 +0200 (CEST)") References: Message-ID: >>>>> "PW" == Paul Wouters writes: PW> Thanks, I'll update that for hping2 and hping3 Actually you can check in the fixed hping3; I approved the package a while back. - J< From jkeating at redhat.com Thu Jun 29 20:31:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 Jun 2006 16:31:05 -0400 Subject: PHP packaging guidelines not yet accepted In-Reply-To: References: Message-ID: <200606291631.06087.jkeating@redhat.com> On Thursday 29 June 2006 14:28, Jason L Tibbitts III wrote: > The packaging committee met for the first time today, in part to take > up the issue of the PHP guidelines. ?The result was that the current > draft was not accepted. Its worth noting that we like the guideline, its just that there are some unresolved questions. Until those are resolved, we cannot accept the guideline. -- 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 Thu Jun 29 22:41:14 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 29 Jun 2006 18:41:14 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-06-29 Message-ID: <20060629224114.40C1C15217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 41 TeXmacs-1.0.6.4-1.fc5 aiccu-2005.01.31-4.fc5 argus-2.0.6.fixes.1-11.fc5 asymptote-1.10-1.fc5 bazaar-1.4.2-7.fc5 chmlib-0.38-1.fc5 cogito-0.17.3-1.fc5 dkms-2.0.13-1.fc5 gnome-blog-0.9.1-1.fc5 gtkwave-3.0.5-1.fc5 hping2-2.0.0-0.8.rc3.fc5 kid3-0.7-1.fc5 kipi-plugins-0.1.1-1.fc5 libhugetlbfs-0.20060628-1.fc5 lyx-1.4.1-9.fc5 multitail-4.0.6-1.fc5 oidentd-2.0.8-1.fc5 openbox-3.3-0.8.rc2.fc5.1 pam_script-0.1.7-2.fc5 perl-Algorithm-Annotate-0.10-4.fc5 perl-File-chdir-0.06-2.fc5 perl-IO-Digest-0.10-4.fc5 perl-Params-Validate-0.85-1.fc5 perl-PerlIO-eol-0.13-3.fc5 perl-PerlIO-via-dynamic-0.12-2.fc5 perl-PerlIO-via-symlink-0.05-3.fc5 perl-RRD-Simple-1.39-1.fc5 perl-SVN-Mirror-0.68-8.fc5 perl-SVN-Simple-0.27-3.fc5 perl-XML-DOM-1.44-2.fc5 perl-XML-RegExp-0.03-2.fc5 php-pear-DB-1.7.6-6.fc5 python-setuptools-0.6b3-1.fc5 qalculate-gtk-0.9.4-1.fc5 qalculate-kde-0.9.4-1.fc5.2 qt4-4.1.4-4.fc5 rpmlint-0.77-1.fc5 tetex-eurofont-1.1.3-5.fc5 ucblogo-5.5-4.fc5 wavpack-4.32-1.fc5 xwrits-2.23-1.fc5 Packages built and released for Fedora Extras 4: 29 TeXmacs-1.0.6.4-1.fc4 aiccu-2005.01.31-4.fc4 argus-2.0.6.fixes.1-11.fc4 asymptote-1.10-1.fc4 chmlib-0.38-1.fc4 clips-6.24-13.fc4 cogito-0.17.3-1.fc4 dillo-0.8.6-1.fc4 dkms-2.0.13-1.fc4 gtkwave-3.0.5-1.fc4 kipi-plugins-0.1.1-1.fc4 lyx-1.4.1-9.fc4 multitail-4.0.6-1.fc4 openbox-3.3-0.8.rc2.fc4 pam_script-0.1.7-2.fc4 perl-Algorithm-Annotate-0.10-4.fc4 perl-File-chdir-0.06-2.fc4 perl-IO-Digest-0.10-4.fc4 perl-Params-Validate-0.85-1.fc4 perl-PerlIO-eol-0.13-3.fc4 perl-PerlIO-via-dynamic-0.12-2.fc4 perl-PerlIO-via-symlink-0.05-3.fc4 perl-RRD-Simple-1.39-1.fc4 perl-SVN-Mirror-0.68-8.fc4 perl-SVN-Simple-0.27-3.fc4 python-setuptools-0.6b3-1.fc4 qalculate-gtk-0.9.4-1.fc4 qalculate-kde-0.9.4-1.fc4 qt4-4.1.4-4.fc4 Packages built and released for Fedora Extras 3: 4 amaya-9.5-1.fc3 cogito-0.17.3-1.fc3 gtkwave-3.0.5-1.fc3 plone-2.1.2-2.fc3 Packages built and released for Fedora Extras development: 54 aiccu-2005.01.31-4.fc6 airsnort-0.2.7e-9.fc6 argus-2.0.6.fixes.1-11.fc6 asymptote-1.10-1.fc6 bazaar-1.4.2-7.fc6 chmlib-0.38-1.fc6 cogito-0.17.3-1.fc6 darcs-1.0.8-2.fc6 dkms-2.0.13-1.fc6 gaim-meanwhile-2.0.0-0.3.beta3.fc6 gtk-qt-engine-0.60-10.cvs20060629.fc6 gtkwave-3.0.5-1.fc6 haddock-0.7-2.fc6 hping2-2.0.0-0.11.rc3.fc6 inkscape-0.44-2.fc6 kid3-0.7-1.fc6 kipi-plugins-0.1.1-1.fc6 libedit-2.9-3.20060603cvs.fc6 libqalculate-0.9.4-3.fc6 libxml++-2.14.0-1.fc6 loudmouth-1.0.4-2.fc6 lyx-1.4.1-9.fc6 multitail-4.0.6-1.fc6 nazghul-0.5.3-6.20060627cvs.fc6 nessus-libraries-2.2.8-2.fc6 oidentd-2.0.8-1.fc6 openbox-3.3-0.8.rc2.fc6.1 p0f-2.0.6-2.fc6 p7zip-4.42-1.fc6 pam_script-0.1.7-2.fc6 perl-Data-Hierarchy-0.22-2.fc6 perl-File-chdir-0.06-2.fc6 perl-IO-Digest-0.10-4.fc6 perl-PerlIO-eol-0.13-3.fc6 perl-PerlIO-via-dynamic-0.12-2.fc6 perl-PerlIO-via-symlink-0.05-3.fc6 perl-SVN-Mirror-0.68-8.fc6 perl-SVN-Simple-0.27-3.fc6 perl-XML-DOM-1.44-2.fc6 perl-XML-RegExp-0.03-2.fc6 pylint-0.11.0-1.fc6 python-astng-0.16.0-0.fc6 python-logilab-common-0.15.0-1.fc6 python-setuptools-0.6b3-1.fc6 qalculate-gtk-0.9.4-3.fc6 qt4-4.1.4-4.fc6 rpmlint-0.77-1.fc6 seahorse-0.8-4.fc6 tetex-eurofont-1.1.3-5.fc6 ucblogo-5.5-4.fc6 ushare-0.9.7-2.fc6 wavpack-4.32-1.fc6 xscreensaver-5.00-10.fc6 xwrits-2.23-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jun 29 22:41:47 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 29 Jun 2006 18:41:47 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-06-29 Message-ID: <20060629224147.25A5515217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) clips: 4: 0:6.24-13.fc4 (FE4) 5: 0:6.24-8.fc5 (FE5) 6: 0:6.24-8.fc6 (FE6) cscope: 5: 0:15.5-13.7 (FC5-updates) 6: 0:15.5-13.5 (FC6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-9 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nfs-utils: 5: 0:1.0.8.rc2-5.FC5 (FC5-updates) 6: 0:1.0.8-2 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) paraview: 4: 0:2.4.3-7.fc4 (FE4) 5: 0:2.4.3-6.fc5 (FE5) 6: 0:2.4.3-7.fc6 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-fonts-hebrew: 4: 0:0.1-6.fc4 (FE4) 5: 0:0.1-5.fc5 (FE5) 6: 0:0.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) xbindkeys: 5: 0:1.7.3-1.fc5 (FE5) 6: 0:1.7.2-5.fc6 (FE6) From sundaram at fedoraproject.org Thu Jun 29 23:02:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 30 Jun 2006 04:32:18 +0530 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <20060629224147.25A5515217B@buildsys.fedoraproject.org> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> Message-ID: <44A45BFA.5080601@fedoraproject.org> buildsys at fedoraproject.org wrote: >abiword: > 5: 1:2.4.4-4.fc5 (FE5) > 6: 1:2.4.4-2.fc6 (FE6) > > Now that these reports include both FC and FE, shouldnt they be going into fedora-maintainers or fedora-devel list instead of in here? Better visibility hopefully gets things fixed faster. -- Rahul From buildsys at fedoraproject.org Thu Jun 29 22:56:32 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 29 Jun 2006 22:56:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-06-29 Message-ID: <20060629225632.23819.75443@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 qt4-config - 4.1.4-1.fc4.i386 qt4-config - 4.1.4-1.fc4.ppc qt4-config - 4.1.4-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.i386 requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.ppc requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.x86_64 requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: rdieter AT math.unl.edu package: qt4-config - 4.1.4-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: qt4 = 0:4.1.4-1.fc4 package: qt4-config - 4.1.4-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: qt4 = 0:4.1.4-1.fc4 package: qt4-config - 4.1.4-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: qt4 = 0:4.1.4-1.fc4 From buildsys at fedoraproject.org Thu Jun 29 22:56:32 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 29 Jun 2006 22:56:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-06-29 Message-ID: <20060629225632.23822.21921@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 qt4-config - 4.1.4-1.fc5.i386 qt4-config - 4.1.4-1.fc5.ppc qt4-config - 4.1.4-1.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.i386 requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.ppc requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.x86_64 requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: rdieter AT math.unl.edu package: qt4-config - 4.1.4-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: qt4 = 0:4.1.4-1.fc5 package: qt4-config - 4.1.4-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: qt4 = 0:4.1.4-1.fc5 package: qt4-config - 4.1.4-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: qt4 = 0:4.1.4-1.fc5 From buildsys at fedoraproject.org Thu Jun 29 22:56:32 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 29 Jun 2006 22:56:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-06-29 Message-ID: <20060629225632.23825.19922@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 extras-orphan AT fedoraproject.org Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 orion AT cora.nwra.com gdl - 0.9-0.pre.fc6.i386 gdl - 0.9-0.pre.fc6.ppc gdl - 0.9-0.pre.fc6.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 rdieter AT math.unl.edu qt4-config - 4.1.4-1.fc6.i386 qt4-config - 4.1.4-1.fc6.ppc qt4-config - 4.1.4-1.fc6.x86_64 qt4-debug - 4.1.4-2.fc6.i386 qt4-debug - 4.1.4-2.fc6.ppc qt4-debug - 4.1.4-2.fc6.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gdl-0.9-0.pre.fc6.i386 requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 qiv-2.0-4.i386 requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.i386 requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.i386 requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gdl-0.9-0.pre.fc6.ppc requires libMagick++.so.9 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 qiv-2.0-4.ppc requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.ppc requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.ppc requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gdl-0.9-0.pre.fc6.x86_64 requires libMagick++.so.9()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) qt4-config-4.1.4-1.fc6.x86_64 requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.x86_64 requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: rdieter AT math.unl.edu package: qt4-debug - 4.1.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: qt4 = 0:4.1.4-2.fc6 package: qt4-debug - 4.1.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: qt4 = 0:4.1.4-2.fc6 package: qt4-debug - 4.1.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: qt4 = 0:4.1.4-2.fc6 From buildsys at fedoraproject.org Thu Jun 29 22:56:32 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 29 Jun 2006 22:56:32 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-06-29 Message-ID: <20060629225632.23811.28372@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From dimitris at glezos.com Fri Jun 30 02:18:55 2006 From: dimitris at glezos.com (Dimitris Glezos) Date: Fri, 30 Jun 2006 03:18:55 +0100 Subject: Changing the default font in Fedora Core 6 Message-ID: <44A48A0F.5070609@glezos.com> Hello all. Having read the thread that was active 2+ weeks ago "Changing the default font in Fedora Core 6" [1], I think that it's obvious that the Best Thing? would be to include DejaVu in Core as soon as possible. Translators work hard for translating fedora core, extras, the docs and the release notes, but the installer is absolutely unusable in some languages because the best font out there isn't included in the Core. Ambassadors work hard in event organizing and spreading the word about Fedora to new users, but one has to manually edit the fonts.conf file to get a usable desktop in > 1 languages. I am sad to say this, but I heard people using the words "unacceptable" and "proof that the community doesn't matter" for the fonts issues in Fedora. (For some screenshots, take a look at [2].) Many people from this list agreed that we should include DejaVu. I believe that we should try our best to include it in the Core, definitely before Test 3 so that some testing gets done too. I don't know if someone is willing to transfer it to Core before Test 2 and I am not sure if the fontconfig patch to exclude characters from a font will be ready soon, or if it is even needed, since DejaVu LGU exists. What I do know is that we should fix this problem that spoils the image of our distribution as soon as possible. Not only because it's simply the best free font out there, but because the community really needs it straight away. Other major distros like Suse and Ubuntu have already realized this, and while this decision is considered a no-brainer, we are still talking about it. Thanks to Nicolas Mailhot, a package already exists in extras-devel, so most of the work is already done. Now, the only thing that remains (as I see it) is a Core maintainer to step forward. -Dimitris Glezos Fedora ambassador for Greece [1]: https://www.redhat.com/archives/fedora-devel-list/2006-June/thread.html#00292 [2]: http://fedoraproject.org/wiki/L10N/Teams/Greek/Issues#head-6355afab18e12a4bc80288e6476fbfecb8530a24 -- Dimitris Glezos Jabber ID: glezos at jabber.org, PGP: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From rc040203 at freenet.de Fri Jun 30 02:22:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 30 Jun 2006 04:22:56 +0200 Subject: Clarification on Packaging Guidelines In-Reply-To: <44A3FCEB.4090202@hhs.nl> References: <44A3F685.7000106@poolshark.org> <1151596663.15566.1.camel@mccallum.corsepiu.local> <44A3FB0C.8010005@poolshark.org> <44A3FCEB.4090202@hhs.nl> Message-ID: <1151634176.15566.12.camel@mccallum.corsepiu.local> On Thu, 2006-06-29 at 18:16 +0200, Hans de Goede wrote: > Denis Leroy wrote: > > Ralf Corsepius wrote: > >> On Thu, 2006-06-29 at 08:49 -0700, Denis Leroy wrote: > >> > >>> Rex Dieter wrote: > >>> > >>>> Eric Work wrote: > >>>> > >>>> > >>>>> I was previously unsure whether %pre/%post ldconfig lines on shared > >>>>> library devel packages were needed. In a recent discussion with some > >>>>> others on #fedora-extras I was informed that they were not needed. > >>>> > >>>> > >>>> The policy is clear, IMO, ldconfig is needed if said package > >>>> includes any > >>>> shared libraries (pkgs with *symlinks* to shared libs, like most -devel > >>>> ones, don't count). > >>> > >>> I think there's an implicit assumption here that you are installing > >>> shared libraries *meant to be picked up by the dynamic linker*. Some > >>> packages ship dynamic libraries that are dlopened() directly by the > >>> application (plugins), in that case calling ldconfig will not do > >>> anything and so is not necessary. > >> > >> > >> The open question here would be: Should dlopen'ed plugins in $libdir be > >> allowed? > > > > Do you mean in %libdir itself, or anywhere under %libdir ? > > I think he means in %libdir itself, thats how I read it when I posted I > agreed :) Correct, I meant %libdir itself. > In a subdir under libdir is not only fine, thats actually mandatory by > the FHS. Exactly. This keeps "shared libraries" separate from "plugins" [1]. Ralf [1] I prefer to think of "shared libraries" as "ld.so plugins"/"system plugins", and of "dlopen'ed plugins" as "application plugins". From nicolas.mailhot at laposte.net Fri Jun 30 08:16:29 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 30 Jun 2006 10:16:29 +0200 (CEST) Subject: Changing the default font in Fedora Core 6 In-Reply-To: <44A48A0F.5070609@glezos.com> References: <44A48A0F.5070609@glezos.com> Message-ID: <40386.192.54.193.52.1151655389.squirrel@rousalka.dyndns.org> Le Ven 30 juin 2006 04:18, Dimitris Glezos a ?crit : > but one has to manually edit the fonts.conf file to > get a usable desktop in > 1 languages. Installing the makedefault dejavu subpackage will make dejavu the default without editing manually fontconfig files Installing the block subpackage will substitute other fonts for arabic and farsi for people who feel the dejavu arabic bloc is not ready yet > I don't > know if someone is willing to transfer it to Core before Test 2 and I am > not sure if the fontconfig patch to exclude characters from a font will > be ready soon, or if it is even needed, since DejaVu LGU exists. Note that even distributions like debian who currently strip some glyphs from the font are interested in the patch, and it's pretty much a requisite for evolving fonts like dejavu where some parts will always be WIP. The current status of the patch can be seen here http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html Even without the patch I believe the current blocking code in the FE rpms is sufficient for arabic and farsi needs. Regards, -- Nicolas Mailhot From ville.skytta at iki.fi Fri Jun 30 10:22:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 13:22:06 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <44A45BFA.5080601@fedoraproject.org> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> <44A45BFA.5080601@fedoraproject.org> Message-ID: <1151662926.6570.243.camel@localhost.localdomain> On Fri, 2006-06-30 at 04:32 +0530, Rahul Sundaram wrote: > buildsys at fedoraproject.org wrote: > > >abiword: > > 5: 1:2.4.4-4.fc5 (FE5) > > 6: 1:2.4.4-2.fc6 (FE6) > > > > > Now that these reports include both FC and FE, shouldnt they be going > into fedora-maintainers or fedora-devel list instead of in here? Better > visibility hopefully gets things fixed faster. Yep, but I'm not sure about what's the best list for visibility. Perhaps fedora-maintainers is better than here; no docs recommend Extras contributors to subscribe to fedora-devel and I believe many don't read it (myself included). Changing the target or adding additional ones in the script is trivial and I can take care of it when it's clear where the report is wanted, but someone who has the rights needs to auto-whitelist/subscribe the sender (buildsys at fedoraproject.org) to those lists or let me know if there's another sender that should be used. From tcallawa at redhat.com Fri Jun 30 14:34:37 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 30 Jun 2006 09:34:37 -0500 Subject: Fedora Packaging Committee Meeting (2006-06-29) Message-ID: <1151678077.7108.27.camel@localhost.localdomain> The Fedora Packaging Committee met yesterday (June 29, 2006). Full minutes of this meeting and the full IRC log of the meeting can be found here: http://fedoraproject.org/wiki/Packaging/Minutes Here are the minutes from this meeting: * All members in attendance, except Michael Schwendt, who has not yet accepted (or declined) the invitation to join. * It was agreed that all decisions by the Fedora Packaging Committee would be decided by a majority vote of 6. Thus, a 6 member quorum is required. If the committee adds/removes members, the quorum amount will be revisited. * The moderator (TomCallaway) started going through the list of open issues found here: Packaging/GuidelinesTodo * On the first issue, libexecdir, the Committee voted to add text to the Guidelines permitting the use of %{_libexecdir} in Fedora packages even though it is not currently part of the FHS. The issue passed with 6 yes votes, 0 no votes, 4 members abstaining. * The Committee also voted to recommend that subdirs be used in % _libexecdir where upstream shows no clear preference. Ultimately, the use of subdirs in %{_libexecdir} is at the packager's discretion. The issue passed with 7 yes votes, 0 no votes, 3 members abstaining. * AxelThimm agreed to take the issue of including libexecdir to the FHS on behalf of the Fedora Packaging Committee. * TomCallaway agreed to write up the libexecdir changes. * On the issue of mono guidelines, the Committee discussed the confusing (and frightening) nature of mono packages at length, and ultimately voted to standardize mono packages as architecture specific packages that put their files under %{_libdir}/%{name}. The issue passed with 8 yes votes, 0 no votes, 2 members abstaining. * On the issue of ruby guidelines, the Committee discussed the draft guidelines, and voted to approve them as formal guidelines and lift the hold on ruby packages. The issue passed with 6 yes votes, 0 no votes, 4 members abstaining. * On the issue of php guidelines, the Committee discussed the draft guidelines. It was noted that there are still several key open issues around the PHP guidelines. A vote was taken to approve the existing guidelines, and this vote failed, with 5 yes votes, 0 no votes, and 5 members abstaining. This issue was tabled, and put on the agenda for next week. JasonTibbs and TomCallaway were tasked with resolving the open issues with the PHP guidelines. * As a result of the PHP guidelines not being approved, a moratorium was placed on all php packages. JasonTibbs announced this on the fedora-extras and fedora-maintainers lists. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Fri Jun 30 15:39:30 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 30 Jun 2006 11:39:30 -0400 Subject: Changing the default font in Fedora Core 6 In-Reply-To: <40386.192.54.193.52.1151655389.squirrel@rousalka.dyndns.org> References: <44A48A0F.5070609@glezos.com> <40386.192.54.193.52.1151655389.squirrel@rousalka.dyndns.org> Message-ID: <20060630153930.GA31330@jadzia.bu.edu> On Fri, Jun 30, 2006 at 10:16:29AM +0200, Nicolas Mailhot wrote: > Installing the makedefault dejavu subpackage will make dejavu the default > without editing manually fontconfig files Hmmm. I'm not sure this is a good approach. What if later, there's ilikethisonebetterbutyoudont-makedefault, and they're both installed? Who wins? Or do they need to be marked as conflicting? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Fri Jun 30 15:49:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 30 Jun 2006 21:19:07 +0530 Subject: Changing the default font in Fedora Core 6 In-Reply-To: <44A48A0F.5070609@glezos.com> References: <44A48A0F.5070609@glezos.com> Message-ID: <44A547F3.1010703@fedoraproject.org> Dimitris Glezos wrote: > > Hello all. > > Having read the thread that was active 2+ weeks ago "Changing the > default font in Fedora Core 6" [1], I think that it's obvious that the > Best Thing? would be to include DejaVu in Core as soon as possible. > > Translators work hard for translating fedora core, extras, the docs > and the release notes, but the installer is absolutely unusable in > some languages because the best font out there isn't included in the > Core. Ambassadors work hard in event organizing and spreading the word > about Fedora to new users, but one has to manually edit the fonts.conf > file to get a usable desktop in > 1 languages. I am sad to say this, > but I heard people using the words "unacceptable" and "proof that the > community doesn't matter" for the fonts issues in Fedora. (For some > screenshots, take a look at [2].) The request was filed by me and I wouldnt consider a rejection a community or personal thing. Repeated arguments that everybody should give me what I want, otherwise community doesnt matter is pretty obnoxious. Lets keep the discussion technical. > > Many people from this list agreed that we should include DejaVu. I > believe that we should try our best to include it in the Core, > definitely before Test 3 so that some testing gets done too. I don't > know if someone is willing to transfer it to Core before Test 2 and I > am not sure if the fontconfig patch to exclude characters from a font > will be ready soon, or if it is even needed, since DejaVu LGU exists. > > What I do know is that we should fix this problem that spoils the > image of our distribution as soon as possible. Not only because it's > simply the best free font out there, but because the community really > needs it straight away. Other major distros like Suse and Ubuntu have > already realized this, and while this decision is considered a > no-brainer, we are still talking about it. > > Thanks to Nicolas Mailhot, a package already exists in extras-devel, > so most of the work is already done. Now, the only thing that remains > (as I see it) is a Core maintainer to step forward. > > > -Dimitris Glezos > > Fedora ambassador for Greece > > > [1]: > https://www.redhat.com/archives/fedora-devel-list/2006-June/thread.html#00292 > > [2]: > http://fedoraproject.org/wiki/L10N/Teams/Greek/Issues#head-6355afab18e12a4bc80288e6476fbfecb8530a24 > > > Rahul -- Rahul From nicolas.mailhot at laposte.net Fri Jun 30 16:22:59 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 30 Jun 2006 18:22:59 +0200 (CEST) Subject: Changing the default font in Fedora Core 6 In-Reply-To: <20060630153930.GA31330@jadzia.bu.edu> References: <44A48A0F.5070609@glezos.com> <40386.192.54.193.52.1151655389.squirrel@rousalka.dyndns.org> <20060630153930.GA31330@jadzia.bu.edu> Message-ID: <11813.192.54.193.52.1151684579.squirrel@rousalka.dyndns.org> Le Ven 30 juin 2006 17:39, Matthew Miller a ?crit : > On Fri, Jun 30, 2006 at 10:16:29AM +0200, Nicolas Mailhot wrote: >> Installing the makedefault dejavu subpackage will make dejavu the >> default >> without editing manually fontconfig files > > Hmmm. I'm not sure this is a good approach. What if later, there's > ilikethisonebetterbutyoudont-makedefault, and they're both installed? Who > wins? Or do they need to be marked as conflicting? Of course it sucks as a general solution. I did it in the (naive) hope people would stop asking me why dejavu was not the default FC font yet. Regards, -- Nicolas Mailhot From notting at redhat.com Fri Jun 30 16:34:55 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 Jun 2006 12:34:55 -0400 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <1151662926.6570.243.camel@localhost.localdomain> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> <44A45BFA.5080601@fedoraproject.org> <1151662926.6570.243.camel@localhost.localdomain> Message-ID: <20060630163455.GA6720@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > Yep, but I'm not sure about what's the best list for visibility. > Perhaps fedora-maintainers is better than here; no docs recommend Extras > contributors to subscribe to fedora-devel and I believe many don't read > it (myself included). > > Changing the target or adding additional ones in the script is trivial > and I can take care of it when it's clear where the report is wanted, > but someone who has the rights needs to auto-whitelist/subscribe the > sender (buildsys at fedoraproject.org) to those lists or let me know if > there's another sender that should be used. How much work would it be to file bugs via XML-RPC, and track which paths have had bugs filed for them so that we only file a bug once? Bill From sopwith at redhat.com Fri Jun 30 18:06:18 2006 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 30 Jun 2006 14:06:18 -0400 Subject: Extras Package Database Message-ID: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> Hi all, http://fedoraproject.org/wiki/Infrastructure/PackageDatabase has been out there for a bit... I've put together a strawman schema (as a TurboGears model.py) to help move things along - apologies if someone else has beaten me to it. I think at this point the right questions to be asking are long the lines of "will this schema support feature X or use case Y?". From a quick glance at the web page, I *think* it mostly will. There are some problems with this still, but open source is all about fixing those problems :) class Collection(SQLObject): name = StringCol(length=128, notNone=True) # "Core", "Extras", or whatever names-for-grouping you want class Package(SQLObject): name = StringCol(length=128, notNone=True) # "Core", "Extras", or whatever names-for-grouping you want created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) status = EnumCol(enumValues=('awaitingreview', 'approved', 'denied'), default='awaitingreview', notNone=True) class PackageHistory(SQLObject): # Records changes to packages package = ForeignKey('Package', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'removed', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageListing(SQLObject): package = ForeignKey('Package', notNone=True) collection = ForeignKey('Collection', notNone=True) created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) status = EnumCol(enumValues=('awaitingreview', 'awaitingbranch', 'approved', 'denied'), default='awaitingreview', notNone=True) class PackageListingHistory(SQLObject): # Records changes to packages package_listing = ForeignKey('PackageListing', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'removed', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageVersion(SQLObject): # A specific version on a specific branch package_listing = ForeignKey('PackageListing', notNone=True) version = StringCol(length=128, notNone=True) status = EnumCol(enumValues=('awaitingdevel', 'awaitingreview', 'awaitingqa', 'awaitingpublish', 'approved', 'denied', 'obsolete'), default='awaitingdevel', notNone=True) created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageVersionHistory(SQLObject): # Records changes to packages package_version = ForeignKey('PackageVersion', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageInterest(SQLObject): # Note: PackageInterestHistory table assumes that records will never be removed from here. # Instead, set the status to 'obsolete' user_id = IntCol(notNone=True) package_listing = ForeignKey('PackageListing', notNone=True) status = EnumCol(enumValues=('awaitingreview', 'approved', 'denied', 'obsolete'), default='awaitingreview', notNone=True) role = EnumCol(enumValues=('watcher', 'owner'), default='watcher', notNone=True) # Used for authorization class PackageInterestHistory(SQLObject): package_interest = ForeignKey('PackageInterest', notNone=True) action = EnumCol(enumValues=('added', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) Best, -- Elliot From ville.skytta at iki.fi Fri Jun 30 18:10:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 21:10:57 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <20060630163455.GA6720@nostromo.devel.redhat.com> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> <44A45BFA.5080601@fedoraproject.org> <1151662926.6570.243.camel@localhost.localdomain> <20060630163455.GA6720@nostromo.devel.redhat.com> Message-ID: <1151691057.6570.318.camel@localhost.localdomain> On Fri, 2006-06-30 at 12:34 -0400, Bill Nottingham wrote: > How much work would it be to file bugs via XML-RPC, and track which > paths have had bugs filed for them so that we only file a bug once? Cannot tell, I have no experience with Bugzilla's XML-RPC interface. Is it documented somewhere? For tracking, maybe checking for open bugs having a fixed format bug summary (eg. "$package: broken upgrade path") and matching product/component would work sufficiently well. From jpo at lsd.di.uminho.pt Fri Jun 30 18:29:38 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 30 Jun 2006 19:29:38 +0100 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <1151691057.6570.318.camel@localhost.localdomain> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> <44A45BFA.5080601@fedoraproject.org> <1151662926.6570.243.camel@localhost.localdomain> <20060630163455.GA6720@nostromo.devel.redhat.com> <1151691057.6570.318.camel@localhost.localdomain> Message-ID: <44A56D92.2020509@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > On Fri, 2006-06-30 at 12:34 -0400, Bill Nottingham wrote: > >> How much work would it be to file bugs via XML-RPC, and track which >> paths have had bugs filed for them so that we only file a bug once? > > Cannot tell, I have no experience with Bugzilla's XML-RPC interface. Is > it documented somewhere? I don't know if this helps but it should be possible to create new tickets with the perl module WWW::Bugzilla [1]. jpo [1] - http://search.cpan.org/dist/WWW-Bugzilla/Bugzilla.pm [2] - The perl module Crypt::SSLeay must be installed in order to have secure connections. - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEpW2Sl0metZG9hRsRAofEAKCslbEpAMda1g/t/mlwP258onnRPACcDclr 3b8qtFWO4RhehA5PcXTluds= =aT0b -----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 ville.skytta at iki.fi Fri Jun 30 19:04:18 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 22:04:18 +0300 Subject: Broken upgrade paths in FC+FE 2006-06-29 In-Reply-To: <44A56D92.2020509@lsd.di.uminho.pt> References: <20060629224147.25A5515217B@buildsys.fedoraproject.org> <44A45BFA.5080601@fedoraproject.org> <1151662926.6570.243.camel@localhost.localdomain> <20060630163455.GA6720@nostromo.devel.redhat.com> <1151691057.6570.318.camel@localhost.localdomain> <44A56D92.2020509@lsd.di.uminho.pt> Message-ID: <1151694258.6570.325.camel@localhost.localdomain> On Fri, 2006-06-30 at 19:29 +0100, Jose Pedro Oliveira wrote: > I don't know if this helps but it should be possible to create new > tickets with the perl module WWW::Bugzilla [1]. The upgrade checker is written in Python due to repodata library availability, so a Python interface would be preferable. Also, WWW::Bugzilla doesn't seem to have any query capabilities (and quite frankly, it looks like a pretty ugly HTML/CGI scraper to me ;)), so it probably isn't what we're looking for. From j.w.r.degoede at hhs.nl Fri Jun 30 20:34:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 30 Jun 2006 22:34:23 +0200 Subject: packaging a lib which needs to be compiled in different ways for different users Message-ID: <44A58ACF.3080700@hhs.nl> Hi all, I and Eitch are currently looking into packaging ode (a physics library). Ode uses OPCODE which is a 3D collision detection library. Opcode is included in ode's sources but is used by many opensource projects to name 2: -crystal space -ode Opcode can be compiled to use either callbacks to get the next object from a list of objects that need to be checked for collisions _OR_ to use an array of pointers to these objects. however it cannot be compiled to support both! And it has more compile time options like these which are likely to be used in a mix and match style by other projects. Also all projects using opcode seem to have made their own additions to it, now these extra overloaded operators and methods could be merged into the mainline, but thats going to be a pain, because then each time a new package using opcode is going to get packaged any functionality added to opcode by this application much first be merged into our seperate opcode package. And even with that done we still have the compile time options. Notice that I gave one example, but that there are atleast 2 options which lead to incompatible libs, so thats 4 versions of the lib. and that is only after checking the 3 options modifed from the default settings by ode and crystalspace, so thats 2 out of 3 :| All in all this leads me to the conclusion that its best to make an exception to the rule: "libraries with a seperate upstream yet included in the sourcetarbal must not be used" in the case of opcode. Does not following this rule sound reasonable / any objections? Thanks and Regards, Hans p.s. I know we have this rule, atleast I think we have this rule and we should have this rule, but is it written down somewhere? From bugzilla at redhat.com Fri Jun 30 22:20:34 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 30 Jun 2006 18:20:34 -0400 Subject: [Bug 175201] Review Request: python-cheetah In-Reply-To: Message-ID: <200606302220.k5UMKYC3019994@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-cheetah https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175201 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 dmalcolm at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmalcolm 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 Matt_Domsch at dell.com Fri Jun 30 22:24:10 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 30 Jun 2006 17:24:10 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-06-30 Message-ID: <20060630222410.GC6833@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Fri Jun 30 17:04:29 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 134 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 123 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 115 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org drgeo-1.1.0-8.fc6 eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 bnocera at redhat.com ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu fish-1.12.0-1.fc5 oliver at linux-kernel.at flim-1.14.7-3 petersen at redhat.com flow-tools-0.68-8.fc6 i at stingr.net foobillard-3.0a-4 mitr at redhat.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gazpacho-0.6.5-1.fc5 icon at fedoraproject.org gdesklets-0.35.3-8.fc6 luya256 at yahoo.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de glabels-2.0.4-2.fc5 jspaleta at gmail.com gnomad2-2.8.6-1.fc6 triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ivazquez at ivazquez.net gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gnome-schedule-1.0.0-1 frank at scirocco-5v-turbo.de gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com grhino-0.15.0-5.fc5 michel.salim at gmail.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org gsynaptics-0.9.5-2.fc5 fedora at leemhuis.info GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtk-gnutella-0.96.1-1.fc5 dmitry at butskoy.name Gtk-Perl-0.7008-40.fc5 extras-orphan at fedoraproject.org gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de hercules-3.02-3 matthias at rpmforge.net ifplugd-0.24-6 aaron.bennett at olin.edu jack-audio-connection-kit-0.101.1-10.fc6 andy at smile.org.ua jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net libtranslate-0.99-7.fc6 dmitry at butskoy.name licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr monodoc-1.1.13-13.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ed at eh3.com NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org pam_keyring-0.0.7-2 redhat at flyn.org pam_mount-0.13.0-3 redhat at flyn.org perl-Image-Info-1.21-2.fc6 jpo at di.uminho.pt perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com uqm-0.5.0-1.fc5 icon at fedoraproject.org verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbindkeys-1.7.2-5.fc6 gauret at free.fr xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 8 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bmp-0.9.7.1-4.fc5 ['197356 NEW'] redhat-bugzilla at camperquake.de ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 NEW'] foolish at guezz.net dillo-0.8.6-1.fc6 ['197370 NEW'] andreas.bierfert at lowlatency.de xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de 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 Fri Jun 30 22:24:34 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 30 Jun 2006 17:24:34 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-06-30 Message-ID: <20060630222434.GD6833@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Fri Jun 30 17:08:00 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Number failed to build: 114 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 113 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 103 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org drgeo-1.1.0-8.fc6 eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 bnocera at redhat.com ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com erlang-R11B-0.1.fc6 gemi at bluewin.ch exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu fish-1.12.0-1.fc5 oliver at linux-kernel.at flim-1.14.7-3 petersen at redhat.com flow-tools-0.68-8.fc6 i at stingr.net gazpacho-0.6.5-1.fc5 icon at fedoraproject.org gdesklets-0.35.3-8.fc6 luya256 at yahoo.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de glabels-2.0.4-2.fc5 jspaleta at gmail.com gnomad2-2.8.6-1.fc6 triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ivazquez at ivazquez.net gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gnome-schedule-1.0.0-1 frank at scirocco-5v-turbo.de gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com grads-1.9b4-11.fc6 pertusus at free.fr grhino-0.15.0-5.fc5 michel.salim at gmail.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org gsynaptics-0.9.5-2.fc5 fedora at leemhuis.info GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtk-gnutella-0.96.1-1.fc5 dmitry at butskoy.name Gtk-Perl-0.7008-40.fc5 extras-orphan at fedoraproject.org gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de Hermes-1.3.3-7 thomas at apestaart.org ifplugd-0.24-6 aaron.bennett at olin.edu jack-audio-connection-kit-0.101.1-10.fc6 andy at smile.org.ua jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net libtranslate-0.99-7.fc6 dmitry at butskoy.name licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ed at eh3.com NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com ucblogo-5.5-4.fc6 gemi at bluewin.ch verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbindkeys-1.7.2-5.fc6 gauret at free.fr xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com With bugs filed: 10 ---------------------------------- abiword-2.4.4-2.fc6 ['196690 NEW'] uwog at uwog.net alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bmp-0.9.7.1-4.fc5 ['197356 NEW'] redhat-bugzilla at camperquake.de ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net compat-erlang-R10B-10.2.fc6 ['197364 NEW'] gemi at bluewin.ch cowbell-0.2.7.1-2.fc6 ['197366 NEW'] foolish at guezz.net dillo-0.8.6-1.fc6 ['197370 NEW'] andreas.bierfert at lowlatency.de xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de 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