Re: Orphaning packages
23.08.2009 02:15, Kevin Kofler wrote: Pavel Alexeev (aka Pahan-Hubbitus) wrote: My point was different: I want use gwenview but don't always use kdegrapics, wich have big size. So, I often use it in XFCE. But packaging an obsolete standalone package which is no longer released standalone by upstream and which conflicts with another package containing the current version surely cannot be the solution, and the resulting file conflicts are a violation of Fedora's guidelines. Ok. I'll try ask maintainer of kdegraphics to split gwenview into separate package. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
23.08.2009 02:13, Kevin Kofler wrote: If gwenview is to be split, it has to be built as a subpackage of kdegraphics, but I'm opposed to that too. Why? You are like big monolitic packages instead of freedom chouse components what you are really need? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090823 changes
Compose started at Sun Aug 23 06:15:14 UTC 2009 Updated Packages: cheese-2.27.90-3.fc12 - * Sat Aug 22 2009 Matthias Clasen 2.27.90-3 - Update sensitivity of menu items chemtool-1.6.12-1.fc12 -- * Sat Aug 22 2009 Dominik 'Rathann' Mierzejewski 1.6.12-1 - updated to 1.6.12 - dropped obsolete patch hunks - moved gtk-update-icon-cache to posttrans scriptlet compiz-0.8.2-12.fc12 * Sat Aug 22 2009 Adel Gadllah - 0.8.2-11 - Fix up the compiz-gtk script * Sat Aug 22 2009 Adel Gadllah - 0.8.2-12 - Fix build cpdup-1.14-1.fc12 - * Sat Aug 22 2009 Michel Salim - 1.14-1 - Update to 1.14 dhcp-4.1.0p1-6.fc12 --- * Fri Aug 21 2009 David Cantrell - 12:4.1.0p1-6 - BR libcap-ng-devel (#517649) dkms-2.1.0.0-1.fc12 --- * Sat Aug 22 2009 Matt Domsch - 2.1.0.0-1 - update to latest upstream - drop Requires: lsb. avoid calling rpm (recursively) if possible. - add recognition for Oracle Enterprise Linux, Oracle VM, Scientific Linux, and VMware 3.x eclipse-dltk-1.0.0-3.fc12 - * Thu Aug 20 2009 Mat Booth 1.0.0-3 - Add a SDK package. - Require Mylyn >= 3.2. eclipse-valgrind-0.3.0-1.fc12 - * Thu Aug 20 2009 Elliott Baron 0.3.0-1 - Upstream 0.3.0 release. fwbackups-1.43.3-0.7.rc4.fc12 - * Sat Aug 22 2009 Stewart Adam 1.43.3-0.7.rc4 - Update to 1.43.3rc4 (fixes #518690) gedit-2.27.4-2.fc12 --- * Sat Aug 22 2009 Matthias Clasen - 1:2.27.4-2 - Respect button-images setting glest-3.2.2-1.fc12 -- * Sat Aug 22 2009 Bruno Wolff III - 3.2.2-1 - rebuild for openal-soft version change - reenable ppc to allow retesting of 219540 - Update to 3.2.2 to pick up some networking fixes * Sun Jul 26 2009 Aurelien Bompard 3.2.1-3 - fix wrapper script (#501181) glest-data-3.2.1-3.fc12 --- * Sat Aug 22 2009 Bruno Wolff III - 3.2.1-3 - Allow glest-data and glest versions to be different - Reenable ppc/ppc64 builds to allow retesting of 219540 gnome-system-monitor-2.27.4-3.fc12 -- * Sat Aug 22 2009 Matthias Clasen - 2.27.4-3 - Fix a button image - Add a close button to the memmaps dialog hydrogen-0.9.4-0.7.rc2.fc12 --- * Sat Aug 22 2009 Orcan Ogetbil - 0.9.4-0.7.rc2 - Update to 0.9.4-rc2 hyphen-kn-0.20090815-1.fc12 --- * Sat Aug 22 2009 Caolan McNamara - 0.20090815-1 - latest version ibus-qt-1.2.0.20090822-2.fc12 - libftdi-0.16-7.fc12 --- * Sat Aug 22 2009 Lucian Langa - 0.16-7 - add group for udev rule (#517773) llvm-2.5-5.fc12 --- * Sat Aug 22 2009 Michel Salim - 2.5-4 - Disable use of position-independent code on 32-bit platforms (buggy in LLVM <= 2.5) * Sat Aug 22 2009 Michel Salim - 2.5-5 - Only disable PIC on %ix86; ppc actually needs it lyx-1.6.4-1.fc12 * Sat Aug 22 2009 Rex Dieter - 1.6.4-1 - lyx-1.6.4 - handle fonts manually (now EPEL-5 compatible) maxima-5.19.1-1.fc12 * Sat Aug 22 2009 Rex Dieter - 5.19.1-1 - maxima-5.19.1 - -gui: optimize scriptlets * Tue Aug 18 2009 Rex Dieter - 5.19.0-2 - safer evaluation of %sbcl_ver macro * Sat Aug 01 2009 Rex Dieter - 5.19.0-1 - maxima-5.19.0 mingw32-libp11-0.2.6-1.fc12 --- * Sat Aug 22 2009 Kalev Lember - 0.2.6-1 - Update to 0.2.6 - Use INSTALL="install -p" to preserve timestamps mojito-0.20-2.fc12 -- * Sat Aug 22 2009 Peter Robinson 0.20-2 - Enable twitter, lastfm, MySpace and Flickr networks mr-0.42-1.fc12 -- * Sat Aug 22 2009 Fabian Affolter - 0.42-1 - Added new man page - Updated to new upstream version 0.42 perl-Text-Textile-2.12-2.fc12 - * Sat Aug 22 2009 Iain Arnell 2.12-1 - update to latest upstream * Sat Aug 22 2009 Iain Arnell 2.12-2 - BR perl(Test::Pod) policycoreutils-2.0.71-10.fc12 -- * Sat Aug 22 2009 Dan Walsh 2.0.71-10 - Fix realpath usage to only happen on argv input from user rakudo-0.0.2009.08_1.5.0-2.fc12 --- ratproxy-1.58-1.fc12 * Sun Aug 23 2009 Rakesh Pandit - 1.58-1 - Adjusted Steve's patch for updateing to 1.58 # 518542 * Fri Aug 21 2009 Tomas Mraz - 1.56-3 - rebuilt with new openssl rhythmbox-0.12.3-5.fc12 --- * Sat Aug 22 2009 Matthias Clasen - 0.12.3-5 - Respect the button-images setting better selinux-policy-3.6.28-5.fc12 * Sat Aug 22 2009 Dan Walsh 3.6.28-5 - Allow cronjobs to read exim_spool_t setroubleshoot-2.2.22-2.fc12 * Sat Aug 22 2009 Dan Walsh - 2.2.22-1 - Differentiate between permissive domains and permissive mode * Sat Aug 22 2009 Dan Walsh - 2.2.22-2 - Turn on libcap-ng-devel setroubleshoot-plugins-2.1.16-1.fc12 -
Re: source file audit - 2009-08-10
On Tue, Aug 11, 2009 at 7:41 PM, Andrea Musuruane wrote: > On Tue, Aug 11, 2009 at 7:30 AM, Kevin Fenzi wrote: >> The URL is fine, but the source doesn't match up. >> What I downloaded from the URL: >> e2932389d10ccee20dc922155165c8f8 libicns-0.7.0.tar.gz >> >> what sources has in the lookaside cache: >> d2539bb1bec033395ad908311c49a954 libicns-0.7.0.tar.gz >> >> So, either upstream changed sources without changing release, or >> something else bad happened. ;( > > Yes, upstream changed the sources without issuing a new release :( > > I'll update the package soon. Fixed. Thanks again for your report. Regards, Andrea. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Fri, Aug 21, 2009 at 10:34 PM, Aurelien Bompard wrote: > - php-adodb -- Active Data Objects Data Base Taking this one, co-maintainers welcome -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Sun, Aug 23, 2009 at 4:55 PM, Gianluca Sforna wrote: > On Fri, Aug 21, 2009 at 10:34 PM, Aurelien Bompard wrote: >> - php-adodb -- Active Data Objects Data Base > > Taking this one, co-maintainers welcome > Additionally, can you orphan the other active branches as well? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Sun, 2009-08-23 at 14:34 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 23.08.2009 02:13, Kevin Kofler wrote: > If gwenview is > > to be split, it has to be built as a subpackage of kdegraphics, but I'm > > opposed to that too. > Why? You are like big monolitic packages instead of freedom chouse > components what you are really need? > There is no need for accusations and heated language, surely. What Kevin is expressing is a natural expression of the packager's Occam razor: it's simpler to maintain a package if we keep the binaries as close in packaging to the way upstream ships it. Unless splitting gives enough advantage, e.g. separating out plugins for a program that have additional dependencies. In case of kdegraphics, apart from for some disk space saving (not that great, surely in this day and age), can you argue the case for wanting such split? Best, -- Michel Salim GPG key ID: 78884778 IRC:hircus Package Sponsor, Fedora Project -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
fedora-pkgdb: make it discoverable on browser home page?
Hi Adam, Thanks for the wonderful fedora-pkgdb search engine! I was wondering -- since it's a standard opensearch plugin, whether it would be a good idea or not to make it auto-discoverable on *.fedoraproject.org, especially start.fedoraproject.org which is our default browser home page? That way, users gain another way to search for packages -- one they are already familiar with -- and it's an easier way to look for existing bugs and file new ones too, IMHO. Regards, -- Michel Salim GPG key ID: 78884778 IRC:hircus Package Sponsor, Fedora Project signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
> Additionally, can you orphan the other active branches as well? Done, thanks. Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Bug 506671] GNOME/Gtk scrollbar corruption with fedora-gnome-theme
> https://bugzilla.redhat.com/show_bug.cgi?id=506671 No comment since two months. Not even a confirmation that the last comment is true. Fedora 11 still looks bad due to this. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/23/2009 10:06 AM, Michel Salim wrote: > Hi Adam, > > Thanks for the wonderful fedora-pkgdb search engine! I was wondering -- > since it's a standard opensearch plugin, whether it would be a good idea > or not to make it auto-discoverable on *.fedoraproject.org, especially > start.fedoraproject.org which is our default browser home page? > > That way, users gain another way to search for packages -- one they are > already familiar with -- and it's an easier way to look for existing > bugs and file new ones too, IMHO. > In the past, the pkgdb was seen as a developer-only tool so it wasn't too interesting too the general public. However, as part of GSoC, maploin has done some good work to change that. The interface is a little rough still but there are now end-user features (package build information like repoview, user-supplied tagging and commenting) in the development repo (not deployed yet). -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
On 08/23/2009 11:18 PM, Michael Schwendt wrote: > Doubtful. How much will that save? - A typical problem with KDE apps is > that not only they pull in some KDE libraries, the KDE packages come with > lots of additional KDE-specific dependencies. > > Installing: > ktorrent i586 3.2.3-1.fc11 > updates 3.3 M > Installing for dependencies: > akonadi i586 1.2.0-1.fc11 > updates-testing 682 k > kdebase-workspacei586 4.3.0-8.fc11 > updates-testing14 M > kdebase-workspace-libs i586 4.3.0-8.fc11 > updates-testing 906 k > kdepimlibs-akonadi i586 4.3.0-2.fc11 > updates-testing 505 k > kdm i586 4.3.0-8.fc11 > updates-testing 1.9 M > qt-mysql i586 1:4.5.2-2.fc11 > updates53 k A torrent client requires a display manager and Qt MySQL? Hmm. Something wrong with dependencies, here. I am sure, we can do better. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/23/2009 11:17 PM, Toshio Kuratomi wrote: > On 08/23/2009 10:06 AM, Michel Salim wrote: >> Hi Adam, >> >> Thanks for the wonderful fedora-pkgdb search engine! I was wondering -- >> since it's a standard opensearch plugin, whether it would be a good idea >> or not to make it auto-discoverable on *.fedoraproject.org, especially >> start.fedoraproject.org which is our default browser home page? >> >> That way, users gain another way to search for packages -- one they are >> already familiar with -- and it's an easier way to look for existing >> bugs and file new ones too, IMHO. >> > In the past, the pkgdb was seen as a developer-only tool so it wasn't > too interesting too the general public. However, as part of GSoC, > maploin has done some good work to change that. The interface is a > little rough still but there are now end-user features (package build > information like repoview, user-supplied tagging and commenting) in the > development repo (not deployed yet). Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Rahul Sundaram wrote: > On 08/23/2009 11:18 PM, Michael Schwendt wrote: > >> Doubtful. How much will that save? - A typical problem with KDE apps is >> that not only they pull in some KDE libraries, the KDE packages come with >> lots of additional KDE-specific dependencies. >> >> Installing: >> ktorrent i586 3.2.3-1.fc11 >> updates 3.3 M >> Installing for dependencies: >> akonadi i586 1.2.0-1.fc11 >> updates-testing 682 k >> kdebase-workspacei586 4.3.0-8.fc11 >> updates-testing14 M >> kdebase-workspace-libs i586 4.3.0-8.fc11 >> updates-testing 906 k >> kdepimlibs-akonadi i586 4.3.0-2.fc11 >> updates-testing 505 k >> kdm i586 4.3.0-8.fc11 >> updates-testing 1.9 M >> qt-mysql i586 1:4.5.2-2.fc11 >> updates53 k > > A torrent client requires a display manager and Qt MySQL? Hmm. Something > wrong with dependencies, here. I am sure, we can do better. It grew a dependency on some newer libraries in kdebase-workspace recently, probably some prudent sub-packages are in order. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
gwenview - Re: Orphaning packages
On Sun, 23 Aug 2009 14:31:28 +0400, Pavel wrote: > 23.08.2009 02:15, Kevin Kofler wrote: > > Pavel Alexeev (aka Pahan-Hubbitus) wrote: > >> My point was different: I want use gwenview but don't always use > >> kdegrapics, wich have big size. So, I often use it in XFCE. > > > > But packaging an obsolete standalone package which is no longer released > > standalone by upstream and which conflicts with another package containing > > the current version surely cannot be the solution, and the resulting file > > conflicts are a violation of Fedora's guidelines. > > Ok. I'll try ask maintainer of kdegraphics to split gwenview into > separate package. Doubtful. How much will that save? - A typical problem with KDE apps is that not only they pull in some KDE libraries, the KDE packages come with lots of additional KDE-specific dependencies. Installing: ktorrent i586 3.2.3-1.fc11 updates 3.3 M Installing for dependencies: akonadi i586 1.2.0-1.fc11 updates-testing 682 k kdebase-workspacei586 4.3.0-8.fc11 updates-testing14 M kdebase-workspace-libs i586 4.3.0-8.fc11 updates-testing 906 k kdepimlibs-akonadi i586 4.3.0-2.fc11 updates-testing 505 k kdm i586 4.3.0-8.fc11 updates-testing 1.9 M qt-mysql i586 1:4.5.2-2.fc11 updates53 k -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
On 08/23/2009 11:31 PM, Rex Dieter wrote: >> >> A torrent client requires a display manager and Qt MySQL? Hmm. Something >> wrong with dependencies, here. I am sure, we can do better. > > It grew a dependency on some newer libraries in kdebase-workspace recently, > probably some prudent sub-packages are in order. A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. It usually reveals dependencies which are rather silly. I have seen kde-settings, background packages and kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus et all are often used outside KDE. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Tue, 18 Aug 2009 12:04:14 +0200 Christoph Wickert wrote: > Am Montag, den 10.08.2009, 10:15 -0600 schrieb Kevin Fenzi: > > > cwickert:BADURL:glista-0.4.tar.gz:glista > > works with spectool Yeah, googlecode outage/issue when I ran the script. ;( > > cwickert:BADURL:gwget-1.0.1.tar.bz2:gwget > > 404, new version, fixed. > > > cwickert:BADURL:lxde-settings-daemon-0.4.tar.bz2:lxde-settings-daemon > > 301, due to sf changes I guess. lxde-settings-deamon will be orphaned > soon, because it will become part of lxsession. > > > cwickert:BADURL:termit-2.2.0.tar.bz2:termit > > works with spectool googlecode. ;( > > cwickert:BADURL:thunar-volman-0.3.80.tar.bz2:thunar-volman > > 404, Xfce download archive reorganization. > > > cwickert:BADURL:timer-applet-2.1.2.tar.gz:gnome-applet-timer > > works spectool, SF.net Sourceforge being lame I guess. I just tried this one again from here and it just sits until it times out. ;( > > cwickert:BADURL:xfburn-0.4.2.tar.bz2:xfburn > > 404, Xfce download archive reorganization. > > Regards, > Christoph Thanks! kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
showing dependency trees
Rahul Sundaram wrote: > A quick way to actually check for such dependencies is to switch to > another desktop environment, say Xfce, remove all the KDE packages and > install one of the KDE apps. That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/24 Björn Persson > Rahul Sundaram wrote: > > A quick way to actually check for such dependencies is to switch to > > another desktop environment, say Xfce, remove all the KDE packages and > > install one of the KDE apps. > > That's not all that quick. There ought to be a tool for this. Given a > package > name it should print the dependency tree for that package. It could have an > option to suppress packages in the base set. Couldn't Yum be taught to > answer > that kind of queries? edos-rpmcheck http://www.edos-project.org/xwiki/bin/view/Main/debcheck_home > > > Björn Persson > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Regards, Debayan Banerjee Support Free Software http://deeproot.in -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Wed, 19 Aug 2009 22:45:21 -0400 "Tom \"spot\" Callaway" wrote: > On 08/10/2009 12:15 PM, Kevin Fenzi wrote: > > spot:BADSOURCE:chemoelectric_-_Goudy_Bookletter_1.zip:oflb-goudy-bookletter-1911-fonts > > Not sure why this failed. I confirmed that the .zip file available > from the site is identical to the one in the lookaside. Cute. My download worked, but I got in the zip file: [chemoelectric_-_Goudy_Bookletter_1.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. zipinfo: cannot find zipfile directory in one of chemoelectric_-_Goudy_Bookletter_1.zip or chemoelectric_-_Goudy_Bookletter_1.zip.zip, and cannot find chemoelectric_-_Goudy_Booklett er_1.zip.ZIP, period. So, some weirdness with the upstream ftp/http server I guess. > > spot:BADSOURCE:daa2iso.zip:daa2iso > > Fixed (I have begged the upstream here to put versioning in their > name, but they will not) > > > spot:BADSOURCE:perltex.zip:tetex-perltex > > This package is probably going away with texlive, so I'm just letting > it sit. > > > spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware > > spot:BADSOURCE:ql2500_fw.bin:ql2500-firmware > > Updated to the latest versions of the firmware. > > > spot:BADURL:Acetoneiso_2.0.3.2.tar.gz:AcetoneISO2 > > This checks out for me. > > > spot:BADURL:alsamixergui-0.9.0rc1-2.tar.gz:alsamixergui > > Upstream is gone. I've updated the package to reflect that. > > > spot:BADURL:amanith_03.tar.gz:amanith > > Upstream no longer maintains this code, updated package to reflect > that. > > > spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship > > Fixed. > > > spot:BADURL:ebtables-v2.0.9-1.tar.gz:ebtables > > Fixed. > > > spot:BADURL:giver-0.1.8.tar.gz:giver > > Looks fine to me, can't reproduce failure. > > > spot:BADURL:google-perftools-1.3.tar.gz:google-perftools > > Looks fine to me, can't reproduce failure. Yeah, these are both googlecode, which was giving me 404's when I ran the script. ;( > > spot:BADURL:gxemul-0.4.7.2.tar.gz:gxemul > > Fixed. > > > spot:BADURL:mcrypt-2.6.8.tar.gz:mcrypt > > Took me several tries to get this to work, but it is correct. > Sourceforge seems to be especially flaky these days. yes it does. ;( > > spot:BADURL:musiqwik_musisync_y6.zip:allgeyer-fonts > > Upstream is gone, removed URL from Source. > > > spot:BADURL:pdsh-2.18.tar.bz2:pdsh > > Looks fine to me, can't reproduce failure. SF gave me a 404: --15:54:01-- http://dl.sourceforge.net/sourceforge/pdsh/pdsh-2.18.tar.bz2 Resolving dl.sourceforge.net... 128.101.240.209, 150.65.7.130, 193.1.219.87, ... Connecting to dl.sourceforge.net|128.101.240.209|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:55:14 ERROR 404: Not Found. > > spot:BADURL:Pod-POM-0.18.tar.gz:perl-Pod-POM > > Fixed. > > > spot:BADURL:pydot-1.0.2.tar.gz:pydot > > Looks fine to me, can't reproduce failure. Googlecode. > > spot:BADURL:pyke-1.0.2.tar.gz:pyke > > Looks fine to me, can't reproduce failure. Sourceforge. ;( > > spot:BADURL:python-twitter-0.6.tar.gz:python-twitter > > Looks fine to me, can't reproduce failure. googlecode. > > spot:BADURL:RODBC_1.2-5.tar.gz:R-RODBC > > Fixed. > > > spot:BADURL:rx-1.5.tar.bz2:librx > > FSF no longer maintains or offers this code, dropped URL from Source0. > > > spot:BADURL:Test-Differences-0.4801.tar.gz:perl-Test-Differences > > Fixed. > > > spot:BADURL:winpdb-1.4.6.tar.gz:winpdb > > Looks fine to me, can't reproduce failure. googlecode. > > spot:BADURL:XML-RSS-1.44.tar.gz:perl-XML-RSS > > Fixed. > > > spot:BADURL:zlib.tar.gz:tcl-zlib > > Been waiting more than a year now for upstream to revive his website > (he swears he's going to do it everytime I email him, but I have > given up). Removed URL from Source. :( > *** > > Thanks for running this. No problem > ~spot kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Thu, 20 Aug 2009 10:47:54 +0200 Christof Damian wrote: > On Mon, Aug 10, 2009 at 18:15, Kevin Fenzi wrote: > > > > cdamian:BADURL:wikicalendar-1.15.tar.gz:mediawiki-wikicalendar > > > > Just checked this one and it works. Probably was a temporary problem > with googlecode . yep. ;( googlecode and SF seem to both sometimes sporadically just not work. > > Christof > kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Debayan Banerjee wrote: > 2009/8/24 Björn Persson > > That's not all that quick. There ought to be a tool for this. Given a > > package > > name it should print the dependency tree for that package. It could have > > an option to suppress packages in the base set. Couldn't Yum be taught to > > answer > > that kind of queries? > > edos-rpmcheck > > http://www.edos-project.org/xwiki/bin/view/Main/debcheck_home Judging from the description on that page, that's not what I want. It says the program checks whether a package is installable. Yum can do that. I want to check whether a package drags in other packages unnecessarily. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/23/2009 10:50 AM, Rahul Sundaram wrote: > Aren't we pitching Fedora Community interface as the end user facing > thing, going forward? It seems some of these features will overlap or > duplicate it. > It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 20090729
On Wed, Jul 29, 2009 at 9:52 PM, Till Maas wrote: > Again the log seems to be incomplete. If I type ".fesco 218" in > #feedora-meeting, I get this line from zodbot: FYI, I just updated the meetbot plugin on noc1 to the latest version in koji that Kevin built a bit ago, which contains a fix for this issue. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Wed, 19 Aug 2009 23:49:39 + (UTC) Elio Maldonado wrote: > Author: emaldonado > > Update of /cvs/extras/rpms/nss-softokn/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6734 > > Added Files: > nss-softokn-3.12.3.99.3-stripped.tar.bz2 > Log Message: > Initial checkin Looks like somehow this tar.bz2 file got checked into cvs. ;( Can you 'cvs rm -f nss-softokn-3.12.3.99.3-stripped.tar.bz2; cvs commit' to get rid of it in checkouts at least? Thanks, kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Fri, 21 Aug 2009 22:34:24 +0200 Aurelien Bompard wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take > over: > ... > - perl-Jcode -- Perl extension interface for converting Japanese text I've taken that one. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On 08/23/2009 12:41 PM, Kevin Fenzi wrote: On Wed, 19 Aug 2009 23:49:39 + (UTC) Elio Maldonado wrote: Author: emaldonado Update of /cvs/extras/rpms/nss-softokn/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6734 Added Files: nss-softokn-3.12.3.99.3-stripped.tar.bz2 Log Message: Initial checkin Looks like somehow this tar.bz2 file got checked into cvs. ;( Can you 'cvs rm -f nss-softokn-3.12.3.99.3-stripped.tar.bz2; cvs commit' to get rid of it in checkouts at least? Thanks, kevin Kevin, This wasn't an oversight, nss-softokn-3.12.3.99.3-stripped.tar.bz2 needs to be there for the same reason we currently keep nss-3.12.3.99.3-stripped.tar.bz2 for NSS, because of Red Hat's ban of non-free sources. Elio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
On Sun, 23 Aug 2009, Björn Persson wrote: Debayan Banerjee wrote: 2009/8/24 Björn Persson That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? edos-rpmcheck http://www.edos-project.org/xwiki/bin/view/Main/debcheck_home Judging from the description on that page, that's not what I want. It says the program checks whether a package is installable. Yum can do that. I want to check whether a package drags in other packages unnecessarily. define "unnecessarily"? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Sunday 23 August 2009 05:43:27 pm Elio Maldonado wrote: > On 08/23/2009 12:41 PM, Kevin Fenzi wrote: > > Looks like somehow this tar.bz2 file got checked into cvs. ;( > > > > > > > > kevin > > Kevin, > > This wasn't an oversight, nss-softokn-3.12.3.99.3-stripped.tar.bz2 needs > to be there for the same reason we currently keep > nss-3.12.3.99.3-stripped.tar.bz2 for NSS, because of Red Hat's ban of > non-free sources. > > Elio These should still go in the lookaside cache and not CVS, unless there is some reason I'm not reading here. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On 08/23/2009 06:17 PM, Conrad Meyer wrote: On Sunday 23 August 2009 05:43:27 pm Elio Maldonado wrote: On 08/23/2009 12:41 PM, Kevin Fenzi wrote: Looks like somehow this tar.bz2 file got checked into cvs. ;( kevin Kevin, This wasn't an oversight, nss-softokn-3.12.3.99.3-stripped.tar.bz2 needs to be there for the same reason we currently keep nss-3.12.3.99.3-stripped.tar.bz2 for NSS, because of Red Hat's ban of non-free sources. Elio These should still go in the lookaside cache and not CVS, unless there is some reason I'm not reading here. Regards, Conrad, You are right. By reading at Makefile.common it seems that "make new-source nss-softokn-3.12.3.99.3-stripped.tar.bz2" would be the way to place them in the lookaside cache (after I do the cvs remove on them). Elio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Koji build failure with coreutils-7.5
I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented I _think_ this is due to contrib/hooks being a symlink. A nearly identical spec file worked when Tomas build git-1.6.4 in dist-f12-openssl just a few days ago, but that was with coreutils-7.4-6 in the buildroot. It works for me in mock. Perhaps the problem has something to do with the filesystem or mount options on the build system. Has anyone noticed similar problems? ¹ https://koji.fedoraproject.org/koji/getfile?taskID=1627434&name=build.log -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ I could never recommend the use of drugs or alcohol to anyone, but they've always worked for me. -- Hunter S. Thompson pgpFlQPZXtQAu.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Todd Zullinger wrote:
> I tried to build a git update into dist-f12-openssl earlier and had it
> die in %doc with an error from cp¹:
>
> cp: preserving times for
> `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks':
> Function not implemented
Hi Todd,
This is because that latest version of coreutils tries to preserve
permissions on symlinks when it thinks that is possible.
It determines whether to try by testing at configure time for the
existence of the utimensat function. If it can compile and link
against that function, then the resulting executable will call it
and report any failure. The trouble is when you configure on a system
with recent libraries and headers, yet *run* with a kernel
that is old enough as to lack the syscall.
Normally in coreutils, I try not to pollute the tools with run-time
work-around code that will be obsolete in a few years, but this
time, it appears to be required, due to the distance between koji's
build and run-time environments.
The solution is probably something like this:
>From 57d640722e04352a468cc595b0b94dbceaec4871 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 24 Aug 2009 08:21:47 +0200
Subject: [PATCH] cp: ignore obscure failure to preserve symlink time stamps,
when run on a kernel older than what was implied by headers and
libraries tested at configure time.
* src/copy.c (utimens_symlink): Ignore failure when errno == ENOSYS.
* NEWS (Bug fixes): Mention it.
Reported by Todd Zullinger and Kamil Dudka.
---
NEWS |6 ++
src/copy.c |8 +++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/NEWS b/NEWS
index 2c744b1..c125b31 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*-
outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** Bug fixes
+
+ cp, mv now ignore failure to preserve a symlink time stamp, when it is
+ due to their running on a kernel older than what was implied by headers
+ and libraries tested at configure time.
+
* Noteworthy changes in release 7.5 (2009-08-20) [stable]
diff --git a/src/copy.c b/src/copy.c
index bf9230b..8fc4b68 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -124,7 +124,13 @@ static inline int
utimens_symlink (char const *file, struct timespec const *timespec)
{
#if HAVE_UTIMENSAT
- return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ int err = utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ /* When configuring on a system with new headers and libraries, and
+ running on one with a kernel that is old enough to lack the syscall,
+ utimensat fails with ENOTSUP. Ignore that. */
+ if (err && errno == ENOSYS)
+err = 0;
+ return err;
#else
/* Don't set errno=ENOTSUP here as we don't want
to output an error message for this case. */
--
1.6.4.378.g88f2f
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
On Fri, Aug 21, 2009 at 03:07:19PM +0200, Kevin Kofler wrote: > Jindrich Novy wrote: > > Nope, it is intentional. It is needed to somehow distinguish the > > noarch and arch-dependent part. So package texlive-csplain contains > > the noarch bits and texlive-csplain.ARCH ships the binaries. > > Wouldn't texlive-csplain-libs or texlive-csplain-bin be more compliant to > our guidelines? The .ARCH postfix is actually derived from the TL metadata dependencies but indeed it doesn't look so good. The '-libs' is not appropriate as only binaries which go to /usr/bin are packaged. I will switch to the '-bin' postfix in the next build. Jindrich > > Kevin Kofler > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novyhttp://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
On Fri, Aug 21, 2009 at 04:21:35PM +0300, Jussi Lehtola wrote:
> On Thu, 2009-08-20 at 17:10 +0200, Jindrich Novy wrote:
> > On Thu, Aug 20, 2009 at 04:48:49PM +0300, Jussi Lehtola wrote:
> > > It seems your spec making program has some bugs, as some packages have
> > > names such as texlive-csplain.ARCH, this probably shouldn't be..?
> >
> > Nope, it is intentional. It is needed to somehow distinguish the
> > noarch and arch-dependent part. So package texlive-csplain contains
> > the noarch bits and texlive-csplain.ARCH ships the binaries.
>
> Wouldn't it be better to have texlive-csplain%{_isa} shipping the arch
> dependent bits and a texlive-csplain-common.noarch shipping the arch
> independent stuff? That would be more in line with other packages.
Hmm, this is even better idea. It was not originally possible in the
first designed TL packaging scheme (noarch and binary bits were
created from one src.rpm what prevented arch/noarch package named in
the same way) but now it is actually possible because binaries are built
separately.
Thanks,
Jindrich
> --
> Jussi Lehtola
> Fedora Project Contributor
> jussileht...@fedoraproject.org
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Jindrich Novyhttp://people.redhat.com/jnovy/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
