Re: [gentoo-dev] Email subdomain
On Saturday 19 November 2005 12:00, Thierry Carrez wrote: > The intermediary decision (during the October meeting, one month ago) > was that the GLEP would be approved, pending a list of changes. During > last month, nobody raised his voice to say this list of changes was > fundamentally flawed. Which in the gentoo-dev world, is quite outstanding. Probably because never a revised GLEP was presented?! I think the way to approve a GLEP that still "needs" changes isn't acceptable. There's a lot of information in these lists and I suppose very few ones have the time to read everything, so I did not read the council meeting stuff. Nevertheless, the very least to expect is that a possible final GLEP gets posted and discussed a while before it possibly will be approved. Personally I really don't care about the email address, even though I don't understand why we should unnecessarily overcomplicate things. But the way the base (a GLEP in this case) of decisions get changed by the council behind all of us is misuse of power. Obviously this was noticed by the members of the council as well, but the question why you didn't postpone the decision stands. The GLEP process needs to be a bit more formalized as it seems. Carsten pgpCs3Iwxd2Bj.pgp Description: PGP signature
Re: [gentoo-dev] Modular X porting: dependency changes
On Monday 21 November 2005 21:50, Donnie Berkholz wrote: > Here's the change: > "virtual/x11" -> "<=x11-base/xorg-x11-6.99" virtual/x11 isn't xorg for all profiles. Carsten pgpKJHUHNPisT.pgp Description: PGP signature
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
I have to say I'm somewhat disappointed by what I see compared to Aarons proposed look¹. a) Regarding the space below the two horizontal menus: A continuous image looks much better than these "cells" with a lot of useless and redundant links above them. If you think the space is wasted - well then drop it at all or make the image a small bar so there's more place for imformation. b) Adverts: Title them as what they are and draw a line between contents and adverts. The way it is now is very unfriendly to the reader. c) The cow pictogram and the text beside it is completely superfluous. d) I really don't think viewing the cvs is so important for first time users, that it needs to be linked that prominent. e) I like the thre vertical menus with the pictres above them. But from a usability point of view it's really questionable to expect a first time user finds them instantly when there's so much information on the front page that he has to scroll down. Either limit the information and make an extra news page (including searchable archive, that's missing atm.) or drop these menus at all. f) Handbook and other links: Usually you want to read the page and not metadata about it. The summary/date/author part takes too much place and the title is redundant. Make that a box next to the title or what else, but don't let the first action a user has to do instead to read to press scroll down. Carsten [1] http://www.gentoo.org/images/wwwcontest/contest1_front.png pgpxbnz21Nbdl.pgp Description: PGP signature
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
On Monday 21 November 2005 13:36, Jakub Moc wrote: > Well, I would like to see them on the left (and really could live without > those illustrative pics accompanying them, but that's just me. ;) I don't think they're very useful at the bottom either, but one (imho) important improvement of the design compared to what we have now is not having a left menu and adverts on the right. The two horizontal menus should suffice when you keep one static and one dynamic. Carsten pgpXpl4yilXj9.pgp Description: PGP signature
[gentoo-dev] last rites for net-im/sim
When you are interested in sim and willing to fix all bugs¹ and takeover maintainership) speak now. Christmas morning I'll crucify it. Carsten [1] https://bugs.gentoo.org/show_bug.cgi?id=110241 pgplrITLoIEF7.pgp Description: PGP signature
[gentoo-dev] another global use flag...
use.local.desc:app-text/ghostscript-afpl:jasper - Enable support for jpeg2k (jasper) use.local.desc:kde-base/kdegraphics:jpeg2k - Enable support for jpeg2k (jasper) use.local.desc:kde-base/kdelibs:jpeg2k - Enable support for jpeg2k (jasper) use.local.desc:net-proxy/ziproxy:jpeg2k - Enable support for jpeg2k (jasper) use.local.desc:sci-libs/gdal:jasper - Adds support for JPEG 2000 I was just about adding another one and thought it would be better to merge them to a global jpeg2k use flag. Complains? Carsten pgp9MFis92u5S.pgp Description: PGP signature
Re: [gentoo-dev] another global use flag...
On Thursday 22 December 2005 20:14, Drake Wyrm wrote: > Query: Which would be more appropriate in this case? "jasper" for the > library it pulls in as a depend, or "jpeg2k" for the functionality that > library provides? There's nothing else in the tree (as far as I can > tell) which provides JPEG-2000, but there could be. It is imho a _problem_ when use flags are _unnecessarily_ named after the library instead the provided functionality. When there are two libs doing the same thing, a single use flag should suffice: Less use flags mean reduced complexity for the user, who likely will understand what "jpeg2k" means, but not "jasper". Which leads me to the next issue; Often you can read: foo - enables support for $category/foo Such a description is as good as none. To give a sample how it should be: jpeg2k - Support for JPEG 2000, a wavelet-based image compression format. Carsten pgpisuZVmGT4w.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote: > Erm.. No, I don't think he is. We've been asking / waiting for the > [use] syntax to appear since before you joined the project. It's been on > "the list" for so long that many of us have given up... ; ) He - and I thought I just missed the thread between all those emails in my inbox. I'm interested as well to hear a bit about the proposed enhanced dependency syntax. > (finally we can kill use_with !! ) Why? There're not only autotooled configure scripts, so I don't see how to replace it in a generic way. I don't see what this would have to do with depending on ( ebuild foo without use flag bar ), either. Carsten pgpivOsQ6nOV0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing
On Saturday 24 December 2005 12:34, Peter wrote: > THAT is a very reasonable comment! Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as we have to wait for proper sets and only to be used for a larger set of packages. Wrapping three or four ebuilds with another one, just for the sake of lazy people having only to emerge a single ebuild is ridiculous. The only valid point in the original idea to merge the nvidia-* packages is to reduce the overall number of packages in the repository. As you heard the voices against it, ranging from none to valid reasons, everything left is to bury the idea and to close the bug. Carsten pgprQIFtQfl3A.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing
On Saturday 24 December 2005 13:50, Peter wrote: > Would you please add the comments to the bug report? Or, may I copy them? > Please advise. Feel free to do so. > Also, I find it absolutely fascinating that the only people against this > concept are devs, and the only people for it are users. Remember that > users are your customers. Every effort should be made to keep them happy. The only valid issue I read about against a single nvidia-driver package was Diego's regarding FreeBSD. On the other hand having packages split or merged only because it can be done, doesn't make much sense. Regarding happiness, merry x-mas and best wishes to everyone, but I care about maintainability in the first place. You may be interested in GLEP 21¹, a very user friendly approach to easily group user defined packages. > If you are against meta ebuilds, what is your opinion on KDE? Instead on 9 > (or so) packages, there are now over 250! Are 250 separate ebuilds better? > I cannot think of another distro that slices up KDE that way. Meta > ebuilds at least allow the user the ability to opt out of trying to > decide which ebuilds to emerge! The split was due and having meta packages of some sort was necessary due to the amount of packages. The problems are present though: re-emerging and un-emerging meta packages doesn't affect their child packages. For reasons why the split ebuilds are an advantage please refer to The KDE Split Ebuilds HOWTO². The big downside of (the large number of) split packages is the affect on the code base of the stable Portage versions (and the current layout of the repository), which apparently is not created having scalability issues in mind. > I always used to use CVS to update my KDE source tree, then compile only > the changed modules. I could have a whole updated KDE inside an hour. Now > that is performance! But this has nothing to do with providing a large user base with a reasonable stable set of packages. > Here, with the unified nvidia, the intent was to REDUCE ebuilds and > simplify installation process. I thought the recommendation of a meta > nvidia ebuild is a worthy one worth consideration. As explained above, it isn't. > IMHO sometimes the desire to fine tune things and optimize things goes a > little over the edge. nVidia upstream combines all the products together > in their .run files. There is minimal time difference between having the > entire suite installed versus each one individually. And, from a user's > point of view, what could be simpler? > > Anyway, I appreciate your feedback. If Diego could explain what the FreeBSD problem is and if he can resolve it, personally I don't see a valid reason against having a unified nvidia-driver package. I assume all the steps Portage is doing to install those packages (and uninstall previous versions) will take more time than having it bundled in a single ebuild, anyways. But raising the number of packages by a crappy meta ebuild (sorry, lazy users don't count) - no. Carsten [1] http://www.gentoo.org/proj/en/glep/glep-0021.html [2] http://www.gentoo.org/doc/en/kde-split-ebuilds.xml#doc_chap3 pgpjar6Psrvfo.pgp Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
This isn't politics, but copyright infringement on top of a ridiculous license (when you want to see it as one) we had a short discussion¹ about several months ago. Carsten [1] http://tinyurl.com/9oxgc pgpHcVb3ubq0c.pgp Description: PGP signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
On Monday 26 December 2005 14:57, Drake Wyrm wrote: > You're going to be hard-pressed to get any kind of consensus on this > issue. Many dev seems to feel that the license belongs there. In some > cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate > drivel, but actually unique, useful information. Removing these files and relying on LICENSE=foo in the ebuild could be seen as a copyright violation. There are lots of samples in /usr/src/licenses that aren't generic, but include a copyright notice naming the authors of a particular piece of software, but it doesn't match with all packages under this license of course. Take ZLIB as example. Since I'm not a lawyer I might be wrong, but me thinks it would make sense to ask one. Carsten pgpKKf9Ol6eov.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 19:36, Joe McCann wrote: > This whole thread seems to have come from a > misunderstanding of how use.defaults work and 20 min of boredom. use.defaults are based on the idea that having an ebuild installed should activate the relevant use flag(s) behind the users back. This idea is plain wrong, but has nothing to do with Doug's Christmas day rant. Carsten pgpmSsEbPHRWx.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 18:07, Ciaran McCreesh wrote: > Because it makes sense. For any application which has IUSE="emboss", > chances are emboss should be enabled. There was a long discussion about > this on the -user list a while back where I ended up posting a > newbie-friendly explanation of the whole thing. Perhaps you could hunt > it down on marc or gmane and post a link here... Probably you should have provided the link, because the question that comes to mind is, why this dependency is optional at all, when it should be enabled anyways!? Carsten pgpgudF0puG3p.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 02:04, Brian Harring wrote: > dev-lang/python[tcltk] > ^^^ need that atom resolved with use flag tcltk enabled I think that's exactly what someone told me months ago. :) > >=sys-apps/portage-2.0[sandbox,!build] > > ^^^ need >=portage-2.0 merged with sandbox on, build off. I wonder if portage deals fine with subtle dependency incompatibilities, when one package has foo[!bar] and another one foo[bar] as dependency and spits out a reasonable error message to apply mutual blockers. > kde-libs/kde:3 > ^^^ need any kde, with slotting enabled. > > kde-libs/kde:3,4 > ^^^ need any kde, slotting 3 or 4. > > Combination? Not set in stone afaik, the implementation I have > sitting in saviour doesn't care about the ordering however. This is the one I'm entirely not sure what it is good for. To me it looks more like a workaround for missing dependency ranges, but it won't solve any issue for KDE related packages. - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 is due, we can change to =kde-libs/kde-3.5* because everything else won't be supported anymore. So unless I miss something, kde-libs/kde:X is superfluous. - What we need is that ebuilds build against KDE slot X force a rebuild of those dependencies, which were against KDE slot Y as well as every other installed ebuild depending on them. Right now my fugly slot_rebuild() workaround lets the user do the job by hand. As a general remark I'd like to know if and how this enhanced dependency syntax is ordered. :[], []: or is both allowed!? What if we find out, that we need to consider another factor, later? :[]<>? Wouldn't it be better to have a extensible scheme, like e.g. $category/$ebuild[use:foo,!bar;slot:x,y] ? Carsten pgpu4QYUzO1bD.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: > If they're purely in DEPEND, that one isn't even an incompatability. Right. But it's not that unlikely to see such a corner case sooner or later and it would be good if Portage catches it, instead spitting out a weird message, leaving the root of the issue in the dark. Should be also simple to write a test case. > Well, any library that changes ABI should use a different SLOT for each > revision. So SLOT depends should be able to replace the need for = and > ~ and < and <= dependencies entirely. Which is a good thing, since > those atoms make dependency resolution a general-case unsolvable > problem. The problem is not the SLOT change, but to build "foo" depending on "bar" against KDE X, while bar is built against KDE Y. "foo" and "bar" support all slotted KDE versions, but they need to be build against the same one. You simply cannot express this via slot dependencies, so this feature is useless for KDE packages. > The existing syntax is just as extensible. Up the EABI revision, and > start adding new syntax as needed. EAPI has nothing to do with the consistency of the syntax. Getting it once right, is what you usually call for. I prefer clean data structures. Carsten pgpuUpWXh9dlB.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote: > You solve this either by SLOTting bar and making each bar SLOT use a > SLOT dep upon KDE, or by using USE flags and [use]:slot deps. It's not a that uncommon case and would lead to dozens, very likely (depending on the future development of KDE and libs around it) hundreds of duplicated ebuilds. In short: Your approach would result in a unmaintainable mess and is not going to become reality. > The proposed syntax is cleaner than shoving arbitrary stuff inside > [bleh]. You know the disagree thingie. But it's not that I have to ride on it any longer. Carsten pgp46bUeR5vlY.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:29, Brian Harring wrote: > So... basically, your concern is with the resolver, not use/slot deps > syntax. I did not say that this would have anything to do with the syntax. Am I right to extract from your words that we get rid of ~arch users complains about up/downgrade cycles with Portage 2.1 as well, but have them confronted with a proper error message!? :) > > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 > > is due, we can change to =kde-libs/kde-3.5* because everything else won't > > be supported anymore. So unless I miss something, kde-libs/kde:X is > > superfluous. > > Missing something /me thinks. > shouldn't really be specifying >=kde-x.y; should be specifying the > slotting. Do that, and you wouldn't have to go back and change it > over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a > different slot. Of course slot dependencies are cleaner. Just that they don't address a practical problem with ebuilds buildable against multiple slotted ebuilds of one packages, but the need to have them, their dependencies and all other ebuilds depending on the latter (ones [sp?]) built against one and the same ebuild ( In reality a set of ebuilds, named KDE X.Y). Carsten pgp3UqdzVqgZc.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote: > Nooo! That's exactly the point I was making. Carsten is assuming that > by using [slot:bar] syntax, no backwards incompatibility will be > introduced by adding a new [fish:] key. Nooo! ;) I said it would look more consistent, than always adding a new way (§$%&€<> or so) to describe or latest enhanced dependency atom. Carsten pgpRoB1lv8bPN.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:42, Brian Harring wrote: > Well, we all seem to be missing the issue, so please spell it out > clearly (rather then "it's going to get bad"). Didn't grok it from > the previous email, so spell it out please :) Just did so in the answer on your other email. Carsten pgpN7HZsGAEfF.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:11, Brian Harring wrote: > Either way, still not totally following your complaint, thus an actual > example would help (easiest to assume I'm a moron, and start at that > level of explanation). O.k. 1. You have KDE 3.4 and Digikam (version doesn't matter) installed 2. You update to KDE 3.5 What you now have is the following: KDE 3.5 works fine and Digikam as well, just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you rebuild for whatever reason). You emerge it (against KDE 3.5), but its dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The result is that compiling Digikam fails. You need to rebuild these dependencies and every other ebuild depending n those against KDE 3.5. And Portage should do that transparently. For now I have written slot_rebuild() which detects the problem at least and provides the user with the information what to do, but it's dead ugly. Carsten pgpndvDJCvSD8.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:11, Brian Harring wrote: > Never said anything about 2.1 + resolver enhancements (no clue where > that one came from). Merely commenting on your raised issues about > use/slot deps. From your words. Thanks for destroying my hope in two sentences. ;p So we add this dependency enhancement without having a Portage version in place that can resolve issues as they appeare!?! Scary. Carsten pgpPEvkfU9G2N.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:40, Brian Harring wrote: > The version of digikam being merged requires slot=3.5- it should be > depending on libk* slot=3.5, also, no? No! It (and also its dependencies) can be built against each 3.x slot. > As long as the information is represented dependency wise, portage > should be able to handle it fine. Just need to have that info there. It can't be handled dependency wise, because what is interesting is against which KDE version the relevant ebuilds are actually installed. Carsten pgpcxU0EbgGdg.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 04:08, Brian Harring wrote: > So note the comment in the email you are responding to about locking > down the used dep/rdeps for an install. That would be a maintenance nightmare. Every time a new KDE versions comes out a new ebuild revision for every package depending on KDE would be needed to work with this particular KDE version. Just for the sake of having to match with insufficient slot dependencies. I'll give another example: Application X works with KDE 4.0 (which implies that it will work with all KDE 4.x versions). Locking the dependency down to e.g. kde-base/kdelibs:4.0 implies adding another ebuild revision depending on kde-base/kdelibs:4.1, another one on kde-base/kdelibs:4.2. In short: Even having slot dependencies they won't be used, because =kde-base/kdelibs-4* is the dependency, which matches and no one will add hundreds of ebuilds just to follow the limiting scope Portage is providing via slot dependencies. Based on the packages we have now in Portage, that would mean ~300 additional new ebuild revisions as a side effect of every KDE version bump. Simply ridiculous. Carsten pgptdIP2KO63X.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 04:07, Ciaran McCreesh wrote: > But it's not binary compatible between KDE slots. So, once we > have :slot dependencies, you should link to a specific :slot (possibly > controlled via USE). It's like packages that can use either gtk or gtk2 > -- this has to be handled via a USE flag rather than linking against > whichever happens to be there. Forget it. Not maintainable, doesn't make any sense at all and won't happen. And it's not like gtk1/gtk2. An application working with KDE 3.0 works as fine with KDE 3.5. gtk1/gtk2 is comparable to KDE 3.x/KDE 4.x. Carsten pgpOJXgRK2fLD.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tuesday 27 December 2005 08:08, Mike Frysinger wrote: > anyone who installs a program in portage already has a copy of the license > on their system ... $PORTDIR/licenses/ My point was that it is often not the license of the copyright holder, because the copyright notice included in many licenses names the author of a specific application. Carsten pgpDkHtnGULA0.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: > If all three of those packages were first built against kdelibs:3.4 and > then kdelibs:3.5 became available then rebuilding any one of them without > rebuilding the others will break digikam. I can't see how it's directly > represented in the metadata unless you want to overload the meaning of > SLOT. It's not possible to represent that via dependencies. What is needed is some sort of introspection which relevant ebuild is built against which KDE version and if those _installed_ ebuild:kdever combinations match the one the _actual_ ebuild to emerge. But you're right about the overloading of the meaning of slots, because that's happening right now. Slots are used to install several versions of a package side by side. The idea Ciaranm and Brian are proposing to lock ebuilds depending on slotted packages down to a single slot is the redefinition. And once again: This doesn't match reality. Carsten pgpJIb6PA58Z0.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 14:59, Jason Stubbs wrote: > Do you mind reading and replying to the second paragraph (which happens to > be the only new information I brought to this thread). Underlining words to > emphasize a point to me that I've opened by agreeing is really not > necessary. I did not want to hurt your feelings by underlining, Jason. :) You missed a point in your wording of the digikam example in your first paragraph (while implied in the second), though. It's not only that libkexif and libkipi need to be rebuilt, but any other application (e.g. showimg) depending on them as well. > You've misunderstand what is meant by "locking ebuild dependencies". I gave > you a definition in my second paragraph. Please have a re-read. I did not comment on what you wrote, but on Ciaranm's and Brian's ideas about using slot dependencies regarding KDE packages. Carsten pgpPqXa3zhQjN.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote: > It's worse than O(n^n) if you try to do USE dep conflict resolution > too... Theoretically yes, practically the worst number of dependency levels we speak of to walk up/down is not infinite ;). Of course there's no chance to get this linear (speak: walking down the dependencies once), unless you store the information which ebuild depends (or more exactly DEPENDs && RDEPENDs) on foo in a list in foo's pkg db entry. The dependency resolution of the packages needed to rebuild on top of it is not different as usual. Carsten pgp3ntoKKjKxX.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote: > eclass, and no -r bump. Then it would not be possible to build the Application against different KDE versions and those who want to stay with a previous KDE version wouldn't be able to install any application. And conditional dependencies would break caching. Carsten pgple7l1HhYiZ.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:44, Ciaran McCreesh wrote: > Can you prove it, for the "allow USE and version cycling" case? (Hint: O.k, let m treat you as a the hot potato that you're Ciaran: - We speak about ebuilds, which are installed and need to be reinstalled. There is no version cycling (or I do not get what you're after, please explain in that case). - Changed use flags will be processed by the normal dependency calculation of the ebuilds to be rebuilt which may lead to additional dependencies or blockers. It could also be that some ebuilds are installed, which do not exist in the repository anymore. > you may find the PCP somewhat useful...) PCP - pretty colored potato? I don't know the abbreviation. Please explain it and whatelse I miss in your eyes. Carsten pgpzCSIWdJLT9.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: > Nnnope. If you modify an eclass it forces a cache regen for packages > using said eclass (except possibly if you're using an overlay, but > that's a separate issue...). You're trying to solve something which is already solved, but this has nothing to do with our problem. The question is not listen the possible valid KDE versions or a change of the eclass, but the need to know actual used KDE version. You'd need to call e.g. kde-config to get it. And this breaks caching. Carsten pgpmtt63wzs1W.pgp Description: PGP signature
[gentoo-dev] shoving utils from xpdf to poppler...
Hi Daniel, what you've done breaks runtime dependencies, if not for other packages so at least for KDE. Such a change should be announced on the gentoo-dev mailing list before you do it. Also a tracking bug to coordinate stabilization of new ebuild revisions will be needed, once the changed ebuilds go stable. Moreover you're not free to put a 200k patch into cvs, 20k is the accepted maximum. Carsten pgpcNyos5GjQ0.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Wednesday 28 December 2005 17:32, you wrote: > It's not supposed to break runtime dependencies. Everything that was > installed before is installed now, in the same location. But installed by another package. Of course it breaks dependencies when you depend on xpdf, because you expect it installs pdfinfo, but not that poppler does. It's not that both xpdf and pooppler are installed on every system. Carsten pgphEnxElBZBB.pgp Description: PGP signature
[gentoo-dev] last rites for dev-libs/btparse
It's - broken - dead upstream - unmaintained - and no other ebuild relies on it Carsten pgpL4YGZ6RNAY.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Monday 02 January 2006 10:35, Alexandre Buisse wrote: > Isn't there any way to make xpdf and poppler live together on the same > system? This is not about not being able to run both xpdf and poppler on one system. The blocker exists, because one ebuild of one package installs now files previously installed by ebuilds of another package, which causes collisions, if you don't unmerge the affected ebuild. You can install a newer xpdf ebuild revision later. See also bug #79606. Carsten pgpzEVvty8B84.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Tuesday 03 January 2006 20:25, Luis F. Araujo wrote: > >Portage does not resolve block correctly, look at bugzilla there are tons > > of bugs open. > > So i suppose we should avoid using this kind of notation whenever possible. See, it's not possible to avoid that with the current Portage version. Installing an ebuild, which installs files previously provided by ebuilds of another package results in an error, when you have FEATURES=collision-protect set. In such a case, it's a bug not to add this blocking dependency (and of course you have to add it mutually to the affected ebuilds) - as ugly as it is. And before you say, "Fine, lets add RESTRICT=collision-protect to this particular ebuild."; This doesn't work either, because you never know, when - or to which future version - a user will actually perform the update. Carsten pgpxmUMSeMhYY.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 11:26, Duncan wrote: > This man speaks my mind. That's one of the things I'm worried about with > the Enterprise Gentoo thing, and why I think it will make a better > separate project than part of Gentoo itself. I agree mostly, too. Just that QA has more aspects than "cool nifty package x that has bleeding edge dep y, with dep y sitting due to QA concerns", to quote Brian. A QA team can work concurrently to other subprojects of Gentoo, spot testing ebuild quality, checking e.g. for correct dependencies and licenses (I stumpled about four false ones the last few months) and a lot of other things without slowing development down. It's a pity, that we don't have an proactive QA team. The complaints about Gentoo having no direction, sound (at least in my ears) more like "Gentoo is not heading in the direction I want to have it." - so, attract developers who work with you on your goals (We don't have enough devs anyways, ~10% unmaintained packages in the tree speak for themselves) within Gentoo. I for one can't say we haven't seen a lot of improvements in different subprojects, just that it takes time. > see the history of the Panama canal for instance, but it takes a *LOT* of work Odd comparison, having in mind how much lives it did cost. Carsten pgpqjjrZxhhvD.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 16:46, Diego 'Flameeyes' Pettenò wrote: > Yeah ok, let me end up these holidays, and I'll prepare a written request > to change the Linux part in something else You should also contact the folks working on the gentoo.org redesign. While there was a bit of fuss about the infinity symbol, I always wondered why no one lost a word against the "Linux" below, given that we claim to provide a meta-distribution. Carsten pgpMV9UKLyfL3.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 23:04, Curtis Napier wrote: > > No, that's censored to only display what certain people want it to say > > rather than the truth of what's going on. > > Censored? Please expand on this, how is it censored? I thought we were > allowed to put anything Gentoo related we want to in our Gentoo blog? It's censored in the sense, that you limit the audience. Blog's are not suited for general information/discussion, because no one wants to monitor dozens of them and follow multiple threads on different web pages on one and the same topic. Weblogs are useful for people who feel it's necessary to have their own prominent place to raise their voice - a self-projection thingie, that's all. And therefore 99,5% of all the blogs are superfluous. Also a blog owner controls the comments and can delete them as he likes (less important, since it lets him not look good, but he can). To make it short: When you really have something important to say, post it to the appropriate mailing list - and post the whole text, not a ridiculous link to your blog, most people are not interested in and won't read! The same goes for our userbase: They're right to expect a single source of general information and one for security information, but not being forced to follow lots of blogs. Carsten pgprGqPXMeFme.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
On Friday 06 January 2006 16:27, Lance Albertson wrote: > As seen from the discussion earlier this week, I don't think Gentoo has > the proper open-mindness to create a proper enterprise distro. This has nothing to with open-mindness, but having enough people doing the general maintenance of a clearly defined frozen (sub-)tree as well as backports to fix vulnerabilities and other critical issues, without negative effects on other Gentoo subprojects (like "I work now on GLEP 19 stuff and don't care what I leave unmaintained instead."). Don't expect that maintainers of packages of the current tree do backports for a GLEP 19 tree. This is something the proponents would need to do themselves. You can't expect a commitment of the whole developer crowd in something only a minority is interested in. This doesn't mean there can't be a frozen tree within the context of Gentoo or as a separate project, of course. Carsten pgpMv2GjOlXIr.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sunday 01 January 2006 06:30, Mike Frysinger wrote: > Keep in mind that every resubmission to the council for review must > first be sent to the gentoo-dev mailing list 7 days (minimum) before > being submitted as an agenda item which itself occurs 7 days before the > meeting. Simply put, the gentoo-dev mailing list must be notified at > least 14 days before the meeting itself. I think I'm too late for this month, but want to put it on the table before I forget about it. I'd appreciate a three months moratorium, disallowing everyone to add new packages to the tree (despite new dependencies of existing packages), so everyone is forced/asked to put his energy in existing ebuilds, especially unmaintained ones. Sort of spring-cleaning, because parts of the tree look like a dump. Carsten pgpx5P5M5jnLM.pgp Description: PGP signature
Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips
You don't have to care, Alin. Mips is not among the security-wise supported¹ architectures. Then only problem I see in general is, that every single subproject defines what is supported and the information is scattered on the different gentoo.org documentation pages (release, security, kernel,...). This is anything else but user friendly and can e.g. result in official releases for not security-wise supported architectures. Carsten [1] http://www.gentoo.org/security/en/vulnerability-policy.xml pgp7IxEKtHFEF.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sunday 08 January 2006 01:38, Brian Harring wrote: > Asking people to focus on cleaning the tree? Sure. Generate a list > of candidates would help. Blocking new packages? No... I can't say I did not expect negative replies and "generating a list of candidates" is at least a suggestion. But a very weak one if you think about it; It would presume that most devs are too dumb to use bugzilla or to grep the tree. Carsten pgpSXFvfSUmGI.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sunday 08 January 2006 01:35, Stuart Herbert wrote: > I agree that some cleaning is needed (and some of my packages are > desperate for it!), but I'm totally opposed to this idea. I think the > idea of shutting up shop for three months (presumably with a "closed > for refurbishment" sign on the door) would let down our users who rely > on us for regular package updates, and would be a massive PR disaster. > Cleaning is something that has to happen all the time; it needs to be > a natural and sustainable part of what we do every day. As Donnie already pointed out, I did not mean version bumps, but only new packages. How about this idea: Everyone who adds a new package, has to check and fix an unmaintained package before. This should be a non-issue for seasoned developers, but would slowdown those, who continually add new packages without caring for what they should maintain as well as those who become new devs, add a bunch of packages and hide again, leaving the maintenance to others. This would also have the benefit of continuous QA of unmaintained stuff. Regarding PR: The quality of parts of the tree is more than enough bad PR. > If you feel so strongly about this, why not setup a "cleaning crew" > project that goes around doing exactly this? Don't you think that it is pretty much barefaced to let a small group do the dirty, boring and annoying work, while those who don't care a bit can continue to do so?! Carsten pgp5SDO90yfHE.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sunday 08 January 2006 15:01, Brian Harring wrote: > Guessing you missed the previous flame war about how trying to force > people to do something doesn't actually work? When it's not common sense, that every dev is supposed to do a minimal on general QA, Gentoo has a problem. > You're assuming seasoned devs don't occasionally go MIA on > QA/maintenance? It's not the case... I did not assume anything, I propose better QA. > > but would slowdown those who continually add new > > packages [ snip vitriolic opinions ] Thanks for calling something a vitriolic opinion, I did notice a few times, so it's a description of what's happening, but does not imply the majority of devs do so. > If you've got an issue with certain devs (seems to be the case from > your statement), take it up with QA/ombudsman, not the loop > around attempt you're doing here. > > If you're after trying to decrease the unmaintained packages, like I > said, generate a list _from the tree_, compare it to bugs, etc. Do > the legwork, kick off the effort to cover the gap. > > Basically, you want to decrease bugs for unmaintained, decrease the > gap of maintained vs unmaintained, work on _that_ rather then trying > to force everyone to drop what they're doing and fix an issue they're > already working on at their own pace. > > Folks *are* handling retirement of unmaintained packages, and taking > on maintainance of packages already- just watch -dev for the > occasional announcements if you think otherwise. To answer this paragraph in a short sentence: No, it doesn't work at the moment, and yes I'd like everyone would be urged to care a bit more, not leaving the legwork to a single person or small group, accepting that devs can feel as irresponsible as they like. Carsten pgpnK5iAULCHw.pgp Description: PGP signature
Re: [gentoo-dev] Duplicate licences
On Saturday 21 January 2006 09:08, Ciaran McCreesh wrote: > Were that the case, we'd do as Debian do and distribute a licence with > every single package. I bet there're more than a few ebuilds where this isn't the case. You can't even blame anyone, since there's no proper licence section in the ebuild howto or anywhere else in our documentation. And it is even worse: E.g. the original ZLIB license file we've stored in the license directory names the copyright holders of zlib, so basically we attribute every software with LICENSE="ZLIB" in its ebuild to the authors of zlib. Carsten pgpiHOInEdgX1.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Monday 13 February 2006 20:29, Grobian wrote: > Maybe that has to change then? Like getting more bug wranglers that > also handle canned responses as a first-line helpdesk? Wrangle bugs a few months and you'll see how hard it can be to stay friendly sometimes... And no, bugzilla is not a helpdesk. We have mailing lists and forums.g.o for this. btw.: I think the idea to give someone credit for requesting a version bump is pretty much ridiculous. There're helpful requests/bug reports, where credit is due, but the usual case of a request for a new version isn't. Carsten pgpRt7TKZBV5m.pgp Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
On Sunday 19 February 2006 10:20, Ciaran McCreesh wrote: > It gets worse still. It looks like many our mirrors have broken copies > of certain Berlios-hosted tarballs. Shouldn't that be a general problem with our mirrors - unless Berlios got hacked and modified tarballs injected, of course?! > Does anyone happen to know any of the Berlios staff? I don't, but sent an email (in german, therefore not cc'ed the list ) with yours attached to their contact address. Carsten pgpyj4KZxIC6i.pgp Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
On Sunday 19 February 2006 11:32, Ciaran McCreesh wrote: > As I understand it, our mirror scripts rely upon wget being able to > fetch the correct tarball from the original location. Well, I'd expect them to fail gracefully when the tarball is clearly invalid and not to inject the junk. But I don't know much about our mirror scripts. Carsten pgpcOpvW7WmI5.pgp Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
Got a positive answer. Any remaining issues? Carsten pgpNZUjiYYIkb.pgp Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
On Monday 20 February 2006 19:51, Ciaran McCreesh wrote: > Positive as in "yes, we'll fix it", or positive as in "yes, we're > mangling the tarballs and we hate you"? Positive as in already fixed. Carsten pgpBBuf9e1rQs.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 16:43, Dan Armak wrote: > If you're concerned about diskspace you can filter out /usr/share/doc > entirely, so users do have the choice. The problem here is that the docs > USE flag is off by default. Making more packages use the flag would install > less docs. Has anyone actually complained that too many docs are installed > by default? It's true that some users/situations don't need them, but most > do, especially as long as we don't have separate server profiles. I have seen quite a few bugs about that and actually have filed one¹, rotting in bugzilla, myself. I definitely do not care about a few hundred KB documentation per ebuild, but some install a lot of documentation and accumulated it's a lot of wasted space. Filtering out /usr/share/doc as a whole is no choice, when you usually want it, but a fair share not. Carsten [1] https://bugs.gentoo.org/show_bug.cgi?id=116658 pgpTtLTWWm7nr.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 02:04, Ciaran McCreesh wrote: > This is undocumented and unofficial, so feel free to utterly ignore it > and commit whatever the heck you want. > > The 'doc' and 'examples' (yay for consistency!) Don't now, if I guess right what you want to say, but there's no plural of documentation afaik. ;p Carsten pgpJVcckIIBPO.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Monday 06 March 2006 17:39, Paul de Vrieze wrote:
> I guess some advanced /etc/portage/bashrc magic isn't enough for you?
> There are some neat tricks you can play with that.
I consider this sort of ugly hack. And I don't see the point why everyone
should do this, while a maintainer, even when the install script doesn't
allow to omit doc processing, can - as the very least - add
use doc || rm -rf ${D}/usr/share/doc/${PF}/
at the end of src_install, when megabytes of api docs etc. get installed. The
maintenance cost is zero.
Carsten
pgpV3ArdKaHHB.pgp
Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Monday 06 March 2006 17:49, Paul de Vrieze wrote: > Documentation is uncountable. So no singular or plural ;-) Uh, that was meant ironic, considering Ciaran's remarks to others, that they should know about this or that, leading to the one or the other inflaming thread. But thanks for the explanation. ;) Carsten pgpd7WamFkD0E.pgp Description: PGP signature
[gentoo-dev] last rites: multiple packages
Hi,
a short list of packages, which can be buried imho:
x11-misc/kpasman - unmaintained upstream for years, alternatives e.g.
kde-misc/pwmanager
media-libs/libdbmusic - exclusive dependency of media-sound/kmusicdb, which
has been removed a while ago
net-misc/knetmonapplet - unmaintained upstream for years, alternatives are
net-misc/{kbandwidth,knemo,knetload,ktraynetworker} or the ksysguard kicker
applet
I'll bury these packages in a week, if no one yells that he can't live without
them and takes over maintainership.
As soon as KDE 3.5 goes stable - no date yet - I'd like to bury
x11-misc/karamba (if desktop-misc herd agrees)
x11-misc/superkaramba
as well as
x11-plugins/karamba-* - unmaintained for years
Reasoning is that the Superkaramba that comes with KDE 3.5 is a rewrite,
enabling the user to directly download the karamba plugins he wants, while
the packages are not maintained within Gentoo and the other Karamba versions
are not maintained upstream anymore.
Carsten
pgpx6OJxm8Js7.pgp
Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Saturday 25 March 2006 12:49, Diego 'Flameeyes' Pettenò wrote: > NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris? It's great that you and others are working on alternative platforms, but regarding decisions which tools we use, our main platforms are of interest. Everyone else should/has to make it work, imho. I don't think it's acceptable to base our decisions on platforms nearly no one is using. This is meant as a general remark, not especially regarding a distributed vcs. Carsten pgpoBlRNy1Oae.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Saturday 25 March 2006 19:50, Diego 'Flameeyes' Pettenò wrote: > This is the same line of thinking that makes people use flash or wmv > "because it's the silly Linux users that has to adapt, Windows works fine" > and similar. It's not. Darcs is not proprietary, so you can make it work if you want/need it. And it's up to those who use a specific platform to make it flourish, but holding us back to use something because of some specific platform having not enough developers/users/steam to follow would be entirely stupid. > > Thisis meant as a general remark, not especially regarding a distributed > > vcs. > > In this particular case I'm asking for a solution that can accomodate more > than just us. I'm positive that there are solutions as good as darcs that > does not require Haskell, but of course if there's a killer requirement > that makes darcs the only solution we'll work on make it available. Once again, I did not say anything in favor of any vcs. > Of course doing like people using Flash to write a website that could have > been built using plain HTML and animated GIF images, and using darcs only > because it was the first idea while there are good alternatives that works > for more people would be something that will a) piss me off quite a bit > because of the paradox said above b) make the whole project laughtable by > other Free Software projects finding the above analogy... The comparison to proprietary software is completely out of line. Carsten pgpp1QF4heKhl.pgp Description: PGP signature
[gentoo-dev] questionable usefulness of virtual/pdfviewer,psviewer
Got a request¹ providing them, but I don't see any sense in it at all. The only package using it is app-office/lyx. Imho the dependency should be removed, since it is a optional runtime dependency the user has to configure anyways, so it'll never work out of the box. This sort of virtual is only useless bloat imho. I guess the same goes for virtual/textbrowser which is - for whatever reason - the run- _and_ compile-time dependency of app-text/docbook-sgml-utils. Opinions?! [1] https://bugs.gentoo.org/show_bug.cgi?id=127589 pgpLdoI8neLk0.pgp Description: PGP signature
Re: [gentoo-dev] Not offering help to certain parts of society
Given that most of the world not necessarily knows who the Amish are, it should be added, that they form the heart and soul of the north american technology elite¹. Carsten [1] http://en.wikipedia.org/wiki/Amish pgpDbje8gW1U8.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Thursday 30 March 2006 01:55, Mark Loeser wrote: > Not directed specifically at you, but it seems a lot of people are > masking stuff and removing it very quickly, and I'd really like to see > everyone wait the 30 days to remove something from the tree. That way > anyone using this package in some way will get the message from p.mask, > and know what they should upgrade to. > > With that being said, is there any reason that the package should be > removed so quickly? Yes, there is. It's slowing down the process, getting into the flow. Waiting 30 days is a lot of time. A regular user does not necessarily follow the dev-gentoo mailing list and it doesn't matter for him, if the package is masked or removed. He can always get it from (web-)cvs. The time to wait is to give others the time to step up to maintain the package. And if some dev missed the announcement, nothing is stopping him to reintroduce the it. Honestly, I don't see the point. Carsten pgpoClSML4nUh.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Sunday 02 April 2006 20:41, Mike Frysinger wrote: > nothing personal, but who are you to say whether it's legit ? It's really not a question what's legit (heck, you started using this term, so blaming Olivier for using it is a bit odd), but what we (can and want to) support. Wouldn't it have been time for you to speak up, when the Gnome herd announced to deprecate Gtk1 support for applications that build again Gtk2!? Instead playing the road block for the very few people who may still favor Gtk1, it should be more the question, if there's anyone supporting Gtk1 upstream with regards to security issues etc.. I for one favor it to eliminate toolkits that are superseeded by their successor as fast as possible. Carsten pgpbG5Bik6Ctb.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sunday 02 April 2006 04:48, Daniel Goller wrote: > exactly, what's the point of removing it so fast? give people a chance > to miss it, it does not matter if it's removed or masked only as far as > going "woah, what?" and if masked it is a matter of unmasking rather > than recommitting We haven't had a single issue with the usual seven day period as far as I can remember, so please come up with a valid argument against it, instead assuming turning my argument would be one. > in short, if it's slowing down the process, why do you need it to be > quick in the first place? Getting the junk out of tree and mind as fast as possible is a value in itself. Carsten pgpM3Qs9oescc.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Sunday 02 April 2006 21:51, Harald van Dijk wrote: > Others did speak up at that time. The result: > > http://article.gmane.org/gmane.linux.gentoo.devel/31641 Yeah, that was the one and only single voice. Carsten pgplFkefqq6Ma.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Sunday 02 April 2006 21:28, Mike Frysinger wrote: > last time i recall following the gtk/gtk2 stuff, the idea was that in the > future to move to a gtk/gtk1 situation ... but this was back when Spider > was The Man, so i guess people forgot about that No, see the whole thread Harald references in his email. > > it should be more the question, if there's anyone supporting > > Gtk1 upstream with regards to security issues etc.. > > and when such a situation arises, the solution may to simply drop the > optional support. such a situation has not arose, so using such > hypothetical examples is meaningless. The problem is that no one is working on the code, so the chances for black hats to find something they can abuse for a long time are to consider. The situation is always given. It's just the question, when and if the good guys get to know about it. Carsten pgpc1PEkIjwrp.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sunday 02 April 2006 21:31, Ciaran McCreesh wrote: > The usual period is thirty days. Grep this mailing list, most often a one week period was used. > Once it's in p.mask it's effectively gone, to the extent that ignoring > it for a month is fine. Who said a package gets masked before it gets removed? There is no such requirement in the ebuild policy. Carsten pgpFHPt6EHSxi.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sunday 02 April 2006 22:33, Ciaran McCreesh wrote: > This is a recent change, and usually someone replies with "why not a > month?". This is simply not true or we have very different ideas of the meaning of recent. The vast majority of "last rites" emails from 2005 had slated removals of one week or less. > It's not a requirement. It's a courtesy to your users and fellow > developers, at least some of whom would very much appreciate it if you > left things for ~four weeks rather than ~one. I don't see the necessity for devs and users would have to look at the package.mask file regularly to get the information that a package is masked. If Portage would be that smart to spit out the relevant information on emerge --sync, a longer period would probably make sense. Carsten pgp0vBYtK5V7j.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sunday 02 April 2006 22:29, Simon Stelling wrote: > Come on. Is this a 'policy doesn't say I have to be sane' war? It's > absolutely reasonable to p.mask a package that is pending for removal. That > way you give the users a timeframe which they can search for alternative > tools in. This is not the case. At least unless the user actively looks at package.mask. Since Portage doesn't provide the information, this point is void. And even if - four weeks are a too long, imho. Carsten pgpnCZy5so6UC.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Sunday 02 April 2006 22:40, Mike Frysinger wrote: > lets apply the same logic to all things unmaintained ! Yes, that's one reason I am so annoyed of the unmaintained parts of the tree. > besides, you're talking about removing GTK1 completely ... this thread is > talking about deprecating the gtk2 USE flag Well, from my POV - . You could at least change your packages to use gtk2 by default to be consistent with the other packages and add a (local) gtk1 use flag, so we can get rid of the gtk2 flag. Carsten pgpEAUXX0myA2.pgp Description: PGP signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sunday 02 April 2006 23:26, Jakub Moc wrote: > Not that I'd care so much whether it's a week or a month (IMO individual > depending on ebuild in question) - so just a technical note. Portage 2.1 > *does* spit out the relevant info. I'm aware of this, but that doesn't help anyone running running arch. Not that I like the implementation... > Calculating world dependencies / > !!! Packages for the following atoms are either all > !!! masked or don't exist: > net-ftp/glftpd ...since the user has still manually to look up what's going on. Can't call that user friendly. Carsten pgpfQebo1towQ.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Monday 03 April 2006 00:29, foser wrote: > Already security related issues have been dropped by upstream for the > simple reason that it hasn't been maintained since the day gtk went > 2.0 . Why didn't you file (Gentoo) security bugs? Perfect reason to drop Gtk1 support, if no one steps up to fix them. Carsten pgpX2fQbQLdxW.pgp Description: PGP signature
Re: [gentoo-dev] gtk2 use flag must die
On Monday 03 April 2006 01:54, Daniel Goller wrote: > you are really trying hard to get gtk(1) Everyone as s/he likes. I favor the deprecation of the gtk2 flag and start dancing on my chair, once we have a Portage version with slot/use depends in arch. But this is a completely different topic: Knowingly providing our userbase with software that is vulnerable is a very bad. I'd argue the same for any software. Carsten pgpYdw5G6PRUo.pgp Description: PGP signature
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
On Tuesday 04 April 2006 11:12, Chris Bainbridge wrote: > Surely the question isn't whether the upgrade is perfect, but whether > it's better than the current stable release? Exactly. > (I realise that isn't a perfect patch count...) Exactly. > I think at this point it does more harm than good to be lagging behind > the current upstream kde - last time I checked the kde bugzilla > wouldn't even accept bug reports for the kde currently marked stable > as it was too old, and if bugs can't be filed then it's clearly > "unsupported upstream" and time to upgrade. KDE 3.5.0/1 had grave bugs, leaving users with lost addressbooks and such. KDE 3.5.2 is not even out of our 30 days testing period and I have still a few patches enqueued to be applied. I can live with users complaining, but that doesn't mean it's not going on ones nerve. Especially when developers fall into the chorus, it's getting uneasy. It's ready, when it's ready. Really. Carsten pgp5GodaAekLS.pgp Description: PGP signature
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
On Tuesday 04 April 2006 04:37, Grant Goodyear wrote: > Although I agree with the overall spirit of the comment, I disagree that > RTFM is never the right answer. It helps if somebody points out _which_ > fine manual to read, but ":help hardcopy" is a much better answer to > "How do I print from within vim?" than actual detailed instructions > would be. I wholeheartly agree, just that the help to help yourself is not what I consider as RTFM. Of course you have to learn the relevant bits yourself, so being kindly pointed to exactly those bits is perfectly fine. Carsten pgp7ABoOBSzpu.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
On Tuesday 04 April 2006 06:52, Mike Frysinger wrote: > sorry, those last two paragraphs are covered elsewhere between infra and > evrel ... so the document should be considered without those last two > paragraphs > -mike This is what I'd like to see clarified. To me, only a decision of the Council may lead to such a "suspension", as it is the relevant _elected_ entity. And I hereby request to add a paragraph at least, stating exactly this. Also I do agree with foser and many others about the dubious wording. It can be stretched to any extent, if "needed". And I'm not that suspicious, given that Infra already acted once, without having any right to do so. Carsten pgpgb0LD0E4qS.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
On Tuesday 04 April 2006 01:44, Jon Portnoy wrote: > Well, quite frankly devrel has never fallen down on the job quite so > often & so hard before handling this particular incident. I don't think > it's so unreasonable to have backup plans for preserving Gentoo when > devrel cannot respond in a timely manner If you exclude that devrel for a long long while was unable to retire developers properly and if you exclude that people bitched about devrel not updating docs - then maybe. I'm stating this, please don't take it as flaming. Carsten pgphPKubxwRHS.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
On Tuesday 04 April 2006 21:53, Donnie Berkholz wrote: > This is absurd. The council shouldn't need to make every decision in > Gentoo itself. It should be able to delegate power to any group it chooses. Such a decision is not like /every/ decision and should happen only very seldom, so I don't see any reason or need to delegate it. Carsten pgpL8Q08zUZYq.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo theming during bootup
On Friday 07 April 2006 04:26, Donnie Berkholz wrote: > I also share the opinion that we shouldn't go against upstream wishes > IRT branding, but if upstream encourages some fairly subtle branding > along with keeping their name visible, I'm for it. There's a thread in gentoo-core from 2004 with regards to branding and the outcome was to refrain from it. I don't have a problem, when we do this for live iso's, but generally I strongly dislike it. Users don't choose their distro because of it, so it's just unnecessary bloat. And given that we tout Gentoo a meta distribution, encouraging others to build on it, there's no point forcing them to have to clean out the Gentoo brand, before they actually can use it. Carsten pgp5mpBfaoj37.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo theming during bootup
On Friday 07 April 2006 15:28, Simon Stelling wrote: > He said he wanted to make it easy, not forcing it. Or am I mistaken? How do you want not to enforce it? The last time¹ someone came up with a "branding" use flag, some were in favor of, some against it. Still, the basic question is: Why!? There's no benefit for the user, who will choose whatever theming he wants anyways. Imho it's superfluous and therefore wasted time. I for one favor to stick with that, what upstream provides. Carsten [1] http://tinyurl.com/o7dkc pgp4mnjbnG3MU.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo theming during bootup
On Saturday 08 April 2006 00:52, Mike Frysinger wrote: > highly suspect statements > > these states are all quite common ... trying to make some kind of > supposition as to which is the most common is a waste of time No. It's my opinion. Respect it, please. You don't have to agree. > in my experience, from the many forms of Gentoo communication (real life, > mailing lists, irc, forums, etc...): > - quite common for people to be lazy and just use the default > - quite common for people to change the default to their own thing > - quite common for people to use just Gentoo themes where they can > > as long as people include Gentoo themes in packages for people to select, > we should have pretty good coverage of everyone's needs Well, if we end with some stuff not themed, some stuff themed, having it applied by default as well as non-default, maybe even different looking theming depending on the package, the result will suck. Is it that hard to define a few goals, instead coming up with "ha, let's do Gentoo themes" without having a clue about the conditions, what it should look like and what the side-effects are!? Carsten pgp84Ow0dP39N.pgp Description: PGP signature
Re: [gentoo-dev] Let portage symlink latest version of installed docs
I dislike the idea to create lots of symlinks for that reason. But I'm having a bug¹ open at mozilla.org with the goal to create rss feeds from the documentation. Carsten [¹] https://bugzilla.mozilla.org/show_bug.cgi?id=332095 pgpBhuQuKgGb2.pgp Description: PGP signature
Re: [gentoo-dev] default RDEPEND?
On Friday 28 April 2006 21:57, A. Khattri wrote:
> Does it make sense to make the value of RDEPEND in an ebuild depend on USE
> flags? Example: Im writing an ebuild that use either cvs or svn at
> runtime. I want to allow users to choose which one they want but make cvs
> the default. What's the best practice for scripting this in an ebuild?
RDEPEND="cvs? ( dev-util/cvs )
svn? ( dev-util/subversion )
!cvs? ( ! svn? ( dev-util/cvs ) )"
pkg_setup() {
if ! use cvs && ! use svn ; then
ewarn "Neither CVS nor Subversion use flags enabled, defaulting
to CVS."
fi
}
Carsten
pgpoo7U4tVN4b.pgp
Description: PGP signature
Re: [gentoo-dev] default RDEPEND?
On Saturday 29 April 2006 00:02, Tuan Van wrote: > and I also saw something like below without cvs USE flag: > > RDEPEND="svn? ( dev-util/subversion ) !svn? ( dev-util/cvs )" Does obviously not work, if you want to have both available. Also enabling cvs support by disabling svn is not transparent to the user. Carsten pgpQNWAXGhuwE.pgp Description: PGP signature
Re: [gentoo-dev] default RDEPEND?
On Saturday 29 April 2006 09:08, Alin Nastac wrote: > Huh? How about: > RDEPEND="|| ( dev-util/cvs dev-util/subversion )" Similar problem as with Tuan's version: It's intransparent to the user and he has no choice, unless he looks into the ebuild. || ( foo bar ) is only an option, if you have two packages providing the same functionality, but a virtual is not in order. On the other hand, if the scm support is not a core functionality of the application, I'd refrain from adding these optional runtime dependencies and simply add a post install message instead. Carsten pgpau2PqxCKmG.pgp Description: PGP signature
Re: [gentoo-dev] DEPEND/RDEPEND question
On Tuesday 25 April 2006 08:53, Alin Nastac wrote: > Lets say a package foo depends on bar, both at compile time and run time. > Shouldn't DEPEND _and_ RDEPEND of the foo package reflect that > dependency? I usually set DEPEND="$RDEPEND ..." or vice-versa (depending > on which is the most demanding). Am I utterly wrong here? This is right, when there're more dependencies in DEPEND than in RDEPEND. If DEPEND == RDEPEND you should leave either one unset, as Portage assumes that DEPEND == RDEPEND in that case. To quote the ebuild policy: "The DEPEND variable inside your foo-x.y.z.ebuild tells Portage about which packages are needed to build foo. The RDEPEND variable specifies which packages are needed for foo to run. You only need to explicitly specify RDEPEND if the ebuild's runtime dependencies are different than what you specified in DEPEND; if not specified, RDEPEND will default to your DEPEND settings. Never set RDEPEND to DEPEND yourself in an ebuild." Carsten pgpvOL2PKJcDy.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?
On Friday 05 May 2006 09:20, Bart Braem wrote: > Firefox 1.5: 5 months (the entire world uses it now, in stable) Still has open at least one open vulnerability I know of, still has memory management problems afaik. Despite that it's stable on some architectures. We have exactly one active dev working on the whole Mozilla stuff at the moment. Did you say you want to help? > KDE 3.5.2: 1.5 months (I know our devs get prereleases, so we had this > time) Still open issues, some upstream, some Gentoo related. Also the KDE team lost members the last months and is unfortunately not that active since a while. All the whining leaves me with the feeling that I'm less interested to work for you. The question "What can I do?" I do never hear. Stop whining, but decide to help or give another distro a try. These are your choices. Carsten pgpMGq5lX6NSF.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Friday 05 May 2006 08:32, Kevin F. Quinn (Gentoo) wrote: > If you use specific versions in the package.keywords file (i.e. do > "=category/package-version-revision ~arch" instead of > "category/package ~arch", this doesn't happen. Hardcoding specific ~arch versions or revisions unless absolutely needed is a bad idea. Remember that we don't do GLSA's for testing stuff. If bleeding edge, then bleeding edge. Carsten pgpNXSLqBYpEO.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Friday 05 May 2006 15:23, Kevin F. Quinn (Gentoo) wrote: > I disagree. Your argument is for not using ~arch at all, rather > than an argument against keeping control of what you have from ~arch. No. My argument is that category/ebuild is much better than =category/ebuild-x*. If and only if there's a problem with the former, you should take the latter into account and monitor the ebuild changes closely. > In practice, I tend to do: > > =category/package-version* ~arch > > so that I pick up -rN bumps on unstable versions as this should mean > that the maintainer considers the change necessary for users of that > version. So you won't get security updates, when this means it is a version bump. And this is most often the case. Unless you _always_ read the ChangeLogs and referenced bugs of all ebuilds you run testing, this is not safe. Carsten pgpjltTGPFPD2.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Friday 05 May 2006 20:37, Kevin F. Quinn (Gentoo) wrote: > First, I'll get the security updates when (1) the relevant updated > package goes stable, which is usually pretty quickly, or (2) > notification is made in gentoo-announce (which must be the correct > place to get such notifications). That they go stable quickly is a bet and not always true. When there never was an stable ebuild, there won't be an announcement. > Secondly, "Up-to-date on GLSAs" != "safe". Not by a long shot. > Further, missing GLSAs does not necessarily mean I'm vulnerable. > That's what the detail is for in the GLSAs; so I can make a judgement > call on whether I need to worry about a vulnerability or not. It's a difference, if you can trust on a security team taking care or if you have to do it all yourself. That there will never be 100% perfect security is a different topic. > Lastly, if there are versions of a package in ~arch that have known > security flaws, my understanding is that they either get patched with a > -rN bump, or they get removed from the tree in favour of a later > version that is not vulnerable. Either way, I get notification when I > next do an update. That previous ebuilds get removed is another bet, I wouldn't make. You claim "Up-to-date on GLSAs" != "safe" (which isn't wrong of course), but base your dealing with possible vulnerabilities on assumptions. That doesn't match. Carsten pgpgVn7uk3Atu.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 00:22, Stephen Bennett wrote: > > Does the Gentoo Project not support the > > entire tree all of a sudden? > > There are plenty of ebuilds in the tree marked as unsupported by > gentoo. Probably some profiles too, though I can't name them for > certain off the top of my head. That's not an argument, the share of both unsupported and unmaintaned packages is problematic enough. Unfortunately trying to find a way to change this every time resulted in some devs starting a flame war. > 1) Is bugsy ready for this, with appropriate categories in place? > > Paludis-related bugs can be marked as invalid and the user directed to > Paludis' bug tracker on berlios.de. Alternatively, if our friendly > Bugzilla admins want to create categories I won't complain. I don't see > a need for it though. This costs someones time as well. I haven't had a look at Paludis (the name sucks as much as the name eselect had, before it was named eselect, btw.) yet, so I don't have an opinion on it, but if we (or some of us) start supporting arbitrary package managers, where do we end? Doesn't it cost time, that could be spent better!? If we do it, wouldn't it be better to modularize a bit first? E.g. defining interfaces between - tarball management (fetching via users tool of choice be it from the web or according to a file list from a named media (e.g. DVD or a tape), mirror handling etc.) - profile management (keeping the on disk representation apart from the way the dependency resolver gets the information) - package management (dependency resolver, ect.) - package installer (install files or create binary packages, may the target be .tbz2, .deb or .rpm) and implement them as independent tools, so we can easly exchange one for the other, if there is a superior one, instead having to throw everything away?! I don't think it would be beneficial in the long run, if the outcome would be that Gentoo divides into groups using different package managers. Carsten pgpvhKXcZhDer.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 15:50, Ciaran McCreesh wrote: > On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke <[EMAIL PROTECTED]> > > wrote: > | I haven't had a look at Paludis (the name sucks as much as the name > | eselect had, before it was named eselect, btw.) yet, so I don't have > | an opinion on it > > Aah, and this sums up this entire thread. "The name sucks. I haven't > used it. It isn't pink enough." Please do not mix up the flaming between you and Diego with my email. Yes, it isn't pink enough and I don't like your ponytail either. :p > Nice idea in theory. In reality, Portage is a big incestuous mess and > can't have that kind of change made to it The former yes, the latter statement is questionable. > , and defining such an > interface between package manager parts would take considerably more > time and code than just rewriting the whole thing. That won't mean you face the same situation at one point again, so you likely have to spent the same or even more amount of time, just over a longer time frame. > Having said that, > you can swap around pretty much any component of Paludis, since it's > proper modular code -- Kugelfang has a mostly working implementation of > a CRAN repository, for example. Doesn't sound like independent runtime components, as I am proposing. Carsten pgp2WslpBUQjv.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote: >It's kinda like this: Stop making such odd and wrong comparisons. The package manager is part of what defines a distribution, choosing a shell is the users choice. If you want to make the package manager matter of choice, start your own distribution. Carsten pgpW6ZEHHVCId.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:43, Roy Marples wrote: > Yes, part of it. baselayout is another part - and yet it's possible to run > Gentoo on other variants like initng, daemontools and no doubt others. Sure baselayout is. An there're others in the tree, But that doesn't mean these variants are supported (special cases like embedded aside). > Or are you saying that SUSE is RedHat as they use RPM? Can you install SUSE and RedHat packages arbitrary mixed!? No, you can't (well, you can, but...). Carsten pgp8mCizacJLU.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:15, Ciaran McCreesh wrote: > | Sure baselayout is. An there're others in the tree, But that doesn't > | mean these variants are supported (special cases like embedded aside). > > Sure, some of them are supported. By supported I mean all relevant packages in the tree install matching init scripts. That means officially supported, compared to such a package being maintained. Carsten pgpSIhWLAeOpc.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 09:33, Roy Marples wrote: > Maybe you haven't noticed, but baselayout is a virtual - which does make > things harder as the main "forks" (vserver and fbsd) sometimes break when > we add new things and they haven't synced up yet. I have nothing against a virtual. I just don't think polluting the profile subtree with alternative package mananger stuff is good idea. > But that's OK as they're supported I guess. > > Or are you saying that spb, other devs and people outside of Gentoo who has > submitted SoC applications about Paludis (or what that qaludis?) are just > going to wack it into the tree and then say "we're not going to support > it"? > > Of course not! No, I'm saying it's not the Gentoo package manager. Work on it, make it a viable contender for replacing Portage, but as long it isn't, keep it in an overlay. Carsten pgpAKM1VE6DjN.pgp Description: PGP signature
Re: [gentoo-dev] et_EE locale and language of error messages
On Friday 19 May 2006 15:24, Harald van Dijk wrote: > grep through gcc/po/*, which doesn't require installation of the > locales Providing the error messages in english is part of what I consider the users job when filing a bug report. Having to grep for the strings is wasted time. I'm not so sure, if hiding compilation problems with other locales is a good idea, though. Carsten pgpjPC0QxFmkt.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 16:17, Roy Marples wrote: > I can show you bugs where existing packages have invalid init scripts that > just don't work with any baselayout version in portage. You could argue > that they shouldn't be in the tree - if so then our imap server is > foo-bared as it uses courier-imap. I suggest you check out bug #98745 for a > clear definition of "support". Bugs exist and should be fixed, but this is by no means an argument. > I can also show you Gentoo scripts used by ifplugd and netplug with init-ng > support in the tree right now. I guess that means that init-ng has some > level of support right? There will be always someone who goes ahead. Fact is that every dev who maintains a package installing an init script is expecteted to do so for baselayout, but is free to say no, when someone requests an initng one, as long as it isn't the Gentoo default. Carsten pgpJ1JcWmUR3g.pgp Description: PGP signature
Re: [gentoo-dev] cmake.eclass
Don't repeat a failure of the past. Do NEED_CMAKE x.y inherit foo ... instead this ugly toplevel function call. Carsten pgpkzcuaeL675.pgp Description: PGP signature
Re: [gentoo-dev] cmake.eclass
On Thursday 25 May 2006 16:37, Diego 'Flameeyes' Pettenò wrote: > Probably he meant > > NEED_CMAKE="x.y" Exactly. Sorry for the typo. Carsten pgp0EvhAdBnkq.pgp Description: PGP signature
