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

On Friday 21 August 2009 01:41:09 pm Aurelien Bompard wrote: I have a package or two that uses this, I'll take it. Regards, -- Conrad Meyer <cemeyer(a)u.washington.edu&gt;

Sure, done. Aurélien -- http://aurelien.bompard.org ~~~~ Jabber : abompard(a)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...

On Fri, 21 Aug 2009 22:34:24 +0200, Aurelien wrote: I'll sign up for that one...

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

On Friday 21 August 2009 04:34:24 pm Aurelien Bompard wrote: I'm taking this one. Thanks, -Steve

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 : abompard(a)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.

Hi Aurelien, Aurelien Bompard wrote: 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

Aurelien Bompard wrote: This one is obsolete, gwenview is part of kdegraphics these days. Kevin Kofler

On Sat, 2009-08-22 at 23:36 +0400, Pavel Alexeev (aka Pahan-Hubbitus) 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. 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 <Michael.Silvanus(a)gmail.com&gt;

Pavel Alexeev (aka Pahan-Hubbitus) wrote: 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

On Sun, 23 Aug 2009 14:31:28 +0400, Pavel 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-workspace i586 4.3.0-8.fc11 updates-testing 14 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 updates 53 k

Rahul Sundaram wrote: It grew a dependency on some newer libraries in kdebase-workspace recently, probably some prudent sub-packages are in order. -- Rex

Rahul Sundaram wrote: 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

Debayan Banerjee wrote: 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

Seth Vidal wrote: When you're forced to install package A to be able to install package E even though E doesn't use any of the functionality that A provides. For example, Michael Schwendt demonstrated that ktorrent pulls in qt-mysql, which in turn depends on mysql-libs. That's OK if Ktorrent can actually do something that results in queries to a MySQL database. Otherwise it drags in the MySQL client libraries unnecessarily – that is, I should be allowed to install Ktorrent without installing the MySQL client libraries. One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. Björn Persson

2009/8/24 Björn Persson <bjorn(a)xn--rombobjrn-67a.se&gt;: I hope you understand that chasing down every single instance of this situation ultimately leads to a situation that is more easily duplicated by making the build process automatically split every library binary into its own subpackage. If we aren't willing to do that automatically, then why is it worth the time to have multiple individuals systematically chase them down? I'm wary that the sort of checking you want to do is a rabbit hole that will require significant continued human effort as codebases shift. -jef

2009/8/24 Björn Persson <bjorn(a)xn--rombobjrn-67a.se&gt;: Are you suggesting that things are out of balance now? What is an allowable amount of tangle? Aren't you making an assumption that we are out of balance? Define a prescriptive "good enough" threshold to meet. Make sure you include a cost function for the associated repository metadata increase and subpackage header for each subpackage you add. Are you seriously suggesting expending the manpower at the distribution level to poke at which functional calls need to broken out into more libraries? One function per library! One library per subpackage! There are also libraries I'm fully aware of the difficulty with interpreted languages. And do you know which percent of those are explicit and which are auto-generated via a buildtime dependency generator? Explicit deps and provides are quite fragile..that's not going to change. The win is going to come from automating as much of the depchain in interpreted languages as possible instead of systematically trying to fix explicitly coded deps one package at a time. -jef

On 27/08/2009, Björn Persson <bjorn(a)xn--rombobjrn-67a.se&gt; wrote: Well, I develop a debian distribution for my organisation and I often need to confirm whether the packages in the repository are installable or not. I use edos-debcheck. Here is a sample invocation. debayan@deep-blue:/data/all/distros/deepofix-trunk/install_cd/deepofix/dists/doublethink/main/binary-i386$ edos-debcheck -failures -explain < Packages Parsing package file... 0.4 seconds 684 packages Generating constraints... 0.2 seconds libarchive-tar-perl (= 1.30-2): FAILED The following constraints cannot be satisfied: libarchive-tar-perl (= 1.30-2) conflicts with perl-modules (= 5.10.0-19) libarchive-tar-perl (= 1.30-2) depends on perl (>= 5.6.0-16) {perl (= 5.10.0-19)} perl (= 5.10.0-19) depends on perl-modules (>= 5.10.0-19) {perl-modules (= 5.10.0-19)} liblocale-maketext-simple-perl (= 0.12-2): FAILED The following constraints cannot be satisfied: liblocale-maketext-simple-perl (= 0.12-2) depends on liblocale-maketext-lexicon-perl {liblocale-maketext-lexicon-perl (= 0.66-1)} liblocale-maketext-simple-perl (= 0.12-2) conflicts with perl-modules (= 5.10.0-19) liblocale-maketext-lexicon-perl (= 0.66-1) depends on liblocale-maketext-perl {perl-modules (= 5.10.0-19)} libssp0 (= 4.1.1-21): FAILED The following constraints cannot be satisfied: libssp0 (= 4.1.1-21) depends on gcc-4.1-base (= 4.1.1-21) {NOT AVAILABLE} libversion-perl (= 0.6701-1): FAILED The following constraints cannot be satisfied: libversion-perl (= 0.6701-1) depends on perlapi-5.8.8 {NOT AVAILABLE} Checking packages... 0.3 seconds As you can see, it tells me which packages can not be installed due to dependency failure. It takes the Packages file metadata and processes it. For your particular case, where you want to check dependency tress for a particular package, I think that can be done too. "debayan@deep-blue:~$ edos-debcheck --help Usage: edos-debcheck [OPTION]... [PACKAGE]... Check whether the given packages can be installed. A binary package control file is read from the standard input. The names (for instance, 'emacsen') of the packages to be tested should be given on the command line. A specific version of a package can be selected by following the package name with an equals and the version of the package to test (for instance, 'xemacs21=21.4.17-1'). When no package name is provided, all packages in the control file are tested. Options: -check Double-check the results -explain Explain the results -rules Print generated rules -quiet do not emit warnings nor progress/timing info -failures Only show failures -successes Only show successes -help Display this list of options --help Display this list of options " Replace edos-debcheck with edos-rpmcheck. There is also an apt-cache flag that generates visual dependency graphs for a particular package. " dotty pkg(s) dotty takes a list of packages on the command line and generates output suitable for use by dotty from the GraphViz[1] package. The result will be a set of nodes and edges representing the relationships between the packages. By default the given packages will trace out all dependent packages; this can produce a very large graph. To limit the output to only the packages listed on the command line, set the APT::Cache::GivenOnly option. The resulting nodes will have several shapes; normal packages are boxes, pure provides are triangles, mixed provides are diamonds, missing packages are hexagons. Orange boxes mean recursion was stopped [leaf packages], blue lines are pre-depends, green lines are conflicts. " The above excerpt is from 'man apt-cache'. I am not sure if similar facility is available in yum. Caution, dotty cannot graph larger sets of packages. -- Regards, Debayan Banerjee Support Free Software http://deeproot.in

On Thu, 27 Aug 2009, Kevin Kofler wrote: well - no - that only works if you do it to an empty chroot. doing it locally only verifies that you have the bits on your local system. -sv

On Mon, 24 Aug 2009 23:26:58 +0200, Björn wrote: Installing ktorrent pulls in Akonadi, which is a PIM storage service, which in turn wants qt-mysql. It might be that ktorrent even includes PIM functionality. More unexpected was to see that it drags in a display manager and KDE base packages to offer KDE sessions at X gdm login.

2009/8/23 Björn Persson <bjorn(a)xn--rombobjrn-67a.se&gt;: Maybe speak to Richard Jones: http://rwmj.wordpress.com/2009/03/25/size-of-rpm-dependencies-2/ -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting?

On 08/24/2009 07:44 PM, James Antill wrote: Is there a reason this tool is not part of yum-utils? Rahul

James Antill wrote: Well, that looks like a good start, but it definitely needs some way to avoid listing glibc, like, seven hundred times over. It would also be nice if I could use it on a newly built package that isn't available in the Yum repositories. Björn Persson

Rajeesh K Nambiar wrote: If I understand that function right, it lists only the direct dependencies of a given package, not the dependencies of the dependencies, so it won't help with discovering situations like the one that prompted this discussion. Björn Persson

On 08/25/2009 03:37 AM, Kevin Kofler wrote: 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

Björn Persson wrote: 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

On Tue, 25 Aug 2009 00:07:48 +0200, Kevin wrote: The problem with kdebase-workspace (and kdm) is not disk space. Installing the kdebase-workspace package enables KDE X sessions for users.

Dne Tue, 25 Aug 2009 10:01:39 -0400 Ben Boeckel napsal(a): Session selection appears in the bottom toolbar after you select the user. Michal

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: used I button. how to switch is incomplete. desktop and things many users alternative wm 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. all, I agree.

On Thursday 27 August 2009 18:34:38 Michael Schwendt wrote: 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 <jreznik(a)redhat.com&gt; Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/

On Wed, 26 Aug 2009 14:46:17 +0200, Kevin wrote: "Installing the kdebase-workspace package enables KDE X sessions for users" is what I wrote. Quoted above.

Matthew Woehlke wrote: 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

Kevin Kofler wrote: 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... 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) ;-). 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. 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...) ...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 soooo 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

25.08.2009 02:07, Kevin Kofler wrote: 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?

Pavel Alexeev (aka Pahan-Hubbitus) wrote: 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

On Sun, 2009-08-23 at 14:34 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: 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 <SalimMA(a)fedoraproject.org&gt; GPG key ID: 78884778 IRC: hircus Package Sponsor, Fedora Project

On Sat, Aug 22, 2009 at 15:25:32 -0500, Bruno Wolff III <bruno(a)wolff.to&gt; wrote: 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.

On Sun, Aug 23, 2009 at 4:55 PM, Gianluca Sforna&lt;giallu(a)gmail.com&gt; wrote: Additionally, can you orphan the other active branches as well? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna

On Fri, 21 Aug 2009 22:34:24 +0200 Aurelien Bompard <gauret(a)free.fr&gt; wrote: ... text I've taken that one. Paul.