Orphaning packages
Hi, I intend to orphan the JRuby package and some of the dependencies I don't believe anything else uses. It's a piece of software upstream really doesn't intend to be packaged, and bumping to new versions is a constant struggle. Furthermore, I don't have anymore use for it. Here is the list of packages I'll orphan sometime in the next week or so: - bytelist - constantine - jcodings - jline - jna-posix - joni - jvyamlb If anyone wants any of them, let me know. (In case it's not obvious, they are all java packages.) Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning packages
I've orphaned the following packages in pkgdb: gquilt quilt jfsutils josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning packages
I'm orphaning a few packages I'm not using anymore, feel free to take over: - agave -- Generate a variety of colorschemes from a single starting color - apachetop -- A top-like display of Apache logs - basket -- Taking care of your ideas - blobby -- Volley-ball game - cryptopp -- Public domain C++ class library of cryptographic schemes - glest & glest-data -- 3D real time strategy game - gwenview -- Simple image viewer for KDE - mhonarc -- Perl mail-to-HTML converter - moodbar -- Identifies the "mood" of your music files - pdftohtml -- PDF to HTML converter - perl-Jcode -- Perl extension interface for converting Japanese text - perl-Unicode-Map -- Perl module for mapping charsets from and to utf16 unicode - perl-Unicode-Map8 -- Mapping table between 8-bit chars and Unicode for Perl - perl-Unicode-MapUTF8 -- Conversions to and from arbitrary character sets and UTF8 - perl-Unicode-String -- Perl modules to handle various Unicode issues - php-adodb -- Active Data Objects Data Base - qca -- Qt Cryptographic Architecture - qca-gnupg -- GnuPG plugin for the Qt Cryptographic Architecture v2 - qca-ossl -- OpenSSL plugin for the Qt Cryptographic Architecture v2 - qca-tls -- TLS plugin for the Qt Cryptographic Architecture - qca2 -- Qt Cryptographic Architecture - showimg -- Feature-rich image viewer for KDE - stow -- Manage the installation of software packages from source - taglib -- Audio Meta-Data Library - tetex-unicode -- Unicode support for LaTeX - tiger -- Security auditing on UNIX systems - ulogd -- The userspace logging daemon for netfilter - unrtf -- RTF to other formats converter - wv -- MSWord 6/7/8/9 binary file format to HTML converter - xbindkeys -- Binds keys or mouse buttons to shell commands under X. - xine-lib -- A multimedia engine - xlhtml -- Excel 95/97 and PowerPoint to HTML converter Thanks Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about." -- Albert Einstein -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
grabbed jfsutils co-maintaners welcome. On Thu, Aug 20, 2009 at 10:02 PM, Josh Boyer wrote: > I've orphaned the following packages in pkgdb: > > gquilt > quilt > jfsutils > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Picked up: 1. gquilt 2. quilt Co-maintainers are welcome. Thanks and Regards, Vivek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Whoops, I forgot a few more : - libifp -- A general-purpose library-driver for iRiver's iFP portable audio players - libkexif -- Allow Kipi plugins to extract EXIF information - libkipi -- Common plugin infrastructure for KDE image applications - libvisual & libvisual-plugins -- Abstraction library for audio visualisation plugins - python-dialog -- Python interface to the Unix dialog utility Thanks Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr "Everyone thinks of changing the world, but no one thinks of changing himself." -- Tolstoï -- 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 3:34 PM, Aurelien Bompard wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take over: > > - apachetop -- A top-like display of Apache log I'd like to take this one, I use it quite often. I'll be taking ownership in Fedora pkgdb here in a moment. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
You might not have gotten around to it, but it appears you only orphaned the devel branch of apachetop, wasn't sure if you want to continue to maintain the stable branches but no longer beyond that or completely orphan? -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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 wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take over: > > - taglib -- Audio Meta-Data Library I'll sign up for that one... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
> You might not have gotten around to it, but it appears you only > orphaned the devel branch of apachetop, wasn't sure if you want to > continue to maintain the stable branches but no longer beyond that or > completely orphan? I'm not sure what the right way is. If you want to maintain it, I'll be happy to orphan F10 and F11 too, I just thought that if no-one showed up I could handle maintenance til F12. I'll orphan them right now. Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Hi, I would like to take up pdftohtml. I could only see the devel branch in pkgdb without the Fedora 10 and 11 branch. I will be taking up ownership of the devel branch. Thanks and Regards, Vivek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Hi Aurélien, Picked up stow. If you want I can manage the Fedora-10 and 11 branches as well. In case you orphan them, I will pick them up as well. Thanks and Regards, Vivek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Grabbed tiger and agave as well. Vivek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Friday 21 August 2009 04:34:24 pm Aurelien Bompard wrote: > - ulogd -- The userspace logging daemon for netfilter I'm taking this one. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > - qca2 -- Qt Cryptographic Architecture I'll take this one - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqPE+IACgkQiPi+MRHG3qR5BACdF9QP6V0LSJPnDtLklv3FSUIG roUAoL8FVAQGEyZtbMQtPrjLLRsXpgM4 =Smit -END 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 Friday 21 August 2009 01:41:09 pm Aurelien Bompard wrote: > Whoops, I forgot a few more : > > - libifp -- A general-purpose library-driver for iRiver's iFP portable > audio players I have a package or two that uses this, I'll take it. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
* Aurelien Bompard [21/08/2009 22:59] : > > - perl-Unicode-Map -- Perl module for mapping charsets from and to utf16 > unicode > - perl-Unicode-Map8 -- Mapping table between 8-bit chars and Unicode for > Perl > - perl-Unicode-MapUTF8 -- Conversions to and from arbitrary character sets > and UTF8 > - perl-Unicode-String -- Perl modules to handle various Unicode issues I've taken ownership of these four. Emmanuel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Hi Aurelien, Aurelien Bompard wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take over: > - xbindkeys -- Binds keys or mouse buttons to shell commands under X. I took this one. If you like I can also take care of F11 and F10. So if you orphan them, I'll take ownership of these, too. Best regards, Christian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Aurelien Bompard wrote: > - gwenview -- Simple image viewer for KDE This one is obsolete, gwenview is part of kdegraphics these days. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Hi, On 21.8.2009 22:41, Aurelien Bompard wrote: - python-dialog -- Python interface to the Unix dialog utility I've taken this one, if you want I can also grab the F10/F11 branches. Regards, Milos -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
> I've taken this one, if you want I can also grab the F10/F11 branches. Sure, done. Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr One OS to hook them all One browser to find them One word processor to bring them all And in monopoly, bind them... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
> > - qca2 -- Qt Cryptographic Architecture > > I'll take this one I've added myself as a comaintainer for now if you don't mind, I have a package which depends on it, so I may have to rebuild it when you're offline. Thanks ! Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
> I took this one. If you like I can also take care of F11 and F10. So if > you orphan them, I'll take ownership of these, too. Done, thanks. Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr I was angered, for I had no shoes. Then I met a man who had no feet. -- Chinese proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
22.08.2009 03:03, Kevin Kofler wrote: Aurelien Bompard wrote: - gwenview -- Simple image viewer for KDE This one is obsolete, gwenview is part of kdegraphics these days. Kevin Kofler But may be separate package is more "right" solution?? Also not problem have both packages in Fedora or I mistaken? I want take this. Aurélien, if you like I can also take care of F11 and F10 branches. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Sat, 2009-08-22 at 23:36 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 22.08.2009 03:03, Kevin Kofler wrote: > > Aurelien Bompard wrote: > >> - gwenview -- Simple image viewer for KDE > > > > This one is obsolete, gwenview is part of kdegraphics these days. > > > > Kevin Kofler > > But may be separate package is more "right" solution?? Also not problem > have both packages in Fedora or I mistaken? > That's a matter of aesthetics, and there's no real right answer: Debian, Ubuntu and Mandriva tend to split packages into multiple subs; Fedora tend to keep as close as a one-to-one correspondence between source RPM and binary RPM (save splitting off -devel, -doc, and if a package contains libraries that are usable elsewhere, -libs). openSUSE is in-between. The point, though, is that a package maintainer is in charge of the entire source package (SRPM). So you can't just take over gwenview without taking over kdegraphics. Now, if there are any actively-maintained branches (perhaps EPEL 4 or EPEL 5) that still has a standalone gwenview, and you feel like maintaining it for that branch, that's a different question. Regards, -- Michel Salim 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
On Fri, Aug 21, 2009 at 22:34:24 +0200, Aurelien Bompard wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take over: > > - glest & glest-data -- 3D real time strategy game I'll try taking these. Glest is on the games spin and one way or another I'll need to deal with Glest (as it is currently broken in rawhide). I might find myself over my head in which case I'll need to reophan them. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
22.08.2009 23:44, Michel Salim wrote: That's a matter of aesthetics, and there's no real right answer: Debian, Ubuntu and Mandriva tend to split packages into multiple subs; Fedora tend to keep as close as a one-to-one correspondence between source RPM and binary RPM (save splitting off -devel, -doc, and if a package contains libraries that are usable elsewhere, -libs). openSUSE is in-between. The point, though, is that a package maintainer is in charge of the entire source package (SRPM). So you can't just take over gwenview without taking over kdegraphics. 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. Now, if there are any actively-maintained branches (perhaps EPEL 4 or EPEL 5) that still has a standalone gwenview, and you feel like maintaining it for that branch, that's a different question. No, maintain it *only* for EPEL is not interesting for me. Regards, Pavel Alexeev aka Pahan-Hubbitus -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 22.08.2009 03:03, Kevin Kofler wrote: >> Aurelien Bompard wrote: >>> - gwenview -- Simple image viewer for KDE >> >> This one is obsolete, gwenview is part of kdegraphics these days. >> >> Kevin Kofler > > But may be separate package is more "right" solution?? Also not problem > have both packages in Fedora or I mistaken? > > I want take this. Aurélien, if you like I can also take care of F11 and > F10 branches. You cannot take gwenview, kdegraphics has Obsoletes: for it and it will stay that way. The gwenview package is retired and will stay so. If gwenview is to be split, it has to be built as a subpackage of kdegraphics, but I'm opposed to that too. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
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. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Sat, Aug 22, 2009 at 15:25:32 -0500, Bruno Wolff III wrote: > On Fri, Aug 21, 2009 at 22:34:24 +0200, > Aurelien Bompard wrote: > > I'm orphaning a few packages I'm not using anymore, feel free to take over: > > > > - glest & glest-data -- 3D real time strategy game > > I'll try taking these. Glest is on the games spin and one way or another I'll > need to deal with Glest (as it is currently broken in rawhide). I might find > myself over my head in which case I'll need to reophan them. I have a new rawhide build out now to handle the openal-soft change and finish the update that was partially setup when I took over. The build isn't really really tested yet, as my rawhide machines don't have 3d and I am in the process of making a livedvd to let me test on some other machines. I took over the outstanding bugs. -- 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: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
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
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: 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: Orphaning packages
I'm using basket a lot. I'll take it. 2009/8/23 Paul Howarth : > 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 > -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com - "In a world without walls and fences, who needs windows and gates?!" -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
2009/7/14 Conrad Meyer : > I intend to orphan the JRuby package and some of the dependencies I don't > believe anything else uses. It's a piece of software upstream really doesn't > intend to be packaged, and bumping to new versions is a constant struggle. > Furthermore, I don't have anymore use for it. Here is the list of packages > I'll orphan sometime in the next week or so: > > - bytelist > - constantine > - jcodings > - jline > - jna-posix > - joni > - jvyamlb Hello! I'm sorry to come in three and a half months after the fact (does that mean that they'll all have to be re-reviewed? :( ), but jruby is a dependency of some Java stuff that I'm currently working on so I'd like to take over these packages. MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Friday 30 October 2009 09:01:39 am Mary Ellen Foster wrote: > 2009/7/14 Conrad Meyer : > > I intend to orphan the JRuby package and some of the dependencies I don't > > believe anything else uses. It's a piece of software upstream really > > doesn't intend to be packaged, and bumping to new versions is a constant > > struggle. Furthermore, I don't have anymore use for it. Here is the list > > of packages I'll orphan sometime in the next week or so: > > > > - bytelist > > - constantine > > - jcodings > > - jline > > - jna-posix > > - joni > > - jvyamlb > > Hello! I'm sorry to come in three and a half months after the fact > (does that mean that they'll all have to be re-reviewed? :( ), but > jruby is a dependency of some Java stuff that I'm currently working on > so I'd like to take over these packages. > > MEF They're all orphaned in pkgdb. I'm not sure what process you'll need to go through to take them over (at the least, you'll probably have to talk to rel- eng to get the dead.package's removed). Regards, -- Conrad Meyer -- 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
Orphaning Packages: audacious and dependencies
Hi. As I don't have the time to maintain audacious any more I'm orphaning the following packages: audacious audacious-plugins libmowgli mcs The last two are dependencies which, as far as I am aware, are used by nothing else. There is an accompanying package in the Voldemort Repository which contains the less free and more useful media codecs. That would be up for grabs, too, preferrably by the same person. There are several bugs open against the package, most of which will probably be fixed by the current upstream release. -- 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: 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
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: gwenview - Re: Orphaning packages
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. 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. It's not like those dependencies bite. ;-) HDD space is cheap. I don't find it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- workspace drags in Akonadi (and thus MySQL, which is a hard requirement of Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter split out subpackages to break both the links in the offending chain: in upcoming updates, ktorrent no longer requires kdebase-workspace, only the kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a step in the right direction (as they mean the default installations of both ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather have "unneccessary" dependencies than useful features not installed by default. Kevin Kofler -- 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/25/2009 03:37 AM, Kevin Kofler wrote: > 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. 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. > > It's not like those dependencies bite. ;-) HDD space is cheap. Unneeded dependencies do bite. I have a net connection with a bandwidth cap at home. Packages that pulls in random silly dependencies are a big pain. I have sit through updates of them as well. There more often those packages get updated, the bigger the pain is. yum-presto is a life saver but the dependency bloat is not a ignorable problem at all. 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
Kevin Kofler wrote: > It's not like those dependencies bite. ;-) HDD space is cheap. I don't find > it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- > workspace drags in Akonadi (and thus MySQL, which is a hard requirement of > Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter > split out subpackages to break both the links in the offending chain: in > upcoming updates, ktorrent no longer requires kdebase-workspace, only the > kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer > requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a > step in the right direction (as they mean the default installations of both > ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather > have "unneccessary" dependencies than useful features not installed by > default. It would be nice if things could be set up such that kdebase-workspace-akonadi gets installed by default if both kdebase-workspace and akonadi are installed, but not if only one of them is installed. If RPM had a "Suggests" tag it would at least be possible to inform users that there is a related package available that they can install if they want to. 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: gwenview - Re: Orphaning packages
On Tue, 25 Aug 2009 00:07:48 +0200, Kevin wrote: > 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. 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. > > It's not like those dependencies bite. ;-) HDD space is cheap. I don't find > it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- > workspace drags in Akonadi (and thus MySQL, which is a hard requirement of > Akonadi) The problem with kdebase-workspace (and kdm) is not disk space. Installing the kdebase-workspace package enables KDE X sessions for users. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt wrote: > On Tue, 25 Aug 2009 00:07:48 +0200, Kevin wrote: > >> 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. 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. >> >> It's not like those dependencies bite. ;-) HDD space is cheap. I don't find >> it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- >> workspace drags in Akonadi (and thus MySQL, which is a hard requirement of >> Akonadi) > > The problem with kdebase-workspace (and kdm) is not disk space. > Installing the kdebase-workspace package enables KDE X sessions for users. > Oh dear, run for your lives. Last I used GDM, I didn't know where to change the session type (I was looking). I haven't used it in over a year since it's one of the first things to get replaced on my systems. Looking at a screenshot with solar[1] I see a restart, a shutdown, a power, and an accessibility button. Nothing about sessions. Certainly not visible at least. So I fail to see why this would be any issue at all. What am I missing? - --Ben [1]https://fedoraproject.org/w/uploads/9/94/Tours_Fedora10_018_L ogin_Screen.png -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqT7sMACgkQiPi+MRHG3qTSOQCeNSWl+dRfng5haLmm6LUvBxrf dsgAn1E1IIk29XPgZpFhA8ijm2Wdx6hE =O4yW -END PGP 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
Dne Tue, 25 Aug 2009 10:01:39 -0400 Ben Boeckel napsal(a): > Oh dear, run for your lives. Last I used GDM, I didn't know > where to change the session type (I was looking). I haven't used > it in over a year since it's one of the first things to get > replaced on my systems. Looking at a screenshot with solar[1] I > see a restart, a shutdown, a power, and an accessibility button. > Nothing about sessions. Certainly not visible at least. So I > fail to see why this would be any issue at all. What am I > missing? Session selection appears in the bottom toolbar after you select the user. Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Kevin Kofler wrote: 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. 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. It's not like those dependencies bite. ;-) HDD space is cheap. Not on netbooks it isn't! I'd have to buy a new machine to get bigger than the 4 G ssd I currently have. There's a reason I nuked the entire printing support chain, even though it deprived me (for no good reason IMO) of kcalc. I don't find it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- workspace drags in Akonadi (and thus MySQL, which is a hard requirement of Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter split out subpackages to break both the links in the offending chain: in upcoming updates, ktorrent no longer requires kdebase-workspace, only the kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a step in the right direction (as they mean the default installations of both ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather have "unneccessary" dependencies than useful features not installed by default. I have to disagree with part of this. I don't disagree with kdebase-workspace having a hard dependency on akonadi, but I /am/ leery of anything that doesn't enhance the KDE desktop having a hard dependency on kdebase-workspace. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- $ kill bill kill: can't find process "bill" -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Björn Persson wrote: > It would be nice if things could be set up such that > kdebase-workspace-akonadi gets installed by default if both > kdebase-workspace and akonadi are installed, but not if only one of them > is installed. Being able to have a pair of packages require something is a feature I've wanted for some time as well, unfortunately there's no way to implement this in an RPM package at RPM's current stage. Kevin Kofler -- 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/26/2009 06:13 PM, Kevin Kofler wrote: > Björn Persson wrote: >> It would be nice if things could be set up such that >> kdebase-workspace-akonadi gets installed by default if both >> kdebase-workspace and akonadi are installed, but not if only one of them >> is installed. > > Being able to have a pair of packages require something is a feature I've > wanted for some time as well, unfortunately there's no way to implement this > in an RPM package at RPM's current stage. Have you file a RFE at http://rpm.org? 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
Michael Schwendt wrote: > The problem with kdebase-workspace (and kdm) is not disk space. > Installing the kdebase-workspace package enables KDE X sessions for users. Well, KDM isn't what adds the KDE session type, kdebase-workspace is. KDM can only be enabled by the admin. That said, kdebase-workspace will also not require kdm in F12. We just had to keep this dependency when we split out kdm in F10 and F11 for upgrade path reasons. I'd argue enabling KDE sessions for users on a multi-user system is a good thing. ;-) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Matthew Woehlke wrote: > Not on netbooks it isn't! I'd have to buy a new machine to get bigger > than the 4 G ssd I currently have. Doesn't that thing even have a cardreader slot or something like that? Then IMHO you made a really bad buying decision... But then again I just hate netbooks altogether, as they reintroduced 32-bit-only machines at a time where computing had finally just about completed its migration to 64-bit- capable CPUs throughout and as things like screen "resolution" (pixel count, really), RAM size, storage size etc. are reminiscent of computers from times long past. And when it comes to portability, they can't compete with my TI-89. ;-) Kevin Kofler -- 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 Wed, 26 Aug 2009 14:46:17 +0200, Kevin wrote: > Michael Schwendt wrote: > > The problem with kdebase-workspace (and kdm) is not disk space. > > Installing the kdebase-workspace package enables KDE X sessions for users. > > Well, KDM isn't what adds the KDE session type, kdebase-workspace is. "Installing the kdebase-workspace package enables KDE X sessions for users" is what I wrote. Quoted above. -- 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 Wed, 2009-08-26 at 14:53 +0200, Kevin Kofler wrote: > Matthew Woehlke wrote: > > Not on netbooks it isn't! I'd have to buy a new machine to get bigger > > than the 4 G ssd I currently have. > > Doesn't that thing even have a cardreader slot or something like that? Then > IMHO you made a really bad buying decision... But then again I just hate > netbooks altogether, as they reintroduced 32-bit-only machines at a time > where computing had finally just about completed its migration to 64-bit- > capable CPUs throughout and as things like screen "resolution" (pixel count, > really), RAM size, storage size etc. are reminiscent of computers from times > long past. And when it comes to portability, they can't compete with my > TI-89. ;-) There are other situations in which disk space is not free. I run multiple virtual machines on a box which only has an 80GB hard disk, so I only give each machine 5-10GB of disk space. Sure, I could go out and buy a 500GB hard disk for it for 'only' $60, but that's still $60 I'd rather keep in my pocket and an hour of drive installing and imaging I'd rather avoid. And there's no legitimate reason for me to have to do that when there's no reason a basic operating system installation should be anywhere north of 1GB. Frankly, developers with the attitude you're showing here are the reason we all have to go out and buy new hardware every three years, and it's a pain in the ass. Just because 'most people' have more than minimal resources doesn't constitute a license to stop caring about good practice. My netbook has a 1.6GHz CPU, 120GB of hard disk space, and 2GB of RAM; if you consider any of that to be only appropriate for computers from 'times long past' and not worth supporting, well, geesh. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Kevin Kofler wrote: Matthew Woehlke wrote: Not on netbooks it isn't! I'd have to buy a new machine to get bigger than the 4 G ssd I currently have. Doesn't that thing even have a cardreader slot or something like that? Yes, but it's not usable for system storage. The one and only time I tried to arrange for it to mount on boot (which would, I think, be needed to put anything yum-managed there in a way that isn't an insane hack), I had quite the time getting the machine to boot again. Granted that was partly because inexperience made it fun figuring out how to edit fstab when booted from a rescue disk (which fortunately I had handy!!), but... Then IMHO you made a really bad buying decision... Nah, I *love* my Asus. The small ssd isn't really a *problem*, it just means I have to adjust my expectations that I won't be installing everything plus the kitchen sink, software-wise. (Plus the 8G models weren't out when I bought it.) Besides, even if it /was/ a bad decision, it only cost <$325 (including tax) ;-). But then again I just hate netbooks altogether [...] as things like screen "resolution" (pixel count, really), The screen size issue was I think inevitable, as people in general are turning less to "workstation computers" and more to mobile devices... not just netbooks, but tablets and even phones. I don't buy the theory that "workstation computers" are going to go away (after all, they said that about the mainframe), but I wouldn't be surprised if they become much more "niche", to the point where few people have one in their homes any more. (I heard somewhere this is already happening in Asia.) Like it or not, the vicious hardware upgrade cycle has been broken, and the days of being able to count on people eventually having bigger and better hardware are gone. Or, put differently, "what Adam said". Sorry, but I agree with him here; "[hardware] is cheap" is not a good attitude. RAM size, There is something wrong with having 1 G of RAM? If so, I haven't yet experienced it. (And that number is only going to go up...) storage size etc. are reminiscent of computers from times long past. And when it comes to portability, they can't compete with my TI-89. ;-) ...but does it run Fedora? ;-) I can see a TI-89 *might* be able to keep up with kwrite from a note-taking standpoint, but no way it could replace my Asus for how I use it. Having a *full computer* that is the size of a (hardcover) book and weights <1kg is wonderful for me. I actually bought the thing just before taking a business trip. I took my regular (company) laptop to the office the first day. After that, I just brought my Asus. It did everything I needed on that trip, and is s much easier to carry around (and it's small enough to comfortably use in restaurants). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Signal lost -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Woehlke wrote: > Kevin Kofler wrote: >> RAM size, > > There is something wrong with having 1 G of RAM? If so, I haven't yet > experienced it. (And that number is only going to go up...) I actually discovered recently that the desktop at home has a bad RAM stick and it's running KDE 4.2/4.3 fine from 512MB, so 1GB is still in excess of baseline use. My setup would exhaust that (though 1GB would still work until X eats it all), but for the family it works fine. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqWslAACgkQiPi+MRHG3qQyxgCfX5j48cche8XJtp7Ot6821AU+ IWkAoLcrkwYCywJQLeOAW7fApmxtC+Tf =JFYP -END PGP 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
25.08.2009 02:07, Kevin Kofler wrote: 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. 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. It's not like those dependencies bite. ;-) HDD space is cheap. This is incorrect question setup. HDD space not always cheap. This may be very expensive, f.e. on embedded systems, on USB-stick, Live-CD images... Additionally it additional bandwidth on updates, which cost often is more significant. But at end, main point for me what it is "incorrect". This is very monolithic, small user chose to manipulation, big and, as showed before, often produce additional errors (dependency and others). So, I do not call fanatic split all what we can find, but if we can reasonably (ok, I do not want question and define it as at least anything see in that sense) provide program separately - why you argue with that? At and, we see there discussion about big packages, and some arguments why it is not problem. But what main arguments to do NOT split some thus packages on few? -- 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 Thursday 27 August 2009 19:54:19 Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 25.08.2009 02:07, Kevin Kofler wrote: > > 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. 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. > > > > It's not like those dependencies bite. ;-) HDD space is cheap. > > This is incorrect question setup. HDD space not always cheap. This may > be very expensive, f.e. on embedded systems, on USB-stick, Live-CD > images... Additionally it additional bandwidth on updates, which cost > often is more significant. But at end, main point for me what it is > "incorrect". This is very monolithic, small user chose to manipulation, > big and, as showed before, often produce additional errors (dependency > and others). > > So, I do not call fanatic split all what we can find, but if we can > reasonably (ok, I do not want question and define it as at least > anything see in that sense) provide program separately - why you argue > with that? Hi Pavel, as Kevin has already pointed out - we already did some splits, we discuss it on our meeting, counting pros and cons. If you find something to be split, feel free to report the bug, join our meeting, defend it. With good arguments we can do it. But sometimes even one good reason is not enough to do it and there could be another reason why we shouldn't do it. Jaroslav > At and, we see there discussion about big packages, and some arguments > why it is not problem. But what main arguments to do NOT split some thus > packages on few? -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Wed, Jun 3, 2009 at 1:46 PM, Ralf Ertzinger wrote: > Hi. > > As I don't have the time to maintain audacious any more I'm orphaning the > following packages: > > audacious > audacious-plugins > libmowgli > mcs > > The last two are dependencies which, as far as I am aware, are used by > nothing else. > > There is an accompanying package in the Voldemort Repository which contains > the less free and more useful media codecs. That would be up for grabs, > too, preferrably by the same person. > > There are several bugs open against the package, most of which will > probably be fixed by the current upstream release. > The new binaries are called audiocious2 and audtool2, and they seem to be working just fine. In theory, it would be possible to keep the old audacious and the new one. Another possibility is just to rename some files to match the previous version. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Wed, 3 Jun 2009 18:31:27 -0300, Paulo wrote: > > Hi. > > > > As I don't have the time to maintain audacious any more I'm orphaning the > > following packages: > > > > audacious > > audacious-plugins > > libmowgli > > mcs > > > > The last two are dependencies which, as far as I am aware, are used by > > nothing else. > > > > There is an accompanying package in the Voldemort Repository which contains > > the less free and more useful media codecs. That would be up for grabs, > > too, preferrably by the same person. > > > > There are several bugs open against the package, most of which will > > probably be fixed by the current upstream release. > > I have some limited interest in Audacious only, because it's one of the music players I use from time to time. I would be willing to examine the current state of the Fedora packages, the currently open bugs, and take a look at the new stable 2.0 series, too. The 1.5 series has been declared legacy. However, I don't want to take over the packages in the external repository. As such, anybody else who wants all of the packages would take precedence. > The new binaries are called audiocious2 and audtool2, and they seem to be > working just fine. > > In theory, it would be possible to keep the old audacious and the new one. > Another possibility is just to rename some files to match the previous > version. That would deviate from upstream and break any scripts users may use to control a running instance of Audacious2. If the two releases can coexist, I would say we don't make them conflict with eachother. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Wed, 3 Jun 2009 18:46:27 +0200, Ralf wrote: > Hi. > > As I don't have the time to maintain audacious any more I'm orphaning the > following packages: > > audacious > audacious-plugins > libmowgli > mcs > > The last two are dependencies which, as far as I am aware, are used by > nothing else. "conky" and "kadu-audacious_mediaplayer" depend on libmowgli and libmcs. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Thu, Jun 4, 2009 at 9:48 AM, Michael Schwendt wrote: > On Wed, 3 Jun 2009 18:46:27 +0200, Ralf wrote: > > > Hi. > > > > As I don't have the time to maintain audacious any more I'm orphaning the > > following packages: > > > > audacious > > audacious-plugins > > libmowgli > > mcs > > > > The last two are dependencies which, as far as I am aware, are used by > > nothing else. > > "conky" and "kadu-audacious_mediaplayer" depend on libmowgli and libmcs. > > I have the .src.rprm for audacious2, here: http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious.html http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious-plugins.html But it builds everything, and I just created an audacious-libs2, so I do not need to recompile the applications I have, using libaudclient.so.1, for now. I also do not want to maintain it, because it needs external packages to provide some codecs not allowed in Fedora. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Thu, 4 Jun 2009 10:37:51 -0300, Paulo wrote: > I have the .src.rprm for audacious2, here: > > http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious.html > > http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious-plugins.html Note that Audacious 2 has changed to GPLv3 and that the old Fedora packages contain a lot of cruft. I've cleaned up the 1.5.1 packages in fedora cvs pretty much, but more cleanup is necessary for 2.0.1. See below. > But it builds everything, and I just created an audacious-libs2, > so I do not need to recompile the applications I have, using > libaudclient.so.1, for now. > > I also do not want to maintain it, because it needs external packages > to provide some codecs not allowed in Fedora. Meanwhile I'm almost done with preparing packages for Audacious 2. Actually I have it running here already, but whereas I'm 99% done with the -plugins package I still need to examine/rediff the patches in the main package. It's not something I've done in one tiresome block as I've almost started from scratch, only keeping fragments of the cleaned-up 1.5.1 packages. Will publish them eventually prior to working on including them in Fedora. Some random observations: There are API changes, which break external plugins, GVfs e.g. and header locations. At least audacious-plugin-fc needs an updated implementation. There are patches that still need to be applied upstream. There is stuff in the packages which I consider questionable. E.g. mp3/mpeg/wma related MIME types get removed from the main desktop file, but also WAV and Ogg, then a hidden desktop file is added in the -plugins package which readds the removed types although the needed plugins are not available in the Fedora packages due to legal reasons. The 3rd party packages could add such hidden desktop files. And actually the main player is useless without the plugins package, so why add a second hidden desktop file at all? Audacious 1 and Audacious 2 cannot coexist, since only the executables have different names. I don't think it is worthwhile to create symlinks for the old executable names. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.1.fc10.src.rpm The included tarball is stripped for Fedora, to remove problematic files. Builds have been tested on F10 only. F11 is next. What will be needed is a maintainer for the -freeworld plugin packages. It shall be easy to modify above -plugins package and put back the original tarball, the required BR and configure options, and a desktop file for the MIME types. The API changes must be checked with every package that depends on audacious-devel. > Meanwhile I'm almost done with preparing packages for Audacious 2. > Actually I have it running here already, but whereas I'm 99% done with > the -plugins package I still need to examine/rediff the patches in the > main package. It's not something I've done in one tiresome block as I've > almost started from scratch, only keeping fragments of the cleaned-up > 1.5.1 packages. Will publish them eventually prior to working on including > them in Fedora. > > Some random observations: > > There are API changes, which break external plugins, GVfs e.g. and header > locations. At least audacious-plugin-fc needs an updated implementation. > > There are patches that still need to be applied upstream. > > There is stuff in the packages which I consider questionable. > E.g. mp3/mpeg/wma related MIME types get removed from the main desktop > file, but also WAV and Ogg, then a hidden desktop file is added in the > -plugins package which readds the removed types although the needed > plugins are not available in the Fedora packages due to legal reasons. > The 3rd party packages could add such hidden desktop files. And actually > the main player is useless without the plugins package, so why add a > second hidden desktop file at all? > > Audacious 1 and Audacious 2 cannot coexist, since only the executables > have different names. I don't think it is worthwhile to create symlinks > for the old executable names. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Sun, Jun 7, 2009 at 6:04 AM, Michael Schwendt wrote:
> http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm
> http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.1.fc10.src.rpm
>
> The included tarball is stripped for Fedora, to remove problematic
> files. Builds have been tested on F10 only. F11 is next.
>
> What will be needed is a maintainer for the -freeworld plugin packages.
> It shall be easy to modify above -plugins package and put back the
> original tarball, the required BR and configure options, and a
> desktop file for the MIME types.
>
> The API changes must be checked with every package that depends on
> audacious-devel.
Nice work.
I would create a symbolic link audacious -> audacious2, so the previous
bin can still be called.
Something as
pushd %{buildroot}%{_bindir}
ln -s %{name}2 %{name}
popd
before the clean section.
I would also call the libs package libs2, so the previous lib package do not
need
to be removed during the upgrade.
>
>
> > Meanwhile I'm almost done with preparing packages for Audacious 2.
> > Actually I have it running here already, but whereas I'm 99% done with
> > the -plugins package I still need to examine/rediff the patches in the
> > main package. It's not something I've done in one tiresome block as I've
> > almost started from scratch, only keeping fragments of the cleaned-up
> > 1.5.1 packages. Will publish them eventually prior to working on
> including
> > them in Fedora.
> >
> > Some random observations:
> >
> > There are API changes, which break external plugins, GVfs e.g. and header
> > locations. At least audacious-plugin-fc needs an updated implementation.
> >
> > There are patches that still need to be applied upstream.
> >
> > There is stuff in the packages which I consider questionable.
> > E.g. mp3/mpeg/wma related MIME types get removed from the main desktop
> > file, but also WAV and Ogg, then a hidden desktop file is added in the
> > -plugins package which readds the removed types although the needed
> > plugins are not available in the Fedora packages due to legal reasons.
> > The 3rd party packages could add such hidden desktop files. And actually
> > the main player is useless without the plugins package, so why add a
> > second hidden desktop file at all?
> >
> > Audacious 1 and Audacious 2 cannot coexist, since only the executables
> > have different names. I don't think it is worthwhile to create symlinks
> > for the old executable names.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
--
Paulo Roma Cavalcanti
LCG - UFRJ
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Sun, 7 Jun 2009 12:09:24 -0300, Paulo wrote: > I would create a symbolic link audacious -> audacious2, so the previous > bin can still be called. AFAIK, this is not done in Debian/Ubuntu either. The .desktop file has been renamed, too, and additionally the Fedora "--vendor fedora" has had to be dropped (or else one would need to keep such patches, which deviate from upstream, forever). The manual pages have been renamed to "audtool2" and "audacious2". > I would also call the libs package libs2, so the previous lib package do not > need to be removed during the upgrade. That would create an orphan, an obsolete audacious-libs package which is not tied to any current src.rpm package, and which could cause problems in the future (such as unresolvable deps). http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.3.fc10.src.rpm (updated) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On 06/11/2009 06:28 PM, Michael Schwendt wrote: On Sun, 7 Jun 2009 12:09:24 -0300, Paulo wrote: I would create a symbolic link audacious -> audacious2, so the previous bin can still be called. AFAIK, this is not done in Debian/Ubuntu either. The .desktop file has been renamed, too, and additionally the Fedora "--vendor fedora" has had to be dropped (or else one would need to keep such patches, which deviate from upstream, forever). The manual pages have been renamed to "audtool2" and "audacious2". I agree, lets just stick with what upstream does and drop the old binary names completely. I would also call the libs package libs2, so the previous lib package do not need to be removed during the upgrade. That would create an orphan, an obsolete audacious-libs package which is not tied to any current src.rpm package, and which could cause problems in the future (such as unresolvable deps). +1 Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On 06/04/2009 12:29 PM, Michael Schwendt wrote: On Wed, 3 Jun 2009 18:31:27 -0300, Paulo wrote: Hi. As I don't have the time to maintain audacious any more I'm orphaning the following packages: audacious audacious-plugins libmowgli mcs The last two are dependencies which, as far as I am aware, are used by nothing else. There is an accompanying package in the Voldemort Repository which contains the less free and more useful media codecs. That would be up for grabs, too, preferrably by the same person. There are several bugs open against the package, most of which will probably be fixed by the current upstream release. I have some limited interest in Audacious only, because it's one of the music players I use from time to time. I would be willing to examine the current state of the Fedora packages, the currently open bugs, and take a look at the new stable 2.0 series, too. The 1.5 series has been declared legacy. Cool, As an audacious user I would be happy to co-maintain! Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Thu, Jun 11, 2009 at 1:28 PM, Michael Schwendt wrote: > On Sun, 7 Jun 2009 12:09:24 -0300, Paulo wrote: > > > I would create a symbolic link audacious -> audacious2, so the previous > > bin can still be called. > > AFAIK, this is not done in Debian/Ubuntu either. The .desktop file has > been renamed, too, and additionally the Fedora "--vendor fedora" has had > to be dropped (or else one would need to keep such patches, which deviate > from upstream, forever). The manual pages have been renamed to "audtool2" > and "audacious2". > > > I would also call the libs package libs2, so the previous lib package do > not > > need to be removed during the upgrade. > > That would create an orphan, an obsolete audacious-libs package which > is not tied to any current src.rpm package, and which could cause > problems in the future (such as unresolvable deps). > > http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm > http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.3.fc10.src.rpm(updated) > > In fact, I have one: http://atrpms.net/name/mp3splt-gtk/ However, it can always be rebuilt with the new lib, which will increase the soname version. Furthermore, the source is still referencing audacious (not audacious2), and will have to be patched. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning Packages: audacious and dependencies
On Thu, 11 Jun 2009 16:21:40 -0300, Paulo wrote: > > > I would also call the libs package libs2, so the previous lib package do > > not > > > need to be removed during the upgrade. > > > > That would create an orphan, an obsolete audacious-libs package which > > is not tied to any current src.rpm package, and which could cause > > problems in the future (such as unresolvable deps). > > > > http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm > > http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.3.fc10.src.rpm(updated) > > > > > In fact, I have one: > > http://atrpms.net/name/mp3splt-gtk/ > > However, it can always be rebuilt with the new lib, which will increase the > soname > version. Furthermore, the source is still referencing audacious (not > audacious2), > and will have to be patched. What I mean with "not tied to any current src.rpm package" is that no package in the Fedora package collection would remove or update the old audacious-libs-1.5.1 orphan that may be found on some users' installations. Knowlingly leaving obsolete packages on users' machines is frowned upon, especially if the rest of Audacious is upgraded to v2. For some time the old audacious-libs-1.5.1 will still work (lacking a corresponding audacious-devel-1.5.1 package, however, unless you would want to rename the new one to audacious2-devel or something matching audacious-libs2), but as soon as one of its dependencies will change significantly (see rpm -qR audacious-libs), it would need a rebuild to avoid dependency breakage. Such a rebuild is not possible if no Fedora src.rpm package is responsible for producing audacious-libs-1.5.1 anymore. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
On Tue, 25 Aug 2009 10:01:39 -0400, Ben wrote: > Oh dear, run for your lives. Last I used GDM, I didn't know > where to change the session type (I was looking). I haven't used > it in over a year since it's one of the first things to get > replaced on my systems. Looking at a screenshot with solar[1] I > see a restart, a shutdown, a power, and an accessibility button. > Nothing about sessions. Certainly not visible at least. So I > fail to see why this would be any issue at all. What am I > missing? Users, who discover what software is being offered, who know how to switch the session type, and who will notice that the installed KDE is incomplete. As if the admin had messed it up. Customising the personal desktop and choosing between either GNOME or KDE is one of the first things many users do. They even go as far as replacing the window manager, if alternative wm are available. On your fully private machine(s) it may not be an issue at all, I agree. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
On Thu, 27 Aug 2009 12:14:43 -0400, Ben wrote: [KDE X session file] > So your issue is that kdebase-workspace puts it there, but it's > not complete, so it shouldn't? Well, in case installing ktorrent shall drag in the packages for a complete KDE desktop, the current dependencies are incomplete. Some packages are missing. Alternatively, ktorrent shall drag in only what's really needed. Would be tons better for the "Install KDE app on GNOME desktop" scenario. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt wrote: > On Tue, 25 Aug 2009 10:01:39 -0400, Ben wrote: > >> Oh dear, run for your lives. Last I used GDM, I didn't know >> where to change the session type (I was looking). I haven't used >> it in over a year since it's one of the first things to get >> replaced on my systems. Looking at a screenshot with solar[1] I >> see a restart, a shutdown, a power, and an accessibility button. >> Nothing about sessions. Certainly not visible at least. So I >> fail to see why this would be any issue at all. What am I >> missing? > > Users, who discover what software is being offered, who know how to switch > the session type, and who will notice that the installed KDE is incomplete. > As if the admin had messed it up. Customising the personal desktop and > choosing between either GNOME or KDE is one of the first things many users > do. They even go as far as replacing the window manager, if alternative wm > are available. So your issue is that kdebase-workspace puts it there, but it's not complete, so it shouldn't? Do you have a better package in which to add the session type? As for WMs, Compiz and Metacity are missing things such as rules for specific windows (can lock size or position, hide it from the taskbar, shortcut to set focus, etc). For better or worse, KWin is really indispensable for my setup. Even if I used some other DE, kwin would probably end up being used. > On your fully private machine(s) it may not be an issue at all, I agree. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqWsPMACgkQiPi+MRHG3qRiXgCfZ13vNOrwVhMcYPV8pJr0xF0F jvMAoKDnrCceSFzLevzYDtuR5SAyJOGM =GVie -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
On Thursday 27 August 2009 18:34:38 Michael Schwendt wrote: > On Thu, 27 Aug 2009 12:14:43 -0400, Ben wrote: > > [KDE X session file] > > > So your issue is that kdebase-workspace puts it there, but it's > > not complete, so it shouldn't? > > Well, in case installing ktorrent shall drag in the packages > for a complete KDE desktop, the current dependencies are incomplete. > Some packages are missing. > > Alternatively, ktorrent shall drag in only what's really needed. > Would be tons better for the "Install KDE app on GNOME desktop" > scenario. That's what we are fighting on the other side of barricade - sometimes Gnome stuff brings so many strange dependencies. There's only one solution - report bug, defend it with arguments, it's not only about splitting but provides, etc... But sometimes status quo wins ;-) Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
