[gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. comments? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] emerge glitz fails (/usr/lib64/libGL.so: File wrong format) Glut also
On Sun, Feb 18, 2007 at 07:51:56PM +0100, KLessou wrote: Hello I don't understand why I cannot emerge glitz Not really a gentoo development related issue, so i just wanted to suggest you post to gentoo-user or the forums, but as i just noticed you already did anyway: http://forums.gentoo.org/viewtopic-t-541060.html Let's keep it there and not on this list, thanks. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp5x9H5IPykV.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
On Fri, 2007-02-16 at 19:14 +0100, Rémi Cardona wrote: Luca Barbato wrote: ffmpeg got just vc-1 working as should, all the other code got somewhat halfway, mostly because we expected a lot. (amr and ac3 seems to have something alive, aac isn't something that good) The Gentoo results aren't that bad on the average, we got something, sadly not yet finalized properly. That said I think the experience was good and we should try to get into this other round with the experience of the past summer =) To complement the both of you, how about proposing projects to 2 students at the same time and have them work as a team? Not allowed, atleast not in previous years SoC. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
On Fri, 2007-02-16 at 17:35 +0100, Diego 'Flameeyes' Pettenò wrote: On Friday 16 February 2007, Grant Goodyear wrote: So, is there support among devs for hosting another round of Summer students? Are there good problems for those students to work on, and, if so, what are they? Were people happy with how last year's program went, or should we try to do something different? For what it's worth, I think GSOC is worth putting our effort into, but I'd also like to see projects that at least have the potential to benefit more of the community than just Gentoo. *Shrug* Although last summer I wasn't too involved in the process (I was backup mentor for a couple of projects, but there was no need for a backup mentor for any of them, and I also passed the august offline), I did think with myself of a few issues with what SoC did for Gentoo (and the other way around too). Out of the 14 projects listed in [1], these are the (public) results: - I don't know of any GUI frontend to baselayout; - Antarus's work on CVS migration produced some interesting results, but as we know, the migration isn't possible just yet; - blubb's etc-update replacement is sort of complete, I wasn't able to get it to work yet, but at least blubb is still around; - Gentoo/FreeBSD/AMD64 port is deadish, Victor disappeared for what I can tell, there weren't many patches that were followed till merge, and there's no near hope to get amd64-fbsd working in short time; - I have no clue what's going on with gentoo-stats; - Pioto's dynusers (now creandus, I think) is still work in progress, since starting, pioto became a dev; - I have no clue what's going on with the web-based GuideXML frontend; - JACK support hasn't moved a bit, if possible it became worse because of bitrot, as the student dropped off; - I have no clue what's going on with NetworkManager, but it might actually have seen some work on it, considering it's now in portage, but metalgod/steev would probably know better; - I don't know what happened to qaludis, nor I care to be honest as it's an external project; - I don't know what happened to pkgcore, nor I care to be honest as it's an external project; - Alex completed Gentoo/FreeBSD port of Sandbox, although Martin disappeared and thus we're forced to unmask sandbox on our profiles for now, and in the mean time he also fixed some FreeBSD bugs; - I have no clue what's going on with SCIRE; - I have no clue what's going on with the Xorg configuration too. I admit I cannot of course judge all the progress, as you can see I have no clue on about half the projects, but that also means there wasn't a big new feature or fix that everybody knows about. So maybe, the targets we put were too much fuzzy, and difficult to achieve. Of course there's also the big unknown of the students, that we can't easily judge if we don't know them. This covers one point, but what most interest me to point out is that we have a real low conversion of developers. What I found interesting in the Summer of Code initiative was the ability to find new developers for a project, people that wouldn't have been involved in open sources projects otherwise. We enrolled as students four Gentoo developers, and only one of the remaining ten students was converted into a dev. Actually, I believe we gained four new developers as a result of Summer of Code last year... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Monday, 19. February 2007, Stefan Schweizer Ви написали: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. Can you please clarify what exactly you are proposing. Is this a) move all the keywording into profiles (that is remove all KEYWORDS fields from all the ebuild) and disallow package maintainers and other devs (other than arch teams) to touch keywords or b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move granular per-arch settings to profiles or something else? Even then I am not sure how either of these is going to work, especially this: The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. normally new versions/packages go directly into ~arch unless they are transiently masked by developer (waiting for release, etc) or are permanently masked live-cvs/svn ones. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? b) seems more sane, but then the particulars of the interaction (of devs and arch teams) are not clear. George -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Summer of Code - worth repeating?
Hiya all, Let's do a quick re-cap of Summer of Code '06: Gentoo had 14 project slots, out of these fourteen two were on Gentoo external Gentoo project which I will leave out of the re-cap. That leaves us with twelve projects, four of which were being worked on by at the time current Gentoo developers. Leaving us eight newcomers, out of these eight four has been recruited and I belicve an additional one is in the recruitment queue. Some of the projects have been picked up and are being worked on daily, some we've had problems getting acceptance for from the projects where they would be most suited (Beacon - GDP), and some may have fizzled off and died when SoC ended (be that because the student were no longer involved and didn't feel that they were welcomed into the community post-soc, or be that because it just didn't end up being a small idea turned explosion). Summer of Code 2006 was thrown together practically overnight, we jumped onboard after the deadline, by pure luck, and due to lack of planning ended up with whatever projects people could think up in no time and what mentors felt comfortable mentoring at said time. Based on the timeframe and having to jump into the deep end I'd say SoC was a tremendous success for us, not least as a recruitment tool. And of course, it feels great to put something back into the community. Summer of Code '07 is about to kick off, those of us who participated in one form or another last year are pretty geared up to do it again. This time around we've got a chance to plan better, apply in time.. Should we SoC? Of course we should! Can we think up projects? Do we have willing mentors? Will Google have us once more? (with feeling) Summer of Code itself should be a lot more organised this year, OSPO has put a fair chunk of work into getting things up to speed and has listened to the feedback of both students and mentoring organisations from last year. -- Christel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
It was discussed at the last council meeting... Proposed by jokey. On Mon, Feb 19, 2007 at 10:54:55AM +0100, Stefan Schweizer wrote: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. comments? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list -- Alexander Færøy Bugday Lead Alpha/IA64/MIPS Architecture Teams User Relations, Quality Assurance pgp00Z49LOXnR.pgp Description: PGP signature
[gentoo-dev] Last rites: net-misc/yasuc
As the package may transfer user data to anyone owning that domain after 1 March 2007 it will be removed in 9 days instead of usual 30: # Krzysiek Pawlik [EMAIL PROTECTED] (19 Feb 2007) # Pending removal 28 Feb 2007, bug #167024 # See also http://pl.uptime-project.net/board/viewtopic.php?t=1435 net-misc/yasuc From Uptime-Project admins: ... +++ We are very sad to say it, but we decided to close down the Uptime-Project on the 1st of March 2007. +++ ... Please shut down all the uptime-clients you're running because we can't keep the domain name forever and we don't want somebody to get his hands on the user data the clients are sending. ... -- Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51 desktop-misc, desktop-dock, x86, java, apache, ppc... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 10:54:55AM +0100, Stefan Schweizer wrote: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. That's lame for several different reasons that I'm going to outline below and frankly anybody blowing steam about ~arch keywording the latest version (which ended up as being the goal yesterday) is being extremely silly. Anyway, here's several reasons why it's lame - I'm sure there's even more good reasons but these should suffer: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. C. If (as Diego told me) portage is being too slow regenerating cache because of an extra 300 kde-meta ebuilds in the tree we have to sane options: - C1. Remove kde-meta completely as it's breaking our package manager. - C2. Fix portage immediately or switch to a package manager that works. Now, all of the above is insane as I think everybody can agree so please stop making a big fuss about this. An extra 300 kde-meta ebuilds shouldn't: D. Be in the tree at all unless KDE team thinks it's fun to drop all the ~arch keywords. E. Be a problem for the package manager (or we got bigger problems on our hand which would basically force us to stop adding new packages to the tree until resolved). Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New emul-libs.eclass
Hi all,
I recently worked on the app-emulation/emul-linux-x86-* packages and
used almost identical code snipplets in them, so I realized I might as
well put together an eclass and drop the duplication. The eclass would
provide a common template for the following packages:
app-emulation/emul-linux-x86-baselibs
app-emulation/emul-linux-x86-compat
app-emulation/emul-linux-x86-gtklibs
app-emulation/emul-linux-x86-medialibs
app-emulation/emul-linux-x86-qtlibs
app-emulation/emul-linux-x86-sdl
app-emulation/emul-linux-x86-soundlibs
app-emulation/emul-linux-x86-xlibs
Thanks for any feedback,
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Simon Stelling [EMAIL PROTECTED]
# Purpose: Providing a template for the app-emulation/emul-linux-* packages
#
ECLASS=emul-libs
EXPORT_FUNCTIONS src_unpack src_install
DESCRIPTION=Provides precompiled 32bit libraries
HOMEPAGE=http://amd64.gentoo.org/emul/content.xml;
RESTRICT=nostrip
S=${WORKDIR}
SLOT=0
IUSE=
DEPEND=
emul-libs_src_unpack() {
einfo Note: You can safely ignore the 'trailing garbage after EOF'
einfo warnings below
unpack ${A}
cd ${S}
ALLOWED=${ALLOWED:-^${S}/etc/env.d}
find ${S} ! -type d ! -name '*.so*' | egrep -v ${ALLOWED} | xargs
-d '
' rm -f || die 'failed to remove everything but *.so*'
}
emul-libs_src_install() {
for dir in etc/env.d etc/revdep-rebuild ; do
if [[ -d ${S}/${dir} ]] ; then
for f in ${S}/${dir}/* ; do
mv -f $f{,-emul}
done
fi
done
# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null
cp -a ${S}/* ${D}/ || die copying files failed!
}
Re: [gentoo-dev] Google Summer of Code 2007
On Friday 16 February 2007 19:38, Grant Goodyear wrote: Rémi Cardona wrote: [Fri Feb 16 2007, 12:14:31PM CST] To complement the both of you, how about proposing projects to 2 students at the same time and have them work as a team? It's against the rules to have two students working on exactly the same project, or at least it was last year. Perhaps the google people might have some suggestions on this. It seems that they should also be interested in getting value for their money. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpPc3urF9TGA.pgp Description: PGP signature
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
Bryan Østergaard wrote: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). right, we all agree :) B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. every arch team is allowed to keyword kde-meta, just they should not complain about their keywords not being on bumps when they are late. Keyword-ebuild separation allows to clearly show the arch teams that they are responsible and allows the developers not to get into conflict here. It clearly would have avoided the recent conflict. The problem is with ebuild developers like me having no means to get arch teams to keyword stuff yet we are responsible if something fails and we get bugs assigned. [remove kde-meta talk] Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. yeah. A script for removing all ebuilds that are allowed to be removed by policy would be cool. Sadly I don't have one currently :( We can for example also offer x86-only sync trees without all the ebuilds that are only relevant to the other arches. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
Alexander Færøy schrieb: It was discussed at the last council meeting... Proposed by jokey. Thanks. Sorry I did not know about it because there was no summary for the last council meeting. From the log that I read now I cannot clearly define an outcome. I would appreciate to see summaries again for the council. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 03:16:06PM +0100, Stefan Schweizer wrote: Alexander Færøy schrieb: It was discussed at the last council meeting... Proposed by jokey. Thanks. Sorry I did not know about it because there was no summary for the last council meeting. From the log that I read now I cannot clearly define an outcome. The (very clear imho) outcome was that it wasn't going to save any bandwidth at all and would increase used diskspace quite a bit. Bandwidth reduction was jokeys primary goal iirc. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 03:13:00PM +0100, Stefan Schweizer wrote: Bryan Østergaard wrote: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). right, we all agree :) B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. every arch team is allowed to keyword kde-meta, just they should not complain about their keywords not being on bumps when they are late. Of course they should complain about dropped keywords. Policy says to keep ~arch keywords when doing bumps unless there's a very good reason not to (like a complete rewrite or whatever). Keyword-ebuild separation allows to clearly show the arch teams that they are responsible and allows the developers not to get into conflict here. It clearly would have avoided the recent conflict. Arch teams already know what they're responsible for - moving metadata about isn't going to change that at all and it most certainly wouldn't fix flameeyes complaint about having an extra 300 ebuilds in the tree because some arch team are late regarding keywording. The ebuilds would *still* need to be in the tree no matter where we store keyword information so it wouldn't solve it at all. The problem is with ebuild developers like me having no means to get arch teams to keyword stuff yet we are responsible if something fails and we get bugs assigned. Many arch team members have repeatedly stated that ebuild maintainers are free to reassign bugs about old versions to them if you've given the arch team reasonable time to keyword a newer version first so I don't think that argument has much merit to it at all. [remove kde-meta talk] Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. yeah. A script for removing all ebuilds that are allowed to be removed by policy would be cool. Sadly I don't have one currently :( I'm all for removing old junk from the tree but I don't think that can be entirely automated - there's lots of reasons that we might want to keep an older package around even when a newer package is keyworded on all archs. Sometimes we need to test against the older version and sometimes we need to allow people a transition period for config changes for example. So I think a tool listing versions that could possibly be removed would be much better than an automated tool just removing it all without further concerns. We can for example also offer x86-only sync trees without all the ebuilds that are only relevant to the other arches. As an arch team member I think that's a horrible idea tbh. I don't want to waste any time on keeping all the changes from various arch trees in sync with my own arch tree. And from an ebuild maintainers point of view I'd like to know that when I fix a bug it's fixed on all archs. Both things would be broken if we seperate the tree imo and we would also drastically increase the space requirements for rsync mirrors which is quite bad. Having to keep 12 (or however many archs we support) portage trees instead of just one on rsync servers doesn't sound like a good idea imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
George Shapovalov schrieb: a) move all the keywording into profiles (that is remove all KEYWORDS fields from all the ebuild) and disallow package maintainers and other devs (other than arch teams) to touch keywords or b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move granular per-arch settings to profiles the first one + maintainer arch is what I like to have. Other arches can then go up to maintainer arch automatically(with a bot) for ~arch and manually for arch or define their own policies like they want. or something else? Even then I am not sure how either of these is going to work, especially this: The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. normally new versions/packages go directly into ~arch unless they are transiently masked by developer (waiting for release, etc) or are permanently masked live-cvs/svn ones. The particular case is about having new depends in new versions. For example in ghostscript-esp-8.15.3-r1 there is a new dependency on app-text/djvu and mips, arm, s390 and sh do not keyword it. See bug 148945 too. moving keywording only in the arch teams responsibility is the way to go imo because I hate having keywording bugs assigned to my herd where I can do nothing about it. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? it can be automated to do this from the maintainer arch if the arch team wants it. -Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
On Monday 19 February 2007, Bryan Østergaard wrote: That's lame for several different reasons that I'm going to outline below and frankly anybody blowing steam about ~arch keywording the latest version (which ended up as being the goal yesterday) is being extremely silly. i dont add my voice to the discussion because Bryan seems to have covered plenty of what came to my mind -mike pgp44EgELzN4O.pgp Description: PGP signature
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Dňa Mon, 19 Feb 2007 12:34:19 +0100 Bryan Østergaard [EMAIL PROTECTED] napísal: Anyway, here's several reasons why it's lame - I'm sure there's even more good reasons but these should suffer: Another reason would be that it would cripple (even more) the benefit of having all the relevant info in one place - the ebuild. Currently, everything is in the ebuild, except package.masks, which are in profiles. What OP is proposing would increase number of places to look for info from two to two plus number of supported archs. Not good. Please don't improve the current way of defining keywords just because some people got scary CVS conflict messages. Those happen all the time in larger repositories. Kind regards, -- Andrej Kacian ticho at gentoo org Gentoo Linux developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
On 19-02-2007 14:14:18 +0100, Timothy Redaelli wrote:
cp -a ${S}/* ${D}/ || die copying files failed!
For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho
For my understanding, what's wrong with cp -pPR?
--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
On Monday 19 February 2007, Fabian Groffen wrote:
On 19-02-2007 14:14:18 +0100, Timothy Redaelli wrote:
cp -a ${S}/* ${D}/ || die copying files failed!
For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho
For my understanding, what's wrong with cp -pPR?
nothing ... that should be used rather than `rsync -a` which should never be
found in an ebuild/eclass
-mike
pgpOGGWoGXZXi.pgp
Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
Mike Frysinger wrote:
On Monday 19 February 2007, Fabian Groffen wrote:
On 19-02-2007 14:14:18 +0100, Timothy Redaelli wrote:
cp -a ${S}/* ${D}/ || die copying files failed!
For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho
For my understanding, what's wrong with cp -pPR?
nothing ... that should be used rather than `rsync -a` which should never be
found in an ebuild/eclass
cp -pPR does not copy hardlinks iirc, btw i don't think we need it so it
can work :P
--
Timothy `Drizzt` Redaelli - http://dev.gentoo.org/~drizzt/
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence. -- Jeremy S. Anderson
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New emul-libs.eclass
On Mon, 19 Feb 2007 17:05:01 +0100 Timothy Redaelli [EMAIL PROTECTED]
wrote:
| Mike Frysinger wrote:
| On Monday 19 February 2007, Fabian Groffen wrote:
| On 19-02-2007 14:14:18 +0100, Timothy Redaelli wrote:
| cp -a ${S}/* ${D}/ || die copying files failed!
| For future *BSD compatibility (yes i want to use the linux bsd
| emulation for flash, opera, etc) it's better to use rsync -a imho
| For my understanding, what's wrong with cp -pPR?
|
| nothing ... that should be used rather than `rsync -a` which should
| never be found in an ebuild/eclass
|
| cp -pPR does not copy hardlinks iirc, btw i don't think we need it so
| it can work :P
Neither does your package manager. Nor, probably, should it, given how
few filesystems allow hardlinks...
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] mask and force various profile specific USE flags
On Sat, 2007-02-17 at 15:22 -0800, Zac Medico wrote: We can make this change to the profiles immediately because use.mask support has been available for a long time, and use.force is simply ignored by older versions of portage. Thoughts? If this is done, will anyone who makes such changes to their profiles shoot me a .diff for it? I'd like to include this in the release snapshot so it's already done on new installs. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New emul-libs.eclass
Timothy Redaelli wrote:
# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null
Portage should remove blank dirs or am i wrong?
Yes, but only in the unmerge phase it seems, so you it installs them,
then checks whether they are empty and removes them again, which is both
stupid and confusing.
cp -a ${S}/* ${D}/ || die copying files failed!
For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho
I'll use cp -pPr.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, 2007-02-19 at 15:37 +0100, Stefan Schweizer wrote: moving keywording only in the arch teams responsibility is the way to go imo because I hate having keywording bugs assigned to my herd where I can do nothing about it. Uhh... so why *don't* you assign these to the arch teams? Here's a good example... games. We get keyword requests all the time. Sometimes, one of us has the time to test it right there, so we do and we resolve the bug. EVERY other time, we defer it to the arch team, almost immediately. If we're also members of that arch team, we might come back later and do it ourselves, but it's really a job for the arch team, and up to them to either do the work, or decide not to add KEYWORDS and close the bug. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? it can be automated to do this from the maintainer arch if the arch team wants it. When will people get rid of this concept of maintainer arch ? Not all maintainers only use one architecture. Not all ebuild maintainers use the same architecture all the time. When I do a commit, it could be from one of any of *eight* architectures. The number of people using only one architecture is growing smaller. This is especially true for the top 10% who do most of the commits. Go back and look at who those people are, they're the same people that work on *multiple* architectures. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New emul-libs.eclass
Simon Stelling wrote: I'll use cp -pPr. Actually -dpPR, which is what -a is an alias for. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
On Mon, 19 Feb 2007 18:03:36 +0100 Simon Stelling [EMAIL PROTECTED]
wrote:
| Timothy Redaelli wrote:
| # remove void directories
| find ${S} -depth -type d | xargs rmdir 2/dev/null
|
| Portage should remove blank dirs or am i wrong?
|
| Yes, but only in the unmerge phase it seems, so you it installs them,
| then checks whether they are empty and removes them again, which is
| both stupid and confusing.
Not entirely... Think cases where directories in IMAGE are being merged
over non-directories in ROOT.
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
On 19-02-2007 18:12:42 +0100, Simon Stelling wrote: Simon Stelling wrote: I'll use cp -pPr. Actually -dpPR, which is what -a is an alias for. Yes, but -d is a GNU option, and BSD people are after the POSIX only options, hence the -pPR. :) -- Fabian Groffen Gentoo on a different level -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
On Monday 19 February 2007, Simon Stelling wrote: Thanks for any feedback, every use of find | xargs in there should be fixed to use find -print0 | xargs -0 -mike pgpGdDjhf8ch3.pgp Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
Fabian Groffen wrote: I'll use cp -pPr. Actually -dpPR, which is what -a is an alias for. Yes, but -d is a GNU option, and BSD people are after the POSIX only options, hence the -pPR. :) Missed that, Flameeyes just told me about it, so the -d will be dropped again ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
Simon Stelling wrote: ECLASS=emul-libs Not needed any more: [EMAIL PROTECTED] ~ $ grep ECLASS= /usr/portage/eclass/* /usr/portage/eclass/ccc.eclass:#DEBUG_CCC_ECLASS=1 /usr/portage/eclass/xemacs-packages.eclass:ECLASS=xemacs-packages /usr/portage/eclass/x-modular.eclass:FONT_ECLASS= /usr/portage/eclass/x-modular.eclass: FONT_ECLASS=font Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New emul-libs.eclass
Mike Frysinger wrote: every use of find | xargs in there should be fixed to use find -print0 | xargs -0 The second one, yes, that's fixed now. The first one, no, cause egrep wouldn't like it. The xargs -d' ' ensures that \n instead of a simple space is used as delimiter. If some package really installs files with a newline character in its name, well, then that package is just not worth including in emul-packages. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
On Monday 19 February 2007, Simon Stelling wrote: Mike Frysinger wrote: every use of find | xargs in there should be fixed to use find -print0 | xargs -0 The second one, yes, that's fixed now. The first one, no, cause egrep wouldn't like it. The xargs -d' ' ensures that \n instead of a simple space is used as delimiter. If some package really installs files with a newline character in its name, well, then that package is just not worth including in emul-packages. i'd point out that grep does have an option for dealing with NUL delimited data (-z), but that isnt POSIX so the bsd guys would prob complain :P that said, the syntax you're using is ugly: xargs -d' ' replace that with: xargs -d $'\n' -mike pgpbFF7U3vpij.pgp Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
ALLOWED=${ALLOWED:-^${S}/etc/env.d}
If you are using regex here, why don't you use it in find?
find ${S} ! -type d ! -name '*.so*' ! -regex ${ALLOWED} -print0 |
xargs -0 /bin/rm -f
Note that you will need to change ^${S}/etc/env.d to ^${S}/etc/env\.d.* as it
needs to be a full match( btw. you are not escaping a . in your regex )
--
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
On Friday 16 February 2007 19:38, Grant Goodyear wrote: Rémi Cardona wrote: [Fri Feb 16 2007, 12:14:31PM CST] To complement the both of you, how about proposing projects to 2 students at the same time and have them work as a team? It's against the rules to have two students working on exactly the same project, or at least it was last year. Perhaps the google people might have some suggestions on this. It seems that they should also be interested in getting value for their money. Paul I start on tuesday, so I am able to harass leslie for you in person ;) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Coda maintenance? Going once, going twice, ...
... not sold. I'm still looking for someone to take over Coda maintenance, so if you want to take it up or know someone who might, please let me know. For those who don't know, Coda is a distributed filesystem with its origin in AFS2: http://www.coda.cs.cmu.edu/about.html If I can't find anyone soon, I'll remove myself from metadata.xml. net-fs, if you'd rather I replace my name with maintainer-needed, just tell me. Thanks, Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpqNY8mSICwX.pgp Description: PGP signature
Re: [gentoo-dev] Summer of Code - worth repeating?
I agree that we should do it. Looking a the list for 2006, I think we should steer clear of projects that might require significant knowledge of Gentoo Linux internals or that may have a lot of difficult interdependencies and/or coordination. For example, moving to a different revision control system does not, at least on the surface, seem like a project that a single SoC student could pull off, considering the significant amount of coordination required. I think I good way to start 2007 would be to put together an informal guide for how to choose appropriate SoC projects. These guidelines should be geared towards helping to ensure a greater likelihood of rapid progress and successful completion. My list: 1) Should be a specific, focused problem or challenge 2) Should not have a large number of technical inter-dependencies 3) Should not require significant cross-team coordination/project management work 4) Anything that touches core gentoo functionality should be done as a proof of concept, not as an official replacement (changing official core stuff has distro-wide implications which is not suitable for SoC efforts and makes the design stage overly complex - officialness can be considered afterwards if the SoC effort is successful) 5) An emphasis on training and mentoring future Gentoo developers to bring lasting benefits to the project. This means: interesting, fun projects, good experiences are more important than solving incredibly thorny problems. 6) The challenges need not be hard - this is not our money so we need not set artificially high expectations. We should not expect a student with relatively little Gentoo experience to solve challenges that we have struggled to find solutions for. 7) Projects should be achievable by a single person working part-time over 3 months (this *is* summer, after all) and have clearly defined goals for completion. -Daniel On 2/20/07, Christel Dahlskjaer [EMAIL PROTECTED] wrote: Hiya all, Let's do a quick re-cap of Summer of Code '06: Gentoo had 14 project slots, out of these fourteen two were on Gentoo external Gentoo project which I will leave out of the re-cap. That leaves us with twelve projects, four of which were being worked on by at the time current Gentoo developers. Leaving us eight newcomers, out of these eight four has been recruited and I belicve an additional one is in the recruitment queue. Some of the projects have been picked up and are being worked on daily, some we've had problems getting acceptance for from the projects where they would be most suited (Beacon - GDP), and some may have fizzled off and died when SoC ended (be that because the student were no longer involved and didn't feel that they were welcomed into the community post-soc, or be that because it just didn't end up being a small idea turned explosion). Summer of Code 2006 was thrown together practically overnight, we jumped onboard after the deadline, by pure luck, and due to lack of planning ended up with whatever projects people could think up in no time and what mentors felt comfortable mentoring at said time. Based on the timeframe and having to jump into the deep end I'd say SoC was a tremendous success for us, not least as a recruitment tool. And of course, it feels great to put something back into the community. Summer of Code '07 is about to kick off, those of us who participated in one form or another last year are pretty geared up to do it again. This time around we've got a chance to plan better, apply in time.. Should we SoC? Of course we should! Can we think up projects? Do we have willing mentors? Will Google have us once more? (with feeling) Summer of Code itself should be a lot more organised this year, OSPO has put a fair chunk of work into getting things up to speed and has listened to the feedback of both students and mentoring organisations from last year. -- Christel -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
On Monday 19 February 2007, Piotr Jaroszyński wrote: If you are using regex here, why don't you use it in find? because it isnt a POSIX option -mike pgpm4PU4zcDIt.pgp Description: PGP signature
Re: [gentoo-dev] New emul-libs.eclass
Mike Frysinger wrote: replace that with: xargs -d $'\n' aye, that looks way better. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Package removals: net-misc/kssh, sys-fs/captive, net-print/hpoj
# Stefan Schweizer [EMAIL PROTECTED] (19 Feb 2007) # bug 152513 broken on gcc4 and no release since 2002, masked for removal net-misc/kssh # Stefan Schweizer [EMAIL PROTECTED] (07 Nov 2006) # Please use ntfs3g now - it is better. Will be removed someday sys-fs/captive # Stefan Schweizer [EMAIL PROTECTED] (06 Feb 2006) # deprecated - please use net-print/hplip now net-print/hpoj Will remove in one month Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 removal
Unfortunately I didn't find any suitable candidates from the call for help that went out in the GWN recently. I have contacted all applicants explaining how they can improve their skills, build up a series of contributions, and become more likely developer candidates in the future. Unless something changes, gentoo-sources-2.4 will be put in package.mask on March 1st and removed from portage on March 31st. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Slacker archs
It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. I think the first step is to establish what all the problem architectures are. We all know that mips is by far the worst offender, but by how much? Rather than speculating wildly, I decided to make use of adjutrix and wc to find out. So, here we have a table showing just how much mips is a slacker arch: Arch Number of packages where this arch is slacking == m68k 37 ppc-macos 56 sh84 s390 87 arm 120 sparc155 hppa 176 ia64 221 ppc64278 mips 292 ppc 359 alpha361 amd64413 x86 560 As expected, supporting minority archs is leading to tree-wide bloat and huge initial rsync times for users. Clearly something has to be done to protect Gentoo from those useless minority archs! I mean, how many users do we *really* have using amd64 or x86? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
I'm replying here because I couldn't decide whether or not it made more sense to reply to your email, your blog post, your reply to flameeyes blog post, your radio commercial, your television advertisement, or your phone call. The things that this doesn't do (Or if it does it isn't documented) is account for: *packages where there is no stable version on that arch. (Or does adjutrix still suggest keywording.. its unclear) * This doesn't address the initial claim that versions of packages are in the tree waiting on only a mips/lesser supported arch to keyword them. It only says that some arch has keyworded a package stable, and others havn't, this does not show that version N is only in the tree because of arch xyz (which is why I stated that adjutrix doesn't do this). * The numberes themselves could be considdered useless as it only shows packages which have been marked ~ on that arch in the past (not missing keywords)-- Therefore on an arch like x86/amd64 where more packages have been tested, there will be more to stabilize. (I realize that this doesn't really affect the initial claim any, just pointing out how the numbers are not that representative. On 2/19/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. I think the first step is to establish what all the problem architectures are. We all know that mips is by far the worst offender, but by how much? Rather than speculating wildly, I decided to make use of adjutrix and wc to find out. So, here we have a table showing just how much mips is a slacker arch: Arch Number of packages where this arch is slacking == m68k 37 ppc-macos 56 sh84 s390 87 arm 120 sparc155 hppa 176 ia64 221 ppc64278 mips 292 ppc 359 alpha361 amd64413 x86 560 As expected, supporting minority archs is leading to tree-wide bloat and huge initial rsync times for users. Clearly something has to be done to protect Gentoo from those useless minority archs! I mean, how many users do we *really* have using amd64 or x86? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Mon, 19 Feb 2007 22:22:49 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | *packages where there is no stable version on that arch. (Or does | adjutrix still suggest keywording.. its unclear) Which is fine, since that means no tree bloat. | * This doesn't address the initial claim that versions of packages are | in the tree waiting on only a mips/lesser supported arch to keyword | them. It only says that some arch has keyworded a package stable, and | others havn't, this does not show that version N is only in the tree | because of arch xyz (which is why I stated that adjutrix doesn't do | this). adjutrix shows you what you really want to know, as opposed to your ill thought out claim of what you think it should show. The metric, specifically, is packages that have a stable version on this arch that have a better stable version on another arch, which is exactly how one measures tree bloat. If you consider versions only in the tree for one arch (which, incidentally, is ill defined and ambiguous), the figure is even higher in favour of alt archs, and highly rigged against archs that have more packages stable or that stable new versions faster -- thus, your suggestion isn't a fair benchmark, and even though the numbers make my point even better than honest results, it wouldn't be fair or meaningful to wave them around. | * The numberes themselves could be considdered useless as it only | shows packages which have been marked ~ on that arch in the past (not | missing keywords)-- Therefore on an arch like x86/amd64 where more | packages have been tested, there will be more to stabilize. (I realize | that this doesn't really affect the initial claim any, just pointing | out how the numbers are not that representative. Except that the question is one of absolute tree bloat, and that's exactly what the numbers I gave show. The whole mips are slackers thing is blatantly untrue and a distraction from the real issue. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
Brian Harring wrote: [many statistics] Aside from that, aparently props should be given to sparc; seem to be on top of things. Either way, data to chew on. ~harring Much thanks for the stats, Brian, it does help to have extra perspective. And yes, eroyf is doing a heckuva lot to get things keyworded -- I don't think we should drop mips support or anything (heard that suggested elsewhere), unless the MIPS team themselves think it's not doable anymore). The numbers you've shown are a helluva lot better -- more honest in the breakdown -- than the others. These show a lot more of what's really been going on. signature.asc Description: OpenPGP digital signature
