[gentoo-dev] Last rites: app-admin/hwreport
# Christian Faulhammer (02 Sep 2014) # website not working anymore and will stay like this, # tool is useless. See bug 504734 app-admin/hwreport
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail: ChangeLog claws-mail-3.9.1.ebuild
Hi, Michał Górny : > > libnotify is only a fraction of the supported notification means of > > said plugin in Claws. > > Is the remaining fraction usable without libnotify on Gentoo? Yes. Regards V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail: ChangeLog claws-mail-3.9.1.ebuild
Hi, Samuli Suominen : > On 13/05/13 07:46, Christian Faulhammer (fauli) wrote: > > fauli 13/05/13 04:46:01 > > > >Modified: ChangeLog claws-mail-3.9.1.ebuild > >Log: > >move libnotify usage over to notification, forgotten in last > > commit > > > > - $(use_enable libnotify notification-plugin) > > + $(use_enable notification notification-plugin) > > Why deviate from every other ebuild in Portage? From global to > local :-/ libnotify is only a fraction of the supported notification means of said plugin in Claws. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: New USE_EXPAND: CLAWS_MAIL_PLUGINS
Hi, Christian Faulhammer : > the upcoming Claws Mail release will have no separation between > internal plugins (stuff that is built on mail-client/claws-mail with > USE="crypt bogofilter") and external ones (all packages > mail-client/claws-mail-*) anymore. > All are now integrated, which would mean 21 additional USE flags for > Claws or alternatively a new set of CLAWS_MAIL_PLUGINS which includes > the old and new internal plugins. > > Any objections against the addition? Considering all this I will likely drop the idea of IUSE_EXPAND and go with USE flags. All plugins that need no special dependencies will just be built (as they have to be loaded in the interface -> so no cruft) , the rest will be configurable by normal USE flags. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] New USE_EXPAND: CLAWS_MAIL_PLUGINS
Hello everybody, the upcoming Claws Mail release will have no separation between internal plugins (stuff that is built on mail-client/claws-mail with USE="crypt bogofilter") and external ones (all packages mail-client/claws-mail-*) anymore. All are now integrated, which would mean 21 additional USE flags for Claws or alternatively a new set of CLAWS_MAIL_PLUGINS which includes the old and new internal plugins. Any objections against the addition? Wishes V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: How help in arch testing work
Hi,
Alexis Ballier :
> > 4) Nobody knows how work all packages in tree, so there are obvious
> > packages like a browsers, IM, audio player,that is easy decide if is
> > ok or not, but there are also packages that an Arch tester has never
> > seen, so is a lack of time everytime google about it or ask to
> > maintainer, so, please specify what test you want for this package;
> > e.g. -only compile test
> > -compile test and make sure src_test goes well
> > -make sure /usr/bin/${foo} works properly in ${that} manner
> > -see 5) about library
> >
> > So, you can write one time 'how to' and copy/paste for the future
> > stablereq; I guess I'm not asking a long and difficult task.
>
> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.
To stick with the Emacs example: We barely use all those packages we
maintain. So sometimes we do not even execute this documented
test plan ourselves. Of course it only contains a small subset of
everything, but some test plans contain a "fool around with the
program" and it is better than nothing.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: app-emacs/psql
Hi, # Abandoned by upstream, bug 364775 # Use sql.el shipped with GNU Emacs 21 onwards, which is superior # Removal in 30 days V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-cpp/libthrowable and app-portage/gatt
Hi, # Mask for removal, abandoned by upstream with severe bugs, bug 363927 # Use dev-portage/tatt # 30 days to live dev-cpp/libthrowable app-portage/gatt V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Last rites: mail-client/cachesaver
Hi, # Mask for removal, abandoned by upstream, bug 363925 # 30 days to live mail-client/claws-mail-cachesaver V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: euscan proof of concept (like debian's uscan)
Hi, Corentin Chary : > I started this mostly to see if it was possible, and I don't know if > i'll have the time to continue to work on that project, but I think > gentoo really needs an automated way to detect outdated packages. > This could also be a 2011 GSOC project (finishing euscan, and adding a > web based interface to browse the results). Have you applied for a place in GSoC? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Save dev-util/plan9port !
Hi, Andy Spencer : > However, I am not an official gentoo developer so it sounds like I'll > need a "Proxy Maintainer" to review my work and push updates to > portage. Would anyone be willing to do this? Have you found one already? If not, I could take that role. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: virtualx.eclass
Hi, "Tomas Chvatal (scarabeus)" : > Sync virtualx.eclass from x11 overlay as per review ~week ago. Could we have some more verbose descriptions than that in the commit logs? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: gtk 3 preparation work
Hi, Nirbheek Chauhan : > Indeed, it is quite large, coming at ~1100 ebuilds. Hence, I've > attached it instead of pasting it in-line. Unsurprisingly, some are > gnome packages, and even a few maintained by me :p Claws Mail and plugins are fixed. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Bugzilla - New Default Status Workflow
Hi, Christian Ruppert : > We're almost done with the preparation of bugzilla-4.x for > bugs.gentoo.org. So, do we want the new workflow or do we want to > keep the old? New one, reopened is a bit pointless information on first glance. History tells enough. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: About cups-1.4 stabilization
Hi, Pacho Ramos : > Since printing team don't want to use debian patchset, have you think > in simply disabling that new usb backend? If I haven't misunderstood > the problem, disabling it would simply make cups-1.4 behave like 1.3. We just postpone the problem, maybe 1.5 will only have the new one. There is a news item in my todo file: Title: Upgrade to CUPS 1.4 Author: Christian Faulhammer Author: Timo Gurr Author: Gentoo Printing Team Content-Type: text/plain Posted: 2010-09-13 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Suggestion: Portage should not mask packages globally, but only for some arches
Hi,
Nikos Chantziaras :
> On 02/02/2011 10:30 AM, Kacper Kowalik wrote:
> > W dniu 02.02.2011 08:59, Nikos Chantziaras pisze:
> >> It seems that KDE 4.6 is still hard-masked for x86 and amd64
> >> because it's waiting for ppc and ppc64 keywords. I believe it
> >> would be beneficial for people if they wouldn't have to wait for
> >> arches that don't affect them at all.
> >> [...]
> >
> > I don't know what gave you the idea that ppc* has anything to do
> > with masking/unmasking of KDE-4.6. Just 2 facts:
> > 1) you can unmask anything by using /etc/portage/package.unmask,
> > therefore nothing can ever hold *you* back
>
> This is about all users in general. Not just me :-) If putting
> stuff in /etc/portage/package.unmask should be considered the
> recommended solution for this, then we wouldn't need a masking system
> in the first place. When something is hard-masked, it tells the user
> "we're not considering it safe or working yet."
>
>
> > 2) arches already have independent package.mask files, see
> > ${PORTDIR}/profiles/arch/powerpc/package.mask for an example.
>
> It seems they aren't used though. I mainly posted this because of
> the discussion on this page:
>
>http://blog.tampakrap.gr/kde-sc-4-6-0-in-gentoo
>
> It seems devs have can't modify arch/powerpc/package.mask on their
> own? If not, this looks like a problem, delaying packages for all
> arches.
Don't be so impatient...Debian users wait two years for a new major
version of KDE. This is also a general hard mask for wider testing, it
usually gets moved further down the line to individual profiles.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: gentoo-src cvs repo and svn repos migration to git
Hi, Theo Chatzimichos : > I decided to start migrating some CVS and SVN repos to git. First I > should do a cleanup though, and see which ones are still active. > 1) gentoo-src [1] cvs repo contains a number of projects separated to > directories. Most of them seem really old and inactive. I'd like to > point me out the ones that are either still used, or they should be > migrated because they contain usefull data. The others will be > removed. 2) There are a number of svn repos in svn.gentoo.org (the > list is at http://sources.gentoo.org under "Subversion > Repositories"). Same as before, I'd like to point me out the ones > that are still active, and you (the maintainer(s)) want to be > migrated to git. In that case, I'll contact you for any additional > info I will need, such as the structure of the git repo or any hooks > I should be aware of. Thanks Please do not throw away any repository if there is no conversion. Mark it as read-only and obsolete, move it to a section where it is clear that it is meant for reference only. I think I speak for the GNU Emacs and XEmacs team if I tell you that we want to stick to Subversion in the emacs repository. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Hi, William Hubbs : > Just to clarify, we are talking only about the x86 architecture right? At the moment yes. On the exceptions page I linked there are some conditions under which you can stabilise yourself after permission is granted: * The prerequisites of stabilisation policy still apply. * The architecture must be available in hardware to have at least a compile test. * Several USE flag combinations must be compiled. * Basic operation should be tested on the actual hardware. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Stabilisation exceptions
Hi, Ryan Hill : > I'd also like permission to stabilize fonts ourselves once they've > cleared amd64 and x86. You can have it for x86 right away. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Hi, Markos Chandras : > I think it would be better if we kept a single list instead of > compiling a separate list for every arch. Mike's proposal sounds like the ideal solution. If one wants we can autogenerate a list. For now I will collect it manually and move it over once the DTD is fixed. Can we also add a paragraph to devmanual about exceptions or shouldn't we advertise that "feature"? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Hi, Mike Frysinger : > On Monday, January 24, 2011 07:31:20 Christian Faulhammer wrote: > > over the course of the years the x86 (and other architectures as > > well) has given away permissions to maintainers/teams to mark > > packages stable themselves. As there never was a definitive list > > what exceptions exist, I compiled a list of the ones I could get > > from the top of my head in [1]. Please yell if you have those > > permissions so I can complete the list for reference purposes. > > how about we extend metadata.xml to avoid the "multiple data > locations always leads to bitrot" ? Sounds like an excellent idea. Who can add this? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: On hosting self-produced distfiles
Hi, Mike Frysinger : > first off, drop the caps crap. second, while *you* might be aware of > a long history, you provided absolutely none in your first e-mail. > thus it completely looked like only 1 person (you) was making a > decision which had not been discussed with anyone else. and having > recently been placed into QA lead, you decided to use that position > to force everyone else to agree. again, without any discussion. So now that all misunderstandings are cleared out and everybody agrees that there was a failure in communication (both on sending and receiving end), we can go on committing awesome stuff to the tree. Thanks. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: On hosting self-produced distfiles
Hi, Ulrich Mueller : > missing, we sent a plea for help to -dev (or was it planet?) and had http://www.faulhammer.org/archiv-mainmenu-31/35-gentoo/293-we-are-looking-for-distfiles V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Packages up for grabs
Hi, Dirkjan Ochtman : > On Thu, Jan 6, 2011 at 13:17, Christian Faulhammer > wrote: > > dev-lang/erlang > > Very little bug inflow, responsive upstream (subscribe to their > > -patches and -bugs mailing lists), great support from users. > > lang-misc is still there as herd maintainer, but hardly alive. One > > bug open (compile failure in ~arch, upstream informed, package hard > > masked), which I would like to close on my own. > > I don't really know much about it, but I need this for dev-db/couchdb, > so if no one else wants it, I'll take it. I passed it on to you as the bug seems to be fixed by a PLD Linux patch. I forwarded it upstream, so the next release should contain a fix. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Packages up for grabs
Hi, Sebastian Pipping : > On 01/07/11 09:49, Christian Faulhammer wrote: > >> Besides the bump to 1.7.10... - in tree is 1.7.8-r2. > > > > Where did you find 1.7.10? http://ftp.davidashen.net/PreTI/RNV/ > > does not contain that. > > http://sourceforge.net/projects/rnv/ Bumped and I dropped maintainership. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Packages up for grabs
Hi, Sebastian Pipping : > On 01/06/11 13:17, Christian Faulhammer wrote: > > app-text/rnv > > Near to no maintenance work. > > Besides the bump to 1.7.10... - in tree is 1.7.8-r2. Where did you find 1.7.10? http://ftp.davidashen.net/PreTI/RNV/ does not contain that. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs
Hi, I would like to drop some packages that I do not use or really care for: dev-lang/erlang Very little bug inflow, responsive upstream (subscribe to their -patches and -bugs mailing lists), great support from users. lang-misc is still there as herd maintainer, but hardly alive. One bug open (compile failure in ~arch, upstream informed, package hard masked), which I would like to close on my own. app-text/rnv Near to no maintenance work. dev-libs/qof Very little maintenance. net-misc/tor A bump here and there (especially security fixes). Upstream really nice, there were user requests for beta ebuilds which I have no time to provide. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Deprecate EAPIs 0 and 1?
Hi, Donnie Berkholz : > rather than trying to build up a > mental stack of added and removed features across multiple levels. I always recommend the Reference Card which fits on one page and sums up most features of the EAPIs (found as the last two pages of PMS). V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Disabling auto-bumping of active Python version
Hi,
Sebastian Pipping :
> On 11/29/10 13:10, Christian Faulhammer wrote:
> > $ eselect python --help
> > Manage Python symlinks
> > Usage: eselect python
> >
> > [...]
> > updateSwitch to the most recent CPython
> > interpreter --if-unsetDo not override existing
> > implementation --ignore SLOT Ignore SLOT when setting
> > symlinks --python2 Set active Python 2 interpreter
> > without setting of main active Python interpreter if it is not set
> > to Python 2 --python3 Set active Python 3
> > interpreter without setting of main active Python interpreter if it
> > is not set to Python 3
> >
> > See the --if-unset option.
>
> I see, thanks.
>
> What I would now like to call from the ebuild is
>
> eselect python set --if-unset ${SLOT}
>
> Problem is ..
> * action "set" wants and index, not a slot
The Python eselect module can take python${SLOT} as argument for set.
> * --if-unset works with update only
At least for the Emacs eselect module update works like set if
--if-unset is given. So Python 2.6 has to be merged first to set it to
python2.6 executable, then all subsequent calls from newer Python
ebuilds (like 3.1) will not change the setting.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: Disabling auto-bumping of active Python version
Hi, Sebastian Pipping : > On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote: > > There will probably be no active version of Python set. > > You had two weeks to come up with this. > > Please find my on IRC to team up on an agreed fix. $ eselect python --help Manage Python symlinks Usage: eselect python [...] updateSwitch to the most recent CPython interpreter --if-unsetDo not override existing implementation --ignore SLOT Ignore SLOT when setting symlinks --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 See the --if-unset option. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
Hi, Nikos Chantziaras : > On 11/23/2010 09:32 AM, Mike Frysinger wrote: > > On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: > >> Mike Frysinger writes: > >>> well, not quite. the way we agreed in the past was to not > >>> revbump the masked package, but once it was unmasked, we revbump > >>> it just once at that point. > >> > >> Is there somewhere which tells users when there are upgrades to > >> toolchain packages which are not revbumped once they have been > >> unmasked and in ~arch? > > > > if they arent revbumped, then the changes dont matter to you > > This isn't always the case though, due to developer mistakes. > Sometimes when doing emerge -e system, there are changes in /etc > files that affect runtime behavior rather than build behavior. And > it seems to happen quite often. This is with non-masked packages > though. Sometimes it is not a mistake but laziness. Some minor fixes in configuration files are quite common. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Restabilizing MIPS
Hi, Matt Turner : > I don't have a long-term plan other than to stabilize the base system > and provide n32 stages. Where it goes from there, I don't know. So I am sure you coordinate with redhatter. > Though, you'd think with six members of the MIPS herd we'd have enough > man-power between us to keep some stable keywords. I don't want to stop you, but you are relatively new to the "real" keywording business. amd64 at a point had over 30 members and could not work on the backlog in a timely manner. Think about * your long-time motivation, burn-out in arch work is quite common, * problems you will run on a minor architecture as MIPS -> lots of patching, * reducing your keyword set (stable-wise) to a relative small subset and rethink your normal testing keywords. * proper documentation (handbook or elsewhere) V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Restabilizing MIPS
Hi, Matt Turner : > I'd like to begin stabilizing packages on MIPS. I've gotten acks from > Redhatter, leio, and r0bertz, and Kumba doesn't really care. I hope you know what you are doing. :) Stabilising is a huge effort and I would recommend you get your keywords in testing sorted out before. And decide on what set of software you want to support so you don't stabilise everything. On a side note: I own a Yeelong, but I don't have time to use properly, the Gentoo install is currently broken anyway. So I would like to sell it for a reasonable price (I paid 300€) to somebody who actually wants to support Mips in Gentoo. Anybody? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: News item for restructuring of hardened profiles.
Hi, "Anthony G. Basile" : > 1) authorship - I've added another line for the entire hardened team. > I've kept my name in there because I'm the point person for the work. That was my intention, not replacement, though I should have expressed that more clearly. > 2) bug tracking - I refer at the end to a bug which will track the > progress so the user can look to see where we are in the processs Typo in last sentence: *tracked V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: News item for restructuring of hardened profiles.
Hi, "Anthony G. Basile" : > We will change the profiles one arch at a time, starting with ia64, > and proceeding in order with ppc, ppc64, x86 and amd64. Once your > arch has been update *updated Maybe give harde...@g.o as Author entry and point to Bugzilla, plus give a date when you start, just for completeness. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: mesa.eselect
Hi,
Chí-Thanh Christopher Nguyễn :
> * Accept numbers as do_set() arguments
Taken from emacs.eselect
# target may be specified by its name or its index
if is_number "${target}"; then
# numeric index, find the target's name
targets=( $(find_targets) )
[[ ${target} -ge 1 && ${target} -le ${#targe...@]} ]] \
|| die -q "Number out of range: ${1}"
target=${targets[target-1]}
fi
I would love to have more comments to explain in general and
specifically for the structure of MESA_DRIVERS. The rest of the review
is mostly a matter of style.
> CONFIG_DIR="${EROOT}/usr/share/mesa"
Maybe something less generic as variable name? Also the local x, y, z
variables could be named a bit more obvious.
> for y in classic gallium; do
> z=$(get_drivername ${family} ${y})
> [ -f ${MESA_DIR}/${z} -o -L ${MESA_DIR}/${z} ] &&
> ret+="${y} " done
I would welcome more if constructs instead of &&, as it makes the code
more readable.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/pdfsandwich: metadata.xml pdfsandwich-0.0.2.ebuild ChangeLog
Hi,
"Thomas Kahle (tomka)" :
> tomka 10/10/22 15:11:40
>
> Added:metadata.xml pdfsandwich-0.0.2.ebuild
> ChangeLog Log:
> new ebuild: app-text/pdfsandwich
> RDEPEND=" media-gfx/exact-image
> app-text/ghostscript-gpl"
>
> DEPEND="sys-apps/gawk
> >=dev-lang/ocaml-3.08[ocamlopt]"
Could you add a comment (if you know by any chance), why the
restriction on cuneiform exists and if there is upstream work going on
or not about it. Also are gawk and ocaml no runtime dependencies?
> src_prepare() {
> sed -i "/^OCAMLOPTFLAGS/s/$/ -ccopt \"\$(CFLAGS)
> \$(LDFLAGS)\"/" Makefile }
Make this sed line die, just in case.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: QA last rites for sys-fs/dd-rhelp
Hi, Wernfried Haas : > On Fri, Oct 22, 2010 at 05:36:08PM +0200, Micha?? Górny wrote: > > I don't think there's a reason to do so. We have ddrescue, and users > > should be encouraged to migrate to that. > > Ah, found it (sys-fs/ddrescue, not sys-fs/dd-rescue) and it actually > does all the stuff that dd-rhelp does. > I guess in that case it's a good idea to let dd-rhelp go (probably > with a note to people like me who aren't aware that ddrescue does the > same job these days). Added to the mask entry. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild
Hi, "Peter Volkov (pva)" : > pva 10/10/19 14:35:39 > > Modified: metadata.xml ChangeLog > Added:cdemu-1.3.0.ebuild > Log: > Version bump. Added nocdemud USE flag to avoid cdemud dependency > #315491 wrt Michał Górny. > (Portage version: 2.1.9.18/cvs/Linux x86_64) Is there a reason you don't use EAPI=1 syntax for default USE flags, instead of the unwanted no* USE flags? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: perl-5.12 news item
Hi, Torsten Veller : > This will be committed before the arch teams stabilize > dev-lang/perl-5.12.2-r1. Maybe you should make an agreement with arches about a fixed date. They signal their ok after testing thoroughly in, say, two days and you immediately commit the news. > Display-If-Installed: > Run `perl-cleaner --all` after upgrading to a new Perl version! In my opinion you should move this sentence one or two paragraphs down, to emphasize more. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: CUPS 1.4 and FFMpeg 0.6
Hi, I tried to create an appropriate news item for the CUPS 1.4 stabilisation. p...@g.o is cced. Release deadline is Monday 13 Sep 2010, comments please. Timo Gurr : > If for whatever reason (broken/old printer drivers) that doesn't work > out there's still the way to install CUPS 1.4 with USE="-usb" to get > the old CUPS 1.3 behaviour back. Title: Upgrade to CUPS 1.4 Author: Christian Faulhammer Author: Timo Gurr Author: Gentoo Printing Team Content-Type: text/plain Posted: 2010-09-13 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: CUPS 1.4 and FFMpeg 0.6
Hi, Thanks for the clarifications. Timo Gurr : > As a general rule for upgrading to cups 1.4 when something regarding > local usb printers doesn't work: I will try to create a news item for the upgrade tomorrow, if noone does it before me. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] CUPS 1.4 and FFMpeg 0.6
Hi, a security stabilisation for Chromium [1] wants Cups 1.4 stable. My test requests on Planet Gentoo and via identi.ca revealed no real blockers, although people report that they needed to readd their printers in order to work. Does anybody here know an obstacle to the stabilisation? And should a news item issued for that? The same goes for FFMpeg 0.6, although it is needed for a security stabilisation of VLC [2]. There is one open bug which still needs to be resolved, otherwise I had no reports of problems so far. V-Li [1] https://bugs.gentoo.org/show_bug.cgi?id=335750 [2] https://bugs.gentoo.org/show_bug.cgi?id=332361 -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC Bugzilla interaction guide for devs & editbugs users
Hi, Michael Weber : > What about user issued KEYWORD/STABLE-REQ on maintainer-nee...@g.o > assignd bugs/packages? > > Close as RESO/WONTFIX or add the arches? Common sense. Practice has been to add arches if it fixes a problem in a current stable, if there is no stable version available or the current one is still ok, rethink. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC Bugzilla interaction guide for devs & editbugs users
Hi, "Robin H. Johnson" : > 2.2. Security bugs > The developer should comment, but ONLY members of the security team > should: > - change whiteboard > - add/remove arches As security may be grateful for any kind of help, those two actions is often done by the maintainers. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
Hi, Joshua Saddler : > The big issue with the docs is that IF OpenRC/baselayout-2 are marked > stable, it will require massive changes to hundreds of our other doc > files. Is there a list of the needed changes? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Last rites: mail-client/claws-mail-gtkhtml
Hi, # Has a bundled library for ages (bug 221925), upstream does not care # about that # GtkHTML development is a bit stalled # There are two other HTML display facilities for Claws: # mail-client/claws-mail-fancy (WebKit) and USE=dillo on # mail-client/claws-mail V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
Hi, Markos Chandras : > On Sat, Aug 14, 2010 at 01:58:57PM -0400, Mike Frysinger wrote: > > On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote: > > > ~$ cat > > > development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults > > > > i'm pretty sure all the /dev subdirs are dead now and unified in > > targets/developer > > > > in fact, i dont see anyone referencing that subdir, so i guess we > > can just punt it > > -mike > > > Just committed that new make.defaults for amd64/10.0/developer > profile. > > @x86 Could you please do the same for your dev profile? It would be smart to cc the x86 team actually, and use the ChangeLog file. I don't read all -dev posts so I can react to random requests. Added. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
Hi, Mike Frysinger : > sounds like someone needs to update/extend the arch testing > documentation. random e-mails posted to random dev lists are quickly > forgotten. new arch testers however should be reading the arch tester > documnt. It has been added to the x86 AT guide. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emacs/google-c-style: metadata.xml ChangeLog google-c-style-20091009.ebuild
Hi,
"PaweA Hajdan (phajdan.jr)" :
> pkg_postinst() {
> einfo "Example usage (.emacs):"
> einfo "(require 'google-c-style)"
> einfo "(add-hook 'c-mode-common-hook 'google-set-c-style)"
> einfo "(add-hook 'c-mode-common-hook
> 'google-make-newline-indent)" }
You did not receive my mail regarding the autoload stuff when you
asked for Emacs support?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: Upcoming Council meeting on July 26th, 1900 UTC
Hi, Theo Chatzimichos : > On Sun, Jul 18, 2010 at 9:06 AM, Christian Faulhammer > wrote: > > What about getting rid of -project? > > > > V-Li > > WHAT? Why?? Because it is useless in my eyes. All discussion could also take place here and most people mix it up anyway. The distinction is too blurry. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Upcoming Council meeting on July 26th, 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, "Jorge Manuel B. S. Vicetto" : > I cross-posted this email to both gentoo-dev and gentoo-council mls as > Brian used the former and Alex started this thread in the latter. > Which ML do we want to use? What about getting rid of -project? V-Li - -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxCmdoACgkQNQqtfCuFnePkTwCeP6EFUtcd33aBlA5ChHtYqIQd Ve8An3C3BPWmpqgcxX5NFJgU6X7+xcCF =C8OY -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Hi, Petteri Räty : > If relevant people already know the policy and act accordingly then > why do we have this thread in the first place? Security is (as all the teams), badly understaffed, so sometimes something like this slips. It was a friendly reminder as it happens from time to time and slipping security bugs is the worst that can happen from an arch perspective. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Hi, Thilo Bangert : > > please avoid having stabilisation requests > > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a > > security bug. That way, architecture teams may not see the severity > > directly and it slips, leaving users with vulnerable versions longer > > than needed. Thank you. > > perhaps it's a good idea to tell people what you expect of them > instead. i presume just removing the blocker will not satisfy you. Do stabilisations on the security bug so arch team members can skim through their stabilisation list by just looking for secur...@g.o to find the vulnerable packages. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Should I file three bug reports or just one?
Hi, Nikos Chantziaras : > This won't work correctly for these three packages: > >app-emulation/emul-linux-x86-baselibs >app-emulation/emul-linux-x86-gtklibs >app-emulation/vmware-workstation > > because revdep-rebuild wants to emerge them repeatedly, since they're > binary packages. How do I report this? Do I file one bug per > package, or do I file only one for dev-libs/openssl where I list the > three above packages? Check first if they have been reported already, then look up the maintainers from metadata.xml. If some have the same (and emul-linux-* belongs to the same class) then do one bug for them. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: dotnet herd is "empty"
Hi, Christopher Swift : > If possible I'd like to contribute to this herd, I have little ebuild > experience but I am a willing learner with a keen interest in > Mono/dotNET technologies. I am not (yet) a Gentoo developer nor have > I lots of experience with ebuilds however I have taken an interest in > writing them lately having read as much documentation as I could find. As a general example to learn more about ebuild writing: Use the Sunrise Overlay where all your contributions get reviewed. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Hi, Nirbheek Chauhan : > What needs to be done now is for someone with lots of CPU power to > grab the list of packages[1], and build them one-by-one (all > versions), adding to a new list all the ebuilds that fail. How to > test: > > LDFLAGS="-Wl,--as-needed" emerge -v1 $atom > > Once we have the list that fails with normal as-needed, we can fix > them, get the fix upstreamed (if possible), and switch the flag on. > This action should probably be accompanied by a news item informing > users about the change, and encouraging them to report the (rare) bug > which might hit them. And the stable tree should be safe, too. In general I like the idea. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Should "orphan" package without any "stable" version be stabilized?
Hi, Pacho Ramos : > app-office/ledger doesn't have any maintainer and has no stable > version, also, seems that no other app requires this to be > stabilized. I would prefer to keep this in testing until a maintainer > really maintains it downstream, but I am not sure if there is already > some policy on this :-/ Generally it should not be stabilised. But based on common sense (simple program, no dependencies), you could do it. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [git migration] The problem of ChangeLog generation
Hi, Richard Freeman : > Having branches to do development and facilitate access and testing > seems fine, however we should always have the goal of getting these > tested revisions merged back into the main tree. We really don't > want divergent development to be the norm. Right, the extensive use of overlays shows a clear problem here. Users could work on a branch of the normal tree to bring in their changes, which gets merged by a normal developer at some point. The offical dev-lisp category is in bad shape (== not usable at all), while the overlay is in great condition because of some dedicated users. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Gentoo Council 2010/2011 - Nominations are now open
Hi, Alex Legler : > On Sat, 5 Jun 2010 02:00:02 +0200, Torsten Veller > wrote: > > > Hello fellow developers and users. > > > > Nominations for the Gentoo Council 2010/2011 are now open for the > > next two weeks (until 23:59 UTC, 18/06/2010). > > > > Chainsaw, Fauli and sping please. Thank you for the nomination, but my time does not allow me to attend the meetings, and I am stretched thin anyway and cannot do everything I want for the teams I am already in. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: bugzilla flags for arch-testing
Hi, "Robin H. Johnson" : > How about the following instead, going into the status whiteboard: > AT:x86:+ > AT:x86:- > AT:x86:? > with the same meanings that you defined. > > It should be just as easy to search, and you can do it today already. Yes, sounds good. What is the best way to document it apart from the various AT FAQs? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Unification of variables used within SCM eclasses
Hi,
sorry for the late reply.
Michał Górny :
> a) Common variables - the variables which would have to be used by
> various SCM eclasses as default/fallback values.
>
> 1. ESCM_DISTDIR (defaulting to PORTAGE_ACTUAL_DISTDIR/PORTDIR)
> - an alternate parent dir to all SCM stores. It would be useful
> if user would like to use an small file-inefficient filesystem
> for main DISTDIR or rsync it with other machine (where SCM
> files are not as important as the tarballs are).
Sounds reasonable, though mostly a nice-have.
> 2. ESCM_OFFLINE (most eclasses use it already)
> - a common switch to easily switch off all network interaction.
Crucial, at least for me. :)
> 3. ESCM_LIVE_FAIL_IF_REPO_NOT_UPDATED (similar to the one in
> git.eclass)
> - a common switch to force unpack() phase to fail if no updates
> were found during the pull/update.
Something better named would be great...it looks just stupid in
make.conf.
> b) Common eclass-specific variables - these ones should allow user to
> override above variables for single SCM.
>
> 1. E*_STORE_DIR (defaulting to ${ESCM_DISTDIR}/*-src)
> - already used by few eclasses, allowing user to change
> the location where SCM-specific clones are stored.
>
> 2. E*_OFFLINE (defaulting to ${ESCM_OFFLINE})
> - allowing user to override global 'offline switch'. Thus, it
> should also support setting 'false' value to enable network
> interaction for single SCM.
>
> 3. E*_LIVE_FAIL_...
> - another override for the global one.
Ok with those.
> 4. E*_REPO_URI
> - the URI to the main repository. It might be extended to support
> multiple URIs.
> 5. E*_REVISION
> - explicit expected-revision/tag specification, preferably along
> with implicit one (e.g. in ESVN_REPO_URI) deprecation.
> This would allow applications to easily distinguish
> between 'real' live ebuilds and snapshot ones fetching
> directly from the repo.
Those are not really user settings, but defined by the using ebuild.
> c) Common export variables - these ones should be exported by SCM
> eclass and stored in environment.bz2 after successful emerge.
>
> 1. E*_VERSION (or _REVISION, or ...)
> - the version/revision to which the package was updated. This
> would be useful to determine whether the current repo is newer
> than one used when merging package.
>
> 2. E*_WC_PATH
> - the absolute path to the last-used clone dir (i.e.
> ${E*_STORE_DIR}/sth) and thus the most probable location
> to perform further updates in.
Portage team should comment here, maybe. What is the use case for
this, honestly?
> d) Other:
>
> 1. ESCM_CUSTOM_FETCH
> - this one is not directly related to eclasses but for use of
> ebuild authors. Setting this in an ebuild should notice applications
> that the ebuild does use custom fetching procedures
> (i.e. fetches from multiple repositories in a manner
> unsupported directly by the eclass) and thus external
> applications should not try to update the repository
> themselves.
Use case?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
Hi,
Torsten Veller :
> find "${S}" -type f -name "._*" -print0 | while read -rd ''
> f ; do einfo "Removing AppleDouble encoded Macintosh file: ${f#${S}/}"
> rm -f "${f}"
> f=${f#${S}/}
> # f=${f//\//\/}
> # f=${f//\./\.}
> # sed -i "/${f}/d" "${S}"/MANIFEST || die
> grep -q "${f}" "${S}"/MANIFEST && \
> elog "AppleDouble encoded Macintosh file in
> MANIFEST: ${f#${S}/}" done
> }
Are those f= lines commented? And what was their purpose? Can they
be deleted?
> if [[ -d ${D}/${VENDOR_LIB} ]] ; then
Haven't checked, but quotes not needed?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: Should we disable RESOLVED LATER from bugzilla?
Hi, Petteri Räty : > I don't think later is valid resolution. If there's a valid bug it > just means it's never looked at again. If the bug is not valid then a > different resolution should be used. So what do you think about > disabling later? I would like to avoid things like this: > > https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 > > Not applicable to the bug above but in general our social contract > says: "We will not hide problems" Kill REMIND and LATER, introduce Later keyword or ASSIGNED LATER. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: bug-wranglers queue is large
Hi, "Andreas K. Huettel" : > I can do a bit, I already have bugedit permissions from AMD64 AT and > do bugwrangling for the KDE team. > > Are there any written rules somewhere on what can / should / must not > be done by a non-dev (not yet dev?) bugwrangler on the general queue? The bug wranglers have a project page with instructions. * Always full atoms: category/package * Dupe search V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Hi, Arfrever Frehtes Taifersar Arahesis : > All problems, which were blocking stabilization of Python 3, have > been fixed. Stabilization of Python 3.1.2 is currently scheduled on > 2010-04-19. I'm attaching the news item for Python 3.1. Will add my comments for the whole thread here: As far as I can see, there is no danger to any program as long as Python 3 is not set as system python. As soon as the request is filed I will install it on my stable systems and try it...for some weeks to be absolutely sure nothing happens. Then I have nothing against marking it stable on x86 and will do so. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Moving packages to dev-vcs
Hi, Serkan Kaba : > I'm hitting a repoman failure > > repoman: dev-vcs is not an official category. Skipping QA checks in > this directory. > Please ensure that you add dev-vcs to > /home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories > if it is a new category. > - > After hitting it for the first time I updated the whole profiles dir > and still failing It is in profiles/categories, so everything should be fine. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: New category for version control
Hi, Sebastian Pipping : > Is that a good idea? > Maybe we should restrict the bug to status updates on moving and keep > discussions on here? I don't expect too many discussions. :) > > Anyone can start moving the packages > > over properly to dev-vcs (with profiles/updates entries of course), > > There seems to be a lot more to it: > - Updating eclasses? > - Updating reverse dependencies? That is the normal procedure when pkgmoving a package. So nothing special. :) > - Updating documentation A simple grep for dev-util/ should be sufficient. > - Pushing news out to Gentoo users (and developers) For what? pkgmove should handle that. > - Update package names used in Layman (my task) Yes. > What else can you think of? At the moment, nothing. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: New category for version control
Hi, Sebastian Pipping : > Agreed, "scm" is a bad choice. So it is really tracked in http://bugs.gentoo.org/show_bug.cgi?id=56967 now. If there is anything to comment do it there. Anyone can start moving the packages over properly to dev-vcs (with profiles/updates entries of course), just make it know somehow when you are working on packages not maintained by you. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: New category for version control
Hi, Dirkjan Ochtman : > As the primary maintainer for mercurial, hgsubversion and hg-git, I > would prefer dev-vcs. Yes, I agree now, too. > I wonder, would a Python re-implementation of git libraries belong in > dev-vcs or in dev-python (it's currently dev-python/dulwich)? Up to your common sense (I would go with dev-python). V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] New category for version control
Hi, as dev-util is really crowded, maybe splitting off a category for source code management systems would be a good idea. They are more important today than some years ago. Are any of you against such a split? My proposal would be to call it dev-scm and put all version controls, direct frontends, plugins and the like into that. Diffing tools or programs that only have some kind of binding to a scm should stay in dev-util. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Remove "dev"-status of mips profiles
Hi, Jeremy Olexa : > I would guess that it would be far easier to work in an overlay at > this point. I would also guess that if there are ANY mips users out > there that they would have to use some other ACCEPT_KEYWORDS value > because the shape of ~mips is so...bad. Don't remove an architecture. Ask vapier what it means to reintroduce it. Even if it rots, mark it as unmaintained and wait for someone to pick-up. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Remove "dev"-status of mips profiles
Hi, Torsten Veller : > Can we please move the mips profiles from "dev" to "exp" in > profiles/profiles.desc? Agreement here. Maybe a restart on non-obsolete MIPS hardware (read Loongson instead of SGI) would be great. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: "X" vs "gtk" USE flags
Hi, Nikos Chantziaras : > A Gnome user probably has "X gtk -qt" in make.conf, while a KDE user > has "X qt -gtk" in hope to have programs that support both Gtk and Qt > being built with the toolkit that is more native to his DE. When a > package has a GUI tool that is able to only use one of those > toolkits, people who have it disabled in make.conf will get no GUI > tool at all even though they have "X" in their USE flags. Your proposal does not look to appealing to me. What about people trying to keep "pollution" down and avoid one or the other toolkit? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Major changes to gdesklets.eclass
Hi, Joe Sapp : > Thanks for looking at this Christian. Sorry for the late reply. > Patch to the original revision is attached. I am fine with it. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
Hi, Ciaran McCreesh : > That probably wouldn't be possible. One of the reasons we want to > ditch VDB is to allow multiple slots of the same cat/pkg-ver to be > installed in parallel (which is in turn necessary to allow some of the > more hideous dynamic slot abuses that people are after). VDB doesn't > support that, so you probably won't be able to go back once you've > started using new features. > > *shrug* all of this is years off, anyway. It's at least EAPI 5 > territory. We can work all this out later if EAPI 4 ever happens. As much as you love to have the new and shiny VDB2, it is far off. Prototyping and drafting implementations would be great to have some base where we can discuss on (in a civil manner). So having this timestamp would be a good way to prepare a sane migration path. In the end we have to care for our users and EAPI was just provided to have a clear way. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Hi,
Mike Frysinger :
> btw, latest python.eclass requires bash-3.2+ due to parsing errors in
> the regex checks:
> $ bash-3.1 -c '[[ a =~ ^(a|b)$ ]]'
> bash-3.1: -c: line 0: syntax error in conditional expression:
> unexpected token `(' bash-3.1: -c: line 0: syntax error near `^(a'
>
> we could quote these or require bash-3.2+ ...
We discussed it briefly on the -pms mailing list [1].
V-Li
[1]http://archives.gentoo.org/gentoo-pms/msg_f4fee4c3a79ae4f37eaf4c4ebce6aafe.xml
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: proxy maintainership and gentoo-x86 scm
Hi, justin : > So what is the current mood to switch to git. As there is no traffic > on the scm-ml I assume that there is no progress. But shouldn' we > start to move on? Now!? Mood is good, but someone has to do the work. And robbat2 cannot do all of it. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/bip: metadata.xml ChangeLog bip-0.8.4.ebuild bip-0.8.1.ebuild
Hi, "Alex Legler (a3li)" : > a3li10/01/05 10:30:43 > > Modified: metadata.xml ChangeLog > Added:bip-0.8.4.ebuild > Removed: bip-0.8.1.ebuild > Log: > Version bump, add 'noctcp' option to disable automatic CTCP VERSION > replies. Remove old version (Portage version: 2.2_rc59/cvs/Linux > x86_64) [...] > IUSE="debug noctcp ssl vim-syntax oidentd" Please avoid no* USE flags, they are bad behaviour and will earn you a spanking. Use USE flag defaults if you want to activate it by default. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: News item for Paludis kdebuild-1 removal
Hi, My proposal: --- Title: Paludis kdebuild-1 Removal Author: Ciaran McCreesh Content-Type: text/plain Posted: 2010-01-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Qt3 deprecation and removal policy
Hi, Samuli Suominen : > Just saying... Please track progress somehow. I know it is a lot of work, but makes understanding the process easier. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: clutter.eclass -- new eclass for packages related to "Clutter"
Hi, Nirbheek Chauhan : > The eclass is attached, and is very simple, consisting of just > SRC_URI, DEPEND, LICENSE, DOCS, and src_install. No objections. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Major changes to gdesklets.eclass
Hi,
Joe Sapp :
> Anyways, a diff would be useless so I've attached the proposed eclass
> [2].
Looks fine so far. What puzzled me is the documentation of the SLOT
variable. What is the motivation to do so?
* Sometimes you give a default on undefined ROOT variable, sometimes
not. Please make it consistent for cosmetic reasons.
* addwrite "${ROOT}/root/.gnome2": Is this unconditionally necessary?
Or could a "boolean" in the ebuild be set to activate it?
* DISPLAY variable export could be done with the assignment. Or is the
export always needed?
* Is the file name LICENSE always used for the license or is COPYING
for example also possible?
* einfo "Installing Control ${CTRL_DIRNAME}": Is not mirrored in the
desklet branch of the if clause.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: News item for Paludis kdebuild-1 removal
Hi, Ciaran McCreesh : > Since kdebuild-1 is to be removed from PMS immediately, it's going to > go from Paludis in the next release too. We need to warn users about > this, since they'll no longer be able to uninstall kdebuild-1 > packages they have installed. Please review the following GLEP 42 > news item for this: As we cannot be sure that a former GenKDEsvn user still uses some of the KDE overlays, putting that news item in the main tree seems ok. Although it is a special case. You have a committer for this? > The Gentoo Council has decided that all mention of the kdebuild-1 EAPI > is to be removed from the Package Manager Specification immediately. How many users will care what the PMS is? And why is a cleaned up specification breaking your implementation? Tell them that kdebuild-1 has reached its end of life and support will phase out. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] EAPI={3,4} offset-prefix semantics mandatory?
Hi, Fabian Groffen : > On 16-12-2009 09:29:07 +0300, Peter Volkov wrote: > > В Втр, 15/12/2009 в 19:59 +0100, Fabian Groffen пишет: > > > Should an ebuild using an EAPI that has offset-prefix support > > > make the use of that support mandatory or optional? > > > > I think no. Without real testing that package works in prefix there > > is no need to bother and create illusion that it does. > > Does your no mean mandatory or optional? As I read it: Optional. And that is also my vote here, in the end we have KEYWORDS. > I'll remove all the bits from the quiz that are (no longer) relevant, > and then post them, and their answers. I don't see much secret in the > answers, or do recruiters want to use some of the questions for future > quizzes? Post it on -core and we can decide then. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
Hi, "George Shapovalov (george)" : > Modified: use.local.desc > Log: > added local flags for new version of net-fs/coda Please don't add local flags to use.local.desc anymore. They are now maintained in metadata.xml file. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Code review and main tree inclusion for java-mvn-src.eclass and java-pkg-simple.eclass
Hi, Martin von Gagern : > Christian Faulhammer wrote: > > java-pkg-simple: > > In my eyes, defining all local variables at the beginning of a > > function makes it easier to read. > > Sorry, Fauli, i totally missed your mail as it was only addressed to > gentoo-dev, while I've been intently watching gentoo-java... I am not subscribed to that list, so my mail would not get through. > To sum things up: yes, I could change the local declarations, but I'd > rather keep things as they are, unless you object more vehemently. No problem, it was a matter of style. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: openrc stabilization todo
Hi, William Hubbs : > > Yes, but I haven't found time and desire to triage the bugs as I > > intended to. The news item is in the archives of -dev. Some of my > > todo items like a newer stable eselect are done. > > What other todo items do you have? Actually: * Doc updates, http://bugs.gentoo.org/213988 * Deprecated OpenRC http://bugs.gentoo.org/251730 The rest is done. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: openrc stabilization todo
Hi, Jeremy Olexa : > It makes it hard to triage the openrc bugs when when are on > openrc-0.5.3 and there are openrc-0.2* bugs in the bug tracking > system. Someone really knowing what he is doing is needed here. And with some time. Another thing needed is an init script for wpa_supplicant. > A big change, so prepare a news item? I think Fauli already did this > some time ago. Yes, but I haven't found time and desire to triage the bugs as I intended to. The news item is in the archives of -dev. Some of my todo items like a newer stable eselect are done. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: A parting gift
Hi, Jacob Todd : > On Wed, Dec 02, 2009 at 09:15:10AM +0100, Gunnar Wrobel wrote: > > ... I did buy the rights to my book back. > Wait, you don't keep the 'rights' to *your* book when it's published? You sell the publishing rights for a period of time. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: ruby-ng.eclass - new eclass for ruby-based packages
Hi,
Tomáš Chvátal :
> > The sense of this I don't understand. You should not restrict EAPI
> > like this.
> >
> > V-Li
> >
> Why not. Quite standart way.
> 19 case ${EAPI:-0} in
> 20 2) : ;;
> 21 *) DEPEND="EAPI-TOO-OLD" ;;
> 22 esac
Microsoft Windows is standard software, tooyou want to use it? And
if an ebuild uses EAPI 3 it will fail badly, while it isn't too old. A
sane assumption is that EAPI 3 will at least contain all features from
EAPI 2 with very few adjustments to existing syntax and behaviour if at
all.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: RFC: ruby-ng.eclass - new eclass for ruby-based packages
Hans de Graaff :
> The eclass itself is attached to this message and here:
> http://git.overlays.gentoo.org/gitweb/?p=proj/ruby-scripts.git;a=blob;f=ruby-ng-testbed/eclass/ruby-ng.eclass;h=ce9a37440600c7913a21b5780a18b5e8dd9d712f;hb=HEAD
At the moment I don't remember for what reason exactly, but we renamed
the PATCHES variable to EBZR_PATCHES in bzr.eclass. You should do
something similar.
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile
src_test src_install pkg_setup
case ${EAPI} in
2) ;;
*)
die "Unsupported EAPI=${EAPI} for ruby-ng.eclass"
esac
The sense of this I don't understand. You should not restrict EAPI
like this.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
[gentoo-dev] Re: Code review and main tree inclusion for java-mvn-src.eclass and java-pkg-simple.eclass
Hi, Andrey Kislyuk : > ... and let's say after 30 days from this email pending resolution of > any complaints mvg and I will push these to main tree. You should review your docstrings. Some of them contain overlong sentences, which are hard to grasp. java-pkg-simple: In my eyes, defining all local variables at the beginning of a function makes it easier to read. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: QA: package.mask policies
Hi, Duncan <1i5t5.dun...@cox.net>: > 1) Users using ** in their package.keywords file should know enough > about what they're doing to use their own package.mask, as well. If > they're using ** in the keywords file, they're /saying/ they're > reading to handle such things, after all, why shouldn't we let them? They do it, because they don't know what they are doing. Just seen it somewhere, heard about it. During LinuxTag the question why ** unmasks some live ebuilds occured at least three times. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: QA: package.mask policies
Hi, William Hubbs : > > * Masking live... > > Heck no. This is not proper usage. Just use keywords mask. > > KEYWORDS="". Problem solved and the package.mask is smaller. (Note, > > in overlays do what ever you want, since it does not polute the > > main mask from g-x86). > > True. If we mask live ebuilds with KEYWORDS="", there isn't a reason > to put them in p.mask that I can think of. Many users use "**" in their p.keywords file and get a live ebuild then. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi, Ben de Groot : > What about ppc64? They are MONTHS behind on stabilization, > even for security bugs (see bug 281821 for example). The Qt team > feels this is no longer acceptable. We propose that any arch that > can't keep up will be demoted to experimental status. I surely subscribe to that. At the moment Brent (ranger) is definitely alone on that arch. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi, Markos Chandras : > This is way I keep asking for a complete report of manpower at least > for amd64 and x86 arch teams ( and update the project pages as > well ). We need real numbers so we adjust respectively the number of > stabilization bugs we assign to them. x86 is at the moment three people active (maekke doing the biggest load, armin76 and myself). In the past I asked current members to state if they want to stay on the team or if they leave...I won't throw out anyone. amd64 is ssuominen, darkside and maekke, then some people doing occasional work like chainsaw. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi, Arfrever Frehtes Taifersar Arahesis : > Some packages have new releases more than once a month and sometimes > it's reasonable to not skip stabilization of any version. Given > version of a package is usually no longer tested by users after > release of a newer version, so I suggest the following change to the > policy of stabilizations: Stabilization of given version of a package > can be requested if this version has been in the tree for at least 10 > days and a newer version of this package has been added to the tree. If you do that, you will see arch teams skip those stabilisations in a daily rhythm. Honestly, who should do that work? Having every minor release stable is a big nuisance for arch workers. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: openrc-0.5.1 arrived in the tree
Hi, Tomáš Chvátal : > Actualy i would like to hear what we in KDE did too, we publish into > the tree as 0 days bump mostly since 4.2 and 4.1 was in the tree > right away when we had working configuration. Your bumping is excellent, no discussion here. Gnome does a really good job in figuring out what packages need to go stable along with their newest release, maybe that is easier for them. With the ongoing KDE 4 stabilisation, I have seen a lot of stabilisation requests filed by Samuli, which should have been already there, filed by the KDE team. Figuring out what will be broken with such a major release and trying to get the stable tree on par is what eats a lot of time for us architecture developers...you can ease that by researching beforehand (with a stable chroot for example). V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Add RUBY_TARGETS to USE_EXPAND
Hi, Alex Legler : > RUBY_TARGETS contains a list of ruby implementations and versions to > install a package for, like this: Python has to do the same for 2.x and 3 versions...wouldn't it be nice to have the same solution for both languages? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
