Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, 2005-11-26 at 19:48 -0500, Dan Meltzer wrote:
> On 11/26/05, Petteri Räty <[EMAIL PROTECTED]> wrote:
> > Ned Ludd wrote:
> > > Good afternoon,
> > >
> > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF
> > > executables by default in order to aid in better debugging by or do we
> > > want to only emit it when a FEATURE= is defined.
> > >
> > > Having a split debug pretty much obsoletes the need to add nostrip to
> > > your features in order to get debug info.
> > >
> > > Users wishing to not have debug info can simply add
> > > INSTALL_MASK="/usr/lib/debug ${INSTALL_MASK}" to make.conf or the
> > > environment unless we make it FEATURE based.
> > >
> > > I'm in favor of it enabled per default but I'd like to know what you
> > > think and why. (advantages of on/off by default etc..)
> > >
> >
> > How useful is this debug information with -fomit-frame-pointer? From
> > what I have read it makes debugging at least harder. I think most people
> > have -fomit-frame-pointer in their CFLAGS so it should not be enabled by
> > default if the debug info is not very useful any way.
>
> Well, only on x86 and other lacking arches...
Please note that gcc4 generates location lists by default (at least on
debug builds). This should allow for debugging on x86 with
-fomit-frame-pointers. Not sure how that works in relation to split ELF
debug files.
http://gnu.paradoxical.co.uk/software/gcc/gcc-4.0/changes.html
"Location lists are now generated by default when compiling with debug
info and optimization. Location lists provide more accurate debug info
about locations of variables and they allow debugging code compiled with
-fomit-frame-pointer."
Of course gcc4 isn't even ~x86 yet... ;)
--
With regards,
Mart Raudsepp
Project manager of wxMUD - http://wxmud.sourceforge.net/
Developer of wxWidgets - http://www.wxwidgets.org/
Gtk+ port maintainer of cpaf - http://cpaf.berlios.de/
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] beep-media-player removal: 04/03/2006
On Fri, 2006-02-24 at 08:22 +0100, Luca Barbato wrote: > George Prowse wrote: > > No, BPMx and Audacious are two different things > > > > bmpx is using large frameworks and have some deps that makes it in the > league of amarok totem and friends, call them large players > > bmp is in the league of zinf xmms audacious xmms2 (to a degree) and so > on, call them light players. > > Now, bmp is phased out, which is the gtk2 light player that could match > it's deps and features best? Ok, I guess I can have my try on explaining this once and for all :) BMP main authors started work on BMPx when BMP was around the 0.9.7 versions. BMP was not seeing any new features, and at one point was not maintained anymore, either. Audacious took BMP version 0.9.7.1 code, and worked on top of that, because BMP was unmaintained, and a couple other reasons that one can read from the Audacious FAQ. BMPx is pretty much a rewrite of the player, not having much inherited from XMMS code. So, if you want BMP, get Audacious - it is an advancement to the last released version of BMP. BMPx is a rewrite in progress for a more heavyweight player using lots of modern day tools and libraries (GTK+ 2.8+, cairo, gstreamer-0.10/xine probably SVG for skins soon if not already, etc). As a conclusion, if you used BMP for your lightweight player, you probably want audacious, if you don't want to try a more different thing. Hope this clears things up. -- With regards, Mart Raudsepp Project manager of wxMUD - http://wxmud.sourceforge.net/ Developer of wxWidgets- http://www.wxwidgets.org/ GTK+ port maintainer of OMGUI - http://www.omgui.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk2 use flag must die
On Sun, 2006-04-02 at 23:20 +0200, Jakub Moc wrote: > Mike Frysinger wrote: > > On Sunday 02 April 2006 15:34, Jakub Moc wrote: > >> Mike Frysinger wrote: > >>> and if there are no bugs filed ? this sort of stance is like the > >>> "lets remove packages from portage because upstream is dead" ... it > >>> benefits no one > >> No bugs filed? Well, just search the archives of this ML, and search > >> bugzilla for all those bugs about portage pulling in gtk2 when users had > >> USE="-gtk2" set, or for all bugs about the confusion what USE="gtk > >> -gtk2" or USE="-gtk gtk2" actually means... > > > > unrelated > > > > i'm talking about buts in the packages themselves, not end user confusion > > -mike > > Not really, since the retarded handling of those use flags combos in > ebuilds has been one of the key reasons to deprecate this. Also, this is > rather funny why xml2 use flags needs to be removed (it was you who > suggested that) - yet you resist to get rid of gtk2 use flag, which is > *way* more confusing (heck, look at that old wxGTK stuff, it's nasty and > confusing like hell). wxGTK-2.6* is fully supported upstream as linked against gtk1 and gtk2. However, that only is for things that exist already in case of gtk1 - we can't implement everything for gtk1 due to it not being as feature-rich as gtk2, and there is no point in implementing new features for gtk1 too, if it's easy with gtk2. The official support for gtk1 will end with the development cycle of 2.7.x, and won't be considered a fully supported port with the stable release of 2.8.x either. gtk1 code has been separated into a different port, duplicating some of the common gtk code. wxGTK1 (wxGTK built against GTK+-1.2) is essentially at the same level as wxMotif, wxX11 and other similar community driven ports who don't get the full manpower of developers. wxGTK2 however lives a happy life, free from the gtk1 burden. So, for wxGTK-2.8.x whenever it's out (a year?) there is no USE flag confusion - one port builds only against one major version of gtk2 (until gtk3 comes out, see Project Ridley). There should be a different package for those that wish the wxGTK1 port, if that package is needed at all. This is also the way that I would suggest handling wxGTK today (2.4 and 2.6). Have two different ebuilds, nuke that crazy no_wxgtk1 USE flag (and perhaps have a USE flag for building non-unicode version together with unicode version instead), use gtk instead of gtk2 flag and call it a day. Name em wxGTK and wxGTK1 for example, wxGTK1 perhaps even package.mask'ed - not as feature-rich, more bugs than the gtk2 version, etc. That's then my view and suggestion on how to approach the wxGTK issue in the way to get rid of the gtk2 USE flag. As for the only valid reason to keep it that I've heard, which was people wishing to prefer gtk1 when available for leaner resource usage, I'd personally suggest a gtk1 USE flag instead of gtk2, as that is rarely needed for normal people, and therefore no extra USE flag to set in the common case. I'd also suggest said people to disable anti-aliasing, use the default gtk2 theme, and use gtk2.6 for not that bigger resource usage. Delaying GNOME-2.14 for non-GNOME packages using gtk2 USE flag is mildly funny to me, too. Some two weeks have passed from 2.14 release, I would have expected it to be in x86 at least a week ago... but I'm living in a utopian land. -- With regards, Mart Raudsepp Project manager of wxMUD - http://wxmud.sourceforge.net/ Developer of wxWidgets- http://www.wxwidgets.org/ GTK+ port maintainer of OMGUI - http://www.omgui.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk2 use flag must die
On Mon, 2006-04-03 at 00:53 +0200, foser wrote: > On Mon, 2006-04-03 at 00:43 +0300, Mart Raudsepp wrote: > > Delaying GNOME-2.14 for non-GNOME packages using gtk2 USE flag is mildly > > funny to me, too. > > These two things are not related, 2.14 is not delayed whatsoever. > Jakub's call was just to get attention to the bugs and didn't originate > from the gnome team at all. > > > Some two weeks have passed from 2.14 release, I would have expected it > > to be in x86 at least a week ago... but I'm living in a utopian land. > > I don't know where these expectations come from, but we intend to iron > out the major known issues before we put stuff in ~arch . 2 weeks is > rather short for a volunteer team of 2-3 active people for something the > size of gnome. It is the same sort of nonsense we got with earlier > releases, where people expect things to be in stable the day upstream > declares it release day. People seem to expect the impossible, if you > come from Debian the Gentoo cycle seems perfect, but as soon people are > used to Gentoo the complaining starts anew. Get a grip and try to help > out in constructive ways. That's what I did, and that's exactly the major part of what you cut out from the reply quotes. It being a blocker is exactly what I read out from the mails, without having found a bug number, which I perhaps lost in all the long thread. It being a _personal_ expectation was written with the notion that it would be as such in an ideal world, with the context of it being possibly blocked due to a USE flag in mind, and it was explicitly expressed as such. I do not see why I am getting such unconstructive replies to my majorly constructive e-mails. Should I cease writing e-mails to gentoo-dev, at the rare times I have something constructive to say? Now someone that deals with wxGTK or poEdit feel free to put use the constructive things I said in the thread if it's a good suggestion, and I'll use my time on working on wxGTK instead and upgrading my ~x86 system that has GNOME-2.14 ;) Great work it being in ~x86 already, btw! -- Mart Raudsepp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Remove your modular X unmask
On Thu, 2006-04-20 at 07:05 -0700, Duncan wrote: > * Overlay was doing strange thing. In this case it was SDL overlay as > used by dosbox -- I tried rebuilding both libsdl and dosbox, but the > overlay still failed. Maybe related to the ABI change? SDL is being dumb with alpha visuals here. Need XLIB_SKIP_ARGB_VISUALS=1 env var for SDL apps if a composite manager is running. That's for SDL apps, giving that to everything would defeat the purpose of the composite manager quite a bit, I think. I'll have to pass commenting on anything else. Not sure about the other points and don't want to express guesses :) > It's impressive enough to have me eagerly awaiting the next rc. Good work > both here and upstream! Indeed! > Is the proposed schedule on the wiki at desktop.org still valid? I think ajax is getting out his whip soon, if he hasn't already :P The schedule should be pretty accurate on xorg.fd.org wiki. > A couple more RCs, and release in about a month > if all goes well? -- With regards, Mart Raudsepp Project manager of wxMUD - http://wxmud.sourceforge.net/ Developer of wxWidgets- http://www.wxwidgets.org/ GTK+ port maintainer of OMGUI - http://www.omgui.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/inkscape: ChangeLog inkscape-0.46-r1.ebuild
On P, 2008-03-16 at 23:29 +0100, Jeroen Roovers wrote:
> On Sun, 16 Mar 2008 21:51:12 +0100
> Dawid Węgliński <[EMAIL PROTECTED]> wrote:
>
> > Not if COPYING file is inside $DOCS and is installed in the loop.
>
> Doing something like this would work as well (and go equally unnoticed):
>
> local DOCS="foo bar COPYING baz"
> dodoc ${DOCS}
Well, this DOCS deal is coming through gnome2.eclass, and that's how all
of the packages using that eclass are supposed to install DOCS.
I suppose we could also add a QA warning into the eclass for COPYING?
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On N, 2008-05-01 at 05:30 +, Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. I would like to see the council to chat about two points, which are the following: 1) ChangeLog entries and when one is a must-have. This especially in relation to arch stabilizations. 2) The situation of keywording, stabilization or other bugs being completely ignored by the arm, sh and s390 teams. Can something be done to help in resolving this? Stabilizations do happen, but ignoring the bugs, and whenever they are felt to be done, and no un-CC-ing happens - usually with a 1 to 5 months of delay. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: language bindings as separate packages
On N, 2008-05-01 at 17:52 +0200, Santiago M. Mola wrote: > On Thu, May 1, 2008 at 5:09 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > > > Hi folks, > > > > while building yum, I again ran into trouble because one > > dependency has to be rebuilt with an specific useflag first > > (in this case it was libxml2 + python useflag). Actually, > > there are *lots* of these cases and (AFAIK) portage has no > > way for properly handling this - it's up to the individual > > ebuilds to check for those situations and artifically breaking > > the build. Of coure, breaking builds are ugly. > > The proper solution for these cases is implementing USE dependencies, > which would obsolete pkg_setup checks, and would provide portage with > info about which USE flags are needed for each dependency. This > feature is already implemented in other package managers (it's in > Paludis, maybe in pkgcore too?) and I think we all look forward its > inclusion in portage. I do not see that as a solution, but instead maybe only a fix for the fact that it's failing at some point in an emerge run instead of knowing beforehand. It still means a rebuild of the binding providing library, which involves unnecessary recompilation of the (typically) C or C++ library, which in some cases can be a huge time sink - that in the case that the library in question isn't at that time pulled in (in that case the package manager can enable it at first merge), but already installed without the bindings USE flags. So splitting packages is the perfect solution in my opinion, given unlimited maintainer time and such. In real world that might be too hard to maintain if upstream doesn't go along, but not in all cases (depends on how much time the maintainer has, how complex the build system is, etc). -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: lzma tarball usage
Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. I do realize one would remove build-time dependencies and the toolchain on an embedded system on deployment anyway, but this means gcc USE=nocxx USE flag is pretty much useless, while it would be nice to use it to ensure that nothing sneaks in during development that depends on the C++ standard library easily instead of finding things break later. This is a plea and also a request for comments on the matter of using .tar.lzma tarballs or not, and for what packages this is acceptable and for what not. I'd be happy if some other unpacker is used than lzma-utils - one that does not depend on libstdc++ - I'm sure it can be done, heck it's done in integrated form in some other projects in less than a couple kilobytes of code for the unpacking from a VFS. Meanwhile please consider using the upstream provided .tar.gz tarballs instead and not roll patchsets in .lzma just cause you can. coreutils and linux-headers come to my mind out of system packages right now. I'm sure more dragons await me. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
On K, 2008-05-07 at 15:34 +0200, Fabian Groffen wrote: > On 07-05-2008 16:23:12 +0300, Mart Raudsepp wrote: > > This is a plea and also a request for comments on the matter of > > using .tar.lzma tarballs or not, and for what packages this is > > acceptable and for what not. > > Just as a little background: > GNU chose to switch from bzip2 to lzma, for it produces smaller files > (less bandwith) and decompresses faster. > > They no longer provide the bzip2 versions of archives for newer releases > IIRC, so it's either tar.gz or tar.lzma. > > > I'd be happy if some other unpacker is used than lzma-utils - one that > > does not depend on libstdc++ - I'm sure it can be done, heck it's done > > in integrated form in some other projects in less than a couple > > kilobytes of code for the unpacking from a VFS. Meanwhile please > > consider using the upstream provided .tar.gz tarballs instead and not > > roll patchsets in .lzma just cause you can. > > See above why it might not just be "'cause you can". "and not roll patchsets in .lzma just cause you can". Cause you can applies to patchsets mostly. But using .tar.lzma instead of .tar.gz is also a "because they are available and therefore I can use it" neglecting the issues of a) on-disk format is supposedly not even finalized; high potential breakage of packages in existing ebuilds once lzma-utils gets updated b) The currently used decompressor package links to libstdc++ (and portage uses lzma, not lzmadec) unconditionally for most components c) Potential security issues; details needed, but for other reasons it makes sense to ban .tar.lzma's until a new C only rewritten lzma-utils comes along anyway d) too early adoption in critical system packages - once above issues are solved, higher levels should be using it first, before critical system packages (for example shows in the circular dep hell with m4) e) It has been suggested the support should have been added with new EAPI instead of local build deps (some of which are missing, for instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format net-tools doesn't have a dep in addition to using lzma for no good reason) Probably some more. Base-system, please stop using .tar.lzma for now, thank you. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
On N, 2008-05-08 at 21:09 +0200, Fabian Groffen wrote: > > e) It has been suggested the support should have been added with new > > EAPI instead of local build deps (some of which are missing, for > > instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format > > net-tools doesn't have a dep in addition to using lzma for no good > > reason) > > Chill, relax and cool down. Well, I said how it is. I don't see anything in it that indicates I am so upset and angry that I need to do these things. I did however loose hours of work time, but that's life. > Instead, just ask those who decided to > follow upstream why and if they have even thought about the issues you > brought up. This is what I am doing with this as well, in addition to the bug reports. But as this is widespread to at least 4-6 system packages, I brought it up here as well to ensure this is not something I have to fight against in overlays and time wastes continuously in the future. Oh and net-tools has not distributed anything in .tar.lzma, so this has nothing to do with following upstream in any shape or form in this case. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] Eclass for gnome-python* split
On L, 2008-05-24 at 10:18 +0300, Ali Polatel wrote:
> Arun Raghavan yazmış:
> > Greetings All,
>
> Hey there
>
> > I've been working on an ancient bug [1] requesting a split of the
> > gnome-python, gnome-python-extras, and gnome-python-desktop ebuilds.
>
> Good for you :P
>
> *snip*
> >
> > Feedback and comments (and even brickbats ;)) on the eclass are invited.
> >
>
> Attached is a patch for two minor issues with the eclass. First try to
> remove py-compile only if it exists. Second, python_mod_optimize is
> ROOT aware (since recently).
Does that mean that every python_mod_optimize user (ebuild) that used it
as was expected from python_mod_optimize is now broken for ROOT != "/"
by installing them into ${ROOT}/${ROOT}/ ?
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote: > On Fri, 30 May 2008 21:13:32 +0200 > Luca Barbato <[EMAIL PROTECTED]> wrote: > > Talk to the upstream about this, probably getting a satisfying > > solution isn't that difficult. > > The solution is to use --as-needed in the same way that -ffast-math is > used: only with applications specifically designed to support it. You mean everything but paludis? Doesn't your grand plan include supporting Prefix and Interix with PE binaries and so on? I know projects that need to work around static initialization not being reliable - they only happen to have done that for other reasons (such as Windows PE format, iirc) years before --as-needed was implemented for binutils. Standards is one thing - reality is something quite different. The reality is that everything designed to work everywhere is just mighty happy with --as-needed and lots of benefits to gain from it. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On R, 2008-05-30 at 22:37 +0100, Ciaran McCreesh wrote: > On Sat, 31 May 2008 00:31:22 +0300 > Mart Raudsepp <[EMAIL PROTECTED]> wrote: > > On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote: > > > On Fri, 30 May 2008 21:13:32 +0200 > > > Luca Barbato <[EMAIL PROTECTED]> wrote: > > > > Talk to the upstream about this, probably getting a satisfying > > > > solution isn't that difficult. > > > > > > The solution is to use --as-needed in the same way that -ffast-math > > > is used: only with applications specifically designed to support it. > > > > You mean everything but paludis? > > Paludis is fine with as-needed. But hey, don't let reality get in the > way of your pathetic attempts at turning everything into Paludis > bashing. It happens to be the only package that I know of that couldn't be fixed to work with --as-needed (fix for others being to actually state linking with a library whose symbols are directly used). I have not heard of anything else. > > Doesn't your grand plan include supporting Prefix and Interix with PE > > binaries and so on? > > I have no particular interest in supporting any platform that can't > ship a Standard-compliant C++ environment. That doesn't mean Gentoo progress, in maintainability of a running system through the ease of ABI breaks meaning magnitudes of less recompilations, should be inhibited. > > I know projects that need to work around static initialization not > > being reliable - they only happen to have done that for other reasons > > (such as Windows PE format, iirc) years before --as-needed was > > implemented for binutils. > > Standards is one thing - reality is something quite different. > > The reality is that everything designed to work everywhere is just > > mighty happy with --as-needed and lots of benefits to gain from it. > > And twenty years ago C++ had to work around linkers that only supported > eight character symbol names. Reality moves forward, except in > situations like these where people try to rice it backwards. Maybe you'd like to tell that to the authors of the platforms that don't support this extreme corner case, but are amongst the platforms that we do somewhat support in Gentoo? The story that matters here is, that a C++ corner case that does not work on 0.01% of packages with --as-needed and breaks on non-ELF platforms, should not cause good things for our users to be shot down. 99.9% packages in the tree work just great with --as-needed with many benefits, including ABI break pain reduction (and less importantly memory savings from dirty library private memory pages), so given that percentage the default should be what makes things better for users with exceptions for those tiny percentage of packages that fall into the corner case (that break on more exotic platforms anyway and arguably should be fixed). Portage developers - is there anything we should do to get --as-needed to make.conf.example and other places, beyond fixing the known bugs on the appropriate bug tracker? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On P, 2008-06-01 at 05:30 +, Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. I am still waiting on seeing any results or follow-ups on this: Can the council help fewer bugs get ignored by arm/sh/s390 teams? - The work happens, but Mart says it's not communicated to anyone and has no relationship to whether bugs are open. We need to understand the workflow of undermanned arch teams and see whether there's anything we can help improve. Possibly improving recuitment -- add a good, motivating staffing-needs entry. I still don't see any staffing needs entry or other methods to solve this beyond declaring them as dev profiles which doesn't help with the bugs, and I can't know if any effort has been underway for understanding the workflow. Without an update, it gives the impression nothing has been done, which I don't want to believe. I'd appreciate an update - not necessarily as part of the council agenda, but perhaps just per mail, with any discussions if any is necessary during the meeting. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
On N, 2008-06-05 at 17:34 +0200, Diego 'Flameeyes' Pettenò wrote: > "Łukasz Damentko" <[EMAIL PROTECTED]> writes: > > > Nominations for the Gentoo Council 2008/2009 are open now and will be > > open for the next two weeks (until 23:59 UTC, 18/06/2008). > > I wish to nominate Halcy0n, Cardoe and leio. Thanks, I accept. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Patching of Makefile.in and configure (eautoreconf calls)
Hello,
Recently a big bunch of autotools related bugs were filed, of which
quite a few are quite obvious bugs that need to be fixed, but there are
a few of the kind that I can't agree with without given technical proof
it's a real problem.
So one of those is the "changes both autotools source and result" kind,
as seen from
https://bugs.gentoo.org/showdependencytree.cgi?id=226305&maxdepth=1&hide_resolved=0
The short summary of most/all of those is that the ebuilds in question
are either patching or sed'ing not only Makefile.am and/or
configure.{in,ac}, but also Makefile.in and/or configure and it is
claimed that this is a "treatment [that] is usually reserved for a few
selected system packages that cannot have their autotool scripts
rebuilt.", with a vague claim that it _could_ cause
maintainermode-driven rebuild of the autotools results.
In most cases stopping the patching of Makefile.in and/or configure
involves removing that from the patch AND adding eautoreconf to the
ebuild.
The reason why I'm bringing this up is:
Do we really need to inflict the users with a long eautoreconf step,
when patching Makefile.in and configure alongisde Makefile.am and
configure.in is working just fine when done right, by my some years of
experience doing it once in a while where it's easy to provide a clean
patch for the autotools results?
Some reasoning from my side:
1) maintainer-mode driven rebuild is supposed to only happen if
a) the package defaults to maintainer mode in its configure.in; and
b) the autotools source is newer than the result, which can happen if
you _forget_ (as opposed to doing it, which the bugs are trying to
remove) to patch all results together with sources or you seriously
screw up the timestamps
2) eautoreconf means a considerable amount of extra time inflicted on
all _users_ of that package, without a clear technical reasoning why
that is really necessary
3) Other distributions happily provide a metric ton length of autotools
patches and it works just fine, albeit constrained to only package
maintainers in most cases
So I personally request to hold off with "fixing" these bugs without a
clear reasoning on the extra (every) Gentoo users resources taken, until
a technically valid reason is given, and I believe the burden of proof
should be on those that want the eautoreconf calls as to justify the
extra time and resource requirements involved.
You as the maintainer of an affected package are free to make your own
decision on this of course right now.
Though if you are hitting the maintainer mode rebuild ("missing --run"
in build.log without quotes or something), then it's a real bug and you
could probably just as well fix it by patching the Makefile.in or
configure that you forgot to patch when you patched Makefile.am or
configure.{in,ac}.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
Hello again, Over a year or two ago, it was communicated that it supposedly a policy that USE=static should only control if a package installs static libraries INSTEAD of shared libraries, and never to be used to control if static libraries are installed in _addition_ to shared ones or not. Packages were coerced to stop using USE=static for controlling that, and most of them ended up unconditionally installing both static and shared libraries. What's worse - they were told that if a package can provide both shared libraries and static libraries at once, it just MUST (or SHOULD) install them both instead of choosing to not ship the static libraries. End result that affects me: GNOME does not fit on LiveCD installation media anymore. So I'm proposing a USE=static-libs or similar to get out of this problem, and a lifting of the supposed (I wasn't around as a dev that long ago to know for sure) policy of having to install both instead of choosing to never install static libraries. I am quite sure that absolutely nothing whatsoever uses about 97% of the static GNOME libraries we are now installing as an end result. How can I be sure? Because everything worked just fine when static libraries weren't installed in the past thanks to that not happening from USE=static missing on most systems for years, and you'd have to be quite crazy if you required static version of desktop libraries with well established and followed ABI guarantees. Those that aren't absolutely sure that there is no use case for static libraries, could then use a USE=static-libs or similar to not unnecessarily install static libraries that are not going to ever be used. And LiveCD media could avoid all these static libraries, that it currently has to ship just because the packages by default install that cruft for no real technical reason (and it has to follow that due to GRPs). I would use USE=static-libs on packages like gtkmm, that have good reasons to provide a static version - it allows Gentoo users that would like to do commercial or universal C++ based development against Gentoo system packages, as it avoids feared libstdc++ ABI breaks (there's even a request for it in bugzilla). There are packages in the tree that are required to install static libraries, or something else in the system breaks. So INSTALL_MASK=*.a is not a solution in my eyes. Useful comments, thoughts, agreements? I have had some additional ideas for handling static libraries better at a package manager level, but those still need to be fleshed out and put into writing. Things like possibility to rebuild all packages that link to a static library that was now upgraded, so the higher level package could use a relinking to benefit from the bug fixes from the new library; optional ability to install only the type of library currently needed - shared or static, etc. Much of it goes to blue-sky ideas though with minimal benefit for normal desktop/server systems and potentially high maintenance effort, so I haven't put much effort into putting it into writing. But maybe someone interested wants to chat on IRC on the topic. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Installation of static libraries, USE=static-libs proposal
On T, 2008-07-01 at 11:33 +0200, Rémi Cardona wrote: > Duncan a écrit : > > Probably others than GNOME, too. > > Thus Mart's effort to bring it to gentoo-dev :) And for constructive discussing of it, including with releng and other teams. > > This is the ticklish bit, but there's still a way around it for users > > (such as those trying to fit GNOME on a liveCD) that need it. Useing > > portage's bashrc, setup a conditional that excepts packages that need > > static libs and set INSTALL_MASK='*.a' for everything else. > > No, it was pointed out that this cannot be done for LiveCD material, as > the packages would have a different content as a regular install. So > this is just out of the question. > > For those wondering : "find /usr/lib64 -name "*.a" | xargs du -ch" will > tell you how much disk space is wasted by static libraries. > > On my Gnome box, this is 246M. I know we won't be able to bring this to > 0, but having it closer to 10~20M is a very worthy goal imho. In addition I'm looking for a clean solution, not every Gentoo user having to have a INSTALL_MASK set with a few exceptions that they don't know; and if they don't know what are the exceptions, they'll have trivial problems like bash not working, iirc. Btw, just to be clear, I'm not claiming this is the sole reason GNOME doesn't fit on LiveCD's anymore, but it is a big contributor for that. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected
On L, 2008-07-26 at 03:39 +0300, Nikos Chantziaras wrote: > Fortunately, the majority of ebuilds/packages are honoring LDFLAGS. Of > course it's kinda difficult to always check if a package honors it or > not. But it's a good idea to file a bug for every package that does not > honor it (without a reason). I guess as many are using it to pass --hash-style=gnu in addition to other things[1], an easy way to find out which don't honor it out of your installed packages is to scan for ELF files that contain the .hash ELF section in addition to .gnu.hash ELF section. Something through scanelf -q -k .hash outputting anything or not could be used to determine if the section exists or not. I'm sure there are better ways. This doesn't work for packages that don't ship ELF files, but ld works on ELF files, so those that don't use ELF files shouldn't really care if LDFLAGS is honored or not... Maybe this gives some ideas to someone to write a proper QA script, or point us all to an already existing almighty script or tool that does just that. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected
On P, 2008-07-27 at 18:20 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> 2008-07-26 02:56:24 Mart Raudsepp napisał(a):
> > On L, 2008-07-26 at 03:39 +0300, Nikos Chantziaras wrote:
> > > Fortunately, the majority of ebuilds/packages are honoring LDFLAGS. Of
> > > course it's kinda difficult to always check if a package honors it or
> > > not. But it's a good idea to file a bug for every package that does not
> > > honor it (without a reason).
> >
> > I guess as many are using it to pass --hash-style=gnu in addition to
> > other things[1], an easy way to find out which don't honor it out of
> > your installed packages is to scan for ELF files that contain the .hash
> > ELF section in addition to .gnu.hash ELF section.
>
> The QA check which verifies that LDFLAGS are respected is now in Portage
> trunk and will be released in 2.2_rc4. This check is enabled when LDFLAGS
> contain "--hash-style=gnu" and "${PN}" != *-bin. Other binary packages
> (e.g. net-www/netscape-flash) should set the QA_DT_HASH array/variable.
>
> http://sources.gentoo.org/viewcvs.py/portage?rev=11205&view=rev
You rock for actually putting this stuff to code!
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On T, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote: > The primary use-case that has been publicly stated before was for > users > to be able to identify to developers what version of a given ebuild they > were using. > > Q: How much have you utilized the primary use case? Never. There has never been a reason to ask this from the user for me. If the ebuild in question has changed without changing name, it has always been obvious if it matters, and if the user has an old version if it does (as then what the bug is about is what was just recently fixed without revbump, typically build fixes). > Q: Are there any other use-cases you have and actively use? No. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Questions about stabilization requests
On L, 2008-09-06 at 00:33 +, Duncan wrote: > Christian Faulhammer <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, 05 Sep > 2008 21:47:59 +0200: > > >> 2) Should I file stabilization requests on software that works mostly > >> as in everything that I use it for normally but I can force it to fail > >> if I feed it some really strange input or contrive a specific set of > >> options that will cause invalid or incorrect output. > > > > Try to sort it out with upstream (original package author). Depends > > on the problem, if an older stable version shows the same behavior it > > should be no show-stopper. > > Also, consider merging with FEATURES=test and the test USE flag if > appropriate as well. Setting test USE flag is never appropriate as far as I know. FEATURES=test enables the USE flag on its own, and it should never be enabled or disabled in a users USE settings in /etc/make.conf or any other place. FEATURES=test is the thing that can be modified for this. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, 2008-10-02 at 22:24 +0200, Jeroen Roovers wrote: > # Gen 2 Developer <[EMAIL PROTECTED]> (`date`) > # Masked for testing. > >=rofl-cat/omgpkg-ver > > > Please people, > > >if you want to get something tested, then don't mask it. Stuff with high impact better be masked for initial testing, such as new versions of gcc, glibc and other parts of toolchain and build system, and other similar things affecting other packages than itself. ~arch is in my eyes something that updates shouldn't break vastly - a stable candidate. Of course when that initial testing is done with helping users, the reason could be modified to tell things broke and what the tracking bug is, or unmasked if it works fine with other packages. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
On P, 2008-10-05 at 20:34 +0200, Thomas Sachau wrote:
> Rémi Cardona schrieb:
> > Thomas Sachau a écrit :
> >> Why not do both (rebuild and install) with the doc useflag and none of
> >> both, if it is not set? Imho
> >> the doc flag is for control of installation for (additional) docs, the
> >> way it is used for gtk-doc is
> >> surely confusing.
> >>
> >
> > Building gtk-doc documentation pulls in a lot of deps. Installing it
> > requires only some disk-space. For a full Gnome system, I only have 96M
> > of docs.
> >
> > As for rebuilding docs, one of the advantage is to correctly crosslink
> > docs for tools such as dev-util/devhelp.
> >
> > If anyone is _that_ short on diskspace, we'll gladly take patches :)
> >
> > Cheers
> >
> > Rémi
> >
> >
>
> Did i say something about disk space? I say, you are using the doc use flag
> in a way that is not
> expected.
The doc USE flag is typically used when it means additional
dependencies, noticeable build time increase or extra downloads. For all
the GNOME packages the former two apply for USE=doc because it requires
a hefty dependency list for doc generation and a long documentation
regeneration time.
The tradition is to always install documentation that is already
available. That is what we do. Those that want extra benefits of waiting
on the doc building to get better doc hyperlinking and such, can do so
with USE=doc, which is expected to take a longer time to build.
> The global use flag says, it installs additional documentation. But your doc
> use flag does
> not install anything additional, but instead rebuilds those docs. There is
> nothing wrong with
> rebuilding them on use=doc, but imho you should also only install those docs
> with use=doc.
Docs are installed always when they do not mean extra downloads, build
time or dependencies. They don't if they are kept in the form they are
in the tarballs already, so we already install them, just like many
other packages do (including all the dodoc's)
> The patch could be as simple as adding >use doc || rm -rf
> "${D}"usr/share/gtk-doc< at the end of
> src_install()-function in gnome2.eclass, that should be simple enough to
> apply without a patch. :)
Sorry, I'm not convinced there is anything to patch or change here.
> Btw: e.g. x11-libs/gtk+ has no doc use flag, does not rebuild those docs, but
> does also install
> those docs as reported in bug 239524.
It does have a doc USE flag, and it controls the same thing it does for
everything else gtk-doc - passing --disable-gtk-doc or --enable-gtk-doc
which acts like described above for regeneration.
Making USE=doc control both installation and regeneration is out of the
question. The benefits of rebuilding are not that big that everyone
would want to do that, especially with recent versions of gtk-doc, but
some do want it. Use INSTALL_MASK if you don't want developer API docs
is the current stance.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
On E, 2008-10-06 at 03:46 +0300, Petteri Räty wrote: > With USE="doc" the GNOME packages behave like what you expect but it's > the USE="-doc" case that's in question here. With USE="-doc" you don't > get any use flags installed normally and if it's in the tarball and is > always installed then there is no doc in IUSE either. Global use flags > should behave about the same for both on and off cases. So you propose we would always install the documentation, but have a new global USE flag (remember, we are talking about over a hundred of packages here - everything that inherits gnome2.eclass) with a yet to be determined name to control the re-generation? However, with the advancements of the gtk-doc system, there _might_ not be any more benefits in rebuilding the documentation, so I've had the intention to check that out and perhaps propose removing the doc USE flag completely and never regenerate it if it's true that it has no point. But checking this has been quite a low priority, and given that we need to get GNOME-2.24 out there for the users, it remains so during this month, at least for me. I would propose that we (the GNOME team) investigates the benefits (or lack thereof these days) of the regeneration in the first part of November, and if we don't, you get to remind us and we take care of it as the hurry with a new major GNOME version, that users are awaiting (including squashing all bugs needed before stabilization), will be over then. Taking the renaming of the USE flag approach as a start would also mean touching many GNOME packages (build-depends on gtk-doc if eautoreconf is involved), and I'd rather not risk that at the moment. It would also heavily disrupts the moving of the new version ebuilds from overlay to portage tree. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 is brokened :(
On Fri, 2008-10-10 at 00:55 +0100, Ciaran McCreesh wrote: > On Thu, 9 Oct 2008 16:38:56 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > Of that 308, number of ebuilds that either inherit java-utils (which > > adds src_prepare), define their own src_prepare, or even *match* > > default via grepping in the ebuild is 20. > > Of those, and those in overlays, and those that are going to be > committed over the next few weeks, how many use src_prepare to apply > security related patches? A round zero. Security patches are going stable soon after entering portage tree, and EAPI=2 ebuilds can not go stable yet, as there is no package manager supporting EAPI=2 that is going to be stable in the next week or two (so maintainers make sure they don't use EAPI=2 for security fix revisions). And if the bug is there and properly filed to the appropriate bugzilla, they wouldn't go stable before that bug is fixed (which I read are already fixed). I can not understand why this is dragged on. It was a bug, it is fixed. The sky is not falling and EAPI-2 is not broken - there was a bug in the implementation that is fixed. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
On Sun, 2008-07-20 at 15:40 +0400, Peter Volkov wrote:
> В Втр, 01/07/2008 в 05:05 +0300, Mart Raudsepp пишет:
> > Over a year or two ago, it was communicated that it supposedly a policy
> > that USE=static
>
> Well, I don't have web-reference at hand now, but there was a thread in
> gentoo-dev with the subject: "Say no to static libraries!". Summarizing
> some ideas from there:
>
> 1. Some packages will break if you build their deps with USE=static.
> This can be fixed when we start to use USE-deps in the tree.
>
> 2. We already have mechanism to make what you want. Just drop
> EXTRA_ECONF="--disable-static" into your make.conf and to workaround
> problem stated in point 1 use
>
> EXTRA_ECONF="${EXTRA_ECONF/--disable-static}"
>
> in /etc/portage/env/cat/pkg. (For those who interested list of packages
> for which I have to filter --disable-static is in attachment).
I'm going to simply drop the remaining USE=static's where appropriate,
if upstreams choice is to disable static libraries, and we'll see even
later what to do about those that don't default to not building static
libraries. For now I stumbled on just gtk-engines.
That is, some GNOME packages make it their own business to override the
automake default of building both - they call AM_DISABLE_STATIC.
So for those I'll just drop any --{enable,disable}-static (as I notice)
and honor upstreams choice in not building static libraries. This also
means nothing uses or needs the static libraries because all GNOME
tinderboxes and jhbuild based development machines would scream in agony
if it broke anything.
> Well, I'm using EXTRA_ECONF for more then year now and I'd like to say
> that it's not perfect solution. Not all packages are autotools based and
> ignore --disable-static and now I have 103M of static libs on my
> desktop. So now I'm all for having static-libs USE flag. But please,
> don't do that on per-package base. Make an eclass for that. Think about
> not-autotools packages, and don't put it in the tree until we start
> using USE deps.
I know of absolutely no GNOME package that needs its static libraries
installed. Only exception is glib, but that is a lower level library,
not a GNOME one - there we explicitly enable it for syslog-ng possible
use primarily. And for glib I'm quite cool in enabling it always, as my
take on glib is that it's a standard C library that makes C actually
usable and powerful, just as libstdc++ makes C++ more powerful, and
should be universally available to all. Though an alternative would be
to install it in /lib, so that boot tools can use it and not need to
link statically - having syslog-ng in mind primarily.
> Thanks for reiterating this discussion. I wanted to return to it soon as
> seems that USE deps are really about to enter our life.
And now I'm reiterating it again the first time since 3 months.
> And BTW, seems that all gnome packages obey EXTRA_ECONF ;)
And probably G2CONF too, but we like to use that for ebuild use only -
we aren't sure we have G2CONF="${G2CONF} foo" everywhere, etc.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] kerberos USE flag
On Fri, 2008-10-31 at 15:50 -0600, Joe Peterson wrote: > Michael Hammer wrote: > > * Doug Goldstein <[EMAIL PROTECTED]> [081031 15:53]: > >> If no one opposes, I say we redact this USE flag asap. > > > > ++ > > I was also wondering why kerberos was on by default - I definitely > approve of nuking it. I'm believe the primary reason is for release LiveCD's. They ship with evolution-exchange, and that requires evolution/evolution-data-server to be built with USE=kerberos They don't do /etc/portage business, so it's a global USE flag to get things like GRP packages to work right. Regards, -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] kerberos USE flag
On Fri, 2008-10-31 at 19:22 -0500, Andrew Gaffney wrote: > Mart Raudsepp wrote: > > On Fri, 2008-10-31 at 15:50 -0600, Joe Peterson wrote: > >> Michael Hammer wrote: > >>> * Doug Goldstein <[EMAIL PROTECTED]> [081031 15:53]: > >>>> If no one opposes, I say we redact this USE flag asap. > >>> ++ > >> I was also wondering why kerberos was on by default - I definitely > >> approve of nuking it. > > > > I'm believe the primary reason is for release LiveCD's. > > They ship with evolution-exchange, and that requires > > evolution/evolution-data-server to be built with USE=kerberos > > They don't do /etc/portage business, so it's a global USE flag to get > > things like GRP packages to work right. > > If that's the case, then I say whack it from global USE and change it to an > IUSE > default (or whatever is in vogue these days) for eds. From GNOME teams perspective I don't believe that is a good idea. Users wanting exchange support aren't hardly the majority of evolution users. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Adding lxde-base category
On Sat, 2008-11-01 at 12:05 +0100, Ben de Groot wrote: > Hi, > > I would like to add a new category to the tree: lxde-base, to be used > for the LXDE desktop [1,2] packages, in correspondence to the categories > for the other desktop environments we have (gnome, kde, xfce). With the > help of a few users I have been developing ebuilds for these packages in > the lxde overlay [3], and I would like to move the ebuilds for the > release versions into the official tree now. (The overlay also contains > live svn ebuilds.) ++ Note that I will propose to the GNOME team to reorganize the GNOME categories to gnome-platform/, gnome-desktop/, gnome-dev/, gnome-bindings/ or similar setup once we have atomic commits to the portage tree (a la git) to not disrupt anything from all the moves. But I think with just 14 packages an lxde-base makes the most sense indeed, with upstream probably not having them categorized themselves like GNOME has. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote: > Removing Stable Ebuilds > > If an ebuild meets the time criteria above, and there are no technical issues > preventing stabilization, then the maintainer MAY choose to delete an older > version even if it is the most recent stable version for a particular arch. Even if that is a package that other packages depend on? Lets say I want to delete an ancient version of gtk+, but arch ABC has that as the only stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and break the whole stable tree of arch ABC, unkeyword hundreds of other packages, or I'm just allowed to remove it but should really apply a common sense as usual and you don't want to go into details in this document? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On P, 2008-11-09 at 18:34 +0200, Peter Alfredsen wrote:
> On Sunday 09 November 2008, Fabian Groffen wrote:
> > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > > + # If this is a non-ELF system, chances are good that the .la
> > > files will be needed. + if type -P scanelf &> /dev/null
> >
> > I think this is a not so cool way to check for an ELF system.
>
> Indeed, I think it's a horrid way. Please find a better one.
>
> > > + then
> > > + debug-print "Scanelf found, proceeding..."
> > > + ebegin "Removing useless .la files"
> > > + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> > > rm -f '{}' '+' + eend 0
> > > + else
> > > + debug-print "scanelf not found, this appears to be a non-ELF
> > > system." +debug-print "non-ELF systems are likely to need
> > > .la
> > > files." + debug-print ".la files not removed from ${TARGET}"
> >
> > rationale?
>
> "I've been told" that .la files are really only needed on non-ELF
> systems and with plugin systems that use dlopen. I actually have no way
> of knowing that the .la files are needed on those arches, but I had
> your archs in mind when doing the patch.
I heavily object to having any such function introduced or used or
equivalent .la removals conducted without a good rationale and
explanation of why this is the approach taken. I see no such explanation
anywhere, you are just blatantly removing .la files that the package
itself installs, with no good way to ensure they aren't actually needed
by libltdl and breaking revdep-rebuild heavily when used unwisely.
If such a function is introduced, I'm quite sure it will get used by
some maintainers in revbumps or version bumps, when the library soname
has not changed at all compared to the previous version. What that means
is that the user will get absolutely all packages suggested to
revdep-rebuild that directly OR _indirectly_ rdepend on the library in
question. Therefore to have any relatively safe way to add this, you can
only add the call when the library introduced ABI breaks. Some libraries
are backwards compatible forever, in effect you can't ever add
epunt_la_files to those without causing some serious one-time pain for
users. Therefore this is not a proper solution, and I don't see why this
should be used for just a small set of packages that do have an unstable
ABI while not having a solution for all the rest.
Additionally, I am quite unconvinced on the coverage of the removal or
non-removal of the files. Not removing it on all platforms (because you
can't) also doesn't solve the problem for those non-ELF platforms - you
still will get all the pain you are trying to solve here on those
platforms.
Also, this would be a local Gentoo specific hack to reduce pain on ELF
systems, while I'm sure there are upstream or better solutions available
that have not been explored. Here are two different ideas of mine for
libtool upstream work to perhaps solve this:
* Get libtool to not include indirectly linked libraries as dependencies
in the .la files if it is running on an ELF system (additionally I think
libtool should have a much better idea if a platform is ELF or not)
* Make libtool not install .la files on ELF platform if it doesn't see
libltdl used
These are just two different ideas, that might not work out, but one of
them might (they are mutually exclusive though).
Ideas like these should be investigated and pursued instead of distro
specific hacks, such as epunt_la_files.
I do however think that it would be a good idea to tweak revdep-rebuild
to not take indirect dependencies listed in .la files too seriously, and
mostly just go by DT_NEEDED entries in ELF files on ELF systems instead
of all of the listed ones in .la ones, as even if a solution for
upstream libtool is figured out, we'd still have old installed .la files
around that include indirect libraries.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On K, 2008-11-12 at 15:40 +0100, Peter Alfredsen wrote: > On Wednesday 12 November 2008, Mart Raudsepp wrote: > > > I heavily object to having any such function introduced or used or > > equivalent .la removals conducted without a good rationale and > > explanation of why this is the approach taken. I see no such > > explanation anywhere, you are just blatantly removing .la files that > > the package itself installs, with no good way to ensure they aren't > > actually needed by libltdl and breaking revdep-rebuild heavily when > > used unwisely. > > It's a utility function. I've done all I can to ensure it'll be used > wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). > But let me point out that in most leaf-packages, removing la files will > cause no pain, but will ensure that they do not have to be rebuilt if > a .la-listed dependency loses its .la file. Unless a system happens to have USE=static used for a few lower level indirect dependencies (and those very low level libraries having such an option is sometimes, albeit rarely, quite cool for embedded use cases). It just breaks then according to other subthreads, and you have no way to really check for that in your utility function. > > If such a function is introduced, I'm quite sure it will get used by > > some maintainers in revbumps or version bumps, when the library > > soname has not changed at all compared to the previous version. What > > that means is that the user will get absolutely all packages > > suggested to revdep-rebuild that directly OR _indirectly_ rdepend on > > the library in question. Therefore to have any relatively safe way to > > add this, you can only add the call when the library introduced ABI > > breaks. Some libraries are backwards compatible forever, in effect > > you can't ever add epunt_la_files to those without causing some > > serious one-time pain for users. Therefore this is not a proper > > solution, and I don't see why this should be used for just a small > > set of packages that do have an unstable ABI while not having a > > solution for all the rest. > > Because having la files will automagically provide the equivalent amount > of pain such as in http://bugs.gentoo.org/245889 . There is still no solution for things that do not break ABI, but get rebuilt with different USE flags, for example the USE=esd fiasco where to get rid of esound you had to remove USE=esd and rebuild many packages with revdep-rebuild for no reason other than libtool being stupid. This stupidity should be fixed, not delayed with workarounds to a small subset of cases. > We talked about this on #gentoo-dev the other day. 200 packages out of > 1000 on my system had to be rebuilt because of this. If libxcb didn't > use la files, that wouldn't have been necessary for the majority of > those. If the packages themselves didn't use la files, it wouldn't have > been necessary either. Or if libtool would be fixed to not cause that pain in the first place.. > fix_libtool_files.sh also doesn't play nice with .la files and will > leave orphan .la files around. That's something that can be fixed. > In other words, it's no a question of IF .la files will break stuff but > WHEN they will break stuff. And how BIG the breakage will be. We can > remedy the last part by having leaf packages not install .la files and > by punting library .la files when a .so bump occurs or (as in the case > of libxcb) when other .la-related breakage occurs. > > (Who doesn't remember "The Day the Build Servers were Silenced..." ) > http://bugs.debian.org/354674 > > > Additionally, I am quite unconvinced on the coverage of the removal > > or non-removal of the files. Not removing it on all platforms > > (because you can't) also doesn't solve the problem for those non-ELF > > platforms - you still will get all the pain you are trying to solve > > here on those platforms. > > As those platforms are still not supported by Gentoo as such, but by the > Gentoo/Alt project, that is not really a problem we should be worrying > about. I do worry about projects that make us better than other distributions, by being able to do things that are not possible elsewhere. > That part of the function is a good-faith effort to not > unnecessarily break stuff for Gentoo/Alt users, nothing more. If they > later discover that some of their non-ELF platforms can do without .la > files, they can just wiggle the code and make it so. > > Also, this would be a local Gentoo specific hack to reduce pain on > > ELF systems, while I'm sure there are upstream or better solutions > > avai
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Sat, 2008-11-15 at 00:05 +0100, Peter Alfredsen wrote: > Anyway, we really need to start punting .la files one way or the other. > For desktop users of our distro, they do a lot more harm than good. For > embedded, perhaps static linking serves some purpose, but really, if > you can't afford dynamic linking, what are you going to run on your > board? Just to quickly explain the purpose of static linking on embedded - it has nothing to do with avoiding dynamic linking (run-time?) cost, it has everything to do with size. If you have a library that only one or few applications use, you can end up with smaller size through static linking it, rather than using a shared library of it. This is because during static linking all functions that are not used can be discarded from the final binary, while with shared libraries all the code has to remain, because it isn't know what will be using that shared library, so the toolchain can not safely discard anything, even if you just have one application using some big library, but only using a small subset of its functionality. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Please avoid absolute paths in patched filenames
On Mon, 2008-11-17 at 20:24 +0100, Diego 'Flameeyes' Pettenò wrote: > I ask it here as a favour, please avoid using absolute paths in the > filenames of patched files. This mean avoid having stuff like > > --- foobar/foo.c > +++ /tmp/foobar/foobar.c > > This tends to break from time to time, and I had to fix at least three > packages since I started my treewide build for these problems. I already > asked Zac about adding such a check on repoman, but in the mean time I'd > like to ask here for people to verify their packages. > > I actually am culprit of doing this some time ago but I learnt my lesson > the hard way :P My suggestion for everybody else is to use quilt when > you need to write patches. > > And if you have patches with the filenames like I shown above, you can > change it the git way so that it becomes: > > --- a/foobar/foo.c > +++ b/foobar/foo.c > > and the problem is usually solved. Could you please expand on what the actual problem is for reference, having never seen them fail myself or hear any fail for others? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libxml2: libxml2-2.7.2-r1.ebuild
On P, 2008-12-07 at 12:03 +, Mike Frysinger (vapier) wrote: > vapier 08/12/07 12:03:34 > > Modified: libxml2-2.7.2-r1.ebuild ChangeLog entires are mandatory without any exceptions for stabilizations. Don't touch packages I co-maintain without a ChangeLog entry if it's not a whitespace change. > Log: > s390/sh stable > (Portage version: 2.2_rc17/cvs/Linux 2.6.27.8 x86_64) > > Revision ChangesPath > 1.9 dev-libs/libxml2/libxml2-2.7.2-r1.ebuild > > file : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild?rev=1.9&view=markup > plain: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild?rev=1.9&content-type=text/plain > diff : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild?r1=1.8&r2=1.9 > > Index: libxml2-2.7.2-r1.ebuild > === > RCS file: /var/cvsroot/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild,v > retrieving revision 1.8 > retrieving revision 1.9 > diff -u -r1.8 -r1.9 > --- libxml2-2.7.2-r1.ebuild 7 Dec 2008 05:52:13 - 1.8 > +++ libxml2-2.7.2-r1.ebuild 7 Dec 2008 12:03:34 - 1.9 > @@ -1,6 +1,6 @@ > # Copyright 1999-2008 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > -# $Header: > /var/cvsroot/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild,v 1.8 > 2008/12/07 05:52:13 vapier Exp $ > +# $Header: > /var/cvsroot/gentoo-x86/dev-libs/libxml2/libxml2-2.7.2-r1.ebuild,v 1.9 > 2008/12/07 12:03:34 vapier Exp $ > > inherit libtool flag-o-matic eutils > > @@ -9,7 +9,7 @@ > > LICENSE="MIT" > SLOT="2" > -KEYWORDS="alpha amd64 arm hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh sparc > ~sparc-fbsd x86 ~x86-fbsd" > +KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc > ~sparc-fbsd x86 ~x86-fbsd" > IUSE="debug doc examples ipv6 python readline test" > > XSTS_HOME="http://www.w3.org/XML/2004/xml-schema-test-suite";
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libIDL: libIDL-0.8.10.ebuild
On P, 2008-12-07 at 12:07 +, Mike Frysinger (vapier) wrote: > vapier 08/12/07 12:07:53 > > Modified: libIDL-0.8.10.ebuild ChangeLog entires are mandatory without any exceptions for stabilizations. Don't touch packages I co-maintain without a ChangeLog entry if it's not a whitespace change. etc for any other packages I'll skip replies on this time. Please get the idea. > Log: > arm/sh stable > (Portage version: 2.2_rc17/cvs/Linux 2.6.27.8 x86_64) > > Revision ChangesPath > 1.9 dev-libs/libIDL/libIDL-0.8.10.ebuild > > file : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?rev=1.9&view=markup > plain: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?rev=1.9&content-type=text/plain > diff : > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?r1=1.8&r2=1.9 > > Index: libIDL-0.8.10.ebuild > === > RCS file: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v > retrieving revision 1.8 > retrieving revision 1.9 > diff -u -r1.8 -r1.9 > --- libIDL-0.8.10.ebuild 22 Mar 2008 03:57:44 - 1.8 > +++ libIDL-0.8.10.ebuild 7 Dec 2008 12:07:53 - 1.9 > @@ -1,6 +1,6 @@ > # Copyright 1999-2008 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > -# $Header: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v > 1.8 2008/03/22 03:57:44 dang Exp $ > +# $Header: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v > 1.9 2008/12/07 12:07:53 vapier Exp $ > > inherit eutils gnome2 > > @@ -9,7 +9,7 @@ > > LICENSE="LGPL-2" > SLOT="0" > -KEYWORDS="alpha amd64 ~arm hppa ia64 ~mips ppc ppc64 ~sh sparc x86 ~x86-fbsd" > +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86 ~x86-fbsd" > IUSE="" > > RDEPEND=">=dev-libs/glib-2.4" > > > -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: New global USE flag: gzip-dict
On Sat, 2008-12-20 at 00:16 +, Duncan wrote: > But a gig of space (or even half a gig)... that's rather > different as there are still a decent number of people for whom that's 1% > or more of their total, who may be willing to take that latency as they > have better things to do with the space. If you are dealing with rotating media, I wouldn't be even so sure that 1GB unpacked is quicker than packed 100-200MB. On your typical desktop computer with rotating HDDs, it could very well be quite the opposite, as seek and disk access time can be dozens and hundreds of times slower than a simple zlib inflate, which is a relatively quick operation on x86's. Now of course on something like the Neo FreeRunner, where we'd likely be dealing with a flash based media and an embedded CPU (something like arm7 I guess?, no I don't need to know, I could just google if I did), read from flash is more likely to be quicker. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
On Sun, 2009-02-01 at 19:58 +0100, Rémi Cardona wrote: > Le 01/02/2009 18:32, Norberto Bensa a écrit : > > Excuse me for thread hijack. > > > > Would it make sense to add (for example): > > > >gnome-games > > gnome-games is already the name of a package that contains all official > GNOME games. Only a handful are also released and packaged separately. > > Useless for us IMHO. That said, I'm still threatening to split gnome-games up to individual packages one rainy day. But if that goes through (time-wise and has team agreement), the individual games would be in the suitable games-* category (games-arcade, games-board, etc) with a gnome-extra/gnome-games still in place (one day gnome-base/) - newer versions being meta packages pulling in the individual official games. And not in a gnome-games/ category. Then you can find gnome-games meta package from gnome-*/ category and individual games in their suitable category (glchess is a cool board game, etc).. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Category tags on packages (was: new categories:)
On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote: > On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: > > > not sure how useful could be but could make more sense even if right now > > kde-base contains everything comes from the main kde distribution. > > To be more specific, kde-base contains everything (and only) that is > distributed as KDE stable release (no extragear included). And it causes > confusion as when packages are dropped from KDE release schedule (so they > usually go back to extragear to release when they want), one needs to look to > new place for them (in kde-misc or somewhere else). > Actually categories are bad idea imho. > I was thinking, maybe it would be possible to drop categories completely in > the future (maybe keeping symlinks for compatibility and to ease migration) > and to put *all* packages in one directory - that would require making all > names unique of course. > "Categorization" could be provided for user/search tools as tag clouds being > defined in metadata.xml as vector of tag:weight values where tag would be > some > word from defined dictionary (word like "mail" "client" "kde" "dns" or sth) > and weight - real value [0,1] defining how relevant is that tag. > For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc -> > all/gcc. > But that's just an off-topic. I agree that a tag kind of approach would be nice. Someone should actually do work on it. Here's a random similar idea that I think might work well as a GLEP proposition, that I was about to reply to a different subthread before noticing this post: Packages metadata.xml can be extended with an unlimited amount of elements, whose #text can be a tag string, but one that is limited to a given list in some other place - to have a list of existing tags and not just randomly have tags for everything. Make an effort to populate all packages with sensible tags. Then write tools around it that can show you all packages with a given tag or tags, what tags exist, etc. Those will be your new categories that answer the question of "what mail clients are there" (mail-client tag) or "what mail clients are there using GTK+, well suited for a GNOME environment" (mail-client and gnome tags). Keep categories in place for repository tree sanity (not a huge amount of directories with all packages being sibling dirs) and easier implementation of it all. No-one really types in the categories anyway, and with a tool that deals with the tags, you don't look at the subdirs either - so categories for the user just become a way to differentiate packages with the same name for the few cases there are equal names. However those that prefer the categories approach, can keep using it. Developers also deal with categories, but that's easy enough to keep going as is. Less radical, less controversial, better viability to actually get done. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On K, 2009-02-11 at 19:02 +0100, Santiago M. Mola wrote: > Hello, > > All my packages are up for grabs. Feel free to add yourself to > metadata.xml and don't hesitate to ask me any doubts about them. :( > Telepathy stuff > --- > dev-util/telepathy-inspector (low maintainance) > dev-python/pymsn > net-im/empathy > net-im/telepathy-mission-control > net-irc/telepathy-idle > net-voip/telepathy-butterfly > net-voip/telepathy-haze > > Packages that I've been taking care of and could use a maintainer: > net-libs/telepathy-glib (frequent bumps) > net-voip/telepathy-gabble (frequent bumps) GNOME team need all these working good so we could take those. I think empathy is already co-maintained by us as an official GNOME module. We wouldn't mind co-maintenance of the telepathy stuff with other teams or people. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)
On Sat, 2009-02-21 at 18:55 -0500, Mike Frysinger wrote:
> On Saturday 21 February 2009 18:38:55 Ryan Hill wrote:
> > On Sat, 21 Feb 2009 18:27:10 -0500 Mike Frysinger wrote:
> > > looks like bash-4.0 has broken semicolon escaping in subshells. this
> > > comes up when using find's -exec like we do in a few places in
> > > eclasses: ls=$(find "$1" -name '*.po' -exec basename {} .po \;); shift
> > > you can work around the issue in a couple of ways:
> > > - quote the semicolon:
> > > ';')
> > > - use backticks
> > > `find \;`
> > >
> > > i'll tweak the eclasses to use quoting for now
> >
> > is this a bug or broken on purpose?
>
> i say it's a bug, but i'm not the bash maintainer
>
> i imagine it's fall out from attempts to fix support for case statements in
> subshells
Then the bug should be fixed, instead of changing usage to something
apparently less common, as the conversion could miss some. And more
importantly users still want to use \; for find -exec ending on their
command line and their very own scripts.
And who knows how many shell scripts shipped by packages use the
escaping method.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)
On Sat, 2009-02-21 at 19:29 -0500, Mike Frysinger wrote:
> On Saturday 21 February 2009 19:00:19 Mart Raudsepp wrote:
> > On Sat, 2009-02-21 at 18:55 -0500, Mike Frysinger wrote:
> > > On Saturday 21 February 2009 18:38:55 Ryan Hill wrote:
> > > > On Sat, 21 Feb 2009 18:27:10 -0500 Mike Frysinger wrote:
> > > > > looks like bash-4.0 has broken semicolon escaping in subshells. this
> > > > > comes up when using find's -exec like we do in a few places in
> > > > > eclasses: ls=$(find "$1" -name '*.po' -exec basename {} .po \;);
> > > > > shift you can work around the issue in a couple of ways:
> > > > > - quote the semicolon:
> > > > > ';')
> > > > > - use backticks
> > > > > `find \;`
> > > > >
> > > > > i'll tweak the eclasses to use quoting for now
> > > >
> > > > is this a bug or broken on purpose?
> > >
> > > i say it's a bug, but i'm not the bash maintainer
> > >
> > > i imagine it's fall out from attempts to fix support for case statements
> > > in subshells
> >
> > Then the bug should be fixed, instead of changing usage to something
> > apparently less common, as the conversion could miss some. And more
> > importantly users still want to use \; for find -exec ending on their
> > command line and their very own scripts.
> > And who knows how many shell scripts shipped by packages use the
> > escaping method.
>
> i think you missed the entire point of this thread: there's a bug in bash-4.0
> that code is likely to hit.
I think you missed the entire point of my reply.
That bug should be fixed, not workarounds applied all over the tree, as
users still want to be able to escape semi-colons.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)
On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:
> On Saturday 21 February 2009 19:38:33 Mart Raudsepp wrote:
> > On Sat, 2009-02-21 at 19:29 -0500, Mike Frysinger wrote:
> > > On Saturday 21 February 2009 19:00:19 Mart Raudsepp wrote:
> > > > On Sat, 2009-02-21 at 18:55 -0500, Mike Frysinger wrote:
> > > > > On Saturday 21 February 2009 18:38:55 Ryan Hill wrote:
> > > > > > On Sat, 21 Feb 2009 18:27:10 -0500 Mike Frysinger wrote:
> > > > > > > looks like bash-4.0 has broken semicolon escaping in subshells.
> > > > > > > this comes up when using find's -exec like we do in a few places
> > > > > > > in eclasses: ls=$(find "$1" -name '*.po' -exec basename {} .po
> > > > > > > \;); shift you can work around the issue in a couple of ways: -
> > > > > > > quote the semicolon:
> > > > > > > ';')
> > > > > > > - use backticks
> > > > > > > `find \;`
> > > > > > >
> > > > > > > i'll tweak the eclasses to use quoting for now
> > > > > >
> > > > > > is this a bug or broken on purpose?
> > > > >
> > > > > i say it's a bug, but i'm not the bash maintainer
> > > > >
> > > > > i imagine it's fall out from attempts to fix support for case
> > > > > statements in subshells
> > > >
> > > > Then the bug should be fixed, instead of changing usage to something
> > > > apparently less common, as the conversion could miss some. And more
> > > > importantly users still want to use \; for find -exec ending on their
> > > > command line and their very own scripts.
> > > > And who knows how many shell scripts shipped by packages use the
> > > > escaping method.
> > >
> > > i think you missed the entire point of this thread: there's a bug in
> > > bash-4.0 that code is likely to hit.
> >
> > I think you missed the entire point of my reply.
> > That bug should be fixed, not workarounds applied all over the tree, as
> > users still want to be able to escape semi-colons.
>
> no one suggested doing any of this crap you're talking about. if you want to
> get all retarded, dont install the masked ebuild. i gave a heads up to
> people
> who might want to experiment so they wouldnt have to figure out weird errors.
>
> in the mean time, i tweaked a few common files so people wouldnt hit errors
> and could investigate even further.
Perhaps you should actually state those intentions at the start instead
of starting to rant out on people replying.
Sounds good now that we actually know what the plan is.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Repository stacking and complementary overlays
variable names quite clearly and logically states!) and therefore in the same "stack" and that we need a different way to declare a different stack and standalone repository. I also claim other PMs than portage should default to extending the PORTDIR repo_name "stack" as well with overlay entries in PORTDIR_OVERLAY instead of making a new "stack" as they do now. An PORTDIR_OVERLAY overlay is an overlay on top of PORTDIR and therefore in the same "stack", not a new repository that gets a new "stack". With a very quick thought I see some possible ways to make this more clear and formal: a) Declare in a reposity/overlay what its parent repository is, if any - gnome overlay profiles/parent_repo (or some such) would contain "gentoo". Could also perhaps extend repo_name, e.g "gentoo+gnome" b) Declaring what "stack" a repository/overlay belongs to - e.g, both gentoo main repository and gnome overlay (and quite all other existing _overlays_) both saying "gentoo" in their profiles/stack_name (with a better name) file. c) Maintain the behaviour of portage as is, and assume PORTDIR_OVERLAY is _overlaying_ PORTDIR as the name suggests, but have some kind of sanity checks that can be performed where appropriate either by means of options a) or b) or some different way d) Make use of sets for solving the current use case in question, as has been suggested - this seems to involve portage work and actually understanding why this is a good solution -- concrete explanation on that is most welcome for consideration and evaluation. Keep in mind that this (especially options presented as a), b) and c)) covers more than just package.mask negation, as the triggering reason for this discussion. Knowing that an overlay is complementary to a given repository or repositories, and knowing that a repository is standalone from gentoo-x86 could be beneficial in more cases than this specific one. For package.mask negation as done in GNOME overlay it's also about profiles/package.mask vs profiles/base/package.mask behaviour (in addition to negation of masks in a different repository/overlay) - the discussion of that is not a subject to this thread, so please make a new thread when wanting to discuss about that. Note that I'm on devaway for up to a week from this moment, just getting an actual discussion going on this topic meanwhile as promised at council meeting. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] How to speed up maintenance and other Gentoo work?
Hello, I'm collecting ideas from the wider development and contributing community on how to help maintainers and contributors get work done quicker, or rephrased - how to get more done in the limited time we have. This basically means ideas for tools, scripts, or functionality in some hypothetical centralized maintainer helper website or GUI/CLI program that would help save time in taking care of some of the gruntwork that gets done by maintainers right now manually or by scripts that don't get shared and re-used and generalized as much as they could. Then afterwards I can sort through the suggestions/ideas, try to make a summary and arrange some of them to actually happen. If things get done quicker, there is theoretically more available time, which hopefully would translate into being able to bring us back to the bleeding edge in one hand, and high quality in another. I have intentionally left out my own ideas at start to keep everyone's mind open to various approaches to this. Please share your thoughts and ideas as a reply here, on my matching blog post as comments or via private e-mail! -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Repository stacking and complementary overlays
On Mon, 2009-03-02 at 16:48 +, Ciaran McCreesh wrote: > On Fri, 27 Feb 2009 04:41:23 +0200 > Mart Raudsepp wrote: > > So here the reverting of a masking in gentoo-x86 is quite intentional > > and currently desired. > > This is fundamentally broken as a concept. > > Adding an overlay should not have any impact upon other repositories. Adding an overlay conceptually and fundamentally and per dictionary means laying some packages over something else, PORTDIR in this case - the main repository and therefore adding an overlay impacts other repositories - at least the main one. This is how it has always worked and I do not understand why the behaviour should suddenly change to mean something illogical to the term. > It should be possible for a user to add an overlay, and make limited > use of that repository, without having to worry that the mere act of > adding that overlay will make massive changes to what's visible in > other repositories. Perhaps the package manager should add such a support then with PORTDIR_PREVIEW_OVERLAY or some such if you want your users to be able to have the overlay VCS checkout and addition to PORDIR_OVERLAY or the like to be one operation. > Overlays shouldn't be altering the visibility of things outside of that > overlay without explicit user action. Can you repeat the technically sound reasoning to that again please or point to exact archived posts? This discussion has been going on in other mediums as well, I might have missed the core points. > > By this snippet we could simply move the current relevant maskings > > from profiles/package.mask to profiles/base/package.mask and call it > > a day (and screw over the few profiles that don't end up parenting > > base/), as QA forced us to do in case of per-arch mask negations in > > gentoo-x86 a while back. > > But it doesn't seem to be as simple as that. > > Well no, because profiles/base/ in your overlay is entirely unrelated > to profiles/base/ in the master. > > > > Only reason it flies for portage is because it collapses it all > > > into one stack; for managers designed to support multiple > > > standalone repos that assumption no longer applies, thus that > > > behaviour (outside of PMS) breaks. > > > > Last I knew the official council approved PMS was meant to describe > > portage behaviour at the time, which appears to have been the same > > along the way - treating all overlays in the same "stack" as PORTDIR, > > perhaps as there is no means to declare a different "stack". > > PMS does not attempt to document Portage behaviour in the cases where > Portage behaviour is dumb. That's the reason there's as little as > possible mentioned regarding overlays there -- Portage's overlay model > is a horrible hack, and forcing package managers to implement it rather > than offering a true multiple repository model would be a serious hit > on usability. > > The way forward here is to identify what you're trying to achieve, > whilst ignoring how things are currently defined or what is or is not > possible. Then we can look at that and work out whether it can be > mapped to an existing solution or some easily-implementable new > solution. Starting with implementation is the wrong approach. I'm trying to achieve that merely adding an overlay on top of gentoo-x86 repository actually adds that overlay and things work as desired in regards to visibility. In related reasons, we need to do the unmasking of things masked in main repository because the masks there affect the visibility of packages in the overlay by masking those as well. Perhaps that's the actual core problem for us, if playing along with the notion of current Portage behaviour being dumb (Where do I read how it is dumb and how it'd be better and what a true multiple repository model would be like?) Regards, Mart Raudsepp
Re: [gentoo-dev] EAPI 3 PMS Draft
On Tue, 2009-03-17 at 13:55 +, Ciaran McCreesh wrote: > On Tue, 17 Mar 2009 10:50:17 +0300 > Peter Volkov wrote: > > If failures are non fatal I don't object to having src_test enabled by > > default and I'll all for this even. > > ...and src_test becomes utterly worthless again. Your definition of worthless doesn't match the one in my vocabulary, because it is very much worth it when many developers have FEATURES=test and routinely make sure the packages they use pass the test or file a bug. It is quite irresponsible to enable that by default for the FULL user base, given the state of the tree in regards to it, many upstreams stance on tests and their failures, and the (very) considerable extra time it takes to run them while it's already slower in relation to binary distributions. Enabling tests by default feels like driving users away, because all of a sudden their upgrades taken even more time (possibly unexplained to them, as an EAPI bump in an ebuild introducing it is not visible to them), and they'd just say to hell with it and go to a binary distribution that runs the tests for maintainers only, as we should. Yet we have the _choice_ to take that extra time and double-check on maintainers if they really did their job right. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
thing? I'm not even sure anymore where to find a list of items that is current for what's on the table for EAPI-3 right now... -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote: > > In separate threads: .. > * dohard being deprecated Actually bug #235642 has been fixed by now, and therefore this seems simple enough. The main reasoning for deprecation (and banning) of dohard() was that bug as far as I understood, and it is fixed now. However due to technical restriction intrinsic to hard links, we should rephrase what it does - to emphasize that it tries to do a hard link, but if that is not technically possible, it will be a copy. That is, there is no guarantee but a best effort. It can be useful when it works. If it ends up in a separate partition, there is nothing we can do. But the common case is that the hard link destination is in the same directory as the source, and that pretty much means the same partition as well. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] EAPI-3 draft: slot operator support
Hello, This thread is for any discussion about the slot operator support item in EAPI-3 draft. The premise is good what := and :* allow for, but I'm concerned about the syntax possibly ending up being suboptimal in relation to the syntax we come up in the future for covering the cases not covered now. Such cases are for example: * A library package has slots 2.4, 2.6 and 2.8. An application works with either 2.6 or 2.8, but needs a recompile for changed ABI. It does not work with 2.4 - it has API missing that it needs. * Same case as previous, but additionally the library has a version with slot 3.0 - it is a complete redesign and applications working with 2.8 have no chance of working. So need to express a list of acceptable SLOTs or a minimum and maximum (but slots aren't really guaranteed to be numeric and versionable). * Same case as previous (either of them), but if using SLOT 2.6, it needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not be necessary (considering both cases separately) * A library provides slots 1.2, 1.4 and 1.6. An application can work with all of them, but needs a recompile if upgrading from being linked against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare possibility of this though, involving dlopen and more. Probably acceptable to declare rebuild need for all changes. Are we sure := and :* is the syntax that makes sense once we try to cover some of the above with new syntax? Perhaps some forward thinking is sensible here to not end up with having to deprecate the := and :* syntax soon after its introduction. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On N, 2009-04-09 at 11:30 +0200, Tiziano Müller wrote:
> Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> >
> > The premise is good what := and :* allow for, but I'm concerned about
> > the syntax possibly ending up being suboptimal in relation to the syntax
> > we come up in the future for covering the cases not covered now.
> >
> >
> > Such cases are for example:
> >
> > * A library package has slots 2.4, 2.6 and 2.8. An application works
> > with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> > not work with 2.4 - it has API missing that it needs.
> DEPEND=RDEPEND=">=cat/lib-2.6:="
This is an abuse of the version number. There is no actual guarantee
that SLOT 2.6 revisions carry a 2.6* version number, etc.
> > * Same case as previous, but additionally the library has a version with
> > slot 3.0 - it is a complete redesign and applications working with 2.8
> > have no chance of working. So need to express a list of acceptable SLOTs
> > or a minimum and maximum (but slots aren't really guaranteed to be
> > numeric and versionable).
> slot operators won't help here, so it remains:
> RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"
The package additionally needs to know which one the package manager
picked for it, to instruct the build system to actually use that
version.
Without this the whole := deal is pretty useless for many cases.
> with ranged dependencies:
> RDEPEND="cat/lib[>=2.6&<3]:="
Version/slot mixing abuse
> or slot ranges:
> RDEPEND="cat/lib:[2.6|2.8]="
> or
> RDEPEND="cat/lib:=[2.6|2.8]"
> (depends on how we want to define the syntax)
I guess that would go along with the := proposed now and therefore be an
evolution and not a problem to do := now. At least for this case.
> > * Same case as previous (either of them), but if using SLOT 2.6, it
> > needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> > >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> > be necessary (considering both cases separately)
> slot operators won't help here, so it remains:
> RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"
That doesn't work for the same reason cat/lib or || ( cat/lib:2.6
cat/lib:2.8 ) doesn't.
> again with ranged dependencies (somebody please check this):
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
> or
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
>
> or maybe combined with slot ranges:
> RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]
There is no relation between 2.8.3 and slot 2.8 here really.
We do not declare anywhere how SLOT naming related to version numbers
it's used in. So none of those examples work for me.
> please note: the ebuild maintainer has to make sure that the package has
> to use the best-matching version, otherwise even the slot specifiers are
> worthless.
The package manager needs to tell the ebuild which version it went with,
or this doesn't work right. If you assume best matching version always,
then all this slot operator deal becomes superfluous. Maintainers should
then simply always depend on just the latest version and there is
minimal benefits to slot operators and the complexity in the readability
might not be worth it.
> Real-world example for that:
> DEPEND="sys-libs/db:="
> RDEPEND="${RDEPEND}"
>
> By the time of installation you have sys-libs/db:{4.6,4.7} installed,
> then your app has to use sys-libs/db:4.7.
> (best_version should provide that information as far as I know).
>
> >
> > * A library provides slots 1.2, 1.4 and 1.6. An application can work
> > with all of them, but needs a recompile if upgrading from being linked
> > against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> > possibility of this though, involving dlopen and more. Probably
> > acceptable to declare rebuild need for all changes.
> Yes.
>
> > Are we sure := and :* is the syntax that makes sense once we try to
> > cover some of the above with new syntax?
> Yes. It's quiet extendable (as seen above).
>
> >
> > Perhaps some forward thinking is sensible here to not end up with having
> > to deprecate the := and :* syntax soon after its introduction.
> Done.
I see no need for :* based on the examples provided and can't think of
any real world cases for it either right now.
There is that theoretical case when some package does dynamic usage of
the library through dlopen and handles the ABI differences, but even
then there is no guarantee (and it is quite unlikely) that it can handle
a future ABI SLOT of the library, and so using :* is unsafe, and :=[list
of known to work ABI SLOTs] should be used instead.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On N, 2009-04-09 at 10:37 +0200, Tiziano Müller wrote: > > properties must be cached properly > > == > > > > No opinion, up to the package manager developers. > > Don't see offhand why it should be an EAPI item at all. Feels like > an > > implementation detail. > > The metadata cache needs to be specified to make it work with > compliant > PM's and is therefore a part of the PMS. > A change is therefore required to be done on a per-EAPI base. But the metadata cache isn't per-EAPI in the sense of multiple metadata caches, one for each EAPI. There might be per-EAPI metadata cache items though. Anyhow, if zmedico is cool with it, I'm cool. > > Limit values in $USE to ones in $IUSE: > > == > > > > Seems more of a QA test, but forcing it can make it be caught at > start. > > Don't see why it must be an EAPI item. Just vet the tree of > (future?) > > repoman warnings about it and make it happen for > > all EAPIs. Impact on overlays is minimal because it is a QA error to > not > > define them and they get what they asked for. > > > > Not strongly opposed to it being in the EAPI. > > > Why it has to be done in an EAPI: It matters whether you have to put > for > example userland_GNU in IUSE if you want to use it in the ebuild or > not. I don't think I want to have to specify userland_GNU and co in IUSE. They aren't USE flags that get set by the user, so having to put them in IUSE isn't intuitive either. > > > > > --disable-dependency-tracking: > > == > > > > possible breakage of (custom) configure scripts that don't accept > > unknown arguments. Would be nice to pass that for most packages, but > > doing it always with econf seems slightly inappropriate, given the > > above. > > Don't think this is an item for fast-tracked EAPI-3. > > custom configure scripts mostly already break with econf, so not an > issue. Some might accept all current switches we pass with econf, but not --disable-dependency-tracking. Maybe if there's a way to opt out of the --disable-dependency-tracking when necessary... the unlikely need for that will get seen by the maintainer when he/she upgrades the ebuild to EAPI-3. econf is a complex and long (many arguments passed) beast to replicate just without --disable-dependency-tracking > > ban || ( foo? ( . ) . ) > > === > > > > It is not the business of an EAPI to start disallowing *DEPEND > string > > constructs. > It's EAPI's business to define what's valid and what is not. We disagree there. Things should be an EAPI item when it is reasonably required to be. In this case a simple repoman warning on such a construct suffices. > > There is no useful alternative provided yet to my knowledge and this > is > > really a QA issue, not an EAPI issue. > The problem is that there is no valid use case to justify the > existence > of this construct. In either way users will most likely not have what > they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will > therefore help the user to get what the specified and is therefore a > good thing. Then we should disallow all constructs that currently give a repoman warning as well? It is a QA issue to me, not something to overload an EAPI with. QA warning for all EAPI's. > > Not convinced on the sub-optimal use case being the only one, > either. > > > > Strongly objecting on the grounds that it is not something that > should > > be an EAPI issue. > > > > > > unpack has to handle more types > > === > > > > Would be nice to get a QA warning when unpacking .lzma, .xz, etc > that > > need a build depend for the unpacker and don't have it yet. Then > sounds > > fine. > But you don't want unpack fail on unknown types? Seems a bit > inconsequent. Unknown types in this case is about "not packed at all". Or we could define those types - .patch, .bin, etc PM knows that there's .lzma, .xz and so on, so it could know which build-time deps are necessary - repoman warning anyhow, later some alternative unpacker might surface. > > Did I miss anything? > > I'm not even sure anymore where to find a list of items that is > current > > for what's on the table for EAPI-3 right now... > > > The PMS. (just do "emerge pms" for an up-to-date version). that's a bit complicated with not having texlive installed anywhere yet... -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 3 PMS Draft
On N, 2009-04-09 at 15:37 +0100, Ciaran McCreesh wrote: > On Thu, 09 Apr 2009 04:12:02 +0300 > Mart Raudsepp wrote: > > It is quite irresponsible to enable that by default for the FULL user > > base, given the state of the tree in regards to it > > Which is why we are not talking about enabling it for the tree. We are > talking about enabling it for a subset of the tree that's guaranteed to > have been tested by it. > > > many upstreams stance on tests and their failures > > So for those packages, RESTRICT tests like you should be doing anyway. > > > and the (very) considerable extra time it takes to run them while > > it's already slower in relation to binary distributions. > > PROPERTIES="slow-tests" then. Every single test on any package is going to be done slower than not running tests. This PROPERTIES proposal has no relevance to the argument of why it is an extremely bad idea to enable it by default. All developers should enable it (a QA enforcement), but users by default - no, NO. There is more to a distribution than technical considerations. > We've been over all of this several times previously. Yes, and by my understanding this will not be happening anytime soon, if ever, so I can repeat all my sound objections to it whenever you bring it up again in the more distant future, thank you. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] PMS EAPI 3 more or less ready
dependency tracking being, well, disabled and the affects of that in face of any outside influences to headers used by it from the system, when compared to the case when dependency tracking is enabled. Such as when a separate (possibly parallel) install step kicks in. Olivier Crête also has an outstanding comment about a maintainer possibly not wanting that disabled in case of patches applied. Could use some elaboration on that thought, or comments in replies. --enable-fast-install is completely new to me for consideration under EAPI-3. Maybe I just missed it when reading PMS draft before, and it wasn't listed in the other summaries. It is libtool specific and already the default. Don't see any reason to specify this, as only configure's with libtool usage (LT_INIT in configure.ac) have that option, and enabling it is the default unless package upstream has specifically disabled it with an option to LT_INIT m4 macro. Therefore a definite "no" for --enable-fast-install. > * PKG-INFO query Same question as Petteri but also what if we want to display information based on saved environment? Any suggestion into the spec which way to use for checking if the package in question is already installed or not? > * PROFILE-IUSE-INJECTION query. need to review a bit further for myself in relation to profile set implicit stuff and emerge --newuse behaviour and output > * AA whatever > * KV whatever > * REPLACE-VERSION-VARS query need to think more through for myself, also possibly somewhat in relation to slot operators > * S-WORKDIR-FALLBACK whatever > * UNPACK-IF-COMPRESSED query I think the spec draft reads that it will be an error to pass regular files to unpack --if-compressed. That seems backwards. Still a bit unsure about the default non-argument case choice. > * RDEPEND-DEPEND yes > * DIE-ON-FAILURE whatever > * NONFATAL whatever -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Tue, 2009-04-21 at 16:17 +0100, Ciaran McCreesh wrote: > On Tue, 21 Apr 2009 05:11:15 +0300 > Mart Raudsepp wrote: > > > * ECONF-OPTIONS > > > > query > > --disable-dependency-tracking has other implications than it being > > allowed to be passed to ./configure or not - such as dependency > > tracking being, well, disabled and the affects of that in face of any > > outside influences to headers used by it from the system, when > > compared to the case when dependency tracking is enabled. Such as > > when a separate (possibly parallel) install step kicks in. > > If a parallel install is overwriting things on / whilst a package is > compiling, things are already horribly broken regardless of this > switch. PMS explicitly forbids that from happening. That's that. And then there's the real world. > > Olivier Crête also has an outstanding comment about a maintainer > > possibly not wanting that disabled in case of patches applied. Could > > use some elaboration on that thought, or comments in replies. > > It's always possible to override it if necessary. No. It is possible to not use econf and write all of the options it's supposed to be passing manually. Probably missing something or otherwise being horribly long. > > --enable-fast-install is completely new to me for consideration under > > EAPI-3. Maybe I just missed it when reading PMS draft before, and it > > wasn't listed in the other summaries. > > No, it's been there all along. Ok. That doesn't change it's complete pointlessness to be there. Anyway, "whatever" on --disable-dependency-tracking Definitely _no_ on --enable-fast-install. It is already the default and when it isn't (I know of no such cases), upstream maintainer has _explicitly_ made it so. It is not our business to be passing the libtool specific default argument. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] SLOT-OPERATOR-DEPS (Was: PMS EAPI 3 more or less ready)
On Tue, 2009-04-21 at 16:03 +0100, Ciaran McCreesh wrote: > On Tue, 21 Apr 2009 05:11:15 +0300 > Mart Raudsepp wrote: > > > * SLOT-OPERATOR-DEPS > > > > An outstanding problem to me as a package maintainer is the lack of > > means to know which slot the PM actually picked for the package, as > > some of my co-maintained packages have no use of := if it can't know > > which version was picked to act accordingly in src_configure. > > The best installed version that matches the spec is always picked > for :=. We originally considered making this more complicated, or > possibly making ways of saying "all installed slots", but neither > appears to have a legitimate use case. The latter in particular would > only encourage abuse (people might mistakenly think it's a solution to > the Python / Ruby ABIs thing). I don't think that really works in all cases, e.g in combination with PDEPEND or such. But if there is such a guarantee per spec, it's at least covering the common and most reasonable cases. So to make this easy for everybody in the future, do you perhaps have a concrete ebuild code example that shows how exactly to do it in an ebuild pkg_setup or src_configure exactly? My main open issue with SLOT-OPERATOR-DEPS is about the :* syntax, and specifically how that potentially works un-intuituvely with some future syntax regarding list of slots. The feature concept itself seems sound and reasonable, but I think we might be able to do better with the syntax for the long run when slot lists come into play. I need to lay down for a while now (caught a cold), but I'll work on a detailed description of what I have in mind - after thinking it more through to myself - in some 5-7 hours from now. It is also possible that this thinking will result in the conclusion that the proposed syntax is best afterall, but I'll see what I come up with. Still have REPLACED_BY_VERSIONS stuff to think through too, but I don't expect any big controversies from there from me, I hope. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ECONF-OPTIONS (Was: PMS EAPI 3 more or less ready)
On Thu, 2009-04-23 at 13:58 +0100, Ciaran McCreesh wrote: > On Thu, 23 Apr 2009 10:56:56 +0300 > Mart Raudsepp wrote: > > > If a parallel install is overwriting things on / whilst a package is > > > compiling, things are already horribly broken regardless of this > > > switch. PMS explicitly forbids that from happening. > > > > That's that. And then there's the real world. > > Yes, and in the real world, if you change / whilst something is > compiling, things break. Except with dependency tracking they might not. Anyways, I was "whatever" on the --disable-dependency-tracking already. > > > > Olivier Crête also has an outstanding comment about a maintainer > > > > possibly not wanting that disabled in case of patches applied. > > > > Could use some elaboration on that thought, or comments in > > > > replies. > > > > > It's always possible to override it if necessary. > > > > No. It is possible to not use econf and write all of the options it's > > supposed to be passing manually. Probably missing something or > > otherwise being horribly long. > > Uh, you just do econf --enable-dependency-tracking. I apparently did need that nap. Yeah, that should work. I believe you forgot the topic of --enable-fast-install. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Wed, 2009-04-22 at 23:21 -0700, Donnie Berkholz wrote: > > > Goals: Any unanswered queries? Figure out what to do with features > receiving a "no." I think the whole council should understand why something received a "no" from someone, as they might be important technical (or subjective) arguments against having that in EAPI-3, as to be able to make an informed decision that is best for the whole of Gentoo. I believe we have up to now just given individual stances on the features - voting based on that doesn't really work right. It is quite likely that almost all features will get a majority "yes" vote when taken individually because not all council members have seen the problems a few of the council members have. So my point is that the whole of the council should consider the objections of an individual council member, so that potentially bad things don't end up accepted based on some kind of an uninformed majority vote or concensus. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
On Wed, 2009-05-06 at 17:25 +, Duncan wrote: > Christian Faulhammer posted > 20090506083356.4a561...@gentoo.org, excerpted below, on Wed, 06 May 2009 > 08:33:56 +0200: > > > Apart from growing into your job (that's what happened with me), > > recruiters do quite long IRC sessions with the applicant. Apart from > > questions not found in the quiz they want people to elaborate on answers > > they made. > > As others have occasionally noted, the assumption seems to be that > developers "do" IRC. While it's certainly a useful thing for those that > do it, I believe I've seen a few developers speak up from time to time > that say they do little if any IRC at all, doing their Gentoo comms via > email (including the lists), bugs, and of course commits. Does the way > remain open for such recruits? This subthread would suggest not, that > IRC is now considered not just convenient or useful, but mandatory. I'd > call that a shame, as it could well block otherwise productive potential > devs. Are you suggesting that recruiters should do long e-mail exchanges with the applicants instead, having no real time conversations, leading to no idea about the applicants real knowledge (when there is not much time to do research after a question is posed), attitude and so on? -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries
On Sun, 2009-05-10 at 18:45 +0200, Rémi Cardona wrote: > > Medium term : > - libxcb 1.2 will be moved to portage once we figure out a sane way > to > handle the disappearance of libxcb-x11.so. For those who haven't > heard > or seen what happens during the upgrade, let's just say that the > upgrade > from expat 1.95 to 2.0 was a walk in the park compared to this. An important difference to note here is that expat case (sorry) was hit by everyone, but xcb problem will be hit only by people who have enabled USE=xcb on certain packages or globally, and that is not the default. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: Project proposal -- maintainer-wanted
Hello, I have had this project in my mind for a while, so it's about time to get it out there, as to see if feedback finds it a good one - and if that is so, if there are people who want to make it happen. It is worded as a hypothetical project description for the purpose of the text perhaps being a draft for the projects official description. So in the following text instead of terms like "this project would be" I'm purposely using terms like "this project is", as while writing it, it got quickly very awkward writing "would be" and such all the time. Please take it still as a proposal to be judged, commented, improved, etc etc. And well, do that commenting and improving and volunteering ;) Project maintainer-wanted = Abstract: There are currently quite some package requests (over 3000) languishing on bugzilla waiting for a developer or team to get interested and package it in the official gentoo-x86 portage tree. However in quite some cases that might not happen for quite a while even with very popular packages desired by users. The purpose of the maintainer-wanted project is to get as many of such packages to the official tree as possible as a stopgap solution. Details/implementation: The maintainer-wanted team is actively looking for popular packages in bugzilla that have been waiting for packaging in the official "gentoo-x86" tree for a while, and package and maintain as many of them as the project teams manpower allows without sacrificing quality. To decide which libraries/application get packaged in the official tree by the project, various factors can be considers by the team. These can include metrics such as: * bugzilla vote count amongst open maintainer-wanted packages * recent general useful activity on the packages bugzilla entry * past and present user community activity in providing ebuild improvements, version bumps and fixes in the packages bugzilla maintainer-wanted bug entry * ease of the packaging thanks to active user contributions or consistently good upstream packaging making the workload of the maintainer-team not grow much * team members interest and personal qualification in the type of the package and its packaging methods * ... maintainer-wanted maintained packages are seen as a stopgap solution. As such it is desired that eventually a team or developer takes over maintenance to provide the packages dedicated care and free up the maintainer-wanted team to make available more desired packages that do not yet have a dedicated maintainer. To achieve that, various methods are pursued: * Other teams and developers are encouraged to take over maintenance. This includes proxy maintenance when for example a user is found to consistently and with good quality help out the maintainer-wanted team in providing fixes, improvements and bumps to an in-tree maintainer-wanted maintained package. Taking over maintenance is as easy as for maintainer-needed packages, however a notification to and acknowledgment from a maintainer-wanted team member is appreciated. * Lists of maintainer-wanted packages are generated, sorted by category of interest. Developers and dedicated package teams are encouraged to find packages of interest from these lists and take over maintenance. * Simply the easier availability (and the resulting exposure) of a package in the official tree (as opposed to an unreviewed, yet possibly high quality, ebuild attached to bugzilla, which has thousands of such entries) could catch the interest of another team or developer and they are encouraged to take over maintenance when they have the capacity (manpower/time etc) In other ways the maintainer-wanted team is not significantly different to other package maintaining teams: * The project is responsible for their maintained packages. Quality is not sacrificed; bugs on in-tree packages get acted upon, etc. As such it is likely desired to have a different alias than the default one for new packages (or a different good means of differentiating), as to not have bugs against already in-tree packages get lost amongst the hundreds or thousands of packages still waiting to get into the official package tree. * In-tree maintainer-wanted packages are also tried to be kept up to date in regards to new stable upstream versions. Users are encouraged to file bump requests on bugzilla even as 1-day requests due to the diversity of packages maintained by the project and therefore too many different places and notification mechanisms to manually check and monitor for the team (bugzilla version bump requests solve the diversity); at least until no mechanisms exist for automatic checking of bumps, which could get implemented in the future. The maintainer-team project hopes to make previously directly unavailable popular packages of quality easily available to the user base until other projects and developers are able to take over. Discuss! :) Ma
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Wed, 2009-05-13 at 20:47 -0500, Jeremy Olexa wrote: > Mart Raudsepp wrote: > > Hello, Hey, > > I have had this project in my mind for a while, so it's about time to > > get it out there, as to see if feedback finds it a good one - and if > > that is so, if there are people who want to make it happen. > > > Hmm, I wonder what the point is when there is 400 maintainer-needed bugs > open.. The point is making popular packages available in the _portage tree_. When widely used popular packages end up in maintainer-needed, they tend to be relatively quickly picked up by other teams or developers. maintainer-wanted hopes for the same, that they will tend to be picked up by others. Most of the 400 packages affected by maintainer-needed bugs are probably as such because close to no-one cares about them, and caring by the project proposed here doesn't get us any closer to world domination(tm) - we'd just have more packages of quality, except no-one uses those packages. We already have a set of people, of which you Jeremy seem to be participating in, that takes care of maintainer-needed bugs that have user patches available, hence the packages people actually care about are eventually taken care of as well as I understand. Maybe that project should formalize themselves as well. Or we can add that set of tasks to this one. That said, my initial idea months ago was related to the maintainer-needed alias, taking care of the packages of greater interest marked maintainer-needed and introducing new ones that are encouraged to be taken over. But by now I don't think mixing those together is a good idea. The community maintained packages idea from another e-mail was quite good to not mix with maintainer-wanted either (the point about making sure new package requests and bugs against in-tree maintainer-wanted packages don't get mixed), except I think that naming doesn't so strongly express that other dedicated maintainers are desired. > I think a maintainer-wanted team won't accomplish much because it just > uses more developer time from a pool of "not enough time" that exists > already. Volunteer manpower doesn't work quite like that. Volunteers have as much time as they make for this as a hobby of interest. Developer A is interested in keeping old crufty stuff dropped to maintainer-needed in quality condition as they like that sort of thing, while developer B doesn't and he likes the satisfaction of making much desired new packages available to the wider user base instead. If you don't have a project encouraging that, developer B can end up just not taking more time for Gentoo and does more of other stuff instead, lets say gardening or watching random TV. Because we don't provide monetary motivation to take care of exotic and outdated packages to get that out of the way shouldn't block people motivated in providing popular packages that would be used by a larger set of the user base and contribute to the popularity of Gentoo. > If people are a) too lazy to contribute to sunrise, b) don't > know about sunrise, or c) don't know enough about ebuilds to contribute > to sunrise, then we need to fix[1] that. Sure, the sunrise project can do all of that. That doesn't make the packages available in the official tree. The maintainer-wanted project however can tap into the work done by sunrise when a popular package is to be added to the tree that already exists in Sunrise. If certain interested in the package users are contributing to Sunrise for that package, they could hopefully be turned into proxy maintainers in the official tree version and perhaps even eventually become developers as well when they have interest in a larger set of packages. If they have been maintaining a lot of different package in Sunrise before that, they seem to be a good candidate in joining the maintainer-wanted team too then, as they seem to be motivated by the kind of work they do, as same work was done in an overlay by him/her before. Close collaboration with Sunrise is good, that is. So the end outcome would be that the packages that are used by many people are available in the official tree. > I don't see any reason to create a team that duplicates the sunrise > work. Keep in mind, I am against pretty much any overlay, I think work > should be kept in the main tree. But, for ebuild maintenance with > limited developer time, sunrise just makes sense(tm). Developer time is not so strictly limited. The motivation to spend more time on Gentoo instead of other daily non-work not-so productive activities might be limited. Yes, we also have the small set of developers that do a very large chunk of the work - they are limited in time indeed because they already are so motivated to use so much time for Gentoo. I am a strong believer in the correlation of motivation and tim
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On N, 2009-05-14 at 14:02 +0300, Markos Chandras wrote: > On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote: > > Hello, > > > > I have had this project in my mind for a while, so it's about time to > >[..] > I think there is no need for this project. Developers can always browse > bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this > is what I do. I am not sure how this project will make things better. In > order to push something on portage, you need to test it and use it and like > it and taking care of it. Apparently you wont push a package that you dont > give a s*** :) > So this project will do what each developer is doing individually. Am I the > only one who is searching bugzilla for maintainer-wanted packages? o_0 There are various differences with this being a project instead of individual developers picking up a few. I think most are benefits, but some can be perhaps viewed the opposite way as well, hence the thread :) It is a project and hence a team, so there can be multiple developers in the team, all sharing the workload and making sure quality and up-to-dateness is kept. A separate e-mail alias to get bug reports to that any of the team members can attend to, etc. Basically the typical benefits of a team vs individuals The packages are still kept up for grabs for individual packages. Instead of you looking for packages of interest to maintain from bugzilla maintainer-wanted ones, you have an additional place to look at - one that would be more easily browseable and categorized. If you find a package of interest you would like to maintain out of that list, you simply take over maintenance from maintainer-wanted team, as finding a dedicated is exactly the eventual goal and that gets accomplished then. Meanwhile users have the package available earlier. Liking and using the package yourself shouldn't be a prerequisite for a package getting to be in-tree by the maintainer-wanted team. It is hoped that for them the driving factor is making popular packages available to a larger user base that want to use it themselves, so that popular applications that do not have any existing developers at the time finding deep interest in it will not mean indefinite languishing in bugzilla and not being easily available for users (while it probably is for Fedora or Debian or whatever). I'm quite sure we have developers motivated by that around. For example when I discussed this with Samuli a few months ago, I believe he basically said to already do work like this, except making desktop-misc the dumping ground, loosing the benefits that a separate project and alias would give related to both implied (from the maintaining herd name and knowledge of its purpose) and active seeking (through package lists, etc) for dedicated maintainers. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On Fri, 2009-05-15 at 12:24 +, Duncan wrote: > Daniel Pielmeier posted > 6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted > below, on Fri, 15 May 2009 12:44:47 +0200: > > > 2009/5/15 Marijn Schouten (hkBst) : > >> > >> Thilo Bangert wrote: > >>> > >>> Fedora is a much more current distribution than Gentoo - and has been > >>> for a couple of years... > >> > >> Please elaborate what exactly you think Fedora does better than we do. > >> I have no first-hand experience with Fedora, but from what I read I had > >> the impression that sometimes they go with new stuff before it is > >> ready, like KDE4 and pulseaudio. I like about the current situation > >> that we also have all those things available AFAICS, but have very > >> broad choices in how much we want to bleed. IMO this is a different > >> issue than having supposedly popular ebuilds not in main tree. > >> > > AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to > > compare it with the Gentoo unstable tree instead of the stable > > one. Assuming this there is probably not a big difference in the > > up-to-dateness. > > Well, yes and no. As the GP said, they sometimes go with new stuff > before it's ready -- before Gentoo even has it in-tree hard-masked let > alone ~arch, while it's still in the various project overlays. I know > they've had some serious issues with xorg on Intel GPUs at least, due to > running versions that aren't in our tree yet, only in the X overlay, > because Fedora is running clearly not even ~arch-ready packages, > sometimes even xorg prereleases. I believe you are thinking of rawhide. Fedora and quite most other distributions work fundamentally different. We have a gradually moving tree, as we can do that by being source based. Fedora and other distributions are doing releases, which involves switching to a newer repository branch with dist-upgrade and so on. They release a new version typically every 6 month, we release new major versions of packages all the time (considering the whole set). I'd say that at the point of binary distribution releases their released trees are somewhere between our ~arch and stable tree, while within a month or two, they become similar to our stable tree until our continous releases overcome it with newer versions. Fedora has xorg prereleases in what they call "rawhide". This is what will become a new release in the future, as they have ~6 month cycles. It's unstable on purpose, as they are thriving towards being stable with that repository at the time of the planned next release, while having up to date packages around the time of the release (with a ~1 month stabilization period before the release time). That's the fundamental difference, and where we can have an advantage over them in addition to other things coming from being source based. > Years ago we'd have put these in-tree but hard-masked for those who > wanted to try them. Now, depending on the package and Gentoo but more > likely as the complexity rises to meta-package levels, those who want to > try them must load an overlay. As someone who selectively unmasks and > tries these, having them in-tree but hard-masked is convenient, but I > understand why projects may prefer overlays in many cases. We do tend to prefer overlays in many cases for unstable releases. The project proposal at hand is of course talking about packages that are not available at all in the main tree yet. Overlays are quite nice for tracking unstable releases of package sets that do have their upstream stable releases in official tree. > However, none of this directly applies to the subject at hand, because > while we're talking new versions of packages already in-tree here, the > subject at hand is packages that aren't in-tree in any form yet. Sorry, still felt like replying with my view on Gentoo vs dist-upgraded distros :) -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Thu, 2009-05-14 at 19:24 +0100, Roy Bamford wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2009.05.14 01:32, Mart Raudsepp wrote: > > Hello, > > > [snip] > > > Project maintainer-wanted > > = > > > > Abstract: > > There are currently quite some package requests (over 3000) > > languishing > > on bugzilla waiting for a developer or team to get interested and > > package it in the official gentoo-x86 portage tree. However in quite > > some cases that might not happen for quite a while even with very > > popular packages desired by users. The purpose of the > > maintainer-wanted > > project is to get as many of such packages to the official tree as > > possible as a stopgap solution. > > > [snip] > > > > Discuss! :) > > > > Mart Raudsepp > > Gentoo Developer > > Mail: l...@gentoo.org > > Weblog: http://planet.gentoo.org/developers/leio > > > > Mart, > > I'm against for many of the reasons AllanJB outlined. There is no point > in adding more unmaintained packages to the tree. Over time, the > average quality of the tree will suffer. I have not proposed adding unmaintained packages to the tree. I have proposed adding packages to the tree that are maintained. The maintainer-wanted team maintains them actively until a specific team is interested in taking over. Based on other replies to the thread, it seems no-one believes that a special team could add only so many packages that they are capable of maintaining in good quality. Also it has been brought up many times that if there is a popular package not yet in the tree, there will be someone to add and maintain it. But that doesn't seem to be the case when looking at existing maintainer-wanted bugs. Also by having a team for this, the whole team is accountable. If a maintainer-wanted ebuild is added by this team, it is done as a team - if the person in the team most interested in it is busy otherwise, the team will still take care of its bugs and quality and bumps. > We could use user contributed ebuilds attached to bugs as a way to > bring Sunrise to the contributors attention just by posting a comment > to the bug. If the contributor follows up, we get another user > maintained ebuild in Sunrise, which is good, as the current developers > don't have to do all the work. We already know some Sunrise > contributors become developers so perhaps we can use this as a way to > attract more contributors (both users and developers). Meanwhile there is no-one to add packages that are wanted by many users to the official tree. This project is meant as a remedy for that. The proposal also lists various ways for actually finding out what packages are the ones most beneficial to have in the official tree - as opposed to unknown quality attachment in bugzilla, sunrise overlay, other overlays or requests in bug entries without an attached ebuild - as to be able to inflict as much good for the distribution as possible, given the teams current capacity. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On Sun, 2009-05-17 at 12:08 -0600, Ryan Hill wrote: > On Thu, 14 May 2009 03:32:12 +0300 > Mart Raudsepp wrote: > > > Project maintainer-wanted > > = > > > > Abstract: > > There are currently quite some package requests (over 3000) languishing > > on bugzilla waiting for a developer or team to get interested and > > package it in the official gentoo-x86 portage tree. However in quite > > some cases that might not happen for quite a while even with very > > popular packages desired by users. The purpose of the maintainer-wanted > > project is to get as many of such packages to the official tree as > > possible as a stopgap solution. > > Actually, I'm working on a "get the crap out of the tree" project that is > pretty much the exact opposite of this. ;) I don't think it opposes it much, maybe only 2-5% of maintainer-needed packages. Popular packages aren't crap. Their packaging ease might be, but obviously people want to use those if they are popular, hence we can't dub them really "crap". We could say those packages are "crap" that get building bugs filed by tinderbox runs from Patrick, Diego and other such people, while no-one else has cared. The maintainer-wanted project would not be interested in any such packages. Those are obviously dead applications/libraries that are in no way popular and very beneficial to carry in the official tree. > But, things I like: > > - metrics for package popularity (can we do gentoo-stats already?) Yeah, that'd be cool. Some other metrics ideas I brought out that can be used for this projects purposes while there is no gentoo-stats. > - encouraging teams and maintainers to take an interest in unmaintained > packages It being a project/team making it more likely it doesn't degrade over time when there is no dedicated team maintaining this. Maybe we could make it so that when a package maintained by someone specific (individual or team) that was taken over from maintainer-wanted would drop back to maintainer-wanted team instead of maintainer-needed herd, as the latter currently has technically no members. > - keeping track of maintainer-wanted/needed packages through categorization, > etc. > - proxy-maintainers > > These things I think would benefit both projects, as well as several others. > > I would actually rather see our overall package count dropping than growing, > but if we're adding quality, maintained stuff and tossing out the garbage then > I guess that's an improvement too. Indeed. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Fri, 2009-05-15 at 06:25 -0400, Richard Freeman wrote: > > if you want to exaggerate a bit, we have roughly 500 ebuilds in > portage > > which are maintainer-needed and have only a few users and thats why > you > > want to keep popular packages out of the tree? > > > > Actually, where any of those ebuilds cause problems I'm fine with > getting rid of them. I'm certainly not arguing for inconsistency. > I'm > just suggesting that we shouldn't make the problem worse. I'm not suggesting to make the problem worse either. On the contrary. maintainer-needed packages that clearly are used to close by no-one or no-one (based on no-one reporting build bugs or version bump requests or whatever) should probably indeed be last-rited and removed from the tree, especially if there is no active upstream. This seems to be what the treecleaners project is about, and maintainer-wanted is not meant to have anything to do with that. It is about getting popular packages (based on various metrics) into the official tree for easy access and with known quality. > > If a package is popular then somebody should volunteer to maintain it > (whether by becoming a gentoo dev or by starting their own overlay). > If > that isn't happening than clearly the package isn't THAT important. > This is open source - if you have an itch, then scratch it! Don't > just > complain that nobody else is scratching YOUR itch (even if it is a > popular itch). I don't think we have all topics covered by active teams. When maintainer-wanted team packages something in-tree that would be suitable for a certain existing team, the categorization in the proposed listing of maintainer-wanted packages would imply that, so that once they are able to handle more they can take over if it is well suited for their set of packages. Until such a time this kind of packages would be available in great, good or acceptable quality to the users. > > In any case, my opinion is that for packages to be in portage they > should be of a certain level of quality, and a developer should be > accountable for the packages they commit. Anybody is welcome to grab > ebuilds out of CVS, screen them, and commit them. However, if they > cause havoc then the developer can't just say "but it was popular and > unmaintained, so I figured I'd just commit something without looking > at > it." If a developer is willing to commit an appropriate amount of > time > to QA then they essentially have become a maintainer and the package > is > no-longer maintainer-wanted. The maintainer-wanted team would effectively aggregate those people together, so that the end result would be better quality, quicker response times and so on. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Thu, 2009-05-14 at 10:50 -0400, Richard Freeman wrote: > Mart Raudsepp wrote: > > > > Liking and using the package yourself shouldn't be a prerequisite for a > > package getting to be in-tree by the maintainer-wanted team. > > How about actually maintaining the package? Yes, actually maintaining the package would be a standard for the project. > For example, user contributes ebuild for foo-1.0. I don't use it or > like it, but I go ahead and throw it into portage. User logs bug that > foo-1.0 wipes out random files from time to time. Nobody looks at said > bug since nobody owns foo, and bug starts getting 3000 "me-too!" > comments. The maintainer-wanted team owns that foo package then, which is why having a different mail alias than the existing one for "new package requests that aren't in gentoo tree yet" would be a good idea. > Some charitable developer takes a look and the problem isn't > obvious and offers to just mask the package. Now 3000 people running > foo are upset for it being de-supported (when it wasn't supported in the > first place). > > Wouldn't it make more sense for people who like the foo-1.0 ebuild to > just stick it in their own ebuild or an overlay and be on their own > (since they're really on their own either way)? Or to move it to > sunrise or some other place where it might actually get some level of > support? I am proposing to have it in the official tree and not having such a situation happen at all by random dev adding it to tree without the intention to maintain it. > If Gentoo is going to distribute an ebuild Gentoo should > Do-It-Right(TM). Why put our name on something we don't really want to > care for? The intention would be to Do-It-Right(TM). -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
On Wed, 2009-05-20 at 01:10 +0200, Jesús Guerrero wrote: > On Wed, May 20, 2009 00:37, Dale wrote: > > That would be the point. Gentoo has its own forum so why have two > > forums? What would be the point in having two places to go look for > > answers? Better yet, why would Gentoo support both forums? > > You mean like all the rest of big distros? :p All the the distros > there have some kind of support in LQ, otherwise they wouldn't be > allowed to have a subforum. All of them have also their own forums. Curious, do they also actively point people in their LQ subforums to their official forums when they get the chance? > Like it or not, LQ is the first place where a newcomer goes. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On K, 2009-05-20 at 11:36 -0400, Richard Freeman wrote: > Mart Raudsepp wrote: > > > > The maintainer-wanted team owns that foo package then, which is why > > having a different mail alias than the existing one for "new package > > requests that aren't in gentoo tree yet" would be a good idea. > > > > Ok, I think I see where you're coming from. Essentially > maintainer-wanted is a group for people who want to collectively manage > ebuilds that don't otherwise fall into any particular project/herd. > Almost like a "misc" herd. > > If the packages are actually being maintained then I have no issues at > all with the proposal - in fact I'd endorse it (for what little that is > worth). However "maintainer-wanted" seems like a bit of a misnomer - > these ebuilds would in fact have a maintainer. Perhaps another name > could be used so that it is easy to distinguish between: > > 1. Packages not in the tree (bugzilla requests/etc). > 2. Packages in the tree that truly nobody is caring for. > 3. Packages in the tree that the proposed project is caring for but > would love to see adopted into another herd/project. > 4. Packages that are part of a more dedicated project/herd, or which > have attention from one or more particular developers. > > I don't question the value in having group #3 which I think is what > you're proposing. But, perhaps it should have a specific name/alias so > that we can tell that a package belongs to it. Your proposed team could > scour #1/2 for new builds, and bump builds in #3 back to #2 if > necessary. Treecleaners would prune #2 and ignore #3. Of course, > cooperation with Sunrise would also be a plus. Yes, that's all pretty much what I have in mind here. I have also acknowledge in various e-mails that we need a better naming for the "herd" name (not necessarily for the team) to distinguish bugzilla bugs that are maintained by this proposed team and new package request bugs that are still waiting for someone to pick them up. Also I hope the flow from #3 to #2 doesn't end up happening often and that the team would be caring about the packages in acceptable quality until it can flow to under #4. So some (in)formal policies amongst the team members to ensure the team doesn't get overwhelmed would seem appropriate. I hope the person I found to lead this project (if in the lack of others willing to do that when it becomes an actual project) clarifies things in the project proposal draft that opened this thread, which could then in the end be mostly re-used as the project page text on gentoo.org -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On N, 2009-05-28 at 11:55 +0400, Peter Volkov wrote: > В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет: > > Project maintainer-wanted > > = > > Mart, I think that it's good idea to create such project but with a > different goals. I think currently maintainer-wanted alias is missed by > most developers: new packages are assigned there and from time to time > random developer picks package he needs or user moves ebuild into > Sunrise but nobody actually cares about packages/mail going there in > general. The goal of maintainer-wanted project could be just gather > statistics and highlighting most popular/interesting packages there. > Something like "Top 10 most popular maintainer-wanted packages" monthly > e-mail could be really useful. Good idea in my opinion, but in a different way - the team could maintain such a (unordered) list with varying package count size and pick the packages to put to portage tree by them out of that list as well when the manpower allows to maintain the package in question. But having a list before actually packaging them in official tree could serve as another list where other maintainers could pick them up and package them before maintainer-wanted would, skipping the otherwise supposedly short time maintainer-wanted would be maintaining it -- packages that are maintained by maintainer-wanted would have a list to pick from as well, and the interested maintainer could find it from that one too. Above when I said "maintainer-wanted" I meant the herd/team with another more suitable name then to not confuse with bugs assigned to that alias that are still not maintained by anyone in the official tree (yes, co-operation with Sunrise and the like I'd see as important). -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On K, 2009-05-20 at 00:55 +, Duncan wrote: > Mart Raudsepp posted > 1242777068.30374.30.ca...@localhost, excerpted below, on Wed, 20 May 2009 > 02:51:08 +0300: > > > It is about getting popular packages (based on various metrics) into the > > official tree for easy access and with known quality. > > Perhaps some concrete examples of packages you have in mind might be > useful. A big part of the thing is to get things better qualified in popularity. Encouraging users on maintainer-wanted bugs (automatically adding a link to a describing page if assignee=maintainer-wanted?) to leave their votes appropriately, automated methods to sort bugs based on comment and activity, comparing with popularity metrics in other distributions that have something like the not-really-existing yet gentoo-stats, perhaps working on gentoo-stats, etc etc. > I list in the footnote[1] a couple I originally merged from > sunrise, that are now in-tree. I that the type of package you had in > mind? What /about/ sunrise packages? Will you be working with them to > bring "popular" packages from there in-tree too? > > Of course in your case the ebuilds aren't in the tree yet, but bug > numbers for apps you believe fit the "popular" description might be > useful. "Popular packages" is a nebulous enough term on its own, that > some examples might help. These metrics should be worked out by an upcoming team then, not ignoring common sense. But perhaps a few examples then: miro songbird moovida (previously known as Elisa Media Center) paperbox shutter I see many of the ones I was able to list seem to be either complex deptree packages that no-one has been motivated enough yet to push through (so hopefully once that hard work gets done once, a dedicated maintainer is found easily), and stuff that would be cool to use once it's easily available and found, but not something people very much depend on to care that much alone for themselves, hence a team finding such packages at first could be useful. > Also, an example or two of what you might consider a borderline case, > that you might consider adding if the load on the proposed project wasn't > too high already, but would reject if it was. Feel free to add comments > or explanations on how you came to that conclusion, both for the popular > and borderline examples, as well, if you think it necessary. > > . > > [1] I still use sys-apps/moreutils. > > The other one was www-plugins/swfdec-mozilla and its dep media-libs- > swfdec, which I had some trouble with and eventually unmerged in favor of > a couple of youtube downloaders, since youtube was what I mainly used > swfdec for anyway. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: > USE network is used by 9 ebuilds, and one is using USE networking which > can be converted, that'd be 10. > > > USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx > and others. > > USE static-libs to enable or disable static libs (archives), used by 6 > ebuilds, soon more. > > USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support. > > Any objections? Could you share it with everyone what the proposed global descriptions of these USE flags would be, and what the individual local USE flag descriptions currently are? So that everyone won't need to look up by themselves or guess the global description. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
On K, 2009-06-03 at 21:02 +0300, Samuli Suominen wrote: > Mart Raudsepp wrote: > > On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: > >> USE network is used by 9 ebuilds, and one is using USE networking which > >> can be converted, that'd be 10. > > USE network "Enable networking support" > > >> > >> > >> USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx > >> and others. > > USE 3dnowext "Adds support for 3dnowext multimedia processor instructions" > > (desc. almost copy from 3dnow desc) Maybe it could say in parenthesis what kind of processors have it "(foo and later vendor bar CPUs)" or something if it can be classified like that. I think it's still pretty AMD specific and introduced with a certain family. > >> > >> USE static-libs to enable or disable static libs (archives), used by 6 > >> ebuilds, soon more. > > USE static-libs "Build static libraries" I think this should be clear on that dynamic libraries are still built and installed "Build static libraries in addition to shared libraries" > >> > >> USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support. > > USE mtp "Enable support for Media Transfer Protocol" > > >> > >> Any objections? > > > > Could you share it with everyone what the proposed global descriptions > > of these USE flags would be, > and what the individual local USE flag > > descriptions currently are? You seem to have ignored this part. I guess I'm just lazy to go look up what packages actually have those as a local USE flags and go viewing metadata.xml of each of those. > So that everyone won't need to look up by > > themselves or guess the global description. > > > > > Thanks Samuli >
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On E, 2009-06-01 at 10:48 +0200, Patrick Lauer wrote: > People I nominate: > > * leio / mraudsepp, because he's done a really good job protecting the > distro's interests I accept -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for June 25
On E, 2009-06-22 at 21:23 +0100, Ciaran McCreesh wrote: > On Mon, 22 Jun 2009 22:13:31 +0200 > Ulrich Mueller wrote: > > | (so that certain people can't vote and discuss things based upon > > | what they think the feature is without bothering to find out if it's > > | anything to do with what they assume). > > > > Of course that's not desirable. But can you give a concrete example > > where such a thing happened? > > Yup. Some of leio's huge drawn out objections to EAPI 3 that wasted > huge amounts of my time were based upon him only having read the short > name we chose for things. Thanks for your very detailed concrete examples where such a thing happened. And I'm sorry to have wasted your precious time by doing the opposite of what you claim here and still objecting to things that don't make sense. Now lets get back to useful things, like giving "code names" that make sense and don't need to be looked up with what is actually meant when they are being referred to in short names. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for June 25
On E, 2009-06-22 at 15:18 -0400, Thomas Anderson wrote: > (This is late because I was traveling and dev-zero is/was on devaway.) > > This is your friendly reminder! Same bat time (typically the 2nd & 4th > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ > irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even vote > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > list to see. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ > > > Attached is the preliminary meeting agenda. I acknowledge that agenda, or something. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2009 Council Elections
On E, 2009-06-29 at 12:32 +, Ferris McCormick wrote: > On Sun, 2009-06-28 at 18:12 -0500, Dale wrote: > > Roy Bamford wrote: > > > > > > > > > You agree that common sense can't be used and admit that a corner case > > > exists that would in effect have the trustees pointing out to the > > > council that they had made an error of judgement and need to reverse a > > > decision that the last meeting made. I would prefer never to have to go > > > there. > > > > > > I do not agree that an all proxy council meeting shows that the council > > > does not take its responsibilities very seriously, rather that real > > > life has hit everyone at the same time and they have appointed > > > proxies. GLEP39 does not even set a limit on the maximum number of > > > council members who may be proxied at any single meeting. > > > > > > As I have already said, I'm against the idea of proxies altogether. > > > We should amend glep39 to remove proxies and ensure that council > > > members are drawn from the developer community. Of course, that > > > does not eliminate the possibility of the trustees pointing out to the > > > council that they need to reverse a decision but it does ensure that > > > decisions are made only by council members who are Gentoo developers. > > > > > > > I'm just picking a random message so no fingers being pointed here. > > > > As a long time Gentoo user, I have to ask. Why is that EVERYONE on the > > council must be there or have someone there to represent them? Would > > Gentoo come to a end if one person or even two people were not present? > > > All that's required is a quorum (4 out of 7) to hold a meeting. And when you have one less, it apparently immediately means a new council election. I guess that's one reason these days to always appoint proxies. The other is otherwise getting a missed meeting record, then a slacker mark and then a boot. And then there's the long tradition of always when a meeting un-attendance is foreseen a proxy getting appointed. I guess the new council can think about this, but a) time spent on figuring out such rules and whatnot to have to deal with unfortunately happening corner cases is time better spent on getting actual Gentoo improving done b) I don't think the council itself should be having so much to do with any such figuring out c) there are far bigger reaching restructuring ideas in the works for future proposals > > I do agree that if a proxy is going to be used, they should be a > > developer. If it is not that way now, it should be changed. I been > > using Gentoo for years and wouldn't even consider serving as a proxy. I > > would certainly not want to be a tie breaker on a vote. > > > > As a American that sees his own country's government getting out of > > control, never count on common sense. Elected people rarely have any. > > If they do during the election, it disappears after taking their > > position. I think the vast majority of people here have seen that over > > the years. > > > > My $0.02 worth. > > > > Dale > > > > :-) :-) > > Regards, > Ferris -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On L, 2012-06-23 at 15:10 +0100, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 10:06:58 -0400 > Mike Gilbert wrote: > > > I don't quite understand why this would be necessary. > > > > > > Would "funky-slots" just be used in situations where ebuilds with > > > the same PV but different PVR have different slots? > > > > > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only > > > used in libraries; applications use slot deps to select which one > > > they need. Paludis should not remove the -r200 version if it is > > > still referenced in the depgraph, correct? > > > > Or maybe you are saying that Paludis will not automatically install a > > new slot for a package that is already installed, even when referenced > > by a slot dep? > > The 'standard' behaviour (which can be changed by the user) for Paludis > when doing "complete" resolutions is that whenever there's a slot of > something installed, it will try to bring in the newest version of that > package, even if it's in a different slot. This is generally a good > thing, since newer versions are supposed to be better than older > versions. The problem is that now "newer" versions are being used to > mean "with a different Ruby implementation" or "built in a different > way", which screws up the meaning. Don't do that if the slotted package in question is not in the @world, and all packages depending on it strictly require the older SLOT.
Re: [gentoo-dev] Global Systemd USE Flag
On N, 1970-01-01 at 00:00 +, Jason A. Donenfeld wrote: > On Wed, Aug 8, 2012 at 4:33 PM, Michał Górny wrote: > > You are right. In case users really intend to use that, they may be > > better using app-portage/install-mask, and: > > > > $ install-mask -a systemd > > > > which will add just the right path. > > Still misses the point. USE flags were invented to deal with these > options. On a default install, which uses OpenRC, users shouldn't have > to then emerge an additional program to add more configuration in > order to have a clean system. USE flags are not meant for controlling every little thing, such as conditional installing a 400 byte file that does no harm when not used, other than taking 1 block of filesystem space (4kB or so), which can be workarounded by INSTALL_MASK if you are building an embedded system. I seriously doubt they were invented for such a purpose, but rather to control ./configure arguments and external dependencies. No, wanting to get rid of those on a desktop/server via a USE flag (as opposed to an INSTALL_MASK) is not a consideration, as that's users completely unneeded desire for no technical reason. If taking 500kB total for systemd service files is an issue, then the issue really is that you are using a 1GB /usr partition or something. This all is similar to how we in GNOME unconditionally install user and developer documentation, as long as it does not impose any extra build time or downloads. (no, this is not really negotiable for change, and we are talking about more than 400 byte files here; we'd be happy however if portage binary packages supported splitting of the source packages files to separate packages, so that binary distribution derivatives could work in a similar model as purely binary distributions) USE flags typically control the functionality of compiled binaries, usually involving external dependencies to achieve such extra functionality. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap1_sect2 Best Regards, Mart Raudsepp
Re: [gentoo-dev] supporting static-libs
On N, 1970-01-01 at 00:00 +, Gregory M. Turner wrote:
> On 8/28/2012 1:09 AM, Michał Górny wrote:
> > On Tue, 28 Aug 2012 02:15:40 +0200
> > hasufell wrote:
> >> static-libs
> > pointless
>
> I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
> where one can have static or dynamic, but not both, as per. upstream
> requirements (no idea why). So FTR, this is not always a matter of
> personal taste.
static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.
Best,
Mart Raudsepp
Re: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?
On N, 1970-01-01 at 00:00 +, Tobias Klausmann wrote: > Hi! > > On Wed, 29 Aug 2012, William Hubbs wrote: > > On Wed, Aug 29, 2012 at 01:57:48PM +0200, Tobias Klausmann wrote: > > > As a first crude datapoint, I compared the build times > > > (configure+make) of udev-171-r6 and -188 on our dev Alpha. This > > > is a machine that's on the speedier side of off-mainstream > > > architecures, but as a datapoint, it should be enough. > > > > No, not exactly, because udev-188 doesn't build systemd. We use > > specific targets in the Makefile to avoid doing that. > > Amending my earlier post then, here are the numbers for the > 171 build and the target-specific build of 188: > > ver (1)(2) (1+2) > udev-171-r6: 15s / 71s / 86s; 1m26s > udev-188 : 28s / 78s / 116s; 1m56s > > Much less difference. Still, I figure _really_ slow > machines/arches might be in more pain. I'll run my test with a > Geode-based x86 later this week. Geode LX700 (433MHz) with 256MB RAM MAKEOPTS=-j2 (single core system) gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2 ebuild prepare done before as well. 1. time ebuild foo configure — real time value 2. time ebuild foo compile — real time value ver (1) (2)(1+2) udev-171-r6: 47.2s / 4m36.4 / 5m23.6 udev-188 : 69.6s / 6m27.2 / 7m36.8 Personally of course don't care the slightest of this time. Mart
[gentoo-dev] Use slot deps for all gstreamer package dependencies (including plugins); preparation for gstreamer-1.0
Hello, The release of a new major GStreamer 1.0 release is going to happen soon. It will be parallel-installable with the 0.10 series, so it will be eventually introduced as a separate SLOT and co-exist for a while. As such, if you maintain any packages that have any dependencies on media-libs/gstreamer media-libs/gst-plugins-* media-plugins/gst-plugins-* please get ready for it by pinning the dependencies to the appropriate SLOT, which should currently be 0.10 in all cases. Use SLOT deps if at all possible with your used EAPI, or at least a =media-plugins/gst-plugins-foo-0.10* kind of dependency. This way I'll have less package maintainers to chase around and bugs to file once it's actually time to introduce the new SLOTs to the tree (having all currently packages properly slot depend on 0.10 is considered a blocker for 1.0 introducing). media-libs/gst-plugins-bad used to be SLOT=0 accidentally, but this has been slotmoved now, so SLOT 0.10 dep there as well. Thanks, Mart Raudsepp
[gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
Hello, I am working towards having a clean deptree for arm64 and afterwards marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see value in the developer profile without the desktop specific subprofiles, until there are mix-ins). This e-mail is meant to make sure there are no other pre-requisites for just flipping the switch in profiles.desc from exp to stable, and to express that intent and garner any hands-on help. Also some eyes on the profiles (profiles/arch/arm64/*) would be useful, especially from those who knows how all these CHOST/LIBDIR and other things need to be, to make sure these are all right before the profiles go stable. Currently my plan is to solve all the deptree issues by mostly stable use masks where needed (the stage building stable keywords haven't kept the deptree in mind so far, just for what USE flags are enabled for stage building), and keywording ~arm64 or use.mask/package.use.mask'ing to fix the ~arm64 deptree too (depending on if I want it keyworded immediately, or delay for future consideration and fix the deptree by use masks till then). I'm having the CI hamsters spin for this at https://github.com/gentoo/gentoo/pull/3622 Yes, there is quite some work to do, but this e-mail is meant to get any necessary formalities out of the way in parallel, so we can get the switch flipped right after instead of discussing it then, and not continue a chasing game due to repoman not telling to file a KEYWORDREQ for us for new deps. Note that there is no arm64 project as of yet, it's been worked on to some capacity as part of arm project, which I believe to be a bit confusing (albeit similar to ppc/ppc64), but also a bit daunting with the arm4/5/6/7/vfp/neon/etc combination explosion stuff in arm32 land (so I think it's good to have a clean break there with project documentation pages, people involvement, etc). I haven't been able to convince steev as of yet about this and haven't exercised any project creation rights myself yet :D Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
Ühel kenal päeval, L, 04.02.2017 kell 07:26, kirjutas Mart Raudsepp: > Hello, > > I am working towards having a clean deptree for arm64 and afterwards > marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see > value in the developer profile without the desktop specific > subprofiles, until there are mix-ins). > > This e-mail is meant to make sure there are no other pre-requisites > for > just flipping the switch in profiles.desc from exp to stable, and to > express that intent and garner any hands-on help. Lots of concerns, I see from the zero replies so far :) To make it easier to handle new keywording that's happening earlier too in parallel, I now additionally plan to move half of these profiles from exp to dev in a couple of days, so that when repoman -d is used, it catches it, and when repoman -e y is used, it catches things too with the profiles that are left in exp for now. Moving from there to stable profile would not be done without the deptree fully clean, of course. Additionally there have been questions about stable keywords: I don't have short term personal plans on doing any new stable keywords until I'm done with having useful desktops in ~arm64. To get us towards stable _profiles_, I plan to use.stable.mask or package.use.stable.mask and so on as appropriate if possible, and only look into a stable chroot and stable keywording when that's not reasonable. Then afterwards yes, there is the intention to also have a bigger stable tree, but for me that's more like a 2-4 months timeline from now to even start there, depending on helping manpower and the capability to keep up. And also in the future I do want us to be a security supported architecture, given sufficient manpower and such. > Also some eyes on the profiles (profiles/arch/arm64/*) would be > useful, > especially from those who knows how all these CHOST/LIBDIR and other > things need to be, to make sure these are all right before the > profiles > go stable. > > > Currently my plan is to solve all the deptree issues by mostly stable > use masks where needed (the stage building stable keywords haven't > kept > the deptree in mind so far, just for what USE flags are enabled for > stage building), and keywording ~arm64 or > use.mask/package.use.mask'ing > to fix the ~arm64 deptree too (depending on if I want it keyworded > immediately, or delay for future consideration and fix the deptree by > use masks till then). > I'm having the CI hamsters spin for this at > https://github.com/gentoo/gentoo/pull/3622 > > Yes, there is quite some work to do, but this e-mail is meant to get > any necessary formalities out of the way in parallel, so we can get > the > switch flipped right after instead of discussing it then, and not > continue a chasing game due to repoman not telling to file a > KEYWORDREQ > for us for new deps. > > Note that there is no arm64 project as of yet, it's been worked on to > some capacity as part of arm project, which I believe to be a bit > confusing (albeit similar to ppc/ppc64), but also a bit daunting with > the arm4/5/6/7/vfp/neon/etc combination explosion stuff in arm32 land > (so I think it's good to have a clean break there with project > documentation pages, people involvement, etc). I haven't been able to > convince steev as of yet about this and haven't exercised any project > creation rights myself yet :D > > > Mart
[gentoo-dev] GNOME team meeting 2017-02-10
The Gentoo GNOME team will meet on Friday 2017-02-10, 20:00 UTC in the #gentoo-meetings channel on Freenode. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170210T20 Agenda: * GNOME 3.22 stabling status ** Should we revert default session to X11 before stabling even if USE=wayland is used, as 3.24 is close-by that makes it work better and some team members themselves are having issues with it on 3.22? * Do we need an upgrade guide for 3.22? * - ebuilds in main tree? * Overlay vs main tree for beta/rc releases * Overlay vs main tree for early development releases * Meta packages dependencies and USE flags (gnome, gnome-light, gnome- core-libs, etc) * Lead elections (might get deferred to e-mails for a quorom) * Open floor signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
Ühel kenal päeval, E, 06.02.2017 kell 04:59, kirjutas Mart Raudsepp: > To make it easier to handle new keywording that's happening earlier > too > in parallel, I now additionally plan to move half of these profiles > from exp to dev in a couple of days, so that when repoman -d is used, > it catches it, and when repoman -e y is used, it catches things too > with the profiles that are left in exp for now. > Moving from there to stable profile would not be done without the > deptree fully clean, of course. I've now finally moved default/linux/arm64/13.0 default/linux/arm64/13.0/desktop/systemd from exp to dev as told, with no concerns raised meanwhile. That'd be the main profile and the profile I'm using (or will be using soon instead of just 13.0/systemd). With this I have repoman -d full mostly complaining about stuff I can fix (arm64 and mips), but also some prefix, and various hardened/uclibc stuff that seems to insist to not inherit /profiles/arch//, but I can avoid some of that with --include-arches. For eventual stable profile once issues are fixed, I'm not sure anything more than the arm64 main profile is needed for the time being, in anticipation of mix-ins and other arch profiles mostly covering the targets/features stuff anyways. Mart
[gentoo-dev] Last rites: media-plugins/gst-plugins-ffmpeg
# Mart Raudsepp (16 Feb 2017) # Old gstreamer 0.10 version, which is security vulnerable. # Use gstreamer:1.0 with media-plugins/gst-plugins-libav # instead (despite the name, it uses media-video/ffmpeg too). # Masked for removal in 30 days. Bug #594878 media-plugins/gst-plugins-ffmpeg signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/
Ühel kenal päeval, L, 18.02.2017 kell 19:47, kirjutas Michał Górny: > commit: 7207a292b2591dde5cbd336470bed3c11617a8e1 > Commit: Michał Górny gentoo org> > CommitDate: Sat Feb 18 19:47:25 2017 + > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7207 > a292 > > dev-util/wxglade: python-single-r1, EAPI=6 While I appreciate work done to do this conversion finally, what was the reason to bypass the maintainers after being explicitly told on IRC to not do so? Since when have we entered a free-for-all state of maintenance in Gentoo? I would like to know the state of affairs, so I know for future reference what can I expect and what I can do to packages that I do not explicitly maintain either. And yes, I am aware there was a pending bump request for a couple years. I'm still dealing with backlog after getting back to tree maintenance. Mart Raudsepp, thoroughly confused about current maintenance policies
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/
Ühel kenal päeval, L, 18.02.2017 kell 22:03, kirjutas Mart Raudsepp: > Ühel kenal päeval, L, 18.02.2017 kell 19:47, kirjutas Michał Górny: > > commit: 7207a292b2591dde5cbd336470bed3c11617a8e1 > > Commit: Michał Górny gentoo org> > > CommitDate: Sat Feb 18 19:47:25 2017 + > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=72 > > 07 > > a292 > > > > dev-util/wxglade: python-single-r1, EAPI=6 > > While I appreciate work done to do this conversion finally, what was > the reason to bypass the maintainers after being explicitly told on > IRC > to not do so? > Since when have we entered a free-for-all state of maintenance in > Gentoo? > I would like to know the state of affairs, so I know for future > reference what can I expect and what I can do to packages that I do > not > explicitly maintain either. > > And yes, I am aware there was a pending bump request for a couple > years. I'm still dealing with backlog after getting back to tree > maintenance. > > > Mart Raudsepp, > thoroughly confused about current maintenance policies Hello? wxglade was just one example that affected me, and actually a bad example, but I see constant commits to anything and everything by people not maintaining something, to teams that have not declared their packages open for fixing by anyone nor without Acked-by's; coupled with constant talks of everything being crap, ebuilds being retarded and whatnot. Not a very motivational speak, I must add. What is going on? Do I need to revise how I would judge an ebuild quiz question 12 answer for any future mentees? Mart Raudsepp
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/
Ühel kenal päeval, E, 20.02.2017 kell 13:50, kirjutas Mike Gilbert: > On Sat, Feb 18, 2017 at 3:03 PM, Mart Raudsepp > wrote: > > Ühel kenal päeval, L, 18.02.2017 kell 19:47, kirjutas Michał Górny: > > > commit: 7207a292b2591dde5cbd336470bed3c11617a8e1 > > > Commit: Michał Górny gentoo org> > > > CommitDate: Sat Feb 18 19:47:25 2017 + > > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id= > > > 7207 > > > a292 > > > > > > dev-util/wxglade: python-single-r1, EAPI=6 > > > > While I appreciate work done to do this conversion finally, what > > was > > the reason to bypass the maintainers after being explicitly told on > > IRC > > to not do so? > > Since when have we entered a free-for-all state of maintenance in > > Gentoo? > > I would like to know the state of affairs, so I know for future > > reference what can I expect and what I can do to packages that I do > > not > > explicitly maintain either. > > > > And yes, I am aware there was a pending bump request for a couple > > years. I'm still dealing with backlog after getting back to tree > > maintenance. > > > > Mart Raudsepp, > > thoroughly confused about current maintenance policies > > > > At some point, if the maintainer isn't doing his job, he gets > bypassed. Especially when dealing with a conversion like > python.eclass > where few people know or care how it works. If we waited for > individual maintainers it will never get done. > > Unless you have some reason to slow him down, please get out of his > way and let him work. I am talking about the general attitude and approach as well. But if we want to be stuck in this concrete case then the tracker bug for eclass removal and conversion was filed less than 3 hours prior to maintainer bypassing commit. The blocker to wxglade was marked also less than 3 hours prior to maintainer bypassing commit, and the commit was pushed at the same time as talking about how this and that thing is crap and other demotivational speech with the actual maintainer around and active, saying to contribute a patch to review and push in together with other changes (like that version bump). This is very demotivational, and in fact I ended up doing no gentoo work afterwards over the weekend, primarily because of all this nasty experience. Have respect towards others and their wishes and their maintenance and don't run over other people and maintainers. Do not run over maintainers after a 3 hour period of bug filing (or rather marking a wrong bug as a blocker to the eclass removal, receiving instant replies to that, so clearly an "inactive" maintainer, and then still ignoring everything and committing and pushing regardless). You are not special. Mart
Re: [gentoo-dev] Re: [PATCH] sys-libs/glibc: Convert from eblits to eclass, #586422
Ühel kenal päeval, N, 16.03.2017 kell 12:55, kirjutas Joshua Kinard: > On 03/16/2017 09:49, Michał Górny wrote: > > // > > note: i'm in process of testing [building binpkgs] of all glibc > > versions > > to confirm i didn't accidentally break anything. - fails in > > compile > > phase both before and after the change. > > > > --- > > [snip] > > You need to make a catalyst run as well, especially a stage2 run > which will > invoke /usr/portage/scripts/bootstrap.sh, to cover all corner cases. probably also crossdev usage would be good to test (initial setup, cross-*/glibc upgrade, etc).
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
Ühel kenal päeval, E, 27.03.2017 kell 11:07, kirjutas Fabian Groffen: > On 27-03-2017 09:56:50 +0200, Ulrich Mueller wrote: > > > > > > > On Mon, 27 Mar 2017, Fabian Groffen wrote: > > > > > When you say "arch" you actually mean a keyword as per GLEP- > > > > > 53[1] > > > > > right? > > > > > > > > Which doesn't agree with actual usage in the tree, though. > > > That surprises me. Do you have an example of that? > > > > The GLEP says about the OS suffix: > > > > "The right hand part indicates the operating system or > > distribution, > > such as linux, macos, solaris or fbsd. If the right hand part is > > omitted, it implies the operating system/distribution type is > > GNU/Linux." > > > > So if I understand this correctly, x86-linux should be equivalent > > to > > x86. But in reality, the linux suffix denotes that it is a prefix > > arch. I'm not saying that this is bad, only it's not what the GLEP > > says. > > I see. The lack of explicit mentioning what the difference means > allows > for different interpretations. I always *assumed* it meant Gentoo (1 > part) vs Gentoo/Alt (2 parts). > > > Until recently there was also x64-freebsd vs amd64-fbsd, where both > > the arch and the OS part denoted the same, but used different > > tokens > > to distinguish between prefix and non-prefix. (And I don't > > understand > > why amd64 is called x64 on prefix. A different OS suffix should be > > sufficient.) > > It kind of proves the point that two fields in a keyword isn't > "enough > for everyone". > > Back to the topic of the thread, is it possible to make the > difference > between e.g. x86, x86-linux, x86-solaris and x86-macos in this > proposal? > I believe the intention here is for this file to declare stuff about an "arch" in terms of what repoman names it as such (--include-arches=, etc), and what profiles.desc has as the first column value (in comments it also names that column "arch"). The filename "arches.desc" just comes from that convention, while indeed it really matches what you put in KEYWORDS in terms of ebuild usage. I guess that filename is a shed to paint then too. Mart
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
This looks good overall, thanks. If we stay with the whitespace separated columns, the spec should be clear that implementations should be able to deal with future additional "columns" in their parsing code. Below some paint choices from me. > We introduce a new file "arches.desc" which essentially describes if > an arch > (not a profile) is stable or not. The meaning of profiles.desc is not > affected; Essentially the proposal extends profiles/arch.list but due to backwards compatibility can't just add details there. As such, in my opinion the file should be called arch.desc (not plural arches.desc) to go along with that. > 1] File location: > profiles/arches.descor metadata/arches.desc profiles/arch.desc or metadata/repoman/arch.desc > 3] Meaning of the three values "stable", "testing", "unstable" for > repoman > > * stable: When a profile of arch is tested, then repoman checks > consistency for > "arch" and for "~arch" separately. > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). > This is the current behaviour and should be the default if nothing is > specified > for an arch. > > * testing: When a profile of arch is tested, then repoman treats > "arch" as > "~arch", and tests consistency only for "~arch". > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). > A new switch for repoman may be provided to temporarily upgrade an > arch from > "testing" to "stable" (for arch team work). > > * unstable: When a profile of arch is tested, then repoman treats > "arch" as an > error and aborts. Consistency is only tested for "~arch". > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). This sounds more like "testing" to me - architecture is only meant to have "testing" keywords, which is what I tend to call ~arch because it's in testing to become "stable" in ~30days or so, instead of calling it "unstable" (which feels appropriate only for a package that doesn't carry any stable keywords in older versions either). While taken from another perspective, the meaning for "testing" as in this proposal makes sense too - treat all as "testing" keywords. This goes back to the overloaded terminology concerns that have been echoed by others as well. But I don't have any good suggestions for alternatives either right now. stable/no_stable_check/testing_only? shrug. > 4] Meaning for other tools > All arches set to "stable" are considered "stable arches", meaning > * they get listed first in eshowkw > * they require stabilization requests in bugzilla > * ... If other tools use this, then maybe the repoman specific metadata/repoman/ path isn't appropriate afterall. So then profiles/arch.desc or metadata/arch.desc Mart
[gentoo-dev] Last rites: gnome-extra/gnome-shell-extensions-topicons
# Mart Raudsepp (04 Apr 2017) # Masked for removal in 30 days. Does not work with new # gnome-base/gnome-shell. # gnome-extra/gnome-shell-extensions-topicons-plus is a # fork that has added features and works with modern # gnome-shell that is suitable as a system-wide replacement # package. Alternatively it can be installed per-user from # https://extensions.gnome.org/extension/1031/topicons/ gnome-extra/gnome-shell-extensions-topicons
Re: [gentoo-dev] Reverse use of Python/Ruby versions
Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L. Thomson Jr.: > Again go modify a few hundred python packages to remove say 3.4. I > think about 10-20 ebuilds in. You will be scripting and looking for > another way No, for that you simple remove python3_4 from _PYTHON_ALL_IMPLS in python-utils-r1.eclass and call it a day. Some other day you might make a mass commit to remove 3_4 from PYTHON_COMPAT of all in-tree ebuilds, but that's just janitorial and no other effect. The current implementation makes perfect sense to me, and follows one of the zens of python: Explicit is better than implicit. Declare explicitly what version is supported, don't implicitly do so and merely hope there are no issues. If some lower level module doesn't work with new python and your higher level module wants to use the new python, repoman will catch it for you due to it having been explicit via PYTHON_USE_DEP. There is no difference with reverse approach if one would mass commit the new COMPAT into all ebuilds upon the introduction of a new python slot, but this is not done, because things would break. Mart
Re: [gentoo-dev] Reverse use of Python/Ruby versions
Ühel kenal päeval, E, 10.04.2017 kell 15:38, kirjutas William L. Thomson Jr.: > On Mon, 10 Apr 2017 21:57:10 +0300 > Mart Raudsepp wrote: > > > Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L. > > Thomson Jr.: > > > Again go modify a few hundred python packages to remove say 3.4. > > > I > > > think about 10-20 ebuilds in. You will be scripting and looking > > > for > > > another way > > > > No, for that you simple remove python3_4 from _PYTHON_ALL_IMPLS in > > python-utils-r1.eclass and call it a day. Some other day you might > > make a mass commit to remove 3_4 from PYTHON_COMPAT of all in-tree > > ebuilds, but that's just janitorial and no other effect. > > Ebuilds still must be touched right? Even if just for house cleaning. > That is some 1600+ ebuilds right? What about when a new version is > added? Re-touch all those same ebuilds right? After testing they actually work with the new version, instead of throwing known breakages onto ~arch users. > Am I missing something? You are missing the fact that this is pure janitorial in case of removal of a python3 SLOT, which can be done with scripts in one big commit. The effective change is all done in one touch of some eclass and then any 3_4 in PYTHON_COMPAT just doesn't have any effect. So removal of old stuff is not a concern whatsoever. The janitorial part doesn't have to be done, but because there are scripts that can do it mostly automatically one evening, it can get done after it's sure it won't have to be re-added for some reason in the eclass.
Re: [gentoo-dev] Reverse use of Python/Ruby versions
Ühel kenal päeval, E, 10.04.2017 kell 16:01, kirjutas William L. Thomson Jr.: > On Mon, 10 Apr 2017 22:51:35 +0300 > Mart Raudsepp wrote: > > > > After testing they actually work with the new version, instead of > > throwing known breakages onto ~arch users. > > Ebuilds cannot use the new version till it is added to their > PYTHON_COMPAT correct? > > There does not seem to be any way around touching all ebuilds when > adding a new version. > > > > Am I missing something? > > > > You are missing the fact that this is pure janitorial in case of > > removal of a python3 SLOT, which can be done with scripts in one > > big > > commit. > > Ok I concede on removing older versions. Lets put old version aside. > > What about adding new? You still have to add the new version to > PYTHON_COMPAT in each ebuild right? > > What about users? Do they need do anything if they have specific > targets > set? Or all should just use Wildcard and if in ~arch have 3-4+ > pythons. > > Even if house cleaning, removing old is not an issue. You still have > adding new, and the end user experience. The user experience is suboptimal either way. Some ideas to improve that seems to be e.g something like Kent brought up. But all this requires manpower and so on to actually do; potentially also limiting potential manpower to whom has or can get some deep graph theory knowledge. Explicitly adding things is better, so you don't get some huge unknown breakages of some lower level module not working and then having to work your way towards all consumers and adding the fact they don't work there too, because a dependency doesn't work. The reverse is not feasible due to the breakages, and when you are entering automated testing to catch breakages, you might as well do automated testing and semi-automated addition to PYTHON_COMPAT for stuff that succeeds in this automated testing. We are stuck on defaulting to 3_5 mostly because not everything having 3_5 in COMPAT isn't stable yet or whatnot, combined with python teams conscious decision to tie the stabling of a new dev-lang/python SLOT (that didn't have stable versions before) to flipping default PYTHON_TARGETS as well, and then the tracker bug for that being delayed or something. Mart
