Re: [gentoo-dev] g15 and freevo up for grabs
On Mon, Jan 18, 2010 at 10:56 AM, Robert Buchholz wrote: > Hello, > > I want to drop maintenance for some of the packages that I have acquired > over the years. Some of them are still co-maintained, some are now > unmaintained. > > === Freevo === > > Freevo is split up in different Python components. They are all > maintained by a herd, but a dedicated maintainer is needed. > > media-tv/freevo # media-tv herd > Should be worth noting that no one from media-tv herd actually uses freevo or has an interest in it. You've got 2 MythTV guys and 2 vdr guys in the herd and that's it. Unless someone steps up this package should be marked maintainer-needed. -- Doug Goldstein
Re: [gentoo-dev] g15 and freevo up for grabs
On Mon, Jan 18, 2010 at 10:53:53PM +, Tony Chainsaw Vroon wrote: > On Mon, 2010-01-18 at 20:29 +, Robin H. Johnson wrote: > > I use the above, and will take them. > > Please do feel free to take g15daemon & friends as well, I've not been > able to provide them with the attention they deserve. > > > > media-plugins/audacious-g15-spectrum > I'd rather just get this upstream in Audacious and have the ebuild > disappear. Trade you this for your other g15 packages. That just leaves app-misc/g15mpd for somebody else. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [rfc] layman storage location (again)
On Monday 18 January 2010 19:05:23 Sebastian Pipping wrote: > /var/empty <-- net-misc/openssh this isnt exactly openssh specific. a few other packages use it as well for their users because it's guaranteed to be empty. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman storage location (again)
On 01/18/10 01:38, Sebastian Pipping wrote: > On 01/17/10 21:31, Thilo Bangert wrote: >> /var/layman i dislike due to this sentence in the FHS: >> >>"Applications must generally not add directories to the top level of >> /var. Such directories should only be added if they have some system-wide >> implication[...]" > > [..] > > current ranking through my eyes: > > 1) /var/layman con: adds folder to /var, maybe should not > 2) /var/db/laymancon: you tell me > 3) /var/lib/layman con: not really /var/lib-style data let me put the thoughts we collected so far to a decision. looking at /var shows, that not many application really dared to have a dedicated folder in /var directly: # find /var -maxdepth 1 -type d /var /var/tmp /var/lost+found /var/www /var/cache /var/spool /var/run /var/lock /var/db /var/gdm<-- gnome-base/gdm /var/lib /var/empty <-- net-misc/openssh /var/log /var/state after re-considering the requirements for /var/lib/layman the data in there can be host-specific (and therefore is not host-independent in general). i think it fits _well enough_ and to my impression it has less potential of turning out wrong than non-FHS /var/db: so /var/lib/layman is the new default. expect related commits to layman soon. sebastian
[gentoo-dev] Re: LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
Le 17/01/2010 12:26, Tomáš Chvátal a écrit : > Howdy guys, > please review the attached file and suggest updates to in. > I was asked for this thing going stable due to its being dependency of > new nvidia-drivers. > > Also this thing is probably blocker for the bug on eselect-opengl i just > opened: > http://bugs.gentoo.org/show_bug.cgi?id=301271 I'm not a big fan of the wording but it's something we refine, the general idea is fine though. I'll try to come up with something soon. If not, it can still be posted as-is, it gets the point across. Cheers, Rémi
Re: [gentoo-dev] Re: [rfc] layman storage location (again)
On 01/16/10 19:52, Peter Hjalmarsson wrote: > That is for the overlays, yeah? > But hov about the cache_*.xml files? > > I think what he meant was that should layman really only has one > directory? One for cache (downloaded/downloadable lists of overlays? > in /var/cache/layman/?), one for the make.conf and overlay.xml > (/etc/layman/?) and maybe one more directory for the overlays > (/var/lib/layman/?). > > That make.conf/overlay.xml may not go as cache, nor do the overlays > themselves, but as I said, should really it all be in the same > directory? yes, cache_*.xml are a bit different. Would you benefit from a move of these files to /var/chache/layman? Sebastian
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On 01/18/2010 10:07 AM, Ulrich Mueller wrote: >> On Sun, 17 Jan 2010, Petteri Räty wrote: > >> With GLEP 42 and proper logging of e* messages I think we shouldn't >> annoy users any more with ebeep or epause > > Agreed. > >> so attached is a patch only defines these functions for EAPIs 0, 1 >> and 2. Anyone have a reason to keep these around for EAPI 3? > > We wouldn't gain much by this, because we still have to go through all > ebuilds using ebeep and epause and change them to EAPI 3. > This would force people to upgrade when migrating to EAPI 3. > This would be at least the same amount of work as removing the ebeep > and epause calls from all ebuilds. Why don't we do this instead and > leave the eclass as it is? > This would make sure no-one uses these even in overlays. > There are already enough differences between EAPIs for devs to learn, > and IMHO we shouldn't introduce additional complications such as EAPI > dependent eclass behaviour (except where necessary, e.g. src_prepare). > Yes but as people shouldn't have the need for these there's not that much to learn here. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On 01/18/2010 03:02 PM, Tiziano Müller wrote: > The proper replacement for such interactive notifications when called in > pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4. > Thus I'd keep them around until then. > > Cheers, > Tiziano > ebeep or epause don't make your ebuild interactive. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] g15 and freevo up for grabs
On Mon, 2010-01-18 at 20:29 +, Robin H. Johnson wrote: > I use the above, and will take them. Please do feel free to take g15daemon & friends as well, I've not been able to provide them with the attention they deserve. > > media-plugins/audacious-g15-spectrum I'd rather just get this upstream in Audacious and have the ebuild disappear. Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] g15 and freevo up for grabs
On Mon, Jan 18, 2010 at 05:56:08PM +0100, Robert Buchholz wrote: > These packages are now without a maintainer: > > app-misc/g15macro > app-misc/g15message > dev-libs/libg15render > app-misc/g15stats # already maintainer-needed I use the above, and will take them. > media-plugins/audacious-g15-spectrum Maybe, if nobody else comes forwards. > app-misc/g15mpd no. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
The proper replacement for such interactive notifications when called in pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4. Thus I'd keep them around until then. Cheers, Tiziano Am Sonntag, den 17.01.2010, 22:38 +0200 schrieb Petteri Räty: > With GLEP 42 and proper logging of e* messages I think we shouldn't > annoy users any more with ebeep or epause so attached is a patch only > defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to > keep these around for EAPI 3? If not I will apply the attached patch. > > Regards, > Petteri -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
[gentoo-dev] g15 and freevo up for grabs
Hello, I want to drop maintenance for some of the packages that I have acquired over the years. Some of them are still co-maintained, some are now unmaintained. === Freevo === Freevo is split up in different Python components. They are all maintained by a herd, but a dedicated maintainer is needed. media-tv/freevo# media-tv herd dev-python/kaa-base# python herd dev-python/kaa-display # python herd dev-python/kaa-imlib2 # python herd dev-python/kaa-metadata# python herd dev-python/pynotifier # python herd == G15 tools === These packages are now without a maintainer: app-misc/g15macro app-misc/g15message dev-libs/libg15render media-plugins/audacious-g15-spectrum app-misc/g15mpd app-misc/g15stats # already maintainer-needed These are maintained by Chainsaw: app-misc/g15composer app-misc/g15daemon dev-libs/libg15 Most g15 tools are part of the LCD herd. Since that is only actively myself, it does not help. I will replace the herd association in four weeks if no new maintainer steps up or a new "g15" herd is formed. Otherwise the lack of maintenance is just hidden. Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
2010/1/18 Brian Harring : > Propose something, or shut up frankly. I propose we don't do anything until someone comes up with a decent cache proposal. > If all you're going to contribute is "it's half baked" claims, you're > wasting folks time. You've had a couple of months of time to > counterpropose something- back it up with a proposal or be silent > please. Doing nothing is better than doing something useless. > As is, quite a few folk see how experimental vdb2/vdb1 synchronization > can be done w/ this timestamp- your claims thus far that it won't work > seem to boil down to "but not everyone will update the timestamp". Er, no. It comes down to VDB2 implementing things that VDB1 doesn't support, such as having multiple installed slots of the same cat/pkg-ver, thus making it impossible to have both VDB1 and VDB2 at the same time. I have never argued against this proposal because "not everyone will update the timestamp". That's an argument you've made up and attributed to me. > Which gets right back to why I'm elevating this to the council to > *force* PMS to include this, thus force the holdout (paludis) to > update the timestamp thus invalidating your cyclical claim. PMS doesn't mention VDB at all. You're barking up the wrong tree. If you want me to include it in Paludis, all you have to do is come up with a proposal that does everything we need, rather than a proposal that can't legally be used for anything at all. > What I won't do is sit around and listen to you whinge about the sky > falling or that I/others are being idiots via not going > the route *you* want and standardizing caches across all the managers- > as I said, you want that functionality *you* propose it. I propose that rather than implementing a half-baked cache that isn't usable for anything, we do nothing until someone does come up with a full, unified cache proposal, where the validity of caches after operations is well defined. > It's not how things should be done, but it's about the only way to get > something done when you dig in and go cyclical. Cyclical on what? Explain where there is a cycle anywhere. You keep claiming I "go cyclical", but never point out any actual cycles. It's what you fall back on when you don't have an argument. > Wish it weren't that way, but I've more interest in progress then playing >games w/ > folk looking to be poisonous. And again, the whole "poisonous" thing. It's the last resort of those who are themselves the poison. How is wanting to do nothing until something can be done properly, rather than doing something that doesn't solve anything, poisonous? > Seriously, if you can't even be bothered to spell out your claims in > full or layout a counter proposal, instead spending your time > screaming "nyah nyah it won't work!" as you did for prefix, I'm not > having it. Uh, I already did, several times, and you ignored me, snipped them out and said I was "going cyclical". I'll also point out that I raised a long list of things that were wrong with Prefix way back when it all started, and over the past few months everyone has finally realised that that list was full of legitimate concerns that are just now being addressed. Is it going to take you five years to see how I'm right here too? And how much more damage are you going to do to Gentoo before you admit that, as with Prefix, I've thought this through properly and you're just rushing along with the first thing that popped into your head? So, for you to ignore yet again: * The proposal does not define exactly what the validity of a cache is. You are sort of implicitly assuming that the validity of a cache is a function exclusively of "the VDB not being modified", for some undefined value of "not being modified", but nowhere are you stating concretely what the rules are. * You are addressing *only* VDB validity, rather than doing validity of all repositories at the same time. * There is no granularity to the proposal. There is simply an ill-defined "modified" rule, with no way for a package manager to know what was modified or by whom. * You aren't doing anything to fix the zillions of different caches that package managers have to use. > There are better uses of folks time frankly, and users deserve > functionality over daft pissing matches. Then give them a functional, shared cache, not a cache that can't legally be used for anything. -- Ciaran McCreesh
[gentoo-dev] Re: Re: [rfc] layman storage location (again)
mån 2010-01-18 klockan 12:40 +0100 skrev Michael Haubenwallner:
> Alex Alexander wrote:
> > On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> >> I sometimes think the main problem is the tree itself. Portage really
> >> should had a directory of its own, but maybe with anoher structure,
> >> like /var/portage, /var/portage/tree (the current
> >> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
> >> itself), /var/portage/overlays/layman or /var/portage/layman.
> >> I of course realize that change the structure of the whole portdir would
> >> had inresting complications, so take this comment just as serious as you
> >> like.
>
> > /var/portage/
> > /var/portage/tree
> > /var/portage/layman
> > /var/portage/overlays (non-layman managed, layman could also be in here)
> > /var/portage/distfiles
> > /var/portage/packages
>
> Not that I really care, but are these "portage-only" and we might need
> /var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?
>
> /haubi/
I think "gentoo" is too non-specific. "portage" is more or less a good
name for everything with regards to the package management in gentoo.
That there is a name collision between that and the default
implementation of a package manager I see just as an coincidence.
Just like Gentoo both can refer to a distribution and a file-browser.
Or RPM is both a file-format and a tool to handle said file format.
Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
On Sun, Jan 17, 2010 at 11:09:07AM +, Ciaran McCreesh wrote: > 2010/1/17 Christian Faulhammer : > > Ciaran McCreesh : > > As much as you love to have the new and shiny VDB2, it is far off. > > Prototyping and drafting implementations would be great to have some > > base where we can discuss on (in a civil manner). So having this > > timestamp would be a good way to prepare a sane migration path. > > No, it wouldn't. Brian's proposal a) would be of no use whatsoever for > VDB2 migration, and b) would not be used by VDB2. Having a *decent* > cache validation mechanism is a good idea; having a half-baked one is > a waste of time. Propose something, or shut up frankly. If all you're going to contribute is "it's half baked" claims, you're wasting folks time. You've had a couple of months of time to counterpropose something- back it up with a proposal or be silent please. As is, quite a few folk see how experimental vdb2/vdb1 synchronization can be done w/ this timestamp- your claims thus far that it won't work seem to boil down to "but not everyone will update the timestamp". Which gets right back to why I'm elevating this to the council to *force* PMS to include this, thus force the holdout (paludis) to update the timestamp thus invalidating your cyclical claim. Either way, you find issues w/ the proposal you're more then free to propose something else- hell, I'll even listen if it's sane. What I won't do is sit around and listen to you whinge about the sky falling or that I/others are being idiots via not going the route *you* want and standardizing caches across all the managers- as I said, you want that functionality *you* propose it. About the only thing paludis shares w/ portage/pkgcore is a potential installed-pkgs-cache of pkg names; this isn't incredibly useful frankly (it's nice for cold cache searches but that's it). The cache usage between portage/pkgcore vs paludis differs a fair bit, as such trying to define an LCD vdb cache is pointless. Further it's not what I'm after and you've already opposed adding caches to vdb1 w/in the ticket- you want something beyond this, then go nuts. Either way, that's pretty much the bar I'm sitting for continuing discussion of this w/ you- either it's going to be productive w/ specific claims (no more of this vague handwaving bullshit) and moving towards accomplishing something or I'm just going to continue ignoring your disruptive behaviour, instead getting majority PMS consensus and then pushing it up to the council bypassing your shenanigans. It's not how things should be done, but it's about the only way to get something done when you dig in and go cyclical. Wish it weren't that way, but I've more interest in progress then playing games w/ folk looking to be poisonous. Seriously, if you can't even be bothered to spell out your claims in full or layout a counter proposal, instead spending your time screaming "nyah nyah it won't work!" as you did for prefix, I'm not having it. There are better uses of folks time frankly, and users deserve functionality over daft pissing matches. Be productive and constructive, or be ignored pretty much. ~harring pgpTniK4TKPAj.pgp Description: PGP signature
[gentoo-dev] new USE_EXPAND variable: XTABLES_ADDONS_MODULES
Hi. I'm going to add xtable-addons package to the tree. This is patch-o-matic replacement which allows to extend iptables without touching iptables source itself. Currently package contains 24 modules which I'd like to have USE configurable with USE_EXPAND'ed variable: XTABLES_ADDONS_MODULES Current ebuild is located here: http://overlays.gentoo.org/dev/pva/browser/net-firewall/xtables-addons If there will no objections I'll add this package to the tree within next few days. -- Peter.
Re: [gentoo-dev] Re: [rfc] layman storage location (again)
Alex Alexander wrote:
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
>> I sometimes think the main problem is the tree itself. Portage really
>> should had a directory of its own, but maybe with anoher structure,
>> like /var/portage, /var/portage/tree (the current
>> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
>> itself), /var/portage/overlays/layman or /var/portage/layman.
>> I of course realize that change the structure of the whole portdir would
>> had inresting complications, so take this comment just as serious as you
>> like.
> /var/portage/
> /var/portage/tree
> /var/portage/layman
> /var/portage/overlays (non-layman managed, layman could also be in here)
> /var/portage/distfiles
> /var/portage/packages
Not that I really care, but are these "portage-only" and we might need
/var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Re: [rfc] layman storage location (again)
Alex Alexander dixit (2010-01-18, 11:07): > On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote: > > I sometimes think the main problem is the tree itself. Portage really > > should had a directory of its own, but maybe with anoher structure, > > like /var/portage, /var/portage/tree (the current > > PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree > > itself), /var/portage/overlays/layman or /var/portage/layman. > > I of course realize that change the structure of the whole portdir would > > had inresting complications, so take this comment just as serious as you > > like. > > > > But overlays really was an afterthought? > > I like this suggestion, it certainly makes the whole folder structure > cleaner. If we're going to fix stuff, lets do it properly once and for > all. > > Some compatibility code that checks and uses the old default locations > while printing out warnings would help existing users with the > transition without breaking current systems. Users with custom PORTDIR > and friends could be notified through a news item. > > /var/portage/ > /var/portage/tree > /var/portage/layman > /var/portage/overlays (non-layman managed, layman could also be in here) > /var/portage/distfiles > /var/portage/packages > > or %s/var/usr/ Very much +1. -- [a] pgpqiAFGepd8h.pgp Description: PGP signature
Re: [gentoo-dev] Re: [rfc] layman storage location (again)
On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote: > I sometimes think the main problem is the tree itself. Portage really > should had a directory of its own, but maybe with anoher structure, > like /var/portage, /var/portage/tree (the current > PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree > itself), /var/portage/overlays/layman or /var/portage/layman. > I of course realize that change the structure of the whole portdir would > had inresting complications, so take this comment just as serious as you > like. > > But overlays really was an afterthought? I like this suggestion, it certainly makes the whole folder structure cleaner. If we're going to fix stuff, lets do it properly once and for all. Some compatibility code that checks and uses the old default locations while printing out warnings would help existing users with the transition without breaking current systems. Users with custom PORTDIR and friends could be notified through a news item. /var/portage/ /var/portage/tree /var/portage/layman /var/portage/overlays (non-layman managed, layman could also be in here) /var/portage/distfiles /var/portage/packages or %s/var/usr/ -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpC37DfrQPPw.pgp Description: PGP signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
> On Sun, 17 Jan 2010, Petteri Räty wrote: > With GLEP 42 and proper logging of e* messages I think we shouldn't > annoy users any more with ebeep or epause Agreed. > so attached is a patch only defines these functions for EAPIs 0, 1 > and 2. Anyone have a reason to keep these around for EAPI 3? We wouldn't gain much by this, because we still have to go through all ebuilds using ebeep and epause and change them to EAPI 3. This would be at least the same amount of work as removing the ebeep and epause calls from all ebuilds. Why don't we do this instead and leave the eclass as it is? There are already enough differences between EAPIs for devs to learn, and IMHO we shouldn't introduce additional complications such as EAPI dependent eclass behaviour (except where necessary, e.g. src_prepare). Ulrich
[gentoo-dev] Re: [rfc] layman storage location (again)
mån 2010-01-18 klockan 06:27 +0100 skrev Ulrich Mueller: > > On Mon, 18 Jan 2010, Sebastian Pipping wrote: > > > isn't a package tree somehow having "system-wide implications"? > > i'm not really sure about /var/db - doesn't seem to be in FHS. > > is a package tree a database? > > This depends on your definition of "database". At least some parts of > the tree (like the files/ dirs) at not very database-like. > > > current ranking through my eyes: > > > 1) /var/layman con: adds folder to /var, maybe should not > > 2) /var/db/laymancon: you tell me > > 3) /var/lib/layman con: not really /var/lib-style data > > I still think that it should be close to the portage tree, therefore > in /usr. But if you go for /var then take /var/layman. > > Ulrich > > I sometimes think the main problem is the tree itself. Portage really should had a directory of its own, but maybe with anoher structure, like /var/portage, /var/portage/tree (the current PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree itself), /var/portage/overlays/layman or /var/portage/layman. I of course realize that change the structure of the whole portdir would had inresting complications, so take this comment just as serious as you like. But overlays really was an afterthought?
